* [PATCH] Fixing package-initialize, adding early init file @ 2017-09-18 21:57 Radon Rosborough 2017-09-19 12:30 ` Stefan Monnier 2017-10-10 16:52 ` Robert Weiner 0 siblings, 2 replies; 838+ messages in thread From: Radon Rosborough @ 2017-09-18 21:57 UTC (permalink / raw) To: emacs-devel [-- Attachment #1: Type: text/plain, Size: 904 bytes --] Hello all, Attached is a preliminary patch for fixing "the package-initialize problem" (see [1] [2] [3]) by adding an early init file. Feedback welcome. In particular, - do we want to try to factor out some common logic in loading the early init file versus the regular init file? - have I broken anything in moving the check for an invalid username earlier in startup.el? what about moving package-initialize earlier? - should `early-init-file' be defined in C? - did I miss any documentation fixes? - have I broken any style guidelines for the repository? Additional question: if we moved forward with this patch, would it make it into Emacs 26.1? Best, Radon Rosborough [1]: https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00154.html [2]: https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00433.html [3]: https://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00023.html [-- Attachment #2: 0001-Add-early-init-file-stop-package-initialize-insertio.patch --] [-- Type: application/octet-stream, Size: 24502 bytes --] From dc8ff75037f90938f1d3eb9676f674aad868c2da Mon Sep 17 00:00:00 2001 From: Radon Rosborough <radon.neon@gmail.com> Date: Sun, 17 Sep 2017 22:17:17 -0700 Subject: [PATCH] Add early init file, stop package-initialize insertion * src/lread.c (Vearly_init_file): New variable, for the filename of the early init file that was loaded. * lisp/startup.el: Load the early init file, if it is found. Move the check for an invalid username to just before that, and move the initialization of the package system to just after. * lisp/emacs-lisp/package.el (package--ensure-init-file): Remove. Burn with fire. Remove related code and documentation. * doc/lispref/os.texi: Document early init file. * doc/lispref/package.texi: Document changes to when package-initialize is called, and advise against calling it in the init file. * doc/emacs/package.texi: Document changes to when package-initialize is called. * doc/misc/org.texi: Don't recommend to call package-initialize in the init file. * etc/NEWS: Document changes to startup and package.el. Discussion on emacs-devel leading up to this change (approximately 150 messages): - https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00154.html - https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00433.html - https://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00023.html --- doc/emacs/package.texi | 28 ++----- doc/lispref/os.texi | 14 ++++ doc/lispref/package.texi | 16 +++- doc/misc/org.texi | 4 +- etc/NEWS | 18 ++++ lisp/emacs-lisp/package.el | 71 +--------------- lisp/startup.el | 204 +++++++++++++++++++++++++++++++++------------ src/lread.c | 9 ++ 8 files changed, 212 insertions(+), 152 deletions(-) diff --git a/doc/emacs/package.texi b/doc/emacs/package.texi index 215f50cb40..bd7cccce6c 100644 --- a/doc/emacs/package.texi +++ b/doc/emacs/package.texi @@ -253,30 +253,16 @@ Package Installation consult the package's help buffer. By default, Emacs also automatically loads all installed packages in -subsequent Emacs sessions. This happens at startup, after processing -the init file (@pxref{Init File}). As an exception, Emacs does not -load packages at startup if invoked with the @samp{-q} or -@samp{--no-init-file} options (@pxref{Initial Options}). +subsequent Emacs sessions. This happens at startup, before processing +the init file but after processing the early init file (@pxref{Early +Init File,,, elisp, The Emacs Lisp Reference Manual}). As an +exception, Emacs does not load packages at startup if invoked with the +@samp{-q} or @samp{--no-init-file} options (@xref{Initial Options}). @vindex package-enable-at-startup To disable automatic package loading, change the variable -@code{package-enable-at-startup} to @code{nil}. - -@findex package-initialize - The reason automatic package loading occurs after loading the init -file is that user options only receive their customized values after -loading the init file, including user options which affect the -packaging system. In some circumstances, you may want to load -packages explicitly in your init file (usually because some other code -in your init file depends on a package). In that case, your init file -should call the function @code{package-initialize}. It is up to you -to ensure that relevant user options, such as @code{package-load-list} -(see below), are set up prior to the @code{package-initialize} call. -This will automatically set @code{package-enable-at-startup} to @code{nil}, to -avoid loading the packages again after processing the init file. -Alternatively, you may choose to completely inhibit package loading at -startup, and invoke the command @kbd{M-x package-initialize} to load -your packages manually. +@code{package-enable-at-startup} to @code{nil}. You must do this in +the early init file. Currently it cannot be done via Customize. @vindex package-load-list For finer control over package loading, you can use the variable diff --git a/doc/lispref/os.texi b/doc/lispref/os.texi index 441fda5d82..062aa28222 100644 --- a/doc/lispref/os.texi +++ b/doc/lispref/os.texi @@ -361,6 +361,7 @@ Init File @cindex init file @cindex @file{.emacs} @cindex @file{init.el} +@cindex @file{early-init.el} When you start Emacs, it normally attempts to load your @dfn{init file}. This is either a file named @file{.emacs} or @file{.emacs.el} @@ -384,6 +385,19 @@ Init File file. If those environment variables are absent, though, Emacs uses your user-id to find your home directory. +@cindex early init file + Emacs also attempts to load a second init file, called the + @dfn{early init file}, if it exists. This is a file named + @file{early-init.el} in a subdirectory named @file{.emacs.d} in your + home directory. The difference is that the early init file is + loaded much earlier during the startup process, so you can use it to + customize some things that are initialized before loading the + regular init file. For example, here you can customize the process + of loading installed packages, by setting variables such as + @var{package-load-list} or + @var{package-enable-at-startup}. @xref{Package Installation,,, + emacs,The GNU Emacs Manual}. + @cindex default init file An Emacs installation may have a @dfn{default init file}, which is a Lisp library named @file{default.el}. Emacs finds this file through diff --git a/doc/lispref/package.texi b/doc/lispref/package.texi index 153ee48741..2e93f29bd2 100644 --- a/doc/lispref/package.texi +++ b/doc/lispref/package.texi @@ -106,10 +106,12 @@ Packaging Basics Whenever Emacs starts up, it automatically calls the function @code{package-initialize} to load installed packages. This is done -after loading the init file and abbrev file (if any) and before -running @code{after-init-hook} (@pxref{Startup Summary}). Automatic -package loading is disabled if the user option -@code{package-enable-at-startup} is @code{nil}. +after loading the early init file, but before loading the early init +file and abbrev file (if any) and before running +@code{after-init-hook} (@pxref{Startup Summary}). Automatic package +loading is disabled if the user option +@code{package-enable-at-startup} is @code{nil}. (Of course, the +setting of this user option must be done in the early init file.) @deffn Command package-initialize &optional no-activate This function initializes Emacs' internal record of which packages are @@ -123,6 +125,12 @@ Packaging Basics The optional argument @var{no-activate}, if non-@code{nil}, causes Emacs to update its record of installed packages without actually loading them; it is for internal use only. + +In most cases, you should not need to call @code{package-initialize}, +as this is done automatically during startup. Simply make sure to put +any code that should run before @code{package-initialize} in the early +init file, and any code that should run after in the primary init +file (@xref{Init File,,, emacs, The GNU Emacs Manual}). @end deffn @node Simple Packages diff --git a/doc/misc/org.texi b/doc/misc/org.texi index ca57501f3d..c487d43a13 100644 --- a/doc/misc/org.texi +++ b/doc/misc/org.texi @@ -891,9 +891,7 @@ Installation been visited, i.e., where no Org built-in function have been loaded. Otherwise autoload Org functions will mess up the installation. -Then, to make sure your Org configuration is taken into account, initialize -the package system with @code{(package-initialize)} in your Emacs init file -before setting any Org option. If you want to use Org's package repository, +If you want to use Org's package repository, check out the @uref{http://orgmode.org/elpa.html, Org ELPA page}. @subsubheading Downloading Org as an archive diff --git a/etc/NEWS b/etc/NEWS index 371cdf686c..80678551c7 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -28,6 +28,24 @@ When you add a new item, use the appropriate mark if you are sure it applies, \f * Startup Changes in Emacs 27.1 ++++ +** Emacs can now be configured using an early init file. +The file is called early-init.el, in `user-emacs-directory'. It is +loaded very early in the startup process: in particular, before +graphical elements such as the tool bar are initialized, and before +the package manager is initialized. + ++++ +** Emacs now initializes package.el before loading the init-file. +This is part of a change intended to eliminate the behavior of +package.el inserting a call to (package-initialize) into the +init-file, which was previously done when Emacs was started. Users +who do not configure package.el variables such as `package-load-list' +and `package-user-dir' need not make any configuration changes. Users +who do configure such variables should place the configuration into +the newly introduced early init file, which is loaded before +package.el is initialized. + \f * Changes in Emacs 27.1 diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el index 8b101c1323..305453a4ba 100644 --- a/lisp/emacs-lisp/package.el +++ b/lisp/emacs-lisp/package.el @@ -1436,16 +1436,11 @@ package-read-all-archive-contents ;; available on disk. (defvar package--initialized nil) -(defvar package--init-file-ensured nil - "Whether we know the init file has package-initialize.") - ;;;###autoload (defun package-initialize (&optional no-activate) "Load Emacs Lisp packages, and activate them. The variable `package-load-list' controls which packages to load. If optional arg NO-ACTIVATE is non-nil, don't activate packages. -If `user-init-file' does not mention `(package-initialize)', add -it to the file. If called as part of loading `user-init-file', set `package-enable-at-startup' to nil, to prevent accidentally loading packages twice. @@ -1454,13 +1449,7 @@ package-initialize taken care of by `package-initialize'." (interactive) (setq package-alist nil) - (if after-init-time - (package--ensure-init-file) - ;; If `package-initialize' is before we finished loading the init - ;; file, it's obvious we don't need to ensure-init. - (setq package--init-file-ensured t - ;; And likely we don't need to run it again after init. - package-enable-at-startup nil)) + (setq package-enable-at-startup nil) (package-load-all-descriptors) (package-read-all-archive-contents) (unless no-activate @@ -1877,64 +1866,6 @@ package-download-transaction using `package-compute-transaction'." (mapc #'package-install-from-archive packages)) -(defun package--ensure-init-file () - "Ensure that the user's init file has `package-initialize'. -`package-initialize' doesn't have to be called, as long as it is -present somewhere in the file, even as a comment. If it is not, -add a call to it along with some explanatory comments." - ;; Don't mess with the init-file from "emacs -Q". - (when (and (stringp user-init-file) - (not package--init-file-ensured) - (file-readable-p user-init-file) - (file-writable-p user-init-file)) - (let* ((buffer (find-buffer-visiting user-init-file)) - buffer-name - (contains-init - (if buffer - (with-current-buffer buffer - (save-excursion - (save-restriction - (widen) - (goto-char (point-min)) - (re-search-forward "(package-initialize\\_>" nil 'noerror)))) - ;; Don't visit the file if we don't have to. - (with-temp-buffer - (insert-file-contents user-init-file) - (goto-char (point-min)) - (re-search-forward "(package-initialize\\_>" nil 'noerror))))) - (unless contains-init - (with-current-buffer (or buffer - (let ((delay-mode-hooks t) - (find-file-visit-truename t)) - (find-file-noselect user-init-file))) - (when buffer - (setq buffer-name (buffer-file-name)) - (set-visited-file-name (file-chase-links user-init-file))) - (save-excursion - (save-restriction - (widen) - (goto-char (point-min)) - (while (and (looking-at-p "[[:blank:]]*\\(;\\|$\\)") - (not (eobp))) - (forward-line 1)) - (insert - "\n" - ";; Added by Package.el. This must come before configurations of\n" - ";; installed packages. Don't delete this line. If you don't want it,\n" - ";; just comment it out by adding a semicolon to the start of the line.\n" - ";; You may delete these explanatory comments.\n" - "(package-initialize)\n") - (unless (looking-at-p "$") - (insert "\n")) - (let ((file-precious-flag t)) - (save-buffer)) - (if buffer - (progn - (set-visited-file-name buffer-name) - (set-buffer-modified-p nil)) - (kill-buffer (current-buffer))))))))) - (setq package--init-file-ensured t)) - ;;;###autoload (defun package-install (pkg &optional dont-select) "Install the package PKG. diff --git a/lisp/startup.el b/lisp/startup.el index 7cf6fee425..56f688e334 100644 --- a/lisp/startup.el +++ b/lisp/startup.el @@ -1021,6 +1021,156 @@ command-line (and command-line-args (setcdr command-line-args args))) + ;; Warn for invalid user name. + (when init-file-user + (if (string-match "[~/:\n]" init-file-user) + (display-warning 'initialization + (format "Invalid user name %s" + init-file-user) + :error) + (if (file-directory-p (expand-file-name + ;; We don't support ~USER on MS-Windows + ;; and MS-DOS except for the current + ;; user, and always load .emacs from + ;; the current user's home directory + ;; (see below). So always check "~", + ;; even if invoked with "-u USER", or + ;; if $USER or $LOGNAME are set to + ;; something different. + (if (memq system-type '(windows-nt ms-dos)) + "~" + (concat "~" init-file-user)))) + nil + (display-warning 'initialization + (format "User %s has no home directory" + (if (equal init-file-user "") + (user-real-login-name) + init-file-user)) + :error)))) + + ;; Load the early init file, if found. + (let ((debug-on-error-from-init-file nil) + (debug-on-error-should-be-set nil) + (debug-on-error-initial (if (eq init-file-debug t) + 'startup + init-file-debug)) + (orig-enable-multibyte (default-value 'enable-multibyte-characters))) + (let ((debug-on-error debug-on-error-initial) + (inner + (lambda () + ;; If no username, don't load the init file. + (when init-file-user + (let ((early-init-file-1 + (expand-file-name + "early-init" + (file-name-as-directory + (concat "~" init-file-user "/.emacs.d"))))) + ;; Setting `user-init-file' to t tells `load' to + ;; store the name of the file that was loaded, if + ;; possible, into `user-init-file'. We're not using + ;; `user-init-file' yet, so we can re-use it here for + ;; the early init file. + (setq user-init-file t) + + ;; Attempt to load the early init file. If it doesn't + ;; exist, do nothing. + (load early-init-file-1 t t) + + ;; If the init file could be loaded, move its + ;; discovered filename from `user-init-file' into + ;; `early-init-file', where it belongs. + (unless (eq user-init-file t) + (setq early-init-file user-init-file) + (when (and early-init-file + (equal (file-name-extension early-init-file) + "elc")) + (let* ((source (file-name-sans-extension early-init-file)) + (alt (concat source ".el"))) + (setq source (cond ((file-exists-p alt) alt) + ((file-exists-p source) source) + (t nil))) + (when source + (when (file-newer-than-file-p source early-init-file) + (message "Warning: %s is newer than %s" + source early-init-file) + (sit-for 1)) + (setq early-init-file source)))))))))) + (if init-file-debug + (funcall inner) + (condition-case error + (progn + (funcall inner) + (setq init-file-had-error nil)) + (error + (display-warning + 'initialization + (format-message "\ +An error occurred while loading `%s':\n\n%s%s%s\n\n\ +To ensure normal operation, you should investigate and remove the +cause of the error in your initialization file. Start Emacs with +the `--debug-init' option to view a complete error backtrace." + ;; Use `user-init-file' here because if + ;; there was an error while loading the + ;; init file, then `early-init-file' may + ;; not have been reassigned; but + ;; `user-init-file' will still be set by + ;; `load'. + user-init-file + (get (car error) 'error-message) + (if (cdr error) ": " "") + (mapconcat (lambda (s) (prin1-to-string s t)) + (cdr error) ", ")) + :warning) + (setq init-file-had-error t)))) + (or (eq debug-on-error debug-on-error-initial) + (setq debug-on-error-should-be-set t + debug-on-error-from-init-file debug-on-error))) + (if debug-on-error-should-be-set + (setq debug-on-error debug-on-error-from-init-file)) + (unless (or (default-value 'enable-multibyte-characters) + (eq orig-enable-multibyte (default-value + 'enable-multibyte-characters))) + ;; Init file changed to unibyte. Reset existing multibyte + ;; buffers (probably *scratch*, *Messages*, *Minibuf-0*). + ;; Arguably this should only be done if they're free of + ;; multibyte characters. + (mapc (lambda (buffer) + (with-current-buffer buffer + (if enable-multibyte-characters + (set-buffer-multibyte nil)))) + (buffer-list)) + ;; Also re-set the language environment in case it was + ;; originally done before unibyte was set and is sensitive to + ;; unibyte (display table, terminal coding system &c). + (set-language-environment current-language-environment))) + + ;; If any package directory exists, initialize the package system. + (and user-init-file + package-enable-at-startup + (catch 'package-dir-found + (let (dirs) + (if (boundp 'package-directory-list) + (setq dirs package-directory-list) + (dolist (f load-path) + (and (stringp f) + (equal (file-name-nondirectory f) "site-lisp") + (push (expand-file-name "elpa" f) dirs)))) + (push (if (boundp 'package-user-dir) + package-user-dir + (locate-user-emacs-file "elpa")) + dirs) + (dolist (dir dirs) + (when (file-directory-p dir) + (dolist (subdir (directory-files dir)) + (when (let ((subdir (expand-file-name subdir dir))) + (and (file-directory-p subdir) + (file-exists-p + (expand-file-name + (package--description-file subdir) + subdir)))) + (throw 'package-dir-found t))))))) + (package-initialize)) + ;; Make sure window system's init file was loaded in loadup.el if ;; using a window system. ;; Initialize the window-system only after processing the command-line @@ -1127,33 +1277,6 @@ command-line ;; the startup screen. (setq inhibit-startup-screen nil) - ;; Warn for invalid user name. - (when init-file-user - (if (string-match "[~/:\n]" init-file-user) - (display-warning 'initialization - (format "Invalid user name %s" - init-file-user) - :error) - (if (file-directory-p (expand-file-name - ;; We don't support ~USER on MS-Windows - ;; and MS-DOS except for the current - ;; user, and always load .emacs from - ;; the current user's home directory - ;; (see below). So always check "~", - ;; even if invoked with "-u USER", or - ;; if $USER or $LOGNAME are set to - ;; something different. - (if (memq system-type '(windows-nt ms-dos)) - "~" - (concat "~" init-file-user)))) - nil - (display-warning 'initialization - (format "User %s has no home directory" - (if (equal init-file-user "") - (user-real-login-name) - init-file-user)) - :error)))) - ;; Load that user's init file, or the default one, or none. (let (debug-on-error-from-init-file debug-on-error-should-be-set @@ -1312,33 +1435,6 @@ command-line (eq face-ignored-fonts old-face-ignored-fonts)) (clear-face-cache))) - ;; If any package directory exists, initialize the package system. - (and user-init-file - package-enable-at-startup - (catch 'package-dir-found - (let (dirs) - (if (boundp 'package-directory-list) - (setq dirs package-directory-list) - (dolist (f load-path) - (and (stringp f) - (equal (file-name-nondirectory f) "site-lisp") - (push (expand-file-name "elpa" f) dirs)))) - (push (if (boundp 'package-user-dir) - package-user-dir - (locate-user-emacs-file "elpa")) - dirs) - (dolist (dir dirs) - (when (file-directory-p dir) - (dolist (subdir (directory-files dir)) - (when (let ((subdir (expand-file-name subdir dir))) - (and (file-directory-p subdir) - (file-exists-p - (expand-file-name - (package--description-file subdir) - subdir)))) - (throw 'package-dir-found t))))))) - (package-initialize)) - (setq after-init-time (current-time)) ;; Display any accumulated warnings after all functions in ;; `after-init-hook' like `desktop-read' have finalized possible diff --git a/src/lread.c b/src/lread.c index 6bc93b1481..b4823956e7 100644 --- a/src/lread.c +++ b/src/lread.c @@ -4910,6 +4910,15 @@ While Emacs loads and evaluates the init file, value is the real name of the file, regardless of whether or not it has the `.elc' extension. */); Vuser_init_file = Qnil; + DEFVAR_LISP ("early-init-file", Vearly_init_file, + doc: /* File name, including directory, of user's early init file. +If the file loaded had extension `.elc', and the corresponding source file +exists, this variable contains the name of source file, suitable for use +by functions like `custom-save-all' which edit the init file. +While Emacs loads and evaluates the init file, value is the real name +of the file, regardless of whether or not it has the `.elc' extension. */); + Vearly_init_file = Qnil; + DEFVAR_LISP ("current-load-list", Vcurrent_load_list, doc: /* Used for internal purposes by `load'. */); Vcurrent_load_list = Qnil; -- 2.13.3 ^ permalink raw reply related [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2017-09-18 21:57 [PATCH] Fixing package-initialize, adding early init file Radon Rosborough @ 2017-09-19 12:30 ` Stefan Monnier 2017-09-25 16:27 ` Radon Rosborough 2017-10-10 16:52 ` Robert Weiner 1 sibling, 1 reply; 838+ messages in thread From: Stefan Monnier @ 2017-09-19 12:30 UTC (permalink / raw) To: emacs-devel > Attached is a preliminary patch for fixing "the package-initialize > problem" (see [1] [2] [3]) by adding an early init file. Feedback > welcome. In particular, Thanks, comments below. > ;;;###autoload > (defun package-initialize (&optional no-activate) [...] > + (setq package-enable-at-startup nil) BTW, in a subsequent patch we could rename this to package-initialized, so the name reflects what the variable contains rather than what it's used for. > + DEFVAR_LISP ("early-init-file", Vearly_init_file, > + doc: /* File name, including directory, of user's early init file. > +If the file loaded had extension `.elc', and the corresponding source file > +exists, this variable contains the name of source file, suitable for use > +by functions like `custom-save-all' which edit the init file. > +While Emacs loads and evaluates the init file, value is the real name > +of the file, regardless of whether or not it has the `.elc' extension. */); > + Vearly_init_file = Qnil; This is not used from C code, so make it a plain old defvar in startup.el. I haven't yet looked at the startup.el part, sorry. Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2017-09-19 12:30 ` Stefan Monnier @ 2017-09-25 16:27 ` Radon Rosborough 2017-09-25 16:54 ` John Wiegley ` (2 more replies) 0 siblings, 3 replies; 838+ messages in thread From: Radon Rosborough @ 2017-09-25 16:27 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel [-- Attachment #1.1: Type: text/plain, Size: 534 bytes --] > BTW, in a subsequent patch we could rename this to > package-initialized, so the name reflects what the variable contains > rather than what it's used for. I don't think that's a good idea, since the most common usage of this variable will be (setq package-initialized nil) in the early init file, and that doesn't make much sense from a readability perspective (are we asserting that package.el wasn't initialized?). > This is not used from C code, so make it a plain old defvar in > startup.el. Done. New patch attached. [-- Attachment #1.2: Type: text/html, Size: 810 bytes --] [-- Attachment #2: 0001-Add-early-init-file-stop-package-initialize-insertio.patch --] [-- Type: application/octet-stream, Size: 24190 bytes --] From 9d2e25b8c7c0f11fc8e5fb46047701d43e69af6f Mon Sep 17 00:00:00 2001 From: Radon Rosborough <radon.neon@gmail.com> Date: Sun, 17 Sep 2017 22:17:17 -0700 Subject: [PATCH] Add early init file, stop package-initialize insertion * lisp/startup.el: New variable `early-init-file', for the filename of the early init file that was loaded. Load the early init file, if it is found. Move the check for an invalid username to just before that, and move the initialization of the package system to just after. * lisp/emacs-lisp/package.el (package--ensure-init-file): Remove. Burn with fire. Remove related code and documentation. * doc/lispref/os.texi: Document early init file. * doc/lispref/package.texi: Document changes to when package-initialize is called, and advise against calling it in the init file. * doc/emacs/package.texi: Document changes to when package-initialize is called. * doc/misc/org.texi: Don't recommend to call package-initialize in the init file. * etc/NEWS: Document changes to startup and package.el. Discussion on emacs-devel leading up to this change (approximately 150 messages): - https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00154.html - https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00433.html - https://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00023.html --- doc/emacs/package.texi | 28 ++---- doc/lispref/os.texi | 14 +++ doc/lispref/package.texi | 16 +++- doc/misc/org.texi | 4 +- etc/NEWS | 18 ++++ lisp/emacs-lisp/package.el | 71 +-------------- lisp/startup.el | 213 +++++++++++++++++++++++++++++++++------------ 7 files changed, 212 insertions(+), 152 deletions(-) diff --git a/doc/emacs/package.texi b/doc/emacs/package.texi index 215f50cb40..bd7cccce6c 100644 --- a/doc/emacs/package.texi +++ b/doc/emacs/package.texi @@ -253,30 +253,16 @@ Package Installation consult the package's help buffer. By default, Emacs also automatically loads all installed packages in -subsequent Emacs sessions. This happens at startup, after processing -the init file (@pxref{Init File}). As an exception, Emacs does not -load packages at startup if invoked with the @samp{-q} or -@samp{--no-init-file} options (@pxref{Initial Options}). +subsequent Emacs sessions. This happens at startup, before processing +the init file but after processing the early init file (@pxref{Early +Init File,,, elisp, The Emacs Lisp Reference Manual}). As an +exception, Emacs does not load packages at startup if invoked with the +@samp{-q} or @samp{--no-init-file} options (@xref{Initial Options}). @vindex package-enable-at-startup To disable automatic package loading, change the variable -@code{package-enable-at-startup} to @code{nil}. - -@findex package-initialize - The reason automatic package loading occurs after loading the init -file is that user options only receive their customized values after -loading the init file, including user options which affect the -packaging system. In some circumstances, you may want to load -packages explicitly in your init file (usually because some other code -in your init file depends on a package). In that case, your init file -should call the function @code{package-initialize}. It is up to you -to ensure that relevant user options, such as @code{package-load-list} -(see below), are set up prior to the @code{package-initialize} call. -This will automatically set @code{package-enable-at-startup} to @code{nil}, to -avoid loading the packages again after processing the init file. -Alternatively, you may choose to completely inhibit package loading at -startup, and invoke the command @kbd{M-x package-initialize} to load -your packages manually. +@code{package-enable-at-startup} to @code{nil}. You must do this in +the early init file. Currently it cannot be done via Customize. @vindex package-load-list For finer control over package loading, you can use the variable diff --git a/doc/lispref/os.texi b/doc/lispref/os.texi index 441fda5d82..062aa28222 100644 --- a/doc/lispref/os.texi +++ b/doc/lispref/os.texi @@ -361,6 +361,7 @@ Init File @cindex init file @cindex @file{.emacs} @cindex @file{init.el} +@cindex @file{early-init.el} When you start Emacs, it normally attempts to load your @dfn{init file}. This is either a file named @file{.emacs} or @file{.emacs.el} @@ -384,6 +385,19 @@ Init File file. If those environment variables are absent, though, Emacs uses your user-id to find your home directory. +@cindex early init file + Emacs also attempts to load a second init file, called the + @dfn{early init file}, if it exists. This is a file named + @file{early-init.el} in a subdirectory named @file{.emacs.d} in your + home directory. The difference is that the early init file is + loaded much earlier during the startup process, so you can use it to + customize some things that are initialized before loading the + regular init file. For example, here you can customize the process + of loading installed packages, by setting variables such as + @var{package-load-list} or + @var{package-enable-at-startup}. @xref{Package Installation,,, + emacs,The GNU Emacs Manual}. + @cindex default init file An Emacs installation may have a @dfn{default init file}, which is a Lisp library named @file{default.el}. Emacs finds this file through diff --git a/doc/lispref/package.texi b/doc/lispref/package.texi index 153ee48741..2e93f29bd2 100644 --- a/doc/lispref/package.texi +++ b/doc/lispref/package.texi @@ -106,10 +106,12 @@ Packaging Basics Whenever Emacs starts up, it automatically calls the function @code{package-initialize} to load installed packages. This is done -after loading the init file and abbrev file (if any) and before -running @code{after-init-hook} (@pxref{Startup Summary}). Automatic -package loading is disabled if the user option -@code{package-enable-at-startup} is @code{nil}. +after loading the early init file, but before loading the early init +file and abbrev file (if any) and before running +@code{after-init-hook} (@pxref{Startup Summary}). Automatic package +loading is disabled if the user option +@code{package-enable-at-startup} is @code{nil}. (Of course, the +setting of this user option must be done in the early init file.) @deffn Command package-initialize &optional no-activate This function initializes Emacs' internal record of which packages are @@ -123,6 +125,12 @@ Packaging Basics The optional argument @var{no-activate}, if non-@code{nil}, causes Emacs to update its record of installed packages without actually loading them; it is for internal use only. + +In most cases, you should not need to call @code{package-initialize}, +as this is done automatically during startup. Simply make sure to put +any code that should run before @code{package-initialize} in the early +init file, and any code that should run after in the primary init +file (@xref{Init File,,, emacs, The GNU Emacs Manual}). @end deffn @node Simple Packages diff --git a/doc/misc/org.texi b/doc/misc/org.texi index ca57501f3d..c487d43a13 100644 --- a/doc/misc/org.texi +++ b/doc/misc/org.texi @@ -891,9 +891,7 @@ Installation been visited, i.e., where no Org built-in function have been loaded. Otherwise autoload Org functions will mess up the installation. -Then, to make sure your Org configuration is taken into account, initialize -the package system with @code{(package-initialize)} in your Emacs init file -before setting any Org option. If you want to use Org's package repository, +If you want to use Org's package repository, check out the @uref{http://orgmode.org/elpa.html, Org ELPA page}. @subsubheading Downloading Org as an archive diff --git a/etc/NEWS b/etc/NEWS index 371cdf686c..80678551c7 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -28,6 +28,24 @@ When you add a new item, use the appropriate mark if you are sure it applies, \f * Startup Changes in Emacs 27.1 ++++ +** Emacs can now be configured using an early init file. +The file is called early-init.el, in `user-emacs-directory'. It is +loaded very early in the startup process: in particular, before +graphical elements such as the tool bar are initialized, and before +the package manager is initialized. + ++++ +** Emacs now initializes package.el before loading the init-file. +This is part of a change intended to eliminate the behavior of +package.el inserting a call to (package-initialize) into the +init-file, which was previously done when Emacs was started. Users +who do not configure package.el variables such as `package-load-list' +and `package-user-dir' need not make any configuration changes. Users +who do configure such variables should place the configuration into +the newly introduced early init file, which is loaded before +package.el is initialized. + \f * Changes in Emacs 27.1 diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el index 8b101c1323..305453a4ba 100644 --- a/lisp/emacs-lisp/package.el +++ b/lisp/emacs-lisp/package.el @@ -1436,16 +1436,11 @@ package-read-all-archive-contents ;; available on disk. (defvar package--initialized nil) -(defvar package--init-file-ensured nil - "Whether we know the init file has package-initialize.") - ;;;###autoload (defun package-initialize (&optional no-activate) "Load Emacs Lisp packages, and activate them. The variable `package-load-list' controls which packages to load. If optional arg NO-ACTIVATE is non-nil, don't activate packages. -If `user-init-file' does not mention `(package-initialize)', add -it to the file. If called as part of loading `user-init-file', set `package-enable-at-startup' to nil, to prevent accidentally loading packages twice. @@ -1454,13 +1449,7 @@ package-initialize taken care of by `package-initialize'." (interactive) (setq package-alist nil) - (if after-init-time - (package--ensure-init-file) - ;; If `package-initialize' is before we finished loading the init - ;; file, it's obvious we don't need to ensure-init. - (setq package--init-file-ensured t - ;; And likely we don't need to run it again after init. - package-enable-at-startup nil)) + (setq package-enable-at-startup nil) (package-load-all-descriptors) (package-read-all-archive-contents) (unless no-activate @@ -1877,64 +1866,6 @@ package-download-transaction using `package-compute-transaction'." (mapc #'package-install-from-archive packages)) -(defun package--ensure-init-file () - "Ensure that the user's init file has `package-initialize'. -`package-initialize' doesn't have to be called, as long as it is -present somewhere in the file, even as a comment. If it is not, -add a call to it along with some explanatory comments." - ;; Don't mess with the init-file from "emacs -Q". - (when (and (stringp user-init-file) - (not package--init-file-ensured) - (file-readable-p user-init-file) - (file-writable-p user-init-file)) - (let* ((buffer (find-buffer-visiting user-init-file)) - buffer-name - (contains-init - (if buffer - (with-current-buffer buffer - (save-excursion - (save-restriction - (widen) - (goto-char (point-min)) - (re-search-forward "(package-initialize\\_>" nil 'noerror)))) - ;; Don't visit the file if we don't have to. - (with-temp-buffer - (insert-file-contents user-init-file) - (goto-char (point-min)) - (re-search-forward "(package-initialize\\_>" nil 'noerror))))) - (unless contains-init - (with-current-buffer (or buffer - (let ((delay-mode-hooks t) - (find-file-visit-truename t)) - (find-file-noselect user-init-file))) - (when buffer - (setq buffer-name (buffer-file-name)) - (set-visited-file-name (file-chase-links user-init-file))) - (save-excursion - (save-restriction - (widen) - (goto-char (point-min)) - (while (and (looking-at-p "[[:blank:]]*\\(;\\|$\\)") - (not (eobp))) - (forward-line 1)) - (insert - "\n" - ";; Added by Package.el. This must come before configurations of\n" - ";; installed packages. Don't delete this line. If you don't want it,\n" - ";; just comment it out by adding a semicolon to the start of the line.\n" - ";; You may delete these explanatory comments.\n" - "(package-initialize)\n") - (unless (looking-at-p "$") - (insert "\n")) - (let ((file-precious-flag t)) - (save-buffer)) - (if buffer - (progn - (set-visited-file-name buffer-name) - (set-buffer-modified-p nil)) - (kill-buffer (current-buffer))))))))) - (setq package--init-file-ensured t)) - ;;;###autoload (defun package-install (pkg &optional dont-select) "Install the package PKG. diff --git a/lisp/startup.el b/lisp/startup.el index 7cf6fee425..52fd1f9cf5 100644 --- a/lisp/startup.el +++ b/lisp/startup.el @@ -312,6 +312,15 @@ inhibit-startup-hooks Currently this applies to: `emacs-startup-hook', `term-setup-hook', and `window-setup-hook'.") +(defvar early-init-file nil + "File name, including directory, of user's early init file. +If the file loaded had extension `.elc', and the corresponding +source file exists, this variable contains the name of source +file, suitable for use by functions like `custom-save-all' which +edit the init file. While Emacs loads and evaluates the init +file, value is the real name of the file, regardless of whether +or not it has the `.elc' extension.") + (defvar keyboard-type nil "The brand of keyboard you are using. This variable is used to define the proper function and keypad @@ -1021,6 +1030,156 @@ command-line (and command-line-args (setcdr command-line-args args))) + ;; Warn for invalid user name. + (when init-file-user + (if (string-match "[~/:\n]" init-file-user) + (display-warning 'initialization + (format "Invalid user name %s" + init-file-user) + :error) + (if (file-directory-p (expand-file-name + ;; We don't support ~USER on MS-Windows + ;; and MS-DOS except for the current + ;; user, and always load .emacs from + ;; the current user's home directory + ;; (see below). So always check "~", + ;; even if invoked with "-u USER", or + ;; if $USER or $LOGNAME are set to + ;; something different. + (if (memq system-type '(windows-nt ms-dos)) + "~" + (concat "~" init-file-user)))) + nil + (display-warning 'initialization + (format "User %s has no home directory" + (if (equal init-file-user "") + (user-real-login-name) + init-file-user)) + :error)))) + + ;; Load the early init file, if found. + (let ((debug-on-error-from-init-file nil) + (debug-on-error-should-be-set nil) + (debug-on-error-initial (if (eq init-file-debug t) + 'startup + init-file-debug)) + (orig-enable-multibyte (default-value 'enable-multibyte-characters))) + (let ((debug-on-error debug-on-error-initial) + (inner + (lambda () + ;; If no username, don't load the init file. + (when init-file-user + (let ((early-init-file-1 + (expand-file-name + "early-init" + (file-name-as-directory + (concat "~" init-file-user "/.emacs.d"))))) + ;; Setting `user-init-file' to t tells `load' to + ;; store the name of the file that was loaded, if + ;; possible, into `user-init-file'. We're not using + ;; `user-init-file' yet, so we can re-use it here for + ;; the early init file. + (setq user-init-file t) + + ;; Attempt to load the early init file. If it doesn't + ;; exist, do nothing. + (load early-init-file-1 t t) + + ;; If the init file could be loaded, move its + ;; discovered filename from `user-init-file' into + ;; `early-init-file', where it belongs. + (unless (eq user-init-file t) + (setq early-init-file user-init-file) + (when (and early-init-file + (equal (file-name-extension early-init-file) + "elc")) + (let* ((source (file-name-sans-extension early-init-file)) + (alt (concat source ".el"))) + (setq source (cond ((file-exists-p alt) alt) + ((file-exists-p source) source) + (t nil))) + (when source + (when (file-newer-than-file-p source early-init-file) + (message "Warning: %s is newer than %s" + source early-init-file) + (sit-for 1)) + (setq early-init-file source)))))))))) + (if init-file-debug + (funcall inner) + (condition-case error + (progn + (funcall inner) + (setq init-file-had-error nil)) + (error + (display-warning + 'initialization + (format-message "\ +An error occurred while loading `%s':\n\n%s%s%s\n\n\ +To ensure normal operation, you should investigate and remove the +cause of the error in your initialization file. Start Emacs with +the `--debug-init' option to view a complete error backtrace." + ;; Use `user-init-file' here because if + ;; there was an error while loading the + ;; init file, then `early-init-file' may + ;; not have been reassigned; but + ;; `user-init-file' will still be set by + ;; `load'. + user-init-file + (get (car error) 'error-message) + (if (cdr error) ": " "") + (mapconcat (lambda (s) (prin1-to-string s t)) + (cdr error) ", ")) + :warning) + (setq init-file-had-error t)))) + (or (eq debug-on-error debug-on-error-initial) + (setq debug-on-error-should-be-set t + debug-on-error-from-init-file debug-on-error))) + (if debug-on-error-should-be-set + (setq debug-on-error debug-on-error-from-init-file)) + (unless (or (default-value 'enable-multibyte-characters) + (eq orig-enable-multibyte (default-value + 'enable-multibyte-characters))) + ;; Init file changed to unibyte. Reset existing multibyte + ;; buffers (probably *scratch*, *Messages*, *Minibuf-0*). + ;; Arguably this should only be done if they're free of + ;; multibyte characters. + (mapc (lambda (buffer) + (with-current-buffer buffer + (if enable-multibyte-characters + (set-buffer-multibyte nil)))) + (buffer-list)) + ;; Also re-set the language environment in case it was + ;; originally done before unibyte was set and is sensitive to + ;; unibyte (display table, terminal coding system &c). + (set-language-environment current-language-environment))) + + ;; If any package directory exists, initialize the package system. + (and user-init-file + package-enable-at-startup + (catch 'package-dir-found + (let (dirs) + (if (boundp 'package-directory-list) + (setq dirs package-directory-list) + (dolist (f load-path) + (and (stringp f) + (equal (file-name-nondirectory f) "site-lisp") + (push (expand-file-name "elpa" f) dirs)))) + (push (if (boundp 'package-user-dir) + package-user-dir + (locate-user-emacs-file "elpa")) + dirs) + (dolist (dir dirs) + (when (file-directory-p dir) + (dolist (subdir (directory-files dir)) + (when (let ((subdir (expand-file-name subdir dir))) + (and (file-directory-p subdir) + (file-exists-p + (expand-file-name + (package--description-file subdir) + subdir)))) + (throw 'package-dir-found t))))))) + (package-initialize)) + ;; Make sure window system's init file was loaded in loadup.el if ;; using a window system. ;; Initialize the window-system only after processing the command-line @@ -1127,33 +1286,6 @@ command-line ;; the startup screen. (setq inhibit-startup-screen nil) - ;; Warn for invalid user name. - (when init-file-user - (if (string-match "[~/:\n]" init-file-user) - (display-warning 'initialization - (format "Invalid user name %s" - init-file-user) - :error) - (if (file-directory-p (expand-file-name - ;; We don't support ~USER on MS-Windows - ;; and MS-DOS except for the current - ;; user, and always load .emacs from - ;; the current user's home directory - ;; (see below). So always check "~", - ;; even if invoked with "-u USER", or - ;; if $USER or $LOGNAME are set to - ;; something different. - (if (memq system-type '(windows-nt ms-dos)) - "~" - (concat "~" init-file-user)))) - nil - (display-warning 'initialization - (format "User %s has no home directory" - (if (equal init-file-user "") - (user-real-login-name) - init-file-user)) - :error)))) - ;; Load that user's init file, or the default one, or none. (let (debug-on-error-from-init-file debug-on-error-should-be-set @@ -1312,33 +1444,6 @@ command-line (eq face-ignored-fonts old-face-ignored-fonts)) (clear-face-cache))) - ;; If any package directory exists, initialize the package system. - (and user-init-file - package-enable-at-startup - (catch 'package-dir-found - (let (dirs) - (if (boundp 'package-directory-list) - (setq dirs package-directory-list) - (dolist (f load-path) - (and (stringp f) - (equal (file-name-nondirectory f) "site-lisp") - (push (expand-file-name "elpa" f) dirs)))) - (push (if (boundp 'package-user-dir) - package-user-dir - (locate-user-emacs-file "elpa")) - dirs) - (dolist (dir dirs) - (when (file-directory-p dir) - (dolist (subdir (directory-files dir)) - (when (let ((subdir (expand-file-name subdir dir))) - (and (file-directory-p subdir) - (file-exists-p - (expand-file-name - (package--description-file subdir) - subdir)))) - (throw 'package-dir-found t))))))) - (package-initialize)) - (setq after-init-time (current-time)) ;; Display any accumulated warnings after all functions in ;; `after-init-hook' like `desktop-read' have finalized possible -- 2.14.1 ^ permalink raw reply related [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2017-09-25 16:27 ` Radon Rosborough @ 2017-09-25 16:54 ` John Wiegley 2017-09-25 19:38 ` Radon Rosborough 2017-09-25 16:58 ` Stefan Monnier 2017-10-09 23:17 ` Radon Rosborough 2 siblings, 1 reply; 838+ messages in thread From: John Wiegley @ 2017-09-25 16:54 UTC (permalink / raw) To: Radon Rosborough; +Cc: Stefan Monnier, emacs-devel >>>>> "RR" == Radon Rosborough <radon.neon@gmail.com> writes: RR> Done. New patch attached. This seems like a lot of changes that add new complications to the startup of Emacs. Since I don't have time just now to review those 150 messages, may I please ask for an executive summary to motivate this change? -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2017-09-25 16:54 ` John Wiegley @ 2017-09-25 19:38 ` Radon Rosborough 2017-09-25 21:23 ` Mark Oteiza 0 siblings, 1 reply; 838+ messages in thread From: Radon Rosborough @ 2017-09-25 19:38 UTC (permalink / raw) To: jwiegley; +Cc: Stefan Monnier, emacs-devel > This seems like a lot of changes that add new complications to the > startup of Emacs. Since I don't have time just now to review those > 150 messages, may I please ask for an executive summary to motivate > this change? You could read [1] for an explanation of what the problem is, and [2] for a list of the different ways people have proposed to solve it. But I will summarize again: * Currently, Emacs modifies the init-file to add (package-initialize) to it when Emacs starts. This has many disadvantages [1] which I'm not going to rehash here. * There are many proposals [2] on how to make package.el work out of the box without requiring Emacs to modify the init-file. These all have practical disadvantages, except for the proposal to add an early init file, which solves the package.el problem with essentially no disadvantages, and furthermore solves several other problems at the same time (for example, people having no way to disable the menu bar before it is initialized the first time). You can disagree with the above two points, but they were the outcome of the aforementioned 150 emails, and everybody seems to agree that this is the best approach. The only difficulty is actually making the relevant changes to startup.el, which are honestly pretty small in the grand scheme of things. > new complications The only new code is to load an additional init-file. It's definitely a new complication, but I don't think it's that bad. The other changes to startup.el are to add a new variable, and move the (package-initialize) call and the check for an invalid user name to a bit earlier. Sure, we need to test it thoroughly, but it's certainly not *complicated*. [1]: https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00154.html [2]: https://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00023.html ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2017-09-25 19:38 ` Radon Rosborough @ 2017-09-25 21:23 ` Mark Oteiza 2017-09-25 22:16 ` Radon Rosborough 0 siblings, 1 reply; 838+ messages in thread From: Mark Oteiza @ 2017-09-25 21:23 UTC (permalink / raw) To: Radon Rosborough; +Cc: jwiegley, Stefan Monnier, emacs-devel Radon Rosborough <radon.neon@gmail.com> writes: >> This seems like a lot of changes that add new complications to the >> startup of Emacs. Since I don't have time just now to review those >> 150 messages, may I please ask for an executive summary to motivate >> this change? > > You could read [1] for an explanation of what the problem is, and [2] > for a list of the different ways people have proposed to solve it. But > I will summarize again: > > * Currently, Emacs modifies the init-file to add (package-initialize) > to it when Emacs starts. This has many disadvantages [1] which I'm > not going to rehash here. > * There are many proposals [2] on how to make package.el work out of > the box without requiring Emacs to modify the init-file. These all > have practical disadvantages, except for the proposal to add an > early init file, which solves the package.el problem I haven't seen one place where the problem_s_ involved have been clearly articulated, and still this patch does not improve any of the places where user facing documentation was lacking in the first place, and still requires the user to not only understand the forms that must be in an init file, but now there is one more init file for the user to manage. The whole discussion and push for a "solution" is predicated on users who can't be bothered to do things correctly _not_ having to do any configuration. This patch does not improve things in this regard, and frankly I don't see that predicate as a good one for devising a solution. At least it explains how we ended up with package--ensure-init-file. > with > essentially no disadvantages, and furthermore solves several other > problems at the same time (for example, people having no way to > disable the menu bar before it is initialized the first time). > > You can disagree with the above two points, but they were the outcome > of the aforementioned 150 emails, and everybody seems to agree that > this is the best approach. The only difficulty is actually making the > relevant changes to startup.el, which are honestly pretty small in the > grand scheme of things. I suppose it's time I pipe up and indicate I vehemently oppose this change. AIUI it still breaks existing config of package-archives, package-load-list, etc, which is something the incumbent solution also breaks. The only proposal I can support at this time is reverting the incumbent solution, yet none from the maintainership is willing to entertain the idea. >> new complications > > The only new code is to load an additional init-file. It's definitely > a new complication, but I don't think it's that bad. I think adding another init file is unacceptable. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2017-09-25 21:23 ` Mark Oteiza @ 2017-09-25 22:16 ` Radon Rosborough 2017-09-25 23:15 ` Mark Oteiza 0 siblings, 1 reply; 838+ messages in thread From: Radon Rosborough @ 2017-09-25 22:16 UTC (permalink / raw) To: Mark Oteiza; +Cc: jwiegley, Stefan Monnier, emacs-devel > I haven't seen one place where the problem_s_ involved have been > clearly articulated As for the problems with the current situation, check out [1] and also the section for Proposal A in [2]. But again, I'll re-summarize: * Emacs modifies the init-file automatically, without asking the user. * If the user has set any variables related to package.el in their init-file, then Emacs will modify the init-file to do the wrong thing! Unless by "problems involved" you meant more generally, for all the different proposals? That is exactly what [2] was intended to cover; could you clarify what exactly you would like articulated that hasn't been already? > this patch does not improve any of the places where user facing > documentation was lacking in the first place Actually, I'd disagree. I think this patch improves the situation, not by adding more documentation, but by reducing complexity and therefore reducing the need for additional documentation. In particular, we no longer need to document the placement of (package-initialize) in the init-file, as such placement is no longer necessary. > requires the user to not only understand the forms that must be in > an init file Could you clarify what you mean by this? This patch has the effect that users can put package configuration right into their init-file, or use Custom to achieve the same, without having to know anything about the package system. If on the other hand "forms" is referring to 'setq' forms that customize the package system itself, then indeed, users must know to put them into a different init-file. However, I'd argue that this isn't much worse than the current situation, where users must know to put them *before* (package-initialize), and they must also know that Emacs will put (package-initialize) in the wrong place with regard to these customizations. > The whole discussion and push for a "solution" is predicated on > users who can't be bothered to do things correctly _not_ having to > do any configuration. This patch does not improve things in this > regard Correct. The current behavior is that things work out of the box, and this patch *maintains* that behavior. Since things already work out of the box, I don't see how you expect this patch to somehow improve that particular aspect any further. What this patch accomplishes is eliminating the problems inherent in automatic modification of the init-file, *without* losing the goal of the package system working out of the box. > The whole discussion and push for a "solution" is predicated on > users who can't be bothered to do things correctly _not_ having to > do any configuration [...] and frankly I don't see that predicate as > a good one for devising a solution. The goal is that when someone uses M-x package-install to install a package, and then they paste some Lisp code from the project's README into their init-file, then it works as expected. I think this is desirable behavior, and I think most everyone else thinks this is desirable behavior as well. That's why the current solution was put in in the first place, because people really wanted that use case to "just work". This patch achieves that same goal in a better way. > AIUI it still breaks existing config of package-archives, > package-load-list, etc, which is something the incumbent solution > also breaks. Correct, but here is the important point: it will only do so *once*, when people upgrade to Emacs 26. As opposed to the current solution, which breaks existing config every time (package-initialize) is inserted, which may happen many times for a given user. So this patch is a definite improvement. > The only proposal I can support at this time is reverting the > incumbent solution, yet none from the maintainership is willing to > entertain the idea. That's because it would result in the built-in package manager not working out of the box, which would be embarrassing from a UX perspective. That's the whole *point* of having a built-in package manager: that it works right away without additional setup. > I think adding another init file is unacceptable. Why? (Especially given that being able to run code before the first graphical frame is initialized would be super useful for lots of reasons, entirely separate from the package system.) [1]: https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00154.html [2]: https://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00023.html ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2017-09-25 22:16 ` Radon Rosborough @ 2017-09-25 23:15 ` Mark Oteiza 2017-09-26 3:00 ` Radon Rosborough 2017-09-29 10:22 ` Eli Zaretskii 0 siblings, 2 replies; 838+ messages in thread From: Mark Oteiza @ 2017-09-25 23:15 UTC (permalink / raw) To: Radon Rosborough; +Cc: jwiegley, Stefan Monnier, emacs-devel On 25/09/17 at 10:16pm, Radon Rosborough wrote: > > I haven't seen one place where the problem_s_ involved have been > > clearly articulated > > Unless by "problems involved" you meant more generally, for all the > different proposals? That is exactly what [2] was intended to cover; > could you clarify what exactly you would like articulated that hasn't > been already? I meant more explicitly--each of these use cases should be documented with examples. While the manual in its current state does explain things, it can be better. > > this patch does not improve any of the places where user facing > > documentation was lacking in the first place > > Actually, I'd disagree. I think this patch improves the situation, not > by adding more documentation, but by reducing complexity and therefore > reducing the need for additional documentation. > > In particular, we no longer need to document the placement of > (package-initialize) in the init-file, as such placement is no longer > necessary. The only documentation I see is in NEWS and the manual, which is where the old documentation was. > > requires the user to not only understand the forms that must be in > > an init file > > Could you clarify what you mean by this? This patch has the effect > that users can put package configuration right into their init-file, > or use Custom to achieve the same, without having to know anything > about the package system. At the cost of users who customize package.el and don't need another init file. > If on the other hand "forms" is referring to 'setq' forms that > customize the package system itself, then indeed, users must know to > put them into a different init-file. However, I'd argue that this > isn't much worse than the current situation, where users must know to > put them *before* (package-initialize) The current situation should never have happened. > > The whole discussion and push for a "solution" is predicated on > > users who can't be bothered to do things correctly _not_ having to > > do any configuration. This patch does not improve things in this > > regard > > Correct. The current behavior is that things work out of the box Except for users who who don't need garbage dumped into their init file and for users who change their package archives or the list of activated packages in their init.el without the need of a package-initialize form because they read the docs. Apparently changing those custom variables is an edge case. https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00209.html > and > this patch *maintains* that behavior. which is why it gets a -1 from me. > > AIUI it still breaks existing config of package-archives, > > package-load-list, etc, which is something the incumbent solution > > also breaks. > > Correct, but here is the important point: it will only do so *once*, > when people upgrade to Emacs 26. As opposed to the current solution, > which breaks existing config every time (package-initialize) is > inserted, which may happen many times for a given user. So this patch > is a definite improvement. An improvement from package--ensure-init-file is great, but that's still more breakage than prior to package--ensure-init-file. > > The only proposal I can support at this time is reverting the > > incumbent solution, yet none from the maintainership is willing to > > entertain the idea. > > That's because it would result in the built-in package manager not > working out of the box, which would be embarrassing from a UX > perspective. That's the whole *point* of having a built-in package > manager: that it works right away without additional setup. Emacs itself doesn't work OOTB for most people. That it's customizable in Elisp is a feature. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2017-09-25 23:15 ` Mark Oteiza @ 2017-09-26 3:00 ` Radon Rosborough 2017-09-29 10:22 ` Eli Zaretskii 1 sibling, 0 replies; 838+ messages in thread From: Radon Rosborough @ 2017-09-26 3:00 UTC (permalink / raw) To: Mark Oteiza; +Cc: John Wiegley, Stefan Monnier, emacs-devel > > > I haven't seen one place where the problem_s_ involved have been > > > clearly articulated > > > > Unless by "problems involved" you meant more generally, for all the > > different proposals? That is exactly what [2] was intended to cover; > > could you clarify what exactly you would like articulated that hasn't > > been already? > > I meant more explicitly--each of these use cases should be documented > with examples. While the manual in its current state does explain > things, it can be better. So you're complaining about the documentation? Fine, agreed. The documentation can/should be improved. That is totally orthogonal to this patch, though. > > > this patch does not improve any of the places where user facing > > > documentation was lacking in the first place > > > > Actually, I'd disagree. I think this patch improves the situation, not > > by adding more documentation, but by reducing complexity and therefore > > reducing the need for additional documentation. > > > > In particular, we no longer need to document the placement of > > (package-initialize) in the init-file, as such placement is no longer > > necessary. > > The only documentation I see is in NEWS and the manual, which is where > the old documentation was. So, again, you're complaining about the documentation? Again, fine, agreed. But I don't think that's a reason to criticize this patch. More documentation can be added in future patches; let's not confuse matters by combining this change with general doc improvements. > > > requires the user to not only understand the forms that must be in > > > an init file > > > > Could you clarify what you mean by this? This patch has the effect > > that users can put package configuration right into their init-file, > > or use Custom to achieve the same, without having to know anything > > about the package system. > > At the cost of users who customize package.el and don't need another > init file. Right, so we benefit the 100% (people who customize packages) at the cost of the 0.1% (people who need to customize package.el in the early init-file). A win-win, no? And it's still not clear to me why you think having an early init-file is such a big problem. > package archives If I understand correctly, package-archives need not be set before package-initialize is called. Thus the number of people who would need to use the early init-file is quite small indeed. > > and this patch *maintains* that behavior. > > which is why it gets a -1 from me. The behavior I was referring to was "the built-in package manager works out of the box". Are you really saying that having the built-in package manager work out of the box is a bad thing? > An improvement from package--ensure-init-file is great, but that's still > more breakage than prior to package--ensure-init-file. Prior to package--ensure-init-file, when people pasted Lisp code from their packages' READMEs into their init-file, they would get errors. This was a very common problem for people new to Emacs, see [1]. That affects everyone, so it should be considered "major breakage". > Emacs itself doesn't work OOTB for most people. I think we all agree that this is a bad thing. Shouldn't we be trying to remedy this problem? > That it's customizable in Elisp is a feature. Yeah, but having sane defaults gets more and more important the more powerful your tool gets. [1]: https://lists.gnu.org/archive/html/emacs-devel/2015-03/msg01016.html ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2017-09-25 23:15 ` Mark Oteiza 2017-09-26 3:00 ` Radon Rosborough @ 2017-09-29 10:22 ` Eli Zaretskii 1 sibling, 0 replies; 838+ messages in thread From: Eli Zaretskii @ 2017-09-29 10:22 UTC (permalink / raw) To: Mark Oteiza; +Cc: jwiegley, radon.neon, monnier, emacs-devel > Date: Mon, 25 Sep 2017 19:15:03 -0400 > From: Mark Oteiza <mvoteiza@udel.edu> > Cc: jwiegley@gmail.com, Stefan Monnier <monnier@iro.umontreal.ca>, > emacs-devel@gnu.org > > On 25/09/17 at 10:16pm, Radon Rosborough wrote: > > > I haven't seen one place where the problem_s_ involved have been > > > clearly articulated > > > > Unless by "problems involved" you meant more generally, for all the > > different proposals? That is exactly what [2] was intended to cover; > > could you clarify what exactly you would like articulated that hasn't > > been already? > > I meant more explicitly--each of these use cases should be documented > with examples. While the manual in its current state does explain > things, it can be better. It definitely can, but that's a separate issue, I think. And we cannot finalize the documentation before we finalize the code. > > Could you clarify what you mean by this? This patch has the effect > > that users can put package configuration right into their init-file, > > or use Custom to achieve the same, without having to know anything > > about the package system. > > At the cost of users who customize package.el and don't need another > init file. Do those users have a "fire escape"? If they don't, I agree we should provide one. Otherwise, I expect such users to be knowledgeable enough to work around these changes with minimal hassle. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2017-09-25 16:27 ` Radon Rosborough 2017-09-25 16:54 ` John Wiegley @ 2017-09-25 16:58 ` Stefan Monnier 2017-09-25 19:40 ` Radon Rosborough 2017-10-09 23:17 ` Radon Rosborough 2 siblings, 1 reply; 838+ messages in thread From: Stefan Monnier @ 2017-09-25 16:58 UTC (permalink / raw) To: Radon Rosborough; +Cc: emacs-devel >> BTW, in a subsequent patch we could rename this to >> package-initialized, so the name reflects what the variable contains >> rather than what it's used for. > I don't think that's a good idea, since the most common usage of this > variable will be > (setq package-initialized nil) > in the early init file, and that doesn't make much sense from a > readability perspective (are we asserting that package.el wasn't > initialized?). Why would there be (setq package-initialized nil) in the early init file? I could imagine there being (setq package-initialized t) OTOH, to inhibit subsequent initialization of package.el. Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2017-09-25 16:58 ` Stefan Monnier @ 2017-09-25 19:40 ` Radon Rosborough 0 siblings, 0 replies; 838+ messages in thread From: Radon Rosborough @ 2017-09-25 19:40 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel > Why would there be (setq package-initialized nil) in the early init file? > I could imagine there being > > (setq package-initialized t) > > OTOH, to inhibit subsequent initialization of package.el. Whoops, that was indeed what I meant to say. But I still argue that the readability is hurt, because (setq package-initialized t) is basically a lie: you're saying that package.el was initialized already, when in fact the purpose is quite possibly to ensure that package.el is *never* initialized. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2017-09-25 16:27 ` Radon Rosborough 2017-09-25 16:54 ` John Wiegley 2017-09-25 16:58 ` Stefan Monnier @ 2017-10-09 23:17 ` Radon Rosborough 2 siblings, 0 replies; 838+ messages in thread From: Radon Rosborough @ 2017-10-09 23:17 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel I noticed that discussion seems to have died off on the package-initialize patch. Is there anything I can do to help it along? > Attached is a preliminary patch for fixing "the package-initialize > problem" (see [1] [2] [3]) by adding an early init file. Feedback > welcome. In particular, > > - do we want to try to factor out some common logic in loading the > early init file versus the regular init file? > - have I broken anything in moving the check for an invalid username > earlier in startup.el? what about moving package-initialize earlier? > - should `early-init-file' be defined in C? > - did I miss any documentation fixes? > - have I broken any style guidelines for the repository? > > Additional question: if we moved forward with this patch, would it > make it into Emacs 26.1? > > Best, > Radon Rosborough > > [1]: https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00154.html > [2]: https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00433.html > [3]: https://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00023.html ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2017-09-18 21:57 [PATCH] Fixing package-initialize, adding early init file Radon Rosborough 2017-09-19 12:30 ` Stefan Monnier @ 2017-10-10 16:52 ` Robert Weiner 2017-10-10 16:59 ` Eli Zaretskii 2017-10-10 19:03 ` Radon Rosborough 1 sibling, 2 replies; 838+ messages in thread From: Robert Weiner @ 2017-10-10 16:52 UTC (permalink / raw) To: Radon Rosborough; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 717 bytes --] On Mon, Sep 18, 2017 at 5:57 PM, Radon Rosborough <radon.neon@gmail.com> wrote: > Hello all, > > Attached is a preliminary patch for fixing "the package-initialize > problem" (see [1] [2] [3]) by adding an early init file. > My thoughts are: 1. For most Emacs users who do not program in Elisp, there should be only a single init file that they would personalize, generally as they find snippets of code they can cut and paste for their use. 2. For Elispers, another optional init file for more fine-grained control would be okay, though not ideal. But this means whatever problem exists with package-initialize, it should be solved without requiring the use of a 2nd init file. Bob [-- Attachment #2: Type: text/html, Size: 1972 bytes --] ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2017-10-10 16:52 ` Robert Weiner @ 2017-10-10 16:59 ` Eli Zaretskii 2017-10-14 21:30 ` Mark Oteiza 2017-10-10 19:03 ` Radon Rosborough 1 sibling, 1 reply; 838+ messages in thread From: Eli Zaretskii @ 2017-10-10 16:59 UTC (permalink / raw) To: rswgnu; +Cc: radon.neon, emacs-devel > From: Robert Weiner <rsw@gnu.org> > Date: Tue, 10 Oct 2017 12:52:32 -0400 > Cc: emacs-devel <emacs-devel@gnu.org> > > 1. For most Emacs users who do not program in Elisp, there should be only a single init file that they would > personalize, generally as they find snippets of code they can cut and paste for their use. > > 2. For Elispers, another optional init file for more fine-grained control would be okay, though not ideal. I think the proposed solution satisfies these requirements. The 2nd init file is only needed if you want to tweak package initialization by putting Lisp code into that 2nd file. > But this means whatever problem exists with package-initialize, it should be solved without requiring the use > of a 2nd init file. I don't understand how you reach this conclusion. The problems we are trying to solve exists only for those whom you call "Lispers", so another init file is only needed in that case. What am I missing? ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2017-10-10 16:59 ` Eli Zaretskii @ 2017-10-14 21:30 ` Mark Oteiza 2017-10-14 21:52 ` Stefan Monnier ` (2 more replies) 0 siblings, 3 replies; 838+ messages in thread From: Mark Oteiza @ 2017-10-14 21:30 UTC (permalink / raw) To: Eli Zaretskii; +Cc: rswgnu, radon.neon, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: Robert Weiner <rsw@gnu.org> >> Date: Tue, 10 Oct 2017 12:52:32 -0400 >> Cc: emacs-devel <emacs-devel@gnu.org> >> >> 1. For most Emacs users who do not program in Elisp, there should be >> only a single init file that they would personalize, generally as >> they find snippets of code they can cut and paste for their use. >> >> 2. For Elispers, another optional init file for more fine-grained >> control would be okay, though not ideal. > > I think the proposed solution satisfies these requirements. The 2nd > init file is only needed if you want to tweak package initialization > by putting Lisp code into that 2nd file. Breaking the ability to do such tweaking with the init file we already have is insane. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2017-10-14 21:30 ` Mark Oteiza @ 2017-10-14 21:52 ` Stefan Monnier 2017-10-15 1:18 ` Radon Rosborough 2017-10-15 14:16 ` Eli Zaretskii 2 siblings, 0 replies; 838+ messages in thread From: Stefan Monnier @ 2017-10-14 21:52 UTC (permalink / raw) To: emacs-devel > Breaking the ability to do such tweaking with the init file we already > have is insane. FWIW this second init file has another purpose: it lets you run configuration code before the initial frame is mapped. Stefan "who intends to use a single config file, which will be called ~/.emacs.d/early-init.el" ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2017-10-14 21:30 ` Mark Oteiza 2017-10-14 21:52 ` Stefan Monnier @ 2017-10-15 1:18 ` Radon Rosborough 2017-10-15 14:16 ` Eli Zaretskii 2 siblings, 0 replies; 838+ messages in thread From: Radon Rosborough @ 2017-10-15 1:18 UTC (permalink / raw) To: Mark Oteiza; +Cc: Eli Zaretskii, rswgnu, emacs-devel [-- Attachment #1: Type: text/plain, Size: 415 bytes --] > Breaking the ability to do such tweaking with the init file we > already have is insane. It is equally legitimate for me to say that all of the other proposed solutions are insane. Please provide some reasoning to substantiate your claim, since I have already provided ample reasoning to substantiate my claim to the contrary (see [1]). [1]: https://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00023.html [-- Attachment #2: Type: text/html, Size: 651 bytes --] ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2017-10-14 21:30 ` Mark Oteiza 2017-10-14 21:52 ` Stefan Monnier 2017-10-15 1:18 ` Radon Rosborough @ 2017-10-15 14:16 ` Eli Zaretskii 2017-10-15 16:26 ` Stefan Monnier 2 siblings, 1 reply; 838+ messages in thread From: Eli Zaretskii @ 2017-10-15 14:16 UTC (permalink / raw) To: Mark Oteiza; +Cc: rswgnu, radon.neon, emacs-devel > From: Mark Oteiza <mvoteiza@udel.edu> > Cc: rswgnu@gmail.com, radon.neon@gmail.com, emacs-devel@gnu.org > Date: Sat, 14 Oct 2017 17:30:41 -0400 > > > I think the proposed solution satisfies these requirements. The 2nd > > init file is only needed if you want to tweak package initialization > > by putting Lisp code into that 2nd file. > > Breaking the ability to do such tweaking with the init file we already > have is insane. I hope the "insane" part is a slight exaggeration... Anyway, AFAIU, that was the best/only solution that came up which would solve the original problem without causing more trouble to the uninitiated. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2017-10-15 14:16 ` Eli Zaretskii @ 2017-10-15 16:26 ` Stefan Monnier 2017-10-25 22:13 ` Radon Rosborough 0 siblings, 1 reply; 838+ messages in thread From: Stefan Monnier @ 2017-10-15 16:26 UTC (permalink / raw) To: emacs-devel >> > I think the proposed solution satisfies these requirements. The 2nd >> > init file is only needed if you want to tweak package initialization >> > by putting Lisp code into that 2nd file. >> Breaking the ability to do such tweaking with the init file we already >> have is insane. Actually, it doesn't really break it. All it does really (assuming you don't use the new early-init.el file) is that packages in ~/.emacs.d/elpa will be automatically activated before ~/.emacs is loaded. So if you set package-user-dir in your ~/.emacs presumably you don't have any packages in ~/.emacs.d/elpa and hence it won't make much of a difference: you can still set package-user-dir in your ~/.emacs and then call package-initialize. Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2017-10-15 16:26 ` Stefan Monnier @ 2017-10-25 22:13 ` Radon Rosborough 2017-10-26 0:11 ` Stefan Monnier 0 siblings, 1 reply; 838+ messages in thread From: Radon Rosborough @ 2017-10-25 22:13 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Sorry to be a nag, but discussion seems to have died off again. Again, is there anything I can do to help out with the process of reviewing this patch for merge? > Attached is a preliminary patch for fixing "the package-initialize > problem" (see [1] [2] [3]) by adding an early init file. Feedback > welcome. In particular, > > - do we want to try to factor out some common logic in loading the > early init file versus the regular init file? > - have I broken anything in moving the check for an invalid username > earlier in startup.el? what about moving package-initialize earlier? > - should `early-init-file' be defined in C? > - did I miss any documentation fixes? > - have I broken any style guidelines for the repository? > > Additional question: if we moved forward with this patch, would it > make it into Emacs 26.1? > > Best, > Radon Rosborough > > [1]: https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00154.html > [2]: https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00433.html > [3]: https://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00023.html ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2017-10-25 22:13 ` Radon Rosborough @ 2017-10-26 0:11 ` Stefan Monnier 2017-12-18 0:45 ` Radon Rosborough 0 siblings, 1 reply; 838+ messages in thread From: Stefan Monnier @ 2017-10-26 0:11 UTC (permalink / raw) To: emacs-devel >> - do we want to try to factor out some common logic in loading the >> early init file versus the regular init file? I think so, yes. >> - have I broken anything in moving the check for an invalid username >> earlier in startup.el? what about moving package-initialize earlier? Time will tell. >> - should `early-init-file' be defined in C? If it's not indispensable, then I'd say no. >> Additional question: if we moved forward with this patch, would it >> make it into Emacs 26.1? No, it's too late for that. Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2017-10-26 0:11 ` Stefan Monnier @ 2017-12-18 0:45 ` Radon Rosborough 2018-01-25 4:35 ` Radon Rosborough 0 siblings, 1 reply; 838+ messages in thread From: Radon Rosborough @ 2017-12-18 0:45 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 720 bytes --] I am sorry for the delay in response. Now that the fall semester is over, I have much more time. The revised patch is attached. I have done some basic testing with it applied to the latest master. Please let me know if you have more feedback. > > - do we want to try to factor out some common logic in loading the > > early init file versus the regular init file? > > I think so, yes. This is done; the function `load-user-init-file' is used for loading both the early and regular init-files, and could easily be used for loading more. > > - should `early-init-file' be defined in C? > > If it's not indispensable, then I'd say no. In the attached patch, it is defined as a Lisp variable in startup.el. Best, Radon [-- Attachment #2: 0001-Add-early-init-file-stop-package-initialize-insertio.patch --] [-- Type: application/octet-stream, Size: 33786 bytes --] From c74093ab3dde9042a50eb65e7af46625a834b689 Mon Sep 17 00:00:00 2001 From: Radon Rosborough <radon.neon@gmail.com> Date: Sun, 17 Dec 2017 17:31:17 -0700 Subject: [PATCH] Add early init file, stop package-initialize insertion * lisp/startup.el (early-init-file): New variable, for the filename of the early init file after it has been loaded. * lisp/startup.el (load-user-init-file): New function, used to eliminate duplicate code in loading the early and regular init files. * lisp/startup.el (command-line): Load the early init file using `load-user-init-file'. Move the check for an invalid username to just before that, and move the initialization of the package system to just after. Load the regular init file using `load-user-init-file'. * src/lread.c (Vuser_init_file): Note change in semantics due to its usage while loading the early init file. * lisp/emacs-lisp/package.el (package--ensure-init-file): Remove definition, usage, and documentation. * lisp/emacs-lisp/package.el (package--init-file-ensured): Remove definition and usage. * doc/lispref/os.texi: Document early init file. * doc/lispref/package.texi: Document changes to when package-initialize is called, and advise against calling it in the init file. * doc/emacs/package.texi: Document changes to when package-initialize is called. * doc/misc/org.texi: Don't recommend to call package-initialize in the init file. * etc/NEWS: Document changes to startup and package.el. Discussion on emacs-devel leading up to this change (approximately 150 messages): - https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00154.html - https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00433.html - https://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00023.html - https://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00599.html - https://lists.gnu.org/archive/html/emacs-devel/2017-10/msg00332.html --- doc/emacs/package.texi | 28 +-- doc/lispref/os.texi | 14 ++ doc/lispref/package.texi | 16 +- doc/misc/org.texi | 4 +- etc/NEWS | 18 ++ lisp/emacs-lisp/package.el | 71 +------- lisp/startup.el | 425 +++++++++++++++++++++++++-------------------- src/lread.c | 2 +- 8 files changed, 289 insertions(+), 289 deletions(-) diff --git a/doc/emacs/package.texi b/doc/emacs/package.texi index 215f50cb40..bd7cccce6c 100644 --- a/doc/emacs/package.texi +++ b/doc/emacs/package.texi @@ -253,30 +253,16 @@ Package Installation consult the package's help buffer. By default, Emacs also automatically loads all installed packages in -subsequent Emacs sessions. This happens at startup, after processing -the init file (@pxref{Init File}). As an exception, Emacs does not -load packages at startup if invoked with the @samp{-q} or -@samp{--no-init-file} options (@pxref{Initial Options}). +subsequent Emacs sessions. This happens at startup, before processing +the init file but after processing the early init file (@pxref{Early +Init File,,, elisp, The Emacs Lisp Reference Manual}). As an +exception, Emacs does not load packages at startup if invoked with the +@samp{-q} or @samp{--no-init-file} options (@xref{Initial Options}). @vindex package-enable-at-startup To disable automatic package loading, change the variable -@code{package-enable-at-startup} to @code{nil}. - -@findex package-initialize - The reason automatic package loading occurs after loading the init -file is that user options only receive their customized values after -loading the init file, including user options which affect the -packaging system. In some circumstances, you may want to load -packages explicitly in your init file (usually because some other code -in your init file depends on a package). In that case, your init file -should call the function @code{package-initialize}. It is up to you -to ensure that relevant user options, such as @code{package-load-list} -(see below), are set up prior to the @code{package-initialize} call. -This will automatically set @code{package-enable-at-startup} to @code{nil}, to -avoid loading the packages again after processing the init file. -Alternatively, you may choose to completely inhibit package loading at -startup, and invoke the command @kbd{M-x package-initialize} to load -your packages manually. +@code{package-enable-at-startup} to @code{nil}. You must do this in +the early init file. Currently it cannot be done via Customize. @vindex package-load-list For finer control over package loading, you can use the variable diff --git a/doc/lispref/os.texi b/doc/lispref/os.texi index 501960bdc3..c6990909ab 100644 --- a/doc/lispref/os.texi +++ b/doc/lispref/os.texi @@ -361,6 +361,7 @@ Init File @cindex init file @cindex @file{.emacs} @cindex @file{init.el} +@cindex @file{early-init.el} When you start Emacs, it normally attempts to load your @dfn{init file}. This is either a file named @file{.emacs} or @file{.emacs.el} @@ -384,6 +385,19 @@ Init File file. If those environment variables are absent, though, Emacs uses your user-id to find your home directory. +@cindex early init file + Emacs also attempts to load a second init file, called the + @dfn{early init file}, if it exists. This is a file named + @file{early-init.el} in a subdirectory named @file{.emacs.d} in your + home directory. The difference is that the early init file is + loaded much earlier during the startup process, so you can use it to + customize some things that are initialized before loading the + regular init file. For example, here you can customize the process + of loading installed packages, by setting variables such as + @var{package-load-list} or + @var{package-enable-at-startup}. @xref{Package Installation,,, + emacs,The GNU Emacs Manual}. + @cindex default init file An Emacs installation may have a @dfn{default init file}, which is a Lisp library named @file{default.el}. Emacs finds this file through diff --git a/doc/lispref/package.texi b/doc/lispref/package.texi index 153ee48741..2e93f29bd2 100644 --- a/doc/lispref/package.texi +++ b/doc/lispref/package.texi @@ -106,10 +106,12 @@ Packaging Basics Whenever Emacs starts up, it automatically calls the function @code{package-initialize} to load installed packages. This is done -after loading the init file and abbrev file (if any) and before -running @code{after-init-hook} (@pxref{Startup Summary}). Automatic -package loading is disabled if the user option -@code{package-enable-at-startup} is @code{nil}. +after loading the early init file, but before loading the early init +file and abbrev file (if any) and before running +@code{after-init-hook} (@pxref{Startup Summary}). Automatic package +loading is disabled if the user option +@code{package-enable-at-startup} is @code{nil}. (Of course, the +setting of this user option must be done in the early init file.) @deffn Command package-initialize &optional no-activate This function initializes Emacs' internal record of which packages are @@ -123,6 +125,12 @@ Packaging Basics The optional argument @var{no-activate}, if non-@code{nil}, causes Emacs to update its record of installed packages without actually loading them; it is for internal use only. + +In most cases, you should not need to call @code{package-initialize}, +as this is done automatically during startup. Simply make sure to put +any code that should run before @code{package-initialize} in the early +init file, and any code that should run after in the primary init +file (@xref{Init File,,, emacs, The GNU Emacs Manual}). @end deffn @node Simple Packages diff --git a/doc/misc/org.texi b/doc/misc/org.texi index 1f6e10287d..36b7f87248 100644 --- a/doc/misc/org.texi +++ b/doc/misc/org.texi @@ -890,9 +890,7 @@ Installation been visited, i.e., where no Org built-in function have been loaded. Otherwise autoload Org functions will mess up the installation. -Then, to make sure your Org configuration is taken into account, initialize -the package system with @code{(package-initialize)} in your Emacs init file -before setting any Org option. If you want to use Org's package repository, +If you want to use Org's package repository, check out the @uref{http://orgmode.org/elpa.html, Org ELPA page}. @subsubheading Downloading Org as an archive diff --git a/etc/NEWS b/etc/NEWS index 1382f96a37..4bbf3e237a 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -41,6 +41,24 @@ can enable it when configuring, e.g., './configure CFLAGS="-g3 -O2 \f * Startup Changes in Emacs 27.1 ++++ +** Emacs can now be configured using an early init file. +The file is called early-init.el, in `user-emacs-directory'. It is +loaded very early in the startup process: in particular, before +graphical elements such as the tool bar are initialized, and before +the package manager is initialized. + ++++ +** Emacs now initializes package.el before loading the init-file. +This is part of a change intended to eliminate the behavior of +package.el inserting a call to (package-initialize) into the +init-file, which was previously done when Emacs was started. Users +who do not configure package.el variables such as `package-load-list' +and `package-user-dir' need not make any configuration changes. Users +who do configure such variables should place the configuration into +the newly introduced early init file, which is loaded before +package.el is initialized. + \f * Changes in Emacs 27.1 diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el index f8b4cc888d..815b679cae 100644 --- a/lisp/emacs-lisp/package.el +++ b/lisp/emacs-lisp/package.el @@ -1431,16 +1431,11 @@ package-read-all-archive-contents ;; available on disk. (defvar package--initialized nil) -(defvar package--init-file-ensured nil - "Whether we know the init file has package-initialize.") - ;;;###autoload (defun package-initialize (&optional no-activate) "Load Emacs Lisp packages, and activate them. The variable `package-load-list' controls which packages to load. If optional arg NO-ACTIVATE is non-nil, don't activate packages. -If `user-init-file' does not mention `(package-initialize)', add -it to the file. If called as part of loading `user-init-file', set `package-enable-at-startup' to nil, to prevent accidentally loading packages twice. @@ -1449,13 +1444,7 @@ package-initialize taken care of by `package-initialize'." (interactive) (setq package-alist nil) - (if after-init-time - (package--ensure-init-file) - ;; If `package-initialize' is before we finished loading the init - ;; file, it's obvious we don't need to ensure-init. - (setq package--init-file-ensured t - ;; And likely we don't need to run it again after init. - package-enable-at-startup nil)) + (setq package-enable-at-startup nil) (package-load-all-descriptors) (package-read-all-archive-contents) (unless no-activate @@ -1872,64 +1861,6 @@ package-download-transaction using `package-compute-transaction'." (mapc #'package-install-from-archive packages)) -(defun package--ensure-init-file () - "Ensure that the user's init file has `package-initialize'. -`package-initialize' doesn't have to be called, as long as it is -present somewhere in the file, even as a comment. If it is not, -add a call to it along with some explanatory comments." - ;; Don't mess with the init-file from "emacs -Q". - (when (and (stringp user-init-file) - (not package--init-file-ensured) - (file-readable-p user-init-file) - (file-writable-p user-init-file)) - (let* ((buffer (find-buffer-visiting user-init-file)) - buffer-name - (contains-init - (if buffer - (with-current-buffer buffer - (save-excursion - (save-restriction - (widen) - (goto-char (point-min)) - (re-search-forward "(package-initialize\\_>" nil 'noerror)))) - ;; Don't visit the file if we don't have to. - (with-temp-buffer - (insert-file-contents user-init-file) - (goto-char (point-min)) - (re-search-forward "(package-initialize\\_>" nil 'noerror))))) - (unless contains-init - (with-current-buffer (or buffer - (let ((delay-mode-hooks t) - (find-file-visit-truename t)) - (find-file-noselect user-init-file))) - (when buffer - (setq buffer-name (buffer-file-name)) - (set-visited-file-name (file-chase-links user-init-file))) - (save-excursion - (save-restriction - (widen) - (goto-char (point-min)) - (while (and (looking-at-p "[[:blank:]]*\\(;\\|$\\)") - (not (eobp))) - (forward-line 1)) - (insert - "\n" - ";; Added by Package.el. This must come before configurations of\n" - ";; installed packages. Don't delete this line. If you don't want it,\n" - ";; just comment it out by adding a semicolon to the start of the line.\n" - ";; You may delete these explanatory comments.\n" - "(package-initialize)\n") - (unless (looking-at-p "$") - (insert "\n")) - (let ((file-precious-flag t)) - (save-buffer)) - (if buffer - (progn - (set-visited-file-name buffer-name) - (set-buffer-modified-p nil)) - (kill-buffer (current-buffer))))))))) - (setq package--init-file-ensured t)) - ;;;###autoload (defun package-install (pkg &optional dont-select) "Install the package PKG. diff --git a/lisp/startup.el b/lisp/startup.el index 4575f1f94d..de85933983 100644 --- a/lisp/startup.el +++ b/lisp/startup.el @@ -312,6 +312,15 @@ inhibit-startup-hooks Currently this applies to: `emacs-startup-hook', `term-setup-hook', and `window-setup-hook'.") +(defvar early-init-file nil + "File name, including directory, of user's early init file. +If the file loaded had extension `.elc', and the corresponding +source file exists, this variable contains the name of source +file, suitable for use by functions like `custom-save-all' which +edit the init file. While Emacs loads and evaluates the init +file, value is the real name of the file, regardless of whether +or not it has the `.elc' extension.") + (defvar keyboard-type nil "The brand of keyboard you are using. This variable is used to define the proper function and keypad @@ -870,6 +879,129 @@ startup--setup-quote-display (when standard-display-table (aset standard-display-table char nil))))))) +(defun load-user-init-file + (compute-filename &optional compute-alternate-filename load-defaults) + "Load a user init-file. +COMPUTE-FILENAME is called with no arguments and should return +the name of the init-file to load. If this file cannot be loaded, +and COMPUTE-ALTERNATE-FILENAME is non-nil, then it is called with +no arguments and should return the name of an alternate init-file +to load. If LOAD-DEFAULTS is non-nil, then load default.el after +the init-file. + +This function sets `user-init-file' to the name of the loaded +init-file, or to a default value if loading is not possible." + (let ((debug-on-error-from-init-file nil) + (debug-on-error-should-be-set nil) + (debug-on-error-initial + (if (eq init-file-debug t) + 'startup + init-file-debug)) + (orig-enable-multibyte (default-value 'enable-multibyte-characters))) + (let ((debug-on-error debug-on-error-initial) + ;; We create an anonymous function here so that we can call + ;; it in different contexts depending on the value of + ;; `debug-on-error'. + (read-init-file + (lambda () + (when init-file-user + (let ((init-file-name (funcall compute-filename))) + + ;; If `user-init-file' is t, then `load' will store + ;; the name of the file that it loads into + ;; `user-init-file'. + (setq user-init-file t) + (load init-file-name 'noerror 'nomessage) + + (when (eq user-init-file t) + (let ((alt-file-name (funcall compute-alternate-filename))) + (load alt-file-name 'noerror 'nomessage) + + ;; If we did not find the user's init file, set + ;; user-init-file conclusively. Don't let it be + ;; set from default.el. + (when (eq user-init-file t) + (setq user-init-file init-file-name))))) + + ;; If we loaded a compiled file, set `user-init-file' to + ;; the source version if that exists. + (when (equal (file-name-extension user-init-file) + "elc") + (let* ((source (file-name-sans-extension user-init-file)) + (alt (concat source ".el"))) + (setq source (cond ((file-exists-p alt) alt) + ((file-exists-p source) source) + (t nil))) + (when source + (when (file-newer-than-file-p source user-init-file) + (message "Warning: %s is newer than %s" + source user-init-file) + (sit-for 1)) + (setq user-init-file source)))) + + (when load-defaults + + ;; Prevent default.el from changing the value of + ;; `inhibit-startup-screen'. + (let ((inhibit-startup-screen nil)) + (load "default" 'noerror 'nomessage))))))) + ;; Now call our anonymous function. + (if init-file-debug + ;; Do this without a `condition-case' if the user wants to + ;; debug. + (funcall read-init-file) + (condition-case error + (progn + (funcall read-init-file) + + ;; If a previous init-file had an error, don't forget + ;; about that. + (unless init-file-had-error + (setq init-file-had-error nil))) + (error + (display-warning + 'initialization + (format-message "\ +An error occurred while loading `%s':\n\n%s%s%s\n\n\ +To ensure normal operation, you should investigate and remove the +cause of the error in your initialization file. Start Emacs with +the `--debug-init' option to view a complete error backtrace." + user-init-file + (get (car error) 'error-message) + (if (cdr error) ": " "") + (mapconcat (lambda (s) (prin1-to-string s t)) + (cdr error) ", ")) + :warning) + (setq init-file-had-error t)))) + + ;; If we can tell that the init file altered debug-on-error, + ;; arrange to preserve the value that it set up. + (or (eq debug-on-error debug-on-error-initial) + (setq debug-on-error-should-be-set t + debug-on-error-from-init-file debug-on-error))) + + (when debug-on-error-should-be-set + (setq debug-on-error debug-on-error-from-init-file)) + + (unless (or (default-value 'enable-multibyte-characters) + (eq orig-enable-multibyte (default-value + 'enable-multibyte-characters))) + + ;; Init file changed to unibyte. Reset existing multibyte + ;; buffers (probably *scratch*, *Messages*, *Minibuf-0*). + ;; Arguably this should only be done if they're free of + ;; multibyte characters. + (mapc (lambda (buffer) + (with-current-buffer buffer + (if enable-multibyte-characters + (set-buffer-multibyte nil)))) + (buffer-list)) + + ;; Also re-set the language environment in case it was + ;; originally done before unibyte was set and is sensitive to + ;; unibyte (display table, terminal coding system &c). + (set-language-environment current-language-environment)))) + (defun command-line () "A subroutine of `normal-top-level'. Amongst another things, it parses the command-line arguments." @@ -1021,6 +1153,69 @@ command-line (and command-line-args (setcdr command-line-args args))) + ;; Warn for invalid user name. + (when init-file-user + (if (string-match "[~/:\n]" init-file-user) + (display-warning 'initialization + (format "Invalid user name %s" + init-file-user) + :error) + (if (file-directory-p (expand-file-name + ;; We don't support ~USER on MS-Windows + ;; and MS-DOS except for the current + ;; user, and always load .emacs from + ;; the current user's home directory + ;; (see below). So always check "~", + ;; even if invoked with "-u USER", or + ;; if $USER or $LOGNAME are set to + ;; something different. + (if (memq system-type '(windows-nt ms-dos)) + "~" + (concat "~" init-file-user)))) + nil + (display-warning 'initialization + (format "User %s has no home directory" + (if (equal init-file-user "") + (user-real-login-name) + init-file-user)) + :error)))) + + ;; Load the early init file, if found. + (load-user-init-file + (lambda () + (expand-file-name + "early-init" + (file-name-as-directory + (concat "~" init-file-user "/.emacs.d"))))) + (setq early-init-file user-init-file) + + ;; If any package directory exists, initialize the package system. + (and user-init-file + package-enable-at-startup + (catch 'package-dir-found + (let (dirs) + (if (boundp 'package-directory-list) + (setq dirs package-directory-list) + (dolist (f load-path) + (and (stringp f) + (equal (file-name-nondirectory f) "site-lisp") + (push (expand-file-name "elpa" f) dirs)))) + (push (if (boundp 'package-user-dir) + package-user-dir + (locate-user-emacs-file "elpa")) + dirs) + (dolist (dir dirs) + (when (file-directory-p dir) + (dolist (subdir (directory-files dir)) + (when (let ((subdir (expand-file-name subdir dir))) + (and (file-directory-p subdir) + (file-exists-p + (expand-file-name + (package--description-file subdir) + subdir)))) + (throw 'package-dir-found t))))))) + (package-initialize)) + ;; Make sure window system's init file was loaded in loadup.el if ;; using a window system. ;; Initialize the window-system only after processing the command-line @@ -1127,170 +1322,47 @@ command-line ;; the startup screen. (setq inhibit-startup-screen nil) - ;; Warn for invalid user name. - (when init-file-user - (if (string-match "[~/:\n]" init-file-user) - (display-warning 'initialization - (format "Invalid user name %s" - init-file-user) - :error) - (if (file-directory-p (expand-file-name - ;; We don't support ~USER on MS-Windows - ;; and MS-DOS except for the current - ;; user, and always load .emacs from - ;; the current user's home directory - ;; (see below). So always check "~", - ;; even if invoked with "-u USER", or - ;; if $USER or $LOGNAME are set to - ;; something different. - (if (memq system-type '(windows-nt ms-dos)) - "~" - (concat "~" init-file-user)))) - nil - (display-warning 'initialization - (format "User %s has no home directory" - (if (equal init-file-user "") - (user-real-login-name) - init-file-user)) - :error)))) - ;; Load that user's init file, or the default one, or none. - (let (debug-on-error-from-init-file - debug-on-error-should-be-set - (debug-on-error-initial - (if (eq init-file-debug t) 'startup init-file-debug)) - (orig-enable-multibyte (default-value 'enable-multibyte-characters))) - (let ((debug-on-error debug-on-error-initial) - ;; This function actually reads the init files. - (inner - (function - (lambda () - (if init-file-user - (let ((user-init-file-1 - (cond - ((eq system-type 'ms-dos) - (concat "~" init-file-user "/_emacs")) - ((not (eq system-type 'windows-nt)) - (concat "~" init-file-user "/.emacs")) - ;; Else deal with the Windows situation - ((directory-files "~" nil "^\\.emacs\\(\\.elc?\\)?$") - ;; Prefer .emacs on Windows. - "~/.emacs") - ((directory-files "~" nil "^_emacs\\(\\.elc?\\)?$") - ;; Also support _emacs for compatibility, but warn about it. - (push `(initialization - ,(format-message - "`_emacs' init file is deprecated, please use `.emacs'")) - delayed-warnings-list) - "~/_emacs") - (t ;; But default to .emacs if _emacs does not exist. - "~/.emacs")))) - ;; This tells `load' to store the file name found - ;; into user-init-file. - (setq user-init-file t) - (load user-init-file-1 t t) - - (when (eq user-init-file t) - ;; If we did not find ~/.emacs, try - ;; ~/.emacs.d/init.el. - (let ((otherfile - (expand-file-name - "init" - (file-name-as-directory - (concat "~" init-file-user "/.emacs.d"))))) - (load otherfile t t) - - ;; If we did not find the user's init file, - ;; set user-init-file conclusively. - ;; Don't let it be set from default.el. - (when (eq user-init-file t) - (setq user-init-file user-init-file-1)))) - - ;; If we loaded a compiled file, set - ;; `user-init-file' to the source version if that - ;; exists. - (when (and user-init-file - (equal (file-name-extension user-init-file) - "elc")) - (let* ((source (file-name-sans-extension user-init-file)) - (alt (concat source ".el"))) - (setq source (cond ((file-exists-p alt) alt) - ((file-exists-p source) source) - (t nil))) - (when source - (when (file-newer-than-file-p source user-init-file) - (message "Warning: %s is newer than %s" - source user-init-file) - (sit-for 1)) - (setq user-init-file source)))) - - (unless inhibit-default-init - (let ((inhibit-startup-screen nil)) - ;; Users are supposed to be told their rights. - ;; (Plus how to get help and how to undo.) - ;; Don't you dare turn this off for anyone - ;; except yourself. - (load "default" t t))))))))) - (if init-file-debug - ;; Do this without a condition-case if the user wants to debug. - (funcall inner) - (condition-case error - (progn - (funcall inner) - (setq init-file-had-error nil)) - (error - (display-warning - 'initialization - (format-message "\ -An error occurred while loading `%s':\n\n%s%s%s\n\n\ -To ensure normal operation, you should investigate and remove the -cause of the error in your initialization file. Start Emacs with -the `--debug-init' option to view a complete error backtrace." - user-init-file - (get (car error) 'error-message) - (if (cdr error) ": " "") - (mapconcat (lambda (s) (prin1-to-string s t)) - (cdr error) ", ")) - :warning) - (setq init-file-had-error t)))) - - (if (and deactivate-mark transient-mark-mode) - (with-current-buffer (window-buffer) - (deactivate-mark))) - - ;; If the user has a file of abbrevs, read it (unless -batch). - (when (and (not noninteractive) - (file-exists-p abbrev-file-name) - (file-readable-p abbrev-file-name)) - (quietly-read-abbrev-file abbrev-file-name)) - - ;; If the abbrevs came entirely from the init file or the - ;; abbrevs file, they do not need saving. - (setq abbrevs-changed nil) - - ;; If we can tell that the init file altered debug-on-error, - ;; arrange to preserve the value that it set up. - (or (eq debug-on-error debug-on-error-initial) - (setq debug-on-error-should-be-set t - debug-on-error-from-init-file debug-on-error))) - (if debug-on-error-should-be-set - (setq debug-on-error debug-on-error-from-init-file)) - (unless (or (default-value 'enable-multibyte-characters) - (eq orig-enable-multibyte (default-value - 'enable-multibyte-characters))) - ;; Init file changed to unibyte. Reset existing multibyte - ;; buffers (probably *scratch*, *Messages*, *Minibuf-0*). - ;; Arguably this should only be done if they're free of - ;; multibyte characters. - (mapc (lambda (buffer) - (with-current-buffer buffer - (if enable-multibyte-characters - (set-buffer-multibyte nil)))) - (buffer-list)) - ;; Also re-set the language environment in case it was - ;; originally done before unibyte was set and is sensitive to - ;; unibyte (display table, terminal coding system &c). - (set-language-environment current-language-environment))) + (load-user-init-file + (lambda () + (cond + ((eq system-type 'ms-dos) + (concat "~" init-file-user "/_emacs")) + ((not (eq system-type 'windows-nt)) + (concat "~" init-file-user "/.emacs")) + ;; Else deal with the Windows situation. + ((directory-files "~" nil "^\\.emacs\\(\\.elc?\\)?$") + ;; Prefer .emacs on Windows. + "~/.emacs") + ((directory-files "~" nil "^_emacs\\(\\.elc?\\)?$") + ;; Also support _emacs for compatibility, but warn about it. + (push `(initialization + ,(format-message + "`_emacs' init file is deprecated, please use `.emacs'")) + delayed-warnings-list) + "~/_emacs") + (t ;; But default to .emacs if _emacs does not exist. + "~/.emacs"))) + (lambda () + (expand-file-name + "init" + (file-name-as-directory + (concat "~" init-file-user "/.emacs.d")))) + (not inhibit-default-init)) + + (when (and deactivate-mark transient-mark-mode) + (with-current-buffer (window-buffer) + (deactivate-mark))) + + ;; If the user has a file of abbrevs, read it (unless -batch). + (when (and (not noninteractive) + (file-exists-p abbrev-file-name) + (file-readable-p abbrev-file-name)) + (quietly-read-abbrev-file abbrev-file-name)) + + ;; If the abbrevs came entirely from the init file or the + ;; abbrevs file, they do not need saving. + (setq abbrevs-changed nil) ;; Do this here in case the init file sets mail-host-address. (and mail-host-address @@ -1312,33 +1384,6 @@ command-line (eq face-ignored-fonts old-face-ignored-fonts)) (clear-face-cache))) - ;; If any package directory exists, initialize the package system. - (and user-init-file - package-enable-at-startup - (catch 'package-dir-found - (let (dirs) - (if (boundp 'package-directory-list) - (setq dirs package-directory-list) - (dolist (f load-path) - (and (stringp f) - (equal (file-name-nondirectory f) "site-lisp") - (push (expand-file-name "elpa" f) dirs)))) - (push (if (boundp 'package-user-dir) - package-user-dir - (locate-user-emacs-file "elpa")) - dirs) - (dolist (dir dirs) - (when (file-directory-p dir) - (dolist (subdir (directory-files dir)) - (when (let ((subdir (expand-file-name subdir dir))) - (and (file-directory-p subdir) - (file-exists-p - (expand-file-name - (package--description-file subdir) - subdir)))) - (throw 'package-dir-found t))))))) - (package-initialize)) - (setq after-init-time (current-time)) ;; Display any accumulated warnings after all functions in ;; `after-init-hook' like `desktop-read' have finalized possible diff --git a/src/lread.c b/src/lread.c index 52897b4fcc..5ff438041b 100644 --- a/src/lread.c +++ b/src/lread.c @@ -4892,7 +4892,7 @@ directory. These file names are converted to absolute at startup. */); If the file loaded had extension `.elc', and the corresponding source file exists, this variable contains the name of source file, suitable for use by functions like `custom-save-all' which edit the init file. -While Emacs loads and evaluates the init file, value is the real name +While Emacs loads and evaluates any init file, value is the real name of the file, regardless of whether or not it has the `.elc' extension. */); Vuser_init_file = Qnil; -- 2.14.3 ^ permalink raw reply related [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2017-12-18 0:45 ` Radon Rosborough @ 2018-01-25 4:35 ` Radon Rosborough 2018-01-25 15:43 ` Clément Pit-Claudel 2018-01-25 17:07 ` [PATCH] Fixing package-initialize, adding early init file Stefan Monnier 0 siblings, 2 replies; 838+ messages in thread From: Radon Rosborough @ 2018-01-25 4:35 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 697 bytes --] Since it has been more than a month with no response, I am re-posting the patch which fixes the problems previously discussed [1] [2] [3] with `package-initialize' by adding a second (optional) init-file `early-init.el'. This patch includes some refactoring of the code in `startup.el' to provide for loading any number of init-files in an extensible way. I hope that the change can be included in Emacs 26.2 or Emacs 27. Feedback much appreciated. Best, Radon Rosborough [1]: https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00154.html [2]: https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00433.html [3]: https://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00023.html [-- Attachment #2: 0001-Add-early-init-file-stop-package-initialize-insertio.patch --] [-- Type: application/octet-stream, Size: 33786 bytes --] From c74093ab3dde9042a50eb65e7af46625a834b689 Mon Sep 17 00:00:00 2001 From: Radon Rosborough <radon.neon@gmail.com> Date: Sun, 17 Dec 2017 17:31:17 -0700 Subject: [PATCH] Add early init file, stop package-initialize insertion * lisp/startup.el (early-init-file): New variable, for the filename of the early init file after it has been loaded. * lisp/startup.el (load-user-init-file): New function, used to eliminate duplicate code in loading the early and regular init files. * lisp/startup.el (command-line): Load the early init file using `load-user-init-file'. Move the check for an invalid username to just before that, and move the initialization of the package system to just after. Load the regular init file using `load-user-init-file'. * src/lread.c (Vuser_init_file): Note change in semantics due to its usage while loading the early init file. * lisp/emacs-lisp/package.el (package--ensure-init-file): Remove definition, usage, and documentation. * lisp/emacs-lisp/package.el (package--init-file-ensured): Remove definition and usage. * doc/lispref/os.texi: Document early init file. * doc/lispref/package.texi: Document changes to when package-initialize is called, and advise against calling it in the init file. * doc/emacs/package.texi: Document changes to when package-initialize is called. * doc/misc/org.texi: Don't recommend to call package-initialize in the init file. * etc/NEWS: Document changes to startup and package.el. Discussion on emacs-devel leading up to this change (approximately 150 messages): - https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00154.html - https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00433.html - https://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00023.html - https://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00599.html - https://lists.gnu.org/archive/html/emacs-devel/2017-10/msg00332.html --- doc/emacs/package.texi | 28 +-- doc/lispref/os.texi | 14 ++ doc/lispref/package.texi | 16 +- doc/misc/org.texi | 4 +- etc/NEWS | 18 ++ lisp/emacs-lisp/package.el | 71 +------- lisp/startup.el | 425 +++++++++++++++++++++++++-------------------- src/lread.c | 2 +- 8 files changed, 289 insertions(+), 289 deletions(-) diff --git a/doc/emacs/package.texi b/doc/emacs/package.texi index 215f50cb40..bd7cccce6c 100644 --- a/doc/emacs/package.texi +++ b/doc/emacs/package.texi @@ -253,30 +253,16 @@ Package Installation consult the package's help buffer. By default, Emacs also automatically loads all installed packages in -subsequent Emacs sessions. This happens at startup, after processing -the init file (@pxref{Init File}). As an exception, Emacs does not -load packages at startup if invoked with the @samp{-q} or -@samp{--no-init-file} options (@pxref{Initial Options}). +subsequent Emacs sessions. This happens at startup, before processing +the init file but after processing the early init file (@pxref{Early +Init File,,, elisp, The Emacs Lisp Reference Manual}). As an +exception, Emacs does not load packages at startup if invoked with the +@samp{-q} or @samp{--no-init-file} options (@xref{Initial Options}). @vindex package-enable-at-startup To disable automatic package loading, change the variable -@code{package-enable-at-startup} to @code{nil}. - -@findex package-initialize - The reason automatic package loading occurs after loading the init -file is that user options only receive their customized values after -loading the init file, including user options which affect the -packaging system. In some circumstances, you may want to load -packages explicitly in your init file (usually because some other code -in your init file depends on a package). In that case, your init file -should call the function @code{package-initialize}. It is up to you -to ensure that relevant user options, such as @code{package-load-list} -(see below), are set up prior to the @code{package-initialize} call. -This will automatically set @code{package-enable-at-startup} to @code{nil}, to -avoid loading the packages again after processing the init file. -Alternatively, you may choose to completely inhibit package loading at -startup, and invoke the command @kbd{M-x package-initialize} to load -your packages manually. +@code{package-enable-at-startup} to @code{nil}. You must do this in +the early init file. Currently it cannot be done via Customize. @vindex package-load-list For finer control over package loading, you can use the variable diff --git a/doc/lispref/os.texi b/doc/lispref/os.texi index 501960bdc3..c6990909ab 100644 --- a/doc/lispref/os.texi +++ b/doc/lispref/os.texi @@ -361,6 +361,7 @@ Init File @cindex init file @cindex @file{.emacs} @cindex @file{init.el} +@cindex @file{early-init.el} When you start Emacs, it normally attempts to load your @dfn{init file}. This is either a file named @file{.emacs} or @file{.emacs.el} @@ -384,6 +385,19 @@ Init File file. If those environment variables are absent, though, Emacs uses your user-id to find your home directory. +@cindex early init file + Emacs also attempts to load a second init file, called the + @dfn{early init file}, if it exists. This is a file named + @file{early-init.el} in a subdirectory named @file{.emacs.d} in your + home directory. The difference is that the early init file is + loaded much earlier during the startup process, so you can use it to + customize some things that are initialized before loading the + regular init file. For example, here you can customize the process + of loading installed packages, by setting variables such as + @var{package-load-list} or + @var{package-enable-at-startup}. @xref{Package Installation,,, + emacs,The GNU Emacs Manual}. + @cindex default init file An Emacs installation may have a @dfn{default init file}, which is a Lisp library named @file{default.el}. Emacs finds this file through diff --git a/doc/lispref/package.texi b/doc/lispref/package.texi index 153ee48741..2e93f29bd2 100644 --- a/doc/lispref/package.texi +++ b/doc/lispref/package.texi @@ -106,10 +106,12 @@ Packaging Basics Whenever Emacs starts up, it automatically calls the function @code{package-initialize} to load installed packages. This is done -after loading the init file and abbrev file (if any) and before -running @code{after-init-hook} (@pxref{Startup Summary}). Automatic -package loading is disabled if the user option -@code{package-enable-at-startup} is @code{nil}. +after loading the early init file, but before loading the early init +file and abbrev file (if any) and before running +@code{after-init-hook} (@pxref{Startup Summary}). Automatic package +loading is disabled if the user option +@code{package-enable-at-startup} is @code{nil}. (Of course, the +setting of this user option must be done in the early init file.) @deffn Command package-initialize &optional no-activate This function initializes Emacs' internal record of which packages are @@ -123,6 +125,12 @@ Packaging Basics The optional argument @var{no-activate}, if non-@code{nil}, causes Emacs to update its record of installed packages without actually loading them; it is for internal use only. + +In most cases, you should not need to call @code{package-initialize}, +as this is done automatically during startup. Simply make sure to put +any code that should run before @code{package-initialize} in the early +init file, and any code that should run after in the primary init +file (@xref{Init File,,, emacs, The GNU Emacs Manual}). @end deffn @node Simple Packages diff --git a/doc/misc/org.texi b/doc/misc/org.texi index 1f6e10287d..36b7f87248 100644 --- a/doc/misc/org.texi +++ b/doc/misc/org.texi @@ -890,9 +890,7 @@ Installation been visited, i.e., where no Org built-in function have been loaded. Otherwise autoload Org functions will mess up the installation. -Then, to make sure your Org configuration is taken into account, initialize -the package system with @code{(package-initialize)} in your Emacs init file -before setting any Org option. If you want to use Org's package repository, +If you want to use Org's package repository, check out the @uref{http://orgmode.org/elpa.html, Org ELPA page}. @subsubheading Downloading Org as an archive diff --git a/etc/NEWS b/etc/NEWS index 1382f96a37..4bbf3e237a 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -41,6 +41,24 @@ can enable it when configuring, e.g., './configure CFLAGS="-g3 -O2 \f * Startup Changes in Emacs 27.1 ++++ +** Emacs can now be configured using an early init file. +The file is called early-init.el, in `user-emacs-directory'. It is +loaded very early in the startup process: in particular, before +graphical elements such as the tool bar are initialized, and before +the package manager is initialized. + ++++ +** Emacs now initializes package.el before loading the init-file. +This is part of a change intended to eliminate the behavior of +package.el inserting a call to (package-initialize) into the +init-file, which was previously done when Emacs was started. Users +who do not configure package.el variables such as `package-load-list' +and `package-user-dir' need not make any configuration changes. Users +who do configure such variables should place the configuration into +the newly introduced early init file, which is loaded before +package.el is initialized. + \f * Changes in Emacs 27.1 diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el index f8b4cc888d..815b679cae 100644 --- a/lisp/emacs-lisp/package.el +++ b/lisp/emacs-lisp/package.el @@ -1431,16 +1431,11 @@ package-read-all-archive-contents ;; available on disk. (defvar package--initialized nil) -(defvar package--init-file-ensured nil - "Whether we know the init file has package-initialize.") - ;;;###autoload (defun package-initialize (&optional no-activate) "Load Emacs Lisp packages, and activate them. The variable `package-load-list' controls which packages to load. If optional arg NO-ACTIVATE is non-nil, don't activate packages. -If `user-init-file' does not mention `(package-initialize)', add -it to the file. If called as part of loading `user-init-file', set `package-enable-at-startup' to nil, to prevent accidentally loading packages twice. @@ -1449,13 +1444,7 @@ package-initialize taken care of by `package-initialize'." (interactive) (setq package-alist nil) - (if after-init-time - (package--ensure-init-file) - ;; If `package-initialize' is before we finished loading the init - ;; file, it's obvious we don't need to ensure-init. - (setq package--init-file-ensured t - ;; And likely we don't need to run it again after init. - package-enable-at-startup nil)) + (setq package-enable-at-startup nil) (package-load-all-descriptors) (package-read-all-archive-contents) (unless no-activate @@ -1872,64 +1861,6 @@ package-download-transaction using `package-compute-transaction'." (mapc #'package-install-from-archive packages)) -(defun package--ensure-init-file () - "Ensure that the user's init file has `package-initialize'. -`package-initialize' doesn't have to be called, as long as it is -present somewhere in the file, even as a comment. If it is not, -add a call to it along with some explanatory comments." - ;; Don't mess with the init-file from "emacs -Q". - (when (and (stringp user-init-file) - (not package--init-file-ensured) - (file-readable-p user-init-file) - (file-writable-p user-init-file)) - (let* ((buffer (find-buffer-visiting user-init-file)) - buffer-name - (contains-init - (if buffer - (with-current-buffer buffer - (save-excursion - (save-restriction - (widen) - (goto-char (point-min)) - (re-search-forward "(package-initialize\\_>" nil 'noerror)))) - ;; Don't visit the file if we don't have to. - (with-temp-buffer - (insert-file-contents user-init-file) - (goto-char (point-min)) - (re-search-forward "(package-initialize\\_>" nil 'noerror))))) - (unless contains-init - (with-current-buffer (or buffer - (let ((delay-mode-hooks t) - (find-file-visit-truename t)) - (find-file-noselect user-init-file))) - (when buffer - (setq buffer-name (buffer-file-name)) - (set-visited-file-name (file-chase-links user-init-file))) - (save-excursion - (save-restriction - (widen) - (goto-char (point-min)) - (while (and (looking-at-p "[[:blank:]]*\\(;\\|$\\)") - (not (eobp))) - (forward-line 1)) - (insert - "\n" - ";; Added by Package.el. This must come before configurations of\n" - ";; installed packages. Don't delete this line. If you don't want it,\n" - ";; just comment it out by adding a semicolon to the start of the line.\n" - ";; You may delete these explanatory comments.\n" - "(package-initialize)\n") - (unless (looking-at-p "$") - (insert "\n")) - (let ((file-precious-flag t)) - (save-buffer)) - (if buffer - (progn - (set-visited-file-name buffer-name) - (set-buffer-modified-p nil)) - (kill-buffer (current-buffer))))))))) - (setq package--init-file-ensured t)) - ;;;###autoload (defun package-install (pkg &optional dont-select) "Install the package PKG. diff --git a/lisp/startup.el b/lisp/startup.el index 4575f1f94d..de85933983 100644 --- a/lisp/startup.el +++ b/lisp/startup.el @@ -312,6 +312,15 @@ inhibit-startup-hooks Currently this applies to: `emacs-startup-hook', `term-setup-hook', and `window-setup-hook'.") +(defvar early-init-file nil + "File name, including directory, of user's early init file. +If the file loaded had extension `.elc', and the corresponding +source file exists, this variable contains the name of source +file, suitable for use by functions like `custom-save-all' which +edit the init file. While Emacs loads and evaluates the init +file, value is the real name of the file, regardless of whether +or not it has the `.elc' extension.") + (defvar keyboard-type nil "The brand of keyboard you are using. This variable is used to define the proper function and keypad @@ -870,6 +879,129 @@ startup--setup-quote-display (when standard-display-table (aset standard-display-table char nil))))))) +(defun load-user-init-file + (compute-filename &optional compute-alternate-filename load-defaults) + "Load a user init-file. +COMPUTE-FILENAME is called with no arguments and should return +the name of the init-file to load. If this file cannot be loaded, +and COMPUTE-ALTERNATE-FILENAME is non-nil, then it is called with +no arguments and should return the name of an alternate init-file +to load. If LOAD-DEFAULTS is non-nil, then load default.el after +the init-file. + +This function sets `user-init-file' to the name of the loaded +init-file, or to a default value if loading is not possible." + (let ((debug-on-error-from-init-file nil) + (debug-on-error-should-be-set nil) + (debug-on-error-initial + (if (eq init-file-debug t) + 'startup + init-file-debug)) + (orig-enable-multibyte (default-value 'enable-multibyte-characters))) + (let ((debug-on-error debug-on-error-initial) + ;; We create an anonymous function here so that we can call + ;; it in different contexts depending on the value of + ;; `debug-on-error'. + (read-init-file + (lambda () + (when init-file-user + (let ((init-file-name (funcall compute-filename))) + + ;; If `user-init-file' is t, then `load' will store + ;; the name of the file that it loads into + ;; `user-init-file'. + (setq user-init-file t) + (load init-file-name 'noerror 'nomessage) + + (when (eq user-init-file t) + (let ((alt-file-name (funcall compute-alternate-filename))) + (load alt-file-name 'noerror 'nomessage) + + ;; If we did not find the user's init file, set + ;; user-init-file conclusively. Don't let it be + ;; set from default.el. + (when (eq user-init-file t) + (setq user-init-file init-file-name))))) + + ;; If we loaded a compiled file, set `user-init-file' to + ;; the source version if that exists. + (when (equal (file-name-extension user-init-file) + "elc") + (let* ((source (file-name-sans-extension user-init-file)) + (alt (concat source ".el"))) + (setq source (cond ((file-exists-p alt) alt) + ((file-exists-p source) source) + (t nil))) + (when source + (when (file-newer-than-file-p source user-init-file) + (message "Warning: %s is newer than %s" + source user-init-file) + (sit-for 1)) + (setq user-init-file source)))) + + (when load-defaults + + ;; Prevent default.el from changing the value of + ;; `inhibit-startup-screen'. + (let ((inhibit-startup-screen nil)) + (load "default" 'noerror 'nomessage))))))) + ;; Now call our anonymous function. + (if init-file-debug + ;; Do this without a `condition-case' if the user wants to + ;; debug. + (funcall read-init-file) + (condition-case error + (progn + (funcall read-init-file) + + ;; If a previous init-file had an error, don't forget + ;; about that. + (unless init-file-had-error + (setq init-file-had-error nil))) + (error + (display-warning + 'initialization + (format-message "\ +An error occurred while loading `%s':\n\n%s%s%s\n\n\ +To ensure normal operation, you should investigate and remove the +cause of the error in your initialization file. Start Emacs with +the `--debug-init' option to view a complete error backtrace." + user-init-file + (get (car error) 'error-message) + (if (cdr error) ": " "") + (mapconcat (lambda (s) (prin1-to-string s t)) + (cdr error) ", ")) + :warning) + (setq init-file-had-error t)))) + + ;; If we can tell that the init file altered debug-on-error, + ;; arrange to preserve the value that it set up. + (or (eq debug-on-error debug-on-error-initial) + (setq debug-on-error-should-be-set t + debug-on-error-from-init-file debug-on-error))) + + (when debug-on-error-should-be-set + (setq debug-on-error debug-on-error-from-init-file)) + + (unless (or (default-value 'enable-multibyte-characters) + (eq orig-enable-multibyte (default-value + 'enable-multibyte-characters))) + + ;; Init file changed to unibyte. Reset existing multibyte + ;; buffers (probably *scratch*, *Messages*, *Minibuf-0*). + ;; Arguably this should only be done if they're free of + ;; multibyte characters. + (mapc (lambda (buffer) + (with-current-buffer buffer + (if enable-multibyte-characters + (set-buffer-multibyte nil)))) + (buffer-list)) + + ;; Also re-set the language environment in case it was + ;; originally done before unibyte was set and is sensitive to + ;; unibyte (display table, terminal coding system &c). + (set-language-environment current-language-environment)))) + (defun command-line () "A subroutine of `normal-top-level'. Amongst another things, it parses the command-line arguments." @@ -1021,6 +1153,69 @@ command-line (and command-line-args (setcdr command-line-args args))) + ;; Warn for invalid user name. + (when init-file-user + (if (string-match "[~/:\n]" init-file-user) + (display-warning 'initialization + (format "Invalid user name %s" + init-file-user) + :error) + (if (file-directory-p (expand-file-name + ;; We don't support ~USER on MS-Windows + ;; and MS-DOS except for the current + ;; user, and always load .emacs from + ;; the current user's home directory + ;; (see below). So always check "~", + ;; even if invoked with "-u USER", or + ;; if $USER or $LOGNAME are set to + ;; something different. + (if (memq system-type '(windows-nt ms-dos)) + "~" + (concat "~" init-file-user)))) + nil + (display-warning 'initialization + (format "User %s has no home directory" + (if (equal init-file-user "") + (user-real-login-name) + init-file-user)) + :error)))) + + ;; Load the early init file, if found. + (load-user-init-file + (lambda () + (expand-file-name + "early-init" + (file-name-as-directory + (concat "~" init-file-user "/.emacs.d"))))) + (setq early-init-file user-init-file) + + ;; If any package directory exists, initialize the package system. + (and user-init-file + package-enable-at-startup + (catch 'package-dir-found + (let (dirs) + (if (boundp 'package-directory-list) + (setq dirs package-directory-list) + (dolist (f load-path) + (and (stringp f) + (equal (file-name-nondirectory f) "site-lisp") + (push (expand-file-name "elpa" f) dirs)))) + (push (if (boundp 'package-user-dir) + package-user-dir + (locate-user-emacs-file "elpa")) + dirs) + (dolist (dir dirs) + (when (file-directory-p dir) + (dolist (subdir (directory-files dir)) + (when (let ((subdir (expand-file-name subdir dir))) + (and (file-directory-p subdir) + (file-exists-p + (expand-file-name + (package--description-file subdir) + subdir)))) + (throw 'package-dir-found t))))))) + (package-initialize)) + ;; Make sure window system's init file was loaded in loadup.el if ;; using a window system. ;; Initialize the window-system only after processing the command-line @@ -1127,170 +1322,47 @@ command-line ;; the startup screen. (setq inhibit-startup-screen nil) - ;; Warn for invalid user name. - (when init-file-user - (if (string-match "[~/:\n]" init-file-user) - (display-warning 'initialization - (format "Invalid user name %s" - init-file-user) - :error) - (if (file-directory-p (expand-file-name - ;; We don't support ~USER on MS-Windows - ;; and MS-DOS except for the current - ;; user, and always load .emacs from - ;; the current user's home directory - ;; (see below). So always check "~", - ;; even if invoked with "-u USER", or - ;; if $USER or $LOGNAME are set to - ;; something different. - (if (memq system-type '(windows-nt ms-dos)) - "~" - (concat "~" init-file-user)))) - nil - (display-warning 'initialization - (format "User %s has no home directory" - (if (equal init-file-user "") - (user-real-login-name) - init-file-user)) - :error)))) - ;; Load that user's init file, or the default one, or none. - (let (debug-on-error-from-init-file - debug-on-error-should-be-set - (debug-on-error-initial - (if (eq init-file-debug t) 'startup init-file-debug)) - (orig-enable-multibyte (default-value 'enable-multibyte-characters))) - (let ((debug-on-error debug-on-error-initial) - ;; This function actually reads the init files. - (inner - (function - (lambda () - (if init-file-user - (let ((user-init-file-1 - (cond - ((eq system-type 'ms-dos) - (concat "~" init-file-user "/_emacs")) - ((not (eq system-type 'windows-nt)) - (concat "~" init-file-user "/.emacs")) - ;; Else deal with the Windows situation - ((directory-files "~" nil "^\\.emacs\\(\\.elc?\\)?$") - ;; Prefer .emacs on Windows. - "~/.emacs") - ((directory-files "~" nil "^_emacs\\(\\.elc?\\)?$") - ;; Also support _emacs for compatibility, but warn about it. - (push `(initialization - ,(format-message - "`_emacs' init file is deprecated, please use `.emacs'")) - delayed-warnings-list) - "~/_emacs") - (t ;; But default to .emacs if _emacs does not exist. - "~/.emacs")))) - ;; This tells `load' to store the file name found - ;; into user-init-file. - (setq user-init-file t) - (load user-init-file-1 t t) - - (when (eq user-init-file t) - ;; If we did not find ~/.emacs, try - ;; ~/.emacs.d/init.el. - (let ((otherfile - (expand-file-name - "init" - (file-name-as-directory - (concat "~" init-file-user "/.emacs.d"))))) - (load otherfile t t) - - ;; If we did not find the user's init file, - ;; set user-init-file conclusively. - ;; Don't let it be set from default.el. - (when (eq user-init-file t) - (setq user-init-file user-init-file-1)))) - - ;; If we loaded a compiled file, set - ;; `user-init-file' to the source version if that - ;; exists. - (when (and user-init-file - (equal (file-name-extension user-init-file) - "elc")) - (let* ((source (file-name-sans-extension user-init-file)) - (alt (concat source ".el"))) - (setq source (cond ((file-exists-p alt) alt) - ((file-exists-p source) source) - (t nil))) - (when source - (when (file-newer-than-file-p source user-init-file) - (message "Warning: %s is newer than %s" - source user-init-file) - (sit-for 1)) - (setq user-init-file source)))) - - (unless inhibit-default-init - (let ((inhibit-startup-screen nil)) - ;; Users are supposed to be told their rights. - ;; (Plus how to get help and how to undo.) - ;; Don't you dare turn this off for anyone - ;; except yourself. - (load "default" t t))))))))) - (if init-file-debug - ;; Do this without a condition-case if the user wants to debug. - (funcall inner) - (condition-case error - (progn - (funcall inner) - (setq init-file-had-error nil)) - (error - (display-warning - 'initialization - (format-message "\ -An error occurred while loading `%s':\n\n%s%s%s\n\n\ -To ensure normal operation, you should investigate and remove the -cause of the error in your initialization file. Start Emacs with -the `--debug-init' option to view a complete error backtrace." - user-init-file - (get (car error) 'error-message) - (if (cdr error) ": " "") - (mapconcat (lambda (s) (prin1-to-string s t)) - (cdr error) ", ")) - :warning) - (setq init-file-had-error t)))) - - (if (and deactivate-mark transient-mark-mode) - (with-current-buffer (window-buffer) - (deactivate-mark))) - - ;; If the user has a file of abbrevs, read it (unless -batch). - (when (and (not noninteractive) - (file-exists-p abbrev-file-name) - (file-readable-p abbrev-file-name)) - (quietly-read-abbrev-file abbrev-file-name)) - - ;; If the abbrevs came entirely from the init file or the - ;; abbrevs file, they do not need saving. - (setq abbrevs-changed nil) - - ;; If we can tell that the init file altered debug-on-error, - ;; arrange to preserve the value that it set up. - (or (eq debug-on-error debug-on-error-initial) - (setq debug-on-error-should-be-set t - debug-on-error-from-init-file debug-on-error))) - (if debug-on-error-should-be-set - (setq debug-on-error debug-on-error-from-init-file)) - (unless (or (default-value 'enable-multibyte-characters) - (eq orig-enable-multibyte (default-value - 'enable-multibyte-characters))) - ;; Init file changed to unibyte. Reset existing multibyte - ;; buffers (probably *scratch*, *Messages*, *Minibuf-0*). - ;; Arguably this should only be done if they're free of - ;; multibyte characters. - (mapc (lambda (buffer) - (with-current-buffer buffer - (if enable-multibyte-characters - (set-buffer-multibyte nil)))) - (buffer-list)) - ;; Also re-set the language environment in case it was - ;; originally done before unibyte was set and is sensitive to - ;; unibyte (display table, terminal coding system &c). - (set-language-environment current-language-environment))) + (load-user-init-file + (lambda () + (cond + ((eq system-type 'ms-dos) + (concat "~" init-file-user "/_emacs")) + ((not (eq system-type 'windows-nt)) + (concat "~" init-file-user "/.emacs")) + ;; Else deal with the Windows situation. + ((directory-files "~" nil "^\\.emacs\\(\\.elc?\\)?$") + ;; Prefer .emacs on Windows. + "~/.emacs") + ((directory-files "~" nil "^_emacs\\(\\.elc?\\)?$") + ;; Also support _emacs for compatibility, but warn about it. + (push `(initialization + ,(format-message + "`_emacs' init file is deprecated, please use `.emacs'")) + delayed-warnings-list) + "~/_emacs") + (t ;; But default to .emacs if _emacs does not exist. + "~/.emacs"))) + (lambda () + (expand-file-name + "init" + (file-name-as-directory + (concat "~" init-file-user "/.emacs.d")))) + (not inhibit-default-init)) + + (when (and deactivate-mark transient-mark-mode) + (with-current-buffer (window-buffer) + (deactivate-mark))) + + ;; If the user has a file of abbrevs, read it (unless -batch). + (when (and (not noninteractive) + (file-exists-p abbrev-file-name) + (file-readable-p abbrev-file-name)) + (quietly-read-abbrev-file abbrev-file-name)) + + ;; If the abbrevs came entirely from the init file or the + ;; abbrevs file, they do not need saving. + (setq abbrevs-changed nil) ;; Do this here in case the init file sets mail-host-address. (and mail-host-address @@ -1312,33 +1384,6 @@ command-line (eq face-ignored-fonts old-face-ignored-fonts)) (clear-face-cache))) - ;; If any package directory exists, initialize the package system. - (and user-init-file - package-enable-at-startup - (catch 'package-dir-found - (let (dirs) - (if (boundp 'package-directory-list) - (setq dirs package-directory-list) - (dolist (f load-path) - (and (stringp f) - (equal (file-name-nondirectory f) "site-lisp") - (push (expand-file-name "elpa" f) dirs)))) - (push (if (boundp 'package-user-dir) - package-user-dir - (locate-user-emacs-file "elpa")) - dirs) - (dolist (dir dirs) - (when (file-directory-p dir) - (dolist (subdir (directory-files dir)) - (when (let ((subdir (expand-file-name subdir dir))) - (and (file-directory-p subdir) - (file-exists-p - (expand-file-name - (package--description-file subdir) - subdir)))) - (throw 'package-dir-found t))))))) - (package-initialize)) - (setq after-init-time (current-time)) ;; Display any accumulated warnings after all functions in ;; `after-init-hook' like `desktop-read' have finalized possible diff --git a/src/lread.c b/src/lread.c index 52897b4fcc..5ff438041b 100644 --- a/src/lread.c +++ b/src/lread.c @@ -4892,7 +4892,7 @@ directory. These file names are converted to absolute at startup. */); If the file loaded had extension `.elc', and the corresponding source file exists, this variable contains the name of source file, suitable for use by functions like `custom-save-all' which edit the init file. -While Emacs loads and evaluates the init file, value is the real name +While Emacs loads and evaluates any init file, value is the real name of the file, regardless of whether or not it has the `.elc' extension. */); Vuser_init_file = Qnil; -- 2.14.3 ^ permalink raw reply related [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-01-25 4:35 ` Radon Rosborough @ 2018-01-25 15:43 ` Clément Pit-Claudel 2018-01-25 16:03 ` Stefan Monnier 2018-01-25 17:07 ` [PATCH] Fixing package-initialize, adding early init file Stefan Monnier 1 sibling, 1 reply; 838+ messages in thread From: Clément Pit-Claudel @ 2018-01-25 15:43 UTC (permalink / raw) To: Radon Rosborough, Stefan Monnier; +Cc: emacs-devel On 2018-01-24 23:35, Radon Rosborough wrote: > Since it has been more than a month with no response, I am re-posting > the patch which fixes the problems previously discussed [1] [2] [3] > with `package-initialize' by adding a second (optional) init-file > `early-init.el'. This patch includes some refactoring of the code in > `startup.el' to provide for loading any number of init-files in an > extensible way. I hope that the change can be included in Emacs 26.2 > or Emacs 27. Thanks for this patch. I think it'd be great to have it. I've added some (very few) comments below. > diff --git a/doc/emacs/package.texi b/doc/emacs/package.texi > index 215f50cb40..bd7cccce6c 100644 > --- a/doc/emacs/package.texi > +++ b/doc/emacs/package.texi > @@ -253,30 +253,16 @@ Package Installation > consult the package's help buffer. > > By default, Emacs also automatically loads all installed packages in > -subsequent Emacs sessions. This happens at startup, after processing > -the init file (@pxref{Init File}). As an exception, Emacs does not > -load packages at startup if invoked with the @samp{-q} or > -@samp{--no-init-file} options (@pxref{Initial Options}). > +subsequent Emacs sessions. This happens at startup, before processing Was this supposed to be "previous" rather than "subsequent" (this isn't from your patch, though). > +the init file but after processing the early init file (@pxref{Early > +Init File,,, elisp, The Emacs Lisp Reference Manual}). As an > +exception, Emacs does not load packages at startup if invoked with the > +@samp{-q} or @samp{--no-init-file} options (@xref{Initial Options}). > > @vindex package-enable-at-startup > To disable automatic package loading, change the variable > -@code{package-enable-at-startup} to @code{nil}. > - > -@findex package-initialize > - The reason automatic package loading occurs after loading the init > -file is that user options only receive their customized values after > -loading the init file, including user options which affect the > -packaging system. In some circumstances, you may want to load > -packages explicitly in your init file (usually because some other code > -in your init file depends on a package). In that case, your init file > -should call the function @code{package-initialize}. It is up to you > -to ensure that relevant user options, such as @code{package-load-list} > -(see below), are set up prior to the @code{package-initialize} call. > -This will automatically set @code{package-enable-at-startup} to @code{nil}, to > -avoid loading the packages again after processing the init file. > -Alternatively, you may choose to completely inhibit package loading at > -startup, and invoke the command @kbd{M-x package-initialize} to load > -your packages manually. > +@code{package-enable-at-startup} to @code{nil}. You must do this in > +the early init file. Currently it cannot be done via Customize. I'd add ", as this variable is read before loading the regular init file." after "in the early init file". > @vindex package-load-list > For finer control over package loading, you can use the variable > diff --git a/doc/lispref/os.texi b/doc/lispref/os.texi > index 501960bdc3..c6990909ab 100644 > --- a/doc/lispref/os.texi > +++ b/doc/lispref/os.texi > @@ -361,6 +361,7 @@ Init File > @cindex init file > @cindex @file{.emacs} > @cindex @file{init.el} > +@cindex @file{early-init.el} > > When you start Emacs, it normally attempts to load your @dfn{init > file}. This is either a file named @file{.emacs} or @file{.emacs.el} > @@ -384,6 +385,19 @@ Init File > file. If those environment variables are absent, though, Emacs uses > your user-id to find your home directory. > > +@cindex early init file > + Emacs also attempts to load a second init file, called the > + @dfn{early init file}, if it exists. This is a file named > + @file{early-init.el} in a subdirectory named @file{.emacs.d} in your > + home directory. The difference is that the early init file is > + loaded much earlier during the startup process, so you can use it to > + customize some things that are initialized before loading the > + regular init file. For example, here you can customize the process I'd say "For example, you can use that file to customize the process" > + of loading installed packages, by setting variables such as > + @var{package-load-list} or > + @var{package-enable-at-startup}. @xref{Package Installation,,, > + emacs,The GNU Emacs Manual}. > + > @cindex default init file > An Emacs installation may have a @dfn{default init file}, which is a > Lisp library named @file{default.el}. Emacs finds this file through > diff --git a/doc/lispref/package.texi b/doc/lispref/package.texi > index 153ee48741..2e93f29bd2 100644 > --- a/doc/lispref/package.texi > +++ b/doc/lispref/package.texi > @@ -106,10 +106,12 @@ Packaging Basics > > Whenever Emacs starts up, it automatically calls the function > @code{package-initialize} to load installed packages. This is done > -after loading the init file and abbrev file (if any) and before > -running @code{after-init-hook} (@pxref{Startup Summary}). Automatic > -package loading is disabled if the user option > -@code{package-enable-at-startup} is @code{nil}. > +after loading the early init file, but before loading the early init This should say "but before loading the *reguar* init file." > +file and abbrev file (if any) and before running > +@code{after-init-hook} (@pxref{Startup Summary}). Automatic package > +loading is disabled if the user option > +@code{package-enable-at-startup} is @code{nil}. (Of course, the > +setting of this user option must be done in the early init file.) I'd simplify this to "if the option … is *set to* nil in the early init file." > @deffn Command package-initialize &optional no-activate > This function initializes Emacs' internal record of which packages are > @@ -123,6 +125,12 @@ Packaging Basics > The optional argument @var{no-activate}, if non-@code{nil}, causes > Emacs to update its record of installed packages without actually > loading them; it is for internal use only. > + > +In most cases, you should not need to call @code{package-initialize}, > +as this is done automatically during startup. Simply make sure to put > +any code that should run before @code{package-initialize} in the early > +init file, and any code that should run after in the primary init after *it*, maybe? > +file (@xref{Init File,,, emacs, The GNU Emacs Manual}). > @end deffn > > @node Simple Packages > diff --git a/doc/misc/org.texi b/doc/misc/org.texi > index 1f6e10287d..36b7f87248 100644 > --- a/doc/misc/org.texi > +++ b/doc/misc/org.texi > @@ -890,9 +890,7 @@ Installation > been visited, i.e., where no Org built-in function have been loaded. > Otherwise autoload Org functions will mess up the installation. > > -Then, to make sure your Org configuration is taken into account, initialize > -the package system with @code{(package-initialize)} in your Emacs init file > -before setting any Org option. If you want to use Org's package repository, > +If you want to use Org's package repository, > check out the @uref{http://orgmode.org/elpa.html, Org ELPA page}. > > @subsubheading Downloading Org as an archive > diff --git a/etc/NEWS b/etc/NEWS > index 1382f96a37..4bbf3e237a 100644 > --- a/etc/NEWS > +++ b/etc/NEWS > @@ -41,6 +41,24 @@ can enable it when configuring, e.g., './configure CFLAGS="-g3 -O2 > \f > * Startup Changes in Emacs 27.1 > > ++++ > +** Emacs can now be configured using an early init file. > +The file is called early-init.el, in `user-emacs-directory'. It is > +loaded very early in the startup process: in particular, before no need for "in particular," here? > +graphical elements such as the tool bar are initialized, and before > +the package manager is initialized. > + > ++++ > +** Emacs now initializes package.el before loading the init-file. I think "calls package-initialize" would be clearer. > +This is part of a change intended to eliminate the behavior of > +package.el inserting a call to (package-initialize) into the > +init-file, which was previously done when Emacs was started. Users > +who do not configure package.el variables such as `package-load-list' > +and `package-user-dir' need not make any configuration changes. Users > +who do configure such variables should place the configuration into > +the newly introduced early init file, which is loaded before > +package.el is initialized. I'd mention here that variables like package-archives do not need to move to the early init file. > + > \f > * Changes in Emacs 27.1 > > diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el > index f8b4cc888d..815b679cae 100644 > --- a/lisp/emacs-lisp/package.el > +++ b/lisp/emacs-lisp/package.el > @@ -1431,16 +1431,11 @@ package-read-all-archive-contents > ;; available on disk. > (defvar package--initialized nil) > > -(defvar package--init-file-ensured nil > - "Whether we know the init file has package-initialize.") > - > ;;;###autoload > (defun package-initialize (&optional no-activate) > "Load Emacs Lisp packages, and activate them. > The variable `package-load-list' controls which packages to load. > If optional arg NO-ACTIVATE is non-nil, don't activate packages. > -If `user-init-file' does not mention `(package-initialize)', add > -it to the file. > If called as part of loading `user-init-file', set > `package-enable-at-startup' to nil, to prevent accidentally > loading packages twice. > @@ -1449,13 +1444,7 @@ package-initialize > taken care of by `package-initialize'." > (interactive) > (setq package-alist nil) > - (if after-init-time > - (package--ensure-init-file) > - ;; If `package-initialize' is before we finished loading the init > - ;; file, it's obvious we don't need to ensure-init. > - (setq package--init-file-ensured t > - ;; And likely we don't need to run it again after init. > - package-enable-at-startup nil)) > + (setq package-enable-at-startup nil) > (package-load-all-descriptors) > (package-read-all-archive-contents) > (unless no-activate > @@ -1872,64 +1861,6 @@ package-download-transaction > using `package-compute-transaction'." > (mapc #'package-install-from-archive packages)) > > -(defun package--ensure-init-file () > - "Ensure that the user's init file has `package-initialize'. > -`package-initialize' doesn't have to be called, as long as it is > -present somewhere in the file, even as a comment. If it is not, > -add a call to it along with some explanatory comments." > - ;; Don't mess with the init-file from "emacs -Q". > - (when (and (stringp user-init-file) > - (not package--init-file-ensured) > - (file-readable-p user-init-file) > - (file-writable-p user-init-file)) > - (let* ((buffer (find-buffer-visiting user-init-file)) > - buffer-name > - (contains-init > - (if buffer > - (with-current-buffer buffer > - (save-excursion > - (save-restriction > - (widen) > - (goto-char (point-min)) > - (re-search-forward "(package-initialize\\_>" nil 'noerror)))) > - ;; Don't visit the file if we don't have to. > - (with-temp-buffer > - (insert-file-contents user-init-file) > - (goto-char (point-min)) > - (re-search-forward "(package-initialize\\_>" nil 'noerror))))) > - (unless contains-init > - (with-current-buffer (or buffer > - (let ((delay-mode-hooks t) > - (find-file-visit-truename t)) > - (find-file-noselect user-init-file))) > - (when buffer > - (setq buffer-name (buffer-file-name)) > - (set-visited-file-name (file-chase-links user-init-file))) > - (save-excursion > - (save-restriction > - (widen) > - (goto-char (point-min)) > - (while (and (looking-at-p "[[:blank:]]*\\(;\\|$\\)") > - (not (eobp))) > - (forward-line 1)) > - (insert > - "\n" > - ";; Added by Package.el. This must come before configurations of\n" > - ";; installed packages. Don't delete this line. If you don't want it,\n" > - ";; just comment it out by adding a semicolon to the start of the line.\n" > - ";; You may delete these explanatory comments.\n" > - "(package-initialize)\n") > - (unless (looking-at-p "$") > - (insert "\n")) > - (let ((file-precious-flag t)) > - (save-buffer)) > - (if buffer > - (progn > - (set-visited-file-name buffer-name) > - (set-buffer-modified-p nil)) > - (kill-buffer (current-buffer))))))))) > - (setq package--init-file-ensured t)) > - > ;;;###autoload > (defun package-install (pkg &optional dont-select) > "Install the package PKG. > diff --git a/lisp/startup.el b/lisp/startup.el > index 4575f1f94d..de85933983 100644 > --- a/lisp/startup.el > +++ b/lisp/startup.el > @@ -312,6 +312,15 @@ inhibit-startup-hooks > Currently this applies to: `emacs-startup-hook', `term-setup-hook', > and `window-setup-hook'.") > > +(defvar early-init-file nil > + "File name, including directory, of user's early init file. > +If the file loaded had extension `.elc', and the corresponding > +source file exists, this variable contains the name of source > +file, suitable for use by functions like `custom-save-all' which > +edit the init file. While Emacs loads and evaluates the init > +file, value is the real name of the file, regardless of whether > +or not it has the `.elc' extension.") > + > (defvar keyboard-type nil > "The brand of keyboard you are using. > This variable is used to define the proper function and keypad > @@ -870,6 +879,129 @@ startup--setup-quote-display > (when standard-display-table > (aset standard-display-table char nil))))))) > > +(defun load-user-init-file > + (compute-filename &optional compute-alternate-filename load-defaults) > + "Load a user init-file. > +COMPUTE-FILENAME is called with no arguments and should return > +the name of the init-file to load. If this file cannot be loaded, > +and COMPUTE-ALTERNATE-FILENAME is non-nil, then it is called with > +no arguments and should return the name of an alternate init-file > +to load. If LOAD-DEFAULTS is non-nil, then load default.el after > +the init-file. > + > +This function sets `user-init-file' to the name of the loaded > +init-file, or to a default value if loading is not possible." > + (let ((debug-on-error-from-init-file nil) > + (debug-on-error-should-be-set nil) > + (debug-on-error-initial > + (if (eq init-file-debug t) > + 'startup > + init-file-debug)) > + (orig-enable-multibyte (default-value 'enable-multibyte-characters))) > + (let ((debug-on-error debug-on-error-initial) > + ;; We create an anonymous function here so that we can call > + ;; it in different contexts depending on the value of > + ;; `debug-on-error'. > + (read-init-file > + (lambda () > + (when init-file-user > + (let ((init-file-name (funcall compute-filename))) > + > + ;; If `user-init-file' is t, then `load' will store > + ;; the name of the file that it loads into > + ;; `user-init-file'. > + (setq user-init-file t) > + (load init-file-name 'noerror 'nomessage) > + > + (when (eq user-init-file t) > + (let ((alt-file-name (funcall compute-alternate-filename))) > + (load alt-file-name 'noerror 'nomessage) > + > + ;; If we did not find the user's init file, set > + ;; user-init-file conclusively. Don't let it be > + ;; set from default.el. > + (when (eq user-init-file t) > + (setq user-init-file init-file-name))))) > + > + ;; If we loaded a compiled file, set `user-init-file' to > + ;; the source version if that exists. > + (when (equal (file-name-extension user-init-file) > + "elc") > + (let* ((source (file-name-sans-extension user-init-file)) > + (alt (concat source ".el"))) > + (setq source (cond ((file-exists-p alt) alt) > + ((file-exists-p source) source) > + (t nil))) > + (when source > + (when (file-newer-than-file-p source user-init-file) > + (message "Warning: %s is newer than %s" > + source user-init-file) > + (sit-for 1)) > + (setq user-init-file source)))) > + > + (when load-defaults > + > + ;; Prevent default.el from changing the value of > + ;; `inhibit-startup-screen'. > + (let ((inhibit-startup-screen nil)) > + (load "default" 'noerror 'nomessage))))))) > + ;; Now call our anonymous function. > + (if init-file-debug > + ;; Do this without a `condition-case' if the user wants to > + ;; debug. > + (funcall read-init-file) > + (condition-case error > + (progn > + (funcall read-init-file) > + > + ;; If a previous init-file had an error, don't forget > + ;; about that. > + (unless init-file-had-error > + (setq init-file-had-error nil))) > + (error > + (display-warning > + 'initialization > + (format-message "\ > +An error occurred while loading `%s':\n\n%s%s%s\n\n\ > +To ensure normal operation, you should investigate and remove the > +cause of the error in your initialization file. Start Emacs with > +the `--debug-init' option to view a complete error backtrace." > + user-init-file > + (get (car error) 'error-message) > + (if (cdr error) ": " "") > + (mapconcat (lambda (s) (prin1-to-string s t)) > + (cdr error) ", ")) > + :warning) > + (setq init-file-had-error t)))) > + > + ;; If we can tell that the init file altered debug-on-error, > + ;; arrange to preserve the value that it set up. > + (or (eq debug-on-error debug-on-error-initial) > + (setq debug-on-error-should-be-set t > + debug-on-error-from-init-file debug-on-error))) > + > + (when debug-on-error-should-be-set > + (setq debug-on-error debug-on-error-from-init-file)) > + > + (unless (or (default-value 'enable-multibyte-characters) > + (eq orig-enable-multibyte (default-value > + 'enable-multibyte-characters))) > + > + ;; Init file changed to unibyte. Reset existing multibyte > + ;; buffers (probably *scratch*, *Messages*, *Minibuf-0*). > + ;; Arguably this should only be done if they're free of > + ;; multibyte characters. > + (mapc (lambda (buffer) > + (with-current-buffer buffer > + (if enable-multibyte-characters > + (set-buffer-multibyte nil)))) > + (buffer-list)) > + > + ;; Also re-set the language environment in case it was > + ;; originally done before unibyte was set and is sensitive to > + ;; unibyte (display table, terminal coding system &c). > + (set-language-environment current-language-environment)))) > + > (defun command-line () > "A subroutine of `normal-top-level'. > Amongst another things, it parses the command-line arguments." > @@ -1021,6 +1153,69 @@ command-line > (and command-line-args > (setcdr command-line-args args))) > > + ;; Warn for invalid user name. > + (when init-file-user > + (if (string-match "[~/:\n]" init-file-user) > + (display-warning 'initialization > + (format "Invalid user name %s" > + init-file-user) > + :error) > + (if (file-directory-p (expand-file-name > + ;; We don't support ~USER on MS-Windows > + ;; and MS-DOS except for the current > + ;; user, and always load .emacs from > + ;; the current user's home directory > + ;; (see below). So always check "~", > + ;; even if invoked with "-u USER", or > + ;; if $USER or $LOGNAME are set to > + ;; something different. > + (if (memq system-type '(windows-nt ms-dos)) > + "~" > + (concat "~" init-file-user)))) > + nil > + (display-warning 'initialization > + (format "User %s has no home directory" > + (if (equal init-file-user "") > + (user-real-login-name) > + init-file-user)) > + :error)))) > + > + ;; Load the early init file, if found. > + (load-user-init-file > + (lambda () > + (expand-file-name > + "early-init" > + (file-name-as-directory > + (concat "~" init-file-user "/.emacs.d"))))) > + (setq early-init-file user-init-file) > + > + ;; If any package directory exists, initialize the package system. > + (and user-init-file > + package-enable-at-startup > + (catch 'package-dir-found > + (let (dirs) > + (if (boundp 'package-directory-list) > + (setq dirs package-directory-list) > + (dolist (f load-path) > + (and (stringp f) > + (equal (file-name-nondirectory f) "site-lisp") > + (push (expand-file-name "elpa" f) dirs)))) > + (push (if (boundp 'package-user-dir) > + package-user-dir > + (locate-user-emacs-file "elpa")) > + dirs) > + (dolist (dir dirs) > + (when (file-directory-p dir) > + (dolist (subdir (directory-files dir)) > + (when (let ((subdir (expand-file-name subdir dir))) > + (and (file-directory-p subdir) > + (file-exists-p > + (expand-file-name > + (package--description-file subdir) > + subdir)))) > + (throw 'package-dir-found t))))))) > + (package-initialize)) > + > ;; Make sure window system's init file was loaded in loadup.el if > ;; using a window system. > ;; Initialize the window-system only after processing the command-line > @@ -1127,170 +1322,47 @@ command-line > ;; the startup screen. > (setq inhibit-startup-screen nil) > > - ;; Warn for invalid user name. > - (when init-file-user > - (if (string-match "[~/:\n]" init-file-user) > - (display-warning 'initialization > - (format "Invalid user name %s" > - init-file-user) > - :error) > - (if (file-directory-p (expand-file-name > - ;; We don't support ~USER on MS-Windows > - ;; and MS-DOS except for the current > - ;; user, and always load .emacs from > - ;; the current user's home directory > - ;; (see below). So always check "~", > - ;; even if invoked with "-u USER", or > - ;; if $USER or $LOGNAME are set to > - ;; something different. > - (if (memq system-type '(windows-nt ms-dos)) > - "~" > - (concat "~" init-file-user)))) > - nil > - (display-warning 'initialization > - (format "User %s has no home directory" > - (if (equal init-file-user "") > - (user-real-login-name) > - init-file-user)) > - :error)))) > - > ;; Load that user's init file, or the default one, or none. > - (let (debug-on-error-from-init-file > - debug-on-error-should-be-set > - (debug-on-error-initial > - (if (eq init-file-debug t) 'startup init-file-debug)) > - (orig-enable-multibyte (default-value 'enable-multibyte-characters))) > - (let ((debug-on-error debug-on-error-initial) > - ;; This function actually reads the init files. > - (inner > - (function > - (lambda () > - (if init-file-user > - (let ((user-init-file-1 > - (cond > - ((eq system-type 'ms-dos) > - (concat "~" init-file-user "/_emacs")) > - ((not (eq system-type 'windows-nt)) > - (concat "~" init-file-user "/.emacs")) > - ;; Else deal with the Windows situation > - ((directory-files "~" nil "^\\.emacs\\(\\.elc?\\)?$") > - ;; Prefer .emacs on Windows. > - "~/.emacs") > - ((directory-files "~" nil "^_emacs\\(\\.elc?\\)?$") > - ;; Also support _emacs for compatibility, but warn about it. > - (push `(initialization > - ,(format-message > - "`_emacs' init file is deprecated, please use `.emacs'")) > - delayed-warnings-list) > - "~/_emacs") > - (t ;; But default to .emacs if _emacs does not exist. > - "~/.emacs")))) > - ;; This tells `load' to store the file name found > - ;; into user-init-file. > - (setq user-init-file t) > - (load user-init-file-1 t t) > - > - (when (eq user-init-file t) > - ;; If we did not find ~/.emacs, try > - ;; ~/.emacs.d/init.el. > - (let ((otherfile > - (expand-file-name > - "init" > - (file-name-as-directory > - (concat "~" init-file-user "/.emacs.d"))))) > - (load otherfile t t) > - > - ;; If we did not find the user's init file, > - ;; set user-init-file conclusively. > - ;; Don't let it be set from default.el. > - (when (eq user-init-file t) > - (setq user-init-file user-init-file-1)))) > - > - ;; If we loaded a compiled file, set > - ;; `user-init-file' to the source version if that > - ;; exists. > - (when (and user-init-file > - (equal (file-name-extension user-init-file) > - "elc")) > - (let* ((source (file-name-sans-extension user-init-file)) > - (alt (concat source ".el"))) > - (setq source (cond ((file-exists-p alt) alt) > - ((file-exists-p source) source) > - (t nil))) > - (when source > - (when (file-newer-than-file-p source user-init-file) > - (message "Warning: %s is newer than %s" > - source user-init-file) > - (sit-for 1)) > - (setq user-init-file source)))) > - > - (unless inhibit-default-init > - (let ((inhibit-startup-screen nil)) > - ;; Users are supposed to be told their rights. > - ;; (Plus how to get help and how to undo.) > - ;; Don't you dare turn this off for anyone > - ;; except yourself. > - (load "default" t t))))))))) > - (if init-file-debug > - ;; Do this without a condition-case if the user wants to debug. > - (funcall inner) > - (condition-case error > - (progn > - (funcall inner) > - (setq init-file-had-error nil)) > - (error > - (display-warning > - 'initialization > - (format-message "\ > -An error occurred while loading `%s':\n\n%s%s%s\n\n\ > -To ensure normal operation, you should investigate and remove the > -cause of the error in your initialization file. Start Emacs with > -the `--debug-init' option to view a complete error backtrace." > - user-init-file > - (get (car error) 'error-message) > - (if (cdr error) ": " "") > - (mapconcat (lambda (s) (prin1-to-string s t)) > - (cdr error) ", ")) > - :warning) > - (setq init-file-had-error t)))) > - > - (if (and deactivate-mark transient-mark-mode) > - (with-current-buffer (window-buffer) > - (deactivate-mark))) > - > - ;; If the user has a file of abbrevs, read it (unless -batch). > - (when (and (not noninteractive) > - (file-exists-p abbrev-file-name) > - (file-readable-p abbrev-file-name)) > - (quietly-read-abbrev-file abbrev-file-name)) > - > - ;; If the abbrevs came entirely from the init file or the > - ;; abbrevs file, they do not need saving. > - (setq abbrevs-changed nil) > - > - ;; If we can tell that the init file altered debug-on-error, > - ;; arrange to preserve the value that it set up. > - (or (eq debug-on-error debug-on-error-initial) > - (setq debug-on-error-should-be-set t > - debug-on-error-from-init-file debug-on-error))) > - (if debug-on-error-should-be-set > - (setq debug-on-error debug-on-error-from-init-file)) > - (unless (or (default-value 'enable-multibyte-characters) > - (eq orig-enable-multibyte (default-value > - 'enable-multibyte-characters))) > - ;; Init file changed to unibyte. Reset existing multibyte > - ;; buffers (probably *scratch*, *Messages*, *Minibuf-0*). > - ;; Arguably this should only be done if they're free of > - ;; multibyte characters. > - (mapc (lambda (buffer) > - (with-current-buffer buffer > - (if enable-multibyte-characters > - (set-buffer-multibyte nil)))) > - (buffer-list)) > - ;; Also re-set the language environment in case it was > - ;; originally done before unibyte was set and is sensitive to > - ;; unibyte (display table, terminal coding system &c). > - (set-language-environment current-language-environment))) > + (load-user-init-file > + (lambda () > + (cond > + ((eq system-type 'ms-dos) > + (concat "~" init-file-user "/_emacs")) > + ((not (eq system-type 'windows-nt)) > + (concat "~" init-file-user "/.emacs")) > + ;; Else deal with the Windows situation. > + ((directory-files "~" nil "^\\.emacs\\(\\.elc?\\)?$") > + ;; Prefer .emacs on Windows. > + "~/.emacs") > + ((directory-files "~" nil "^_emacs\\(\\.elc?\\)?$") > + ;; Also support _emacs for compatibility, but warn about it. > + (push `(initialization > + ,(format-message > + "`_emacs' init file is deprecated, please use `.emacs'")) > + delayed-warnings-list) > + "~/_emacs") > + (t ;; But default to .emacs if _emacs does not exist. > + "~/.emacs"))) > + (lambda () > + (expand-file-name > + "init" > + (file-name-as-directory > + (concat "~" init-file-user "/.emacs.d")))) > + (not inhibit-default-init)) > + > + (when (and deactivate-mark transient-mark-mode) > + (with-current-buffer (window-buffer) > + (deactivate-mark))) > + > + ;; If the user has a file of abbrevs, read it (unless -batch). > + (when (and (not noninteractive) > + (file-exists-p abbrev-file-name) > + (file-readable-p abbrev-file-name)) > + (quietly-read-abbrev-file abbrev-file-name)) > + > + ;; If the abbrevs came entirely from the init file or the > + ;; abbrevs file, they do not need saving. > + (setq abbrevs-changed nil) > > ;; Do this here in case the init file sets mail-host-address. > (and mail-host-address > @@ -1312,33 +1384,6 @@ command-line > (eq face-ignored-fonts old-face-ignored-fonts)) > (clear-face-cache))) > > - ;; If any package directory exists, initialize the package system. > - (and user-init-file > - package-enable-at-startup > - (catch 'package-dir-found > - (let (dirs) > - (if (boundp 'package-directory-list) > - (setq dirs package-directory-list) > - (dolist (f load-path) > - (and (stringp f) > - (equal (file-name-nondirectory f) "site-lisp") > - (push (expand-file-name "elpa" f) dirs)))) > - (push (if (boundp 'package-user-dir) > - package-user-dir > - (locate-user-emacs-file "elpa")) > - dirs) > - (dolist (dir dirs) > - (when (file-directory-p dir) > - (dolist (subdir (directory-files dir)) > - (when (let ((subdir (expand-file-name subdir dir))) > - (and (file-directory-p subdir) > - (file-exists-p > - (expand-file-name > - (package--description-file subdir) > - subdir)))) > - (throw 'package-dir-found t))))))) > - (package-initialize)) > - > (setq after-init-time (current-time)) > ;; Display any accumulated warnings after all functions in > ;; `after-init-hook' like `desktop-read' have finalized possible > diff --git a/src/lread.c b/src/lread.c > index 52897b4fcc..5ff438041b 100644 > --- a/src/lread.c > +++ b/src/lread.c > @@ -4892,7 +4892,7 @@ directory. These file names are converted to absolute at startup. */); > If the file loaded had extension `.elc', and the corresponding source file > exists, this variable contains the name of source file, suitable for use > by functions like `custom-save-all' which edit the init file. > -While Emacs loads and evaluates the init file, value is the real name > +While Emacs loads and evaluates any init file, value is the real name > of the file, regardless of whether or not it has the `.elc' extension. */); > Vuser_init_file = Qnil; > > -- > 2.14.3 > ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-01-25 15:43 ` Clément Pit-Claudel @ 2018-01-25 16:03 ` Stefan Monnier 2018-01-25 16:22 ` Clément Pit-Claudel 0 siblings, 1 reply; 838+ messages in thread From: Stefan Monnier @ 2018-01-25 16:03 UTC (permalink / raw) To: emacs-devel >> By default, Emacs also automatically loads all installed packages in >> -subsequent Emacs sessions. This happens at startup, after processing >> -the init file (@pxref{Init File}). As an exception, Emacs does not >> -load packages at startup if invoked with the @samp{-q} or >> -@samp{--no-init-file} options (@pxref{Initial Options}). >> +subsequent Emacs sessions. This happens at startup, before processing > > Was this supposed to be "previous" rather than "subsequent" (this > isn't from your patch, though). Depends how you parse the sentence: Emacs also automatically loads all (installed packages) in subsequent Emacs sessions vs Emacs also automatically loads all (installed packages in previous Emacs sessions) but in the second case you'd rather write it Emacs also automatically loads all packages installed in previous Emacs sessions so I think "subsequent" was not a typo. Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-01-25 16:03 ` Stefan Monnier @ 2018-01-25 16:22 ` Clément Pit-Claudel 2018-01-25 17:12 ` Stefan Monnier ` (2 more replies) 0 siblings, 3 replies; 838+ messages in thread From: Clément Pit-Claudel @ 2018-01-25 16:22 UTC (permalink / raw) To: emacs-devel On 2018-01-25 11:03, Stefan Monnier wrote: > but in the second case you'd rather write it > > Emacs also automatically loads all packages installed in > previous Emacs sessions Indeed, good point. Then let me amend the suggestion: just remove the "in subsequent Emacs sessions" part :) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-01-25 16:22 ` Clément Pit-Claudel @ 2018-01-25 17:12 ` Stefan Monnier 2018-01-26 9:31 ` Eli Zaretskii 2018-01-26 14:34 ` Loading a package applies automatically to future sessions? Richard Stallman 2 siblings, 0 replies; 838+ messages in thread From: Stefan Monnier @ 2018-01-25 17:12 UTC (permalink / raw) To: emacs-devel >> but in the second case you'd rather write it >> >> Emacs also automatically loads all packages installed in >> previous Emacs sessions > > Indeed, good point. Then let me amend the suggestion: just remove the "in > subsequent Emacs sessions" part :) Fine by me, Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-01-25 16:22 ` Clément Pit-Claudel 2018-01-25 17:12 ` Stefan Monnier @ 2018-01-26 9:31 ` Eli Zaretskii 2018-01-26 14:34 ` Loading a package applies automatically to future sessions? Richard Stallman 2 siblings, 0 replies; 838+ messages in thread From: Eli Zaretskii @ 2018-01-26 9:31 UTC (permalink / raw) To: Clément Pit-Claudel; +Cc: emacs-devel > From: Clément Pit-Claudel <cpitclaudel@gmail.com> > Date: Thu, 25 Jan 2018 11:22:25 -0500 > > On 2018-01-25 11:03, Stefan Monnier wrote: > > but in the second case you'd rather write it > > > > Emacs also automatically loads all packages installed in > > previous Emacs sessions > > Indeed, good point. Then let me amend the suggestion: just remove the "in subsequent Emacs sessions" part :) There's no need to remove text that is unclear; instead, it should be rephrased to make it more clear. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Loading a package applies automatically to future sessions? 2018-01-25 16:22 ` Clément Pit-Claudel 2018-01-25 17:12 ` Stefan Monnier 2018-01-26 9:31 ` Eli Zaretskii @ 2018-01-26 14:34 ` Richard Stallman 2018-01-26 17:03 ` Stefan Monnier 2018-01-26 19:24 ` Radon Rosborough 2 siblings, 2 replies; 838+ messages in thread From: Richard Stallman @ 2018-01-26 14:34 UTC (permalink / raw) To: emacs-devel [[[ 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. ]]] Discussion of a patch cited this: > > Emacs also automatically loads all packages installed in > > previous Emacs sessions If that means what I think it means, I think it is bad design for this feature. Suppose the user loads a package to try it out. Will that cause it to be loaded again in every session? It appears that way. I think that asking for a package to be loaded in every session should be distinguished from loading it for the current session. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-26 14:34 ` Loading a package applies automatically to future sessions? Richard Stallman @ 2018-01-26 17:03 ` Stefan Monnier 2018-01-28 12:07 ` Richard Stallman 2018-01-26 19:24 ` Radon Rosborough 1 sibling, 1 reply; 838+ messages in thread From: Stefan Monnier @ 2018-01-26 17:03 UTC (permalink / raw) To: emacs-devel > Suppose the user loads a package to try it out. Will that cause it to > be loaded again in every session? It appears that way. > I think that asking for a package to be loaded in every session > should be distinguished from loading it for the current session. There are 3 different steps: A- installing a package: this places its files under ~/.emacs.d/elpa B- activating a package: this loads its <pkg>-autoloads.el file. C- actually loading the package's files. When a user does A, by default, it will do B in the current session and causes subsequent Emacs invocations to automatically do B as well (i.e. B is done by default on all installed packages). You can configure `package-load-list` if you want to prevent a particular package from being activated even though you still want it to be installed. But regardless, C should only happen on-demand when something actively requests it. Of course, a package is free to set up its autoloads such that B causes C. I'd consider it a misfeature of that package, tho. Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-26 17:03 ` Stefan Monnier @ 2018-01-28 12:07 ` Richard Stallman 2018-01-28 13:24 ` Stefan Monnier 0 siblings, 1 reply; 838+ messages in thread From: Richard Stallman @ 2018-01-28 12:07 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel [[[ 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. ]]] > There are 3 different steps: > A- installing a package: this places its files under ~/.emacs.d/elpa > B- activating a package: this loads its <pkg>-autoloads.el file. > C- actually loading the package's files. > When a user does A, by default, it will do B in the current session and > causes subsequent Emacs invocations to automatically do B as well > (i.e. B is done by default on all installed packages). That doesn't make sense to me. I think A should not, automatically or by default, do B. I think there should be a way to activate the package right now, and a way to specify to activate it in future sessions. Perhaps each of those should automatically do A, since B requires A. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-28 12:07 ` Richard Stallman @ 2018-01-28 13:24 ` Stefan Monnier 2018-01-29 1:50 ` Richard Stallman 0 siblings, 1 reply; 838+ messages in thread From: Stefan Monnier @ 2018-01-28 13:24 UTC (permalink / raw) To: emacs-devel > > When a user does A, by default, it will do B in the current session and > > causes subsequent Emacs invocations to automatically do B as well > > (i.e. B is done by default on all installed packages). > That doesn't make sense to me. Why not? All the packages that come bundled with Emacs are always unconditionally activated and we don't offer any way to prevent this activation (indeed, it's activated during the dump so we basically can't prevent it). Package.el follows the same idea (except that it does offer some way to prevent activation of some packages, by customizing package-load-list). Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-28 13:24 ` Stefan Monnier @ 2018-01-29 1:50 ` Richard Stallman 2018-01-29 5:56 ` Radon Rosborough 0 siblings, 1 reply; 838+ messages in thread From: Richard Stallman @ 2018-01-29 1:50 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel [[[ 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. ]]] > Why not? All the packages that come bundled with Emacs are always > unconditionally activated and we don't offer any way to prevent this > activation (indeed, it's activated during the dump so we basically > can't prevent it). They are always "activated", but the downloadable packages are not. Since the status of activation can change, let's handle this in the way users expect, for things that can be enabled and disabled. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-29 1:50 ` Richard Stallman @ 2018-01-29 5:56 ` Radon Rosborough 2018-02-02 2:14 ` Richard Stallman 0 siblings, 1 reply; 838+ messages in thread From: Radon Rosborough @ 2018-01-29 5:56 UTC (permalink / raw) To: rms; +Cc: Stefan Monnier, emacs-devel > They are always "activated", but the downloadable packages are not. > Since the status of activation can change, let's handle this in the > way users expect, for things that can be enabled and disabled. I think things already work the way users expect. Let's look at Python. When you install a package using 'pip', the package files are placed on Python's search path. Thereafter, 'import <package>' works without any further "activation" step. The package is automatically made available in future sessions, although it is not loaded until requested. The analogous behavior is to have installed packages' autoloads be made available automatically in future sessions of Emacs, although the packages are not loaded until requested. -- Radon ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-29 5:56 ` Radon Rosborough @ 2018-02-02 2:14 ` Richard Stallman 2018-02-02 3:05 ` Clément Pit-Claudel 0 siblings, 1 reply; 838+ messages in thread From: Richard Stallman @ 2018-02-02 2:14 UTC (permalink / raw) To: Radon Rosborough; +Cc: monnier, emacs-devel [[[ 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. ]]] > I think things already work the way users expect. Let's look at > Python. When you install a package using 'pip', the package files are > placed on Python's search path. Thereafter, 'import <package>' works > without any further "activation" step. The package is automatically > made available in future sessions, although it is not loaded until > requested. In Python, once a package is on the search path, the user needs to give a specific command to make it callable from a given module. I think Emacs should work the same way. If I understood correctly, it is currently NOT the same, because in Emacs the package doesn't require any command to make the package callable. Simply getting it from ELPA makes it callable _all the time_. The change I have asked for would make Emacs do like Python. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-02 2:14 ` Richard Stallman @ 2018-02-02 3:05 ` Clément Pit-Claudel 2018-02-04 3:08 ` Richard Stallman 0 siblings, 1 reply; 838+ messages in thread From: Clément Pit-Claudel @ 2018-02-02 3:05 UTC (permalink / raw) To: emacs-devel On 2018-02-01 21:14, Richard Stallman 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. ]]] > > > I think things already work the way users expect. Let's look at > > Python. When you install a package using 'pip', the package files are > > placed on Python's search path. Thereafter, 'import <package>' works > > without any further "activation" step. The package is automatically > > made available in future sessions, although it is not loaded until > > requested. > > In Python, once a package is on the search path, the user needs to > give a specific command to make it callable from a given module. > > I think Emacs should work the same way. There may be a misunderstanding. Emacs already works in (mostly) the same way: Emacs' `require' is very close to Python's `import'. > If I understood correctly, it is currently NOT the same, because in > Emacs the package doesn't require any command to make the package > callable. Simply getting it from ELPA makes it callable _all the time_. No, this isn't quite right. For example, if package foo has a function foo-x, you will need (in most cases) to (require 'foo) before you can call foo-x. There are some differences, but they are small: * `require' works globally in Emacs, so once package foo is `require'd in one file, all subsequently executed code can call foo-x, without calling (require 'foo) again. This is why packages that are in loaded in temacs and dumped don't need to be `require'd. * Emacs has autoloads, small pieces of code from packages that are run inconditionally. Autoloads are what makes it possible to call certain functions without requiring the corresponding package first. In spirit, this is very similar to Python's `pth' files. Autoload files are a performance issue in some cases, because there are many of them (although each is fairly small). Stefan's patch makes them much faster. Hope this helps, Clément. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-02 3:05 ` Clément Pit-Claudel @ 2018-02-04 3:08 ` Richard Stallman 2018-02-04 15:21 ` Clément Pit-Claudel 0 siblings, 1 reply; 838+ messages in thread From: Richard Stallman @ 2018-02-04 3:08 UTC (permalink / raw) To: Clément Pit-Claudel; +Cc: emacs-devel [[[ 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. ]]] > There may be a misunderstanding. Emacs already works in (mostly) the same way: Emacs' `require' is very close to Python's `import'. That's the behavior I'd expect a feature like this to have. > * Emacs has autoloads, small pieces of code from packages that are run inconditionally. I do know about autoloads; I implemented them. The questions are (1) do a lot of these packages have autoloads, or just a few, and (2) when do the autoloads get installed into Emacs. If adding a package to the list for loading has the effect of installing its autploads in all future sessions, that results in behavior very different from the 'require' behavior, and behavior that doesn't match what I'd expect such a feature to have. Does Python have autoloads? I would expect not. > * `require' works globally in Emacs, so once package foo is > * `require'd in one file, all subsequently executed code can call > * foo-x, without calling (require 'foo) again. That is true. With dynamic scoping that was basically inevitable. However, when lexical scoping becomes the default, it might be possible to arrange that a Lisp library is in scope only in files that require it. That would clean up a lot of things. For instance, it would not matter whether you compile A before B or after B. Since the effect of calling an autoload function is to call 'require', it could be that lexical handling of 'require' will automatically clean up the way these autoloads are handled. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-04 3:08 ` Richard Stallman @ 2018-02-04 15:21 ` Clément Pit-Claudel 2018-02-04 21:27 ` Tim Cross 2018-02-05 1:08 ` Richard Stallman 0 siblings, 2 replies; 838+ messages in thread From: Clément Pit-Claudel @ 2018-02-04 15:21 UTC (permalink / raw) Cc: emacs-devel > > There may be a misunderstanding. Emacs already works in (mostly) the same way: Emacs' `require' is very close to Python's `import'. > > That's the behavior I'd expect a feature like this to have. > > > * Emacs has autoloads, small pieces of code from packages that are run inconditionally. > > I do know about autoloads; I implemented them. I know that; but I'm writing to the entire list, and there may be other readers who are less familiar with autoloads :) > The questions are (1) do a lot of these packages have autoloads, or just > a few, and (2) when do the autoloads get installed into Emacs. Most packages, AFAICT, make their main interactive entry points autoloads. I think that is the right behavior. > If adding a package to the list for loading has the effect of installing > its autploads in all future sessions, that results in behavior very > different from the 'require' behavior, and behavior that doesn't match > what I'd expect such a feature to have. > > Does Python have autoloads? I would expect not. Yes, in two senses: * Installing a package with 'pip' commonly installs small binaries in your path, so you can call the program from the command line. * Python has .pth files that work essentially like Emacs autoloads. These aren't used very commonly. > Since the effect of calling an autoload function is to call 'require', > it could be that lexical handling of 'require' will automatically > clean up the way these autoloads are handled. The thing is, I don't a the problem with the way autoloads are currently handled. seeWe just need to find a way to make processing autoloads faster, and in fact Stefan has a solution for that, IIUC. The fact that installing a package installs its autoloads is desirable; just like the fact that running 'apt-get install emacs' puts the emacs binary on your path. I think lexical vs dynamic 'require' is a different issue. Clément. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-04 15:21 ` Clément Pit-Claudel @ 2018-02-04 21:27 ` Tim Cross 2018-02-05 10:07 ` George Plymale II 2018-02-05 1:08 ` Richard Stallman 1 sibling, 1 reply; 838+ messages in thread From: Tim Cross @ 2018-02-04 21:27 UTC (permalink / raw) To: Clément Pit-Claudel; +Cc: Emacs developers [-- Attachment #1: Type: text/plain, Size: 4222 bytes --] While I think I can see what RMS is concerned about, I am not necessarily convinced the concern is significant enough to warrant implementation of additional user action that would be required in order to activate packages in future sessions. One of the great benefits of the ELPA system has been how much easier it has made it to add useful extensions and keep those extensions up-to-date without requiring the user to write any ELISP. While I personally don't find writing ELISP a challenge, many do - or at least shy away from it initially. Bottom line is that when you install most ELPA packages, the package will often install basic autoloads. This means that should you do something or execute one of the autoload commands, the package will load and run in future sessions. So, in effect, the answer to the original question is yes, packages are available and will be automatically loaded in future sessions if the user executes one of those autloaded functions. However, I'm not aware of any packages which setup hooks or add themselves to hooks so that the package is loaded without specific user action in future sessions (I have not tried all packages and it would certainly be possible for a package to do this, though it might be tricky to implement unless you edit the user's init file, which I don't think is normal for an elpa package). I feel the basic mechanism to prevent packages from being available in future sessions is to simply remove them. I actually think this is a good practice as it prevents people from building up large numbers of unused/unnecessary packages that only slow down updates. It also reduces the likelihood of unused packages conflicting with used packages and works towards a cleaner environment. Given that re-installing is also trivial, I don't think this is too much of a burden should there be a package you only need very rarely. Anyone who wants something more complex is of course free to implement such functionality themselves. Tim On 5 February 2018 at 02:21, Clément Pit-Claudel <cpitclaudel@gmail.com> wrote: > > > There may be a misunderstanding. Emacs already works in (mostly) > the same way: Emacs' `require' is very close to Python's `import'. > > > > That's the behavior I'd expect a feature like this to have. > > > > > * Emacs has autoloads, small pieces of code from packages that are > run inconditionally. > > > > I do know about autoloads; I implemented them. > > I know that; but I'm writing to the entire list, and there may be other > readers who are less familiar with autoloads :) > > > The questions are (1) do a lot of these packages have autoloads, or just > > a few, and (2) when do the autoloads get installed into Emacs. > > Most packages, AFAICT, make their main interactive entry points > autoloads. I think that is the right behavior. > > > If adding a package to the list for loading has the effect of installing > > its autploads in all future sessions, that results in behavior very > > different from the 'require' behavior, and behavior that doesn't match > > what I'd expect such a feature to have. > > > > Does Python have autoloads? I would expect not. > > Yes, in two senses: > > * Installing a package with 'pip' commonly installs small binaries in your > path, so you can call the program from the command line. > * Python has .pth files that work essentially like Emacs autoloads. These > aren't used very commonly. > > > Since the effect of calling an autoload function is to call 'require', > > it could be that lexical handling of 'require' will automatically > > clean up the way these autoloads are handled. > > The thing is, I don't a the problem with the way autoloads are currently > handled. seeWe just need to find a way to make processing autoloads > faster, and in fact Stefan has a solution for that, IIUC. > > The fact that installing a package installs its autoloads is desirable; > just like the fact that running 'apt-get install emacs' puts the emacs > binary on your path. > > I think lexical vs dynamic 'require' is a different issue. > > Clément. > > -- regards, Tim -- Tim Cross [-- Attachment #2: Type: text/html, Size: 5186 bytes --] ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-04 21:27 ` Tim Cross @ 2018-02-05 10:07 ` George Plymale II 2018-02-05 21:27 ` Tim Cross 0 siblings, 1 reply; 838+ messages in thread From: George Plymale II @ 2018-02-05 10:07 UTC (permalink / raw) To: Tim Cross; +Cc: cpitclaudel, emacs-devel > Given that re-installing is also trivial This is not always true, esp. given a large number of packages. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-05 10:07 ` George Plymale II @ 2018-02-05 21:27 ` Tim Cross 0 siblings, 0 replies; 838+ messages in thread From: Tim Cross @ 2018-02-05 21:27 UTC (permalink / raw) To: George Plymale II; +Cc: Clément Pit-Claudel, Emacs developers [-- Attachment #1: Type: text/plain, Size: 1342 bytes --] I was referring to re-installation of individual packages i.e. you install a package, find you don't really need it at this time and so remove it and then find later you do need it as opposed to removing ALL packages and then re-installing. However, having said that, I have done this many times in the past and never run into any problems. It can take a bit of time if you have a large number of packages, but I've never found any need to take additional action with only 1 exception and that is with respect to org mode. The only package which has ever given me any problems has been org mode and that was partly my fault (I was loading org functionality and then trying to install a later version from the org repo). Of course, if your using unofficial elpa repositories, all bets are off as there is no curation of the content in these repositories. I have certainly found crappy packages in some of these repos. However, that is not something Emacs has control of and if as a user you decide to install packages from such repos, then you need to be willing to deal with the issues which arise. Tim On 5 February 2018 at 21:07, George Plymale II <georgedp@orbitalimpact.com> wrote: > > Given that re-installing is also trivial > > This is not always true, esp. given a large number of packages. > -- regards, Tim -- Tim Cross [-- Attachment #2: Type: text/html, Size: 1999 bytes --] ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-04 15:21 ` Clément Pit-Claudel 2018-02-04 21:27 ` Tim Cross @ 2018-02-05 1:08 ` Richard Stallman 2018-02-05 4:15 ` Clément Pit-Claudel 1 sibling, 1 reply; 838+ messages in thread From: Richard Stallman @ 2018-02-05 1:08 UTC (permalink / raw) To: Clément Pit-Claudel; +Cc: emacs-devel [[[ 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. ]]] > > Does Python have autoloads? I would expect not. > Yes, in two senses: > * Installing a package with 'pip' commonly installs small binaries in your path, so you can call the program from the command line. > * Python has .pth files that work essentially like Emacs autoloads. These aren't used very commonly. How do these autoload-like constructs in Python interact with the usual need to 'import' a package to make its entry points accessible? -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-05 1:08 ` Richard Stallman @ 2018-02-05 4:15 ` Clément Pit-Claudel 2018-02-05 20:36 ` Richard Stallman 0 siblings, 1 reply; 838+ messages in thread From: Clément Pit-Claudel @ 2018-02-05 4:15 UTC (permalink / raw) Cc: emacs-devel On 2018-02-04 20:08, Richard Stallman wrote: > > > Does Python have autoloads? I would expect not. > > > Yes, in two senses: > > > * Installing a package with 'pip' commonly installs small binaries in your path, so you can call the program from the command line. > > * Python has .pth files that work essentially like Emacs autoloads. These aren't used very commonly. > > How do these autoload-like constructs in Python interact with > the usual need to 'import' a package to make its entry points accessible? They're the first thing the interpreter runs when it starts. You can write 'import foo' on a separate line, and then python imports 'foo' before running your actual program. The code in 'foo' can then introduce new global names by modifying the builtins dictionary (this isn't a very common practice) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-05 4:15 ` Clément Pit-Claudel @ 2018-02-05 20:36 ` Richard Stallman 0 siblings, 0 replies; 838+ messages in thread From: Richard Stallman @ 2018-02-05 20:36 UTC (permalink / raw) To: Clément Pit-Claudel; +Cc: emacs-devel [[[ 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. ]]] I retract my concerns about this feature. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-26 14:34 ` Loading a package applies automatically to future sessions? Richard Stallman 2018-01-26 17:03 ` Stefan Monnier @ 2018-01-26 19:24 ` Radon Rosborough 2018-01-26 20:02 ` Eli Zaretskii 2018-01-27 20:44 ` Richard Stallman 1 sibling, 2 replies; 838+ messages in thread From: Radon Rosborough @ 2018-01-26 19:24 UTC (permalink / raw) To: rms; +Cc: emacs-devel > Suppose the user loads a package to try it out. Will that cause it to > be loaded again in every session? It appears that way. I think the confusion here is because the Emacs manual currently uses the term "load" in two incompatible ways. Loading a package means evaluating its autoloads, while loading a Lisp file means evaluating the file's Lisp code. The problem is complicated by the fact that the word "package" is sometimes used to refer to a package in the package manager sense, and sometimes used to refer to a Lisp file. Perhaps some better terminology would be in order? I would suggest that we never refer to "loading" a package, and instead say: * "activating a package" means evaluating its autoloads * "loading a file/feature" means evaluating some particular file of Lisp code, which is possibly part of a package I don't have strong opinions, except that the current terminology is bad. -- Radon ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-26 19:24 ` Radon Rosborough @ 2018-01-26 20:02 ` Eli Zaretskii 2018-01-28 18:20 ` Radon Rosborough 2018-01-27 20:44 ` Richard Stallman 1 sibling, 1 reply; 838+ messages in thread From: Eli Zaretskii @ 2018-01-26 20:02 UTC (permalink / raw) To: Radon Rosborough; +Cc: rms, emacs-devel > From: Radon Rosborough <radon.neon@gmail.com> > Date: Fri, 26 Jan 2018 11:24:32 -0800 > Cc: emacs-devel <emacs-devel@gnu.org> > > I think the confusion here is because the Emacs manual currently uses > the term "load" in two incompatible ways. Loading a package means > evaluating its autoloads, while loading a Lisp file means evaluating > the file's Lisp code. Please point out the places in the manual where we use "load" in the former sense. I think those places need to be fixed, because that's not what "load" means in the Emacs context. Thanks. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-26 20:02 ` Eli Zaretskii @ 2018-01-28 18:20 ` Radon Rosborough 2018-01-29 1:52 ` Richard Stallman 2018-02-10 12:00 ` Eli Zaretskii 0 siblings, 2 replies; 838+ messages in thread From: Radon Rosborough @ 2018-01-28 18:20 UTC (permalink / raw) To: Eli Zaretskii; +Cc: rms, emacs-devel > Please point out the places in the manual where we use "load" in the > former sense. I think those places need to be fixed, because that's > not what "load" means in the Emacs context. The crux of the problem is here in emacs/package.texi: "Once a package is downloaded and installed, it is @dfn{loaded} into the current Emacs session. Loading a package is not quite the same as loading a Lisp library (@pxref{Lisp Libraries}); loading a package adds its directory to @code{load-path} and loads its autoloads." Frankly the name of `package-load-list' is misleading if we're going to change this terminology. It implies you are setting which packages are going to be loaded. We also have usage of this terminology in emacs/package.texi: "After a package is installed, it is automatically loaded by Emacs in all subsequent sessions." "As an exception, Emacs does not load packages at startup if invoked with the @samp{-q} or @samp{--no-init-file} options (@xref{Initial Options})." "To disable automatic package loading, change the variable @code{package-enable-at-startup} to @code{nil}. You must do this in the early init file, as the variable is read before loading the regular init file." "For finer control over package loading, you can use the variable @code{package-load-list}." "A list element of the form @code{(@var{name} @var{version})} tells Emacs to load version @var{version} of the package named @var{name}. Here, @var{version} should be a version string (corresponding to a specific version of the package), or @code{t} (which means to load any installed version), or @code{nil} (which means no version; this disables the package, preventing it from being loaded). A list element can also be the symbol @code{all}, which means to load the latest installed version of any package not named by the other list elements." "For example, if you set @code{package-load-list} to @code{'((muse "3.20") all)}, then Emacs only loads version 3.20 of the @samp{muse} package, plus any installed version of packages other than @samp{muse}." In lispref/package.texi: "Whenever Emacs starts up, it automatically calls the function @code{package-initialize} to load installed packages." "Automatic package loading is disabled if the user option @code{package-enable-at-startup} is set to @code{nil} in the early init file." "This function initializes Emacs' internal record of which packages are installed, and loads them. The user option @code{package-load-list} specifies which packages to load; by default, all installed packages are loaded. If called during startup, this function also sets @code{package-enable-at-startup} to @code{nil}, to avoid accidentally loading the packages twice." "The optional argument @var{no-activate}, if non-@code{nil}, causes Emacs to update its record of installed packages without actually loading them; it is for internal use only." In lispref/os.texi: "For example, you can customize the process of loading installed packages, by setting variables such as @var{package-load-list} or @var{package-enable-at-startup}. @xref{Package Installation,,, emacs,The GNU Emacs Manual}." ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-28 18:20 ` Radon Rosborough @ 2018-01-29 1:52 ` Richard Stallman 2018-02-10 12:00 ` Eli Zaretskii 1 sibling, 0 replies; 838+ messages in thread From: Richard Stallman @ 2018-01-29 1:52 UTC (permalink / raw) To: Radon Rosborough; +Cc: eliz, emacs-devel [[[ 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. ]]] We can change the name of a variable painlessly by defining an alias for it. So let's decide which terms are best and clearest. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-28 18:20 ` Radon Rosborough 2018-01-29 1:52 ` Richard Stallman @ 2018-02-10 12:00 ` Eli Zaretskii 2018-02-11 1:23 ` George Plymale II 2018-02-15 4:40 ` Loading a package applies automatically to future sessions? Radon Rosborough 1 sibling, 2 replies; 838+ messages in thread From: Eli Zaretskii @ 2018-02-10 12:00 UTC (permalink / raw) To: Radon Rosborough; +Cc: rms, emacs-devel > From: Radon Rosborough <radon.neon@gmail.com> > Date: Sun, 28 Jan 2018 10:20:49 -0800 > Cc: rms@gnu.org, emacs-devel <emacs-devel@gnu.org> > > > Please point out the places in the manual where we use "load" in the > > former sense. I think those places need to be fixed, because that's > > not what "load" means in the Emacs context. > > The crux of the problem is here in emacs/package.texi: > > "Once a package is downloaded and installed, it is @dfn{loaded} into > the current Emacs session. Loading a package is not quite the same as > loading a Lisp library (@pxref{Lisp Libraries}); loading a package > adds its directory to @code{load-path} and loads its autoloads." > > Frankly the name of `package-load-list' is misleading if we're going > to change this terminology. It implies you are setting which packages > are going to be loaded. > > We also have usage of this terminology in emacs/package.texi: > > "After a package is installed, it is automatically loaded by Emacs in > all subsequent sessions." > > "As an exception, Emacs does not load packages at startup if invoked > with the @samp{-q} or @samp{--no-init-file} options (@xref{Initial > Options})." > > "To disable automatic package loading, change the variable > @code{package-enable-at-startup} to @code{nil}. You must do this in > the early init file, as the variable is read before loading the > regular init file." > > "For finer control over package loading, you can use the variable > @code{package-load-list}." > > "A list element of the form @code{(@var{name} @var{version})} tells > Emacs to load version @var{version} of the package named @var{name}. > Here, @var{version} should be a version string (corresponding to a > specific version of the package), or @code{t} (which means to load any > installed version), or @code{nil} (which means no version; this > disables the package, preventing it from being loaded). A list element > can also be the symbol @code{all}, which means to load the latest > installed version of any package not named by the other list > elements." > > "For example, if you set @code{package-load-list} to @code{'((muse > "3.20") all)}, then Emacs only loads version 3.20 of the @samp{muse} > package, plus any installed version of packages other than > @samp{muse}." > > In lispref/package.texi: > > "Whenever Emacs starts up, it automatically calls the function > @code{package-initialize} to load installed packages." > > "Automatic package loading is disabled if the user option > @code{package-enable-at-startup} is set to @code{nil} in the early > init file." > > "This function initializes Emacs' internal record of which packages > are installed, and loads them. The user option > @code{package-load-list} specifies which packages to load; by default, > all installed packages are loaded. If called during startup, this > function also sets @code{package-enable-at-startup} to @code{nil}, to > avoid accidentally loading the packages twice." > > "The optional argument @var{no-activate}, if non-@code{nil}, causes > Emacs to update its record of installed packages without actually > loading them; it is for internal use only." > > In lispref/os.texi: > > "For example, you can customize the process of loading installed > packages, by setting variables such as @var{package-load-list} or > @var{package-enable-at-startup}. @xref{Package Installation,,, > emacs,The GNU Emacs Manual}." Thanks. It looks like all of those places are related to package.el, so could you please take care of clarifying the issue as part of your patch? Most of those places are touched by your patch anyway. I think the fix should be not to use "load" in this sense, but instead tell we just make the package available by loading its autoloads. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-10 12:00 ` Eli Zaretskii @ 2018-02-11 1:23 ` George Plymale II 2018-02-13 21:14 ` Stefan's patch to improve package loading (was Loading a package applies automatically to future sessions?) George Plymale II 2018-02-15 4:40 ` Loading a package applies automatically to future sessions? Radon Rosborough 1 sibling, 1 reply; 838+ messages in thread From: George Plymale II @ 2018-02-11 1:23 UTC (permalink / raw) To: Eli Zaretskii; +Cc: radon.neon, monnier, emacs-devel [-- Attachment #1: Type: text/plain, Size: 2205 bytes --] Hi, Sorry, I don't mean to hijack the conversation, but speaking of patches, Stefan gave me an updated version of his patch recently. This one allows byte-compilation of his ~/.emacs.d/package-fastpath.el file. I asked him in private if he needs any further feedback several days ago, but I did not receive a reply from him so I'll assume that it's okay to re-post his patch here on the list. I have attached two patches. One is the patch that he originally made which applies to the Emacs trunk, and the other is for Emacs 25.3. Which is my current working Emacs version. If anyone could provide further feedback to Stefan to help him improve this patch, I'm sure he would appreciate it and I would as well. So far, I haven't noticed any significant performance improvements from his patch. Although, with the byte-compilation in place (along with some other optimizations to my startup code) my init time has gone down to 1.1 seconds. It was 1.4 seconds last time I reported about it on this thread, I think. Also, I have noticed (and I forgot to tell Stefan about this in our private thread) that the bug which I noticed regarding info files from ELPA is gone. I.e., this bug (which I reported on Jan 31): "The info files for my packages from ELPA are all missing in the info Directory node." is no longer happening, so I guess Stefan has fixed it in this most recent patch. Yay! Unfortunately, I had more problems with byte-compilation when I had the gh.el package installed. package-fastpath.el would refuse to byte-compile. I have since uninstalled this package since I only had one other package which was dependent on it and I haven't used it recently. Stefan's patch probably needs some work in order to properly deal with strange autoload files. However, the developer of gh.el is currently trying to make its autoload file a bit lighter so this may not be a concern much longer. In any case, I think that Stefan's patch here is still the best solution to the original problem posed by RMS at the inception of this thread. It just needs some work. It is also improving startup time quite noticeably for myself and I am sure that it will for others as well. Thanks, - George Plymale II [-- Attachment #2: Stefan's 2nd patch for package.el (trunk version) --] [-- Type: text/x-patch, Size: 4048 bytes --] diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el index 71d1c41ec3..b918eb5dfe 100644 --- a/lisp/emacs-lisp/package.el +++ b/lisp/emacs-lisp/package.el @@ -676,6 +676,8 @@ package--activate-autoloads-and-load-path (defvar Info-directory-list) (declare-function info-initialize "info" ()) +(defvar package--fastpath-pkgs t) + (defun package--load-files-for-activation (pkg-desc reload) "Load files for activating a package given by PKG-DESC. Load the autoloads file, and ensure `load-path' is setup. If @@ -718,7 +720,10 @@ package-activate-1 (message "Unable to activate package `%s'.\nRequired package `%s-%s' is unavailable" name (car req) (package-version-join (cadr req))) (throw 'exit nil)))) - (package--load-files-for-activation pkg-desc reload) + (if (listp package--fastpath-pkgs) + ;; We're only collecting the set of packages to activate! + (push pkg-desc package--fastpath-pkgs) + (package--load-files-for-activation pkg-desc reload)) ;; Add info node. (when (file-exists-p (expand-file-name "dir" pkg-dir)) ;; FIXME: not the friendliest, but simple. @@ -3468,6 +3473,67 @@ package-list-packages-no-fetch (interactive) (list-packages t)) +;;;; Fast-path for activation! + +(defcustom package-fastpath-file (locate-user-emacs-file "package-fastpath.el") + "Location of the file used to speed up activation of packages at startup." + :type 'file) + +(defun package-fastpath-refresh () + "(Re)Generate the `package-fastpath-file'." + (interactive) + (package-initialize 'no-activate) + (require 'info) + (let ((package--fastpath-pkgs ()) + ;; Pretend we haven't activated anything yet! + (package-activated-list ()) + (Info-directory-list '(""))) + (dolist (elt package-alist) + (condition-case err + (package-activate (car elt)) + ;; Don't let failure of activation of a package arbitrarily stop + ;; activation of further packages. + (error (message "%s" (error-message-string err))))) + (setq package--fastpath-pkgs (nreverse package--fastpath-pkgs)) + (with-temp-file package-fastpath-file + (emacs-lisp-mode) + (insert ";;; FastPath file to speed up package activation at startup -*- lexical-binding:t -*-\n") + (insert ";; ¡¡ This file is autogenerated, DO NOT EDIT !!\n\n") + (dolist (pkg package--fastpath-pkgs) + (let* ((file + ;; Prefer uncompiled files (and don't accept .so files). + (let ((load-suffixes '(".el" ".elc"))) + (locate-library (package--autoloads-file-name pkg)))) + (pfile (prin1-to-string file))) + (insert "(let ((load-file-name " pfile "))\n") + (insert-file-contents file) + ;; FIXME: We also need to setup the Info-directory-list! + (while (search-forward "#$" nil 'move) + (unless (nth 8 (syntax-ppss)) + (replace-match pfile t t))) + (unless (bolp) (insert "\n")) + (insert ")\n"))) + (pp `(setq package-activated-list + (append ',(mapcar #'package-desc-name package--fastpath-pkgs) + package-activated-list)) + (current-buffer)) + (let ((info-dirs (butlast Info-directory-list))) + (when info-dirs + (pp `(progn (require 'info) + (info-initialize) + (setq Info-directory-list + (append ',info-dirs Info-directory-list))) + (current-buffer)))) + ;; Use `\s' instead of a space character, so this code chunk is not + ;; mistaken for an actual file-local section of package.el. + (insert "\f +;; Local\sVariables: +;; version-control: never +;; no-byte-compile: nil +;; no-update-autoloads: t +;; End: +")))) + (provide 'package) ;;; package.el ends here [-- Attachment #3: Stefan's 2nd patch for package.el (25.3 stable version) --] [-- Type: text/x-patch, Size: 4097 bytes --] diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el index 32200227de..cbb326f26e 100644 --- a/lisp/emacs-lisp/package.el +++ b/lisp/emacs-lisp/package.el @@ -656,6 +656,8 @@ PKG-DESC is a `package-desc' object." (defvar Info-directory-list) (declare-function info-initialize "info" ()) +(defvar package--fastpath-pkgs t) + (defun package--load-files-for-activation (pkg-desc reload) "Load files for activating a package given by PKG-DESC. Load the autoloads file, and ensure `load-path' is setup. If @@ -696,7 +698,10 @@ correspond to previously loaded files (those returned by (unless (package-activate (car req)) (error "Unable to activate package `%s'.\nRequired package `%s-%s' is unavailable" name (car req) (package-version-join (cadr req)))))) - (package--load-files-for-activation pkg-desc reload) + (if (listp package--fastpath-pkgs) + ;; We're only collecting the set of packages to activate! + (push pkg-desc package--fastpath-pkgs) + (package--load-files-for-activation pkg-desc reload)) ;; Add info node. (when (file-exists-p (expand-file-name "dir" pkg-dir)) ;; FIXME: not the friendliest, but simple. @@ -3437,6 +3442,67 @@ The list is displayed in a buffer named `*Packages*'." (interactive) (list-packages t)) +;;;; Fast-path for activation! + +(defcustom package-fastpath-file (locate-user-emacs-file "package-fastpath.el") + "Location of the file used to speed up activation of packages at startup." + :type 'file) + +(defun package-fastpath-refresh () + "(Re)Generate the `package-fastpath-file'." + (interactive) + (package-initialize 'no-activate) + (require 'info) + (let ((package--fastpath-pkgs ()) + ;; Pretend we haven't activated anything yet! + (package-activated-list ()) + (Info-directory-list '(""))) + (dolist (elt package-alist) + (condition-case err + (package-activate (car elt)) + ;; Don't let failure of activation of a package arbitrarily stop + ;; activation of further packages. + (error (message "%s" (error-message-string err))))) + (setq package--fastpath-pkgs (nreverse package--fastpath-pkgs)) + (with-temp-file package-fastpath-file + (emacs-lisp-mode) + (insert ";;; FastPath file to speed up package activation at startup -*- lexical-binding:t -*-\n") + (insert ";; ¡¡ This file is autogenerated, DO NOT EDIT !!\n\n") + (dolist (pkg package--fastpath-pkgs) + (let* ((file + ;; Prefer uncompiled files (and don't accept .so files). + (let ((load-suffixes '(".el" ".elc"))) + (locate-library (package--autoloads-file-name pkg)))) + (pfile (prin1-to-string file))) + (insert "(let ((load-file-name " pfile "))\n") + (insert-file-contents file) + ;; FIXME: We also need to setup the Info-directory-list! + (while (search-forward "#$" nil 'move) + (unless (nth 8 (syntax-ppss)) + (replace-match pfile t t))) + (unless (bolp) (insert "\n")) + (insert ")\n"))) + (pp `(setq package-activated-list + (append ',(mapcar #'package-desc-name package--fastpath-pkgs) + package-activated-list)) + (current-buffer)) + (let ((info-dirs (butlast Info-directory-list))) + (when info-dirs + (pp `(progn (require 'info) + (info-initialize) + (setq Info-directory-list + (append ',info-dirs Info-directory-list))) + (current-buffer)))) + ;; Use `\s' instead of a space character, so this code chunk is not + ;; mistaken for an actual file-local section of package.el. + (insert "\f +;; Local\sVariables: +;; version-control: never +;; no-byte-compile: nil +;; no-update-autoloads: t +;; End: +")))) + (provide 'package) ;;; package.el ends here ^ permalink raw reply related [flat|nested] 838+ messages in thread
* Stefan's patch to improve package loading (was Loading a package applies automatically to future sessions?) 2018-02-11 1:23 ` George Plymale II @ 2018-02-13 21:14 ` George Plymale II 2018-02-14 2:56 ` John Wiegley 0 siblings, 1 reply; 838+ messages in thread From: George Plymale II @ 2018-02-13 21:14 UTC (permalink / raw) To: George Plymale II; +Cc: eliz, radon.neon, monnier, emacs-devel Hi again, Does anyone mind if I start a new thread with a new subject line? I would like to continue discussion of Stefan's patch and improving the loading of packages in Emacs on this list, but since the thread entitled "Loading a package applies automatically to future sessions?" diverged into copyright debates, I thought perhaps we should make a new thread that specifically discusses Stefan's patches mentioned previously. It should make things more organized and more easily searchable. Is anyone opposed to this? - George Plymale II ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Stefan's patch to improve package loading (was Loading a package applies automatically to future sessions?) 2018-02-13 21:14 ` Stefan's patch to improve package loading (was Loading a package applies automatically to future sessions?) George Plymale II @ 2018-02-14 2:56 ` John Wiegley 2018-02-14 23:32 ` George Plymale II 0 siblings, 1 reply; 838+ messages in thread From: John Wiegley @ 2018-02-14 2:56 UTC (permalink / raw) To: George Plymale II; +Cc: eliz, radon.neon, monnier, emacs-devel >>>>> "GP" == George Plymale <georgedp@orbitalimpact.com> writes: GP> Does anyone mind if I start a new thread with a new subject line? I would GP> like to continue discussion of Stefan's patch and improving the loading of GP> packages in Emacs on this list, but since the thread entitled "Loading a GP> package applies automatically to future sessions?" diverged into copyright GP> debates, I thought perhaps we should make a new thread that specifically GP> discusses Stefan's patches mentioned previously. It should make things GP> more organized and more easily searchable. Is anyone opposed to this? This is actually standard practice nowadays. Just create a new thread exactly as you've done, and propose the new discussion topic. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Stefan's patch to improve package loading (was Loading a package applies automatically to future sessions?) 2018-02-14 2:56 ` John Wiegley @ 2018-02-14 23:32 ` George Plymale II 2018-03-09 2:54 ` Stefan's patch to improve package loading George Plymale II 0 siblings, 1 reply; 838+ messages in thread From: George Plymale II @ 2018-02-14 23:32 UTC (permalink / raw) To: John Wiegley; +Cc: eliz, radon.neon, monnier, emacs-devel "John Wiegley" <johnw@gnu.org> writes: > This is actually standard practice nowadays. Just create a new thread exactly > as you've done, and propose the new discussion topic. Ok, great. Thanks for letting me know. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Stefan's patch to improve package loading 2018-02-14 23:32 ` George Plymale II @ 2018-03-09 2:54 ` George Plymale II 0 siblings, 0 replies; 838+ messages in thread From: George Plymale II @ 2018-03-09 2:54 UTC (permalink / raw) To: George Plymale II; +Cc: monnier, emacs-devel Hi Stefan, I know we've sent each other messages in private about this patch and you said that you'd post some updates here on the mailing list, but it's been a few weeks so I thought I'd give you a thread to send it to. I have to say that your patch has really cut down on my startup time to a point where I'm satisfied with it again (although it's not always under one second, but that is mostly due to some of my configuration plus the workload of my machine). I'm excited to see what kinds of updates you have for it, as I hope it makes it into the trunk at some point. Thanks. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-10 12:00 ` Eli Zaretskii 2018-02-11 1:23 ` George Plymale II @ 2018-02-15 4:40 ` Radon Rosborough 1 sibling, 0 replies; 838+ messages in thread From: Radon Rosborough @ 2018-02-15 4:40 UTC (permalink / raw) To: Eli Zaretskii; +Cc: rms, emacs-devel [-- Attachment #1.1: Type: text/plain, Size: 328 bytes --] > Thanks. It looks like all of those places are related to package.el, > so could you please take care of clarifying the issue as part of your > patch? Most of those places are touched by your patch anyway. I have done this; the patch and my comments are in the main thread. For convenience, the patch is also attached here. [-- Attachment #1.2: Type: text/html, Size: 596 bytes --] [-- Attachment #2: 0001-Add-early-init-file-stop-package-initialize-insertio.patch --] [-- Type: application/octet-stream, Size: 38832 bytes --] From aaf0192d3da753df1f5e0dab1907affc719e191c Mon Sep 17 00:00:00 2001 From: Radon Rosborough <radon.neon@gmail.com> Date: Sun, 17 Dec 2017 17:31:17 -0700 Subject: [PATCH] Add early init file, stop package-initialize insertion * lisp/startup.el (early-init-file): New variable. (load-user-init-file): New function. (command-line): Load the early init file using `load-user-init-file'. Move the check for an invalid username to just before that, and move the initialization of the package system to just after. Load the regular init file using `load-user-init-file'. * src/lread.c (Vuser_init_file): Note change in semantics due to its usage while loading the early init file. * lisp/emacs-lisp/package.el (package--ensure-init-file): Remove definition, usage, and documentation. (package--init-file-ensured): Remove definition and usage. * doc/emacs/custom.texi: Document early init file. * doc/lispref/os.texi: Document early init file. Update startup summary. * doc/lispref/package.texi: Document changes to when package-initialize is called, and advise against calling it in the init file. Change terminology for package 'loading'. * doc/emacs/package.texi: Document changes to when package-initialize is called. Change terminology for package 'loading'. * doc/misc/org.texi: Don't recommend to call package-initialize in the init file. Discussion on emacs-devel leading up to this change (approximately 150 messages): - https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00154.html - https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00433.html - https://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00023.html - https://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00599.html - https://lists.gnu.org/archive/html/emacs-devel/2017-10/msg00332.html --- doc/emacs/custom.texi | 17 ++ doc/emacs/package.texi | 78 +++++----- doc/lispref/os.texi | 38 +++-- doc/lispref/package.texi | 30 ++-- doc/misc/org.texi | 4 +- etc/NEWS | 19 +++ lisp/emacs-lisp/package.el | 71 +-------- lisp/startup.el | 379 ++++++++++++++++++++++++--------------------- src/lread.c | 2 +- 9 files changed, 331 insertions(+), 307 deletions(-) diff --git a/doc/emacs/custom.texi b/doc/emacs/custom.texi index e27760b379..263dff7cb0 100644 --- a/doc/emacs/custom.texi +++ b/doc/emacs/custom.texi @@ -2575,3 +2575,20 @@ Init Non-ASCII coding system, for your init file as well as the files you edit. For example, don't mix the @samp{latin-1} and @samp{latin-9} coding systems. + +@node Early Init File +@subsection The Early Init File +@cindex early init file + + Most customizations for Emacs can be put in the normal init file, +@file{.emacs} or @file{~/.emacs.d/init.el}. However, it is sometimes +desirable to have customizations that take effect during Emacs startup +earlier than the normal init file is processed. Such customizations +can be put in the early init file, @file{~/.emacs.d/early-init.el}. +This file is loaded before the package system is initialized, so in it +you can customize variables that affect the initialization process, +such as @code{package-enable-at-startup} and @code{package-load-list}. +@xref{Package Installation}. + + For more information on the early init file, @pxref{Early Init +File,,, elisp, The Emacs Lisp Reference Manual}. diff --git a/doc/emacs/package.texi b/doc/emacs/package.texi index bc6afb7966..d5339e9124 100644 --- a/doc/emacs/package.texi +++ b/doc/emacs/package.texi @@ -241,57 +241,55 @@ Package Installation package is available from a higher-priority archive. (This is controlled by the value of @code{package-menu-hide-low-priority}.) - Once a package is downloaded and installed, it is @dfn{loaded} into -the current Emacs session. Loading a package is not quite the same as -loading a Lisp library (@pxref{Lisp Libraries}); loading a package -adds its directory to @code{load-path} and loads its autoloads. The -effect of a package's autoloads varies from package to package. Most -packages just make some new commands available, while others have more + Once a package is downloaded and installed, it is made available to +the current Emacs session. Making a package available adds its +directory to @code{load-path} and loads its autoloads. The effect of +a package's autoloads varies from package to package. Most packages +just make some new commands available, while others have more wide-ranging effects on the Emacs session. For such information, consult the package's help buffer. - By default, Emacs also automatically loads all installed packages in -subsequent Emacs sessions. This happens at startup, after processing -the init file (@pxref{Init File}). As an exception, Emacs does not -load packages at startup if invoked with the @samp{-q} or -@samp{--no-init-file} options (@pxref{Initial Options}). + After a package is installed, it is automatically made available by +Emacs in all subsequent sessions. This happens at startup, before +processing the init file but after processing the early init file +(@pxref{Early Init File,,, elisp, The Emacs Lisp Reference Manual}). +As an exception, Emacs does not make packages available at startup if +invoked with the @samp{-q} or @samp{--no-init-file} options +(@xref{Initial Options}). @vindex package-enable-at-startup - To disable automatic package loading, change the variable -@code{package-enable-at-startup} to @code{nil}. + To keep Emacs from automatically making packages available at +startup, change the variable @code{package-enable-at-startup} to +@code{nil}. You must do this in the early init file (@pxref{Early +Init File,,, elisp, The Emacs Lisp Reference Manual}), as the variable +is read before loading the regular init file. Currently this variable +cannot be set via Customize. @findex package-initialize - The reason automatic package loading occurs after loading the init -file is that user options only receive their customized values after -loading the init file, including user options which affect the -packaging system. In some circumstances, you may want to load -packages explicitly in your init file (usually because some other code -in your init file depends on a package). In that case, your init file -should call the function @code{package-initialize}. It is up to you -to ensure that relevant user options, such as @code{package-load-list} -(see below), are set up prior to the @code{package-initialize} call. -This will automatically set @code{package-enable-at-startup} to @code{nil}, to -avoid loading the packages again after processing the init file. -Alternatively, you may choose to completely inhibit package loading at -startup, and invoke the command @kbd{M-x package-initialize} to load -your packages manually. + If you have set @code{package-enable-at-startup} to @code{nil}, you +can still make packages available either during or after startup. To +make installed packages available during startup, call the function +@code{package-initialize} in your init file. To make installed +packages available after startup, invoke the command @kbd{M-x +package-initialize}. @vindex package-load-list - For finer control over package loading, you can use the variable -@code{package-load-list}. Its value should be a list. A list element -of the form @code{(@var{name} @var{version})} tells Emacs to load -version @var{version} of the package named @var{name}. Here, -@var{version} should be a version string (corresponding to a specific -version of the package), or @code{t} (which means to load any -installed version), or @code{nil} (which means no version; this -disables the package, preventing it from being loaded). A list -element can also be the symbol @code{all}, which means to load the -latest installed version of any package not named by the other list -elements. The default value is just @code{'(all)}. + For finer control over which packages are made available at startup, +you can use the variable @code{package-load-list}. Its value should +be a list. A list element of the form @code{(@var{name} +@var{version})} tells Emacs to make available version @var{version} of +the package named @var{name}. Here, @var{version} should be a version +string (corresponding to a specific version of the package), or +@code{t} (which means to make available any installed version), or +@code{nil} (which means no version; this disables the package, +preventing it from being made available). A list element can also be +the symbol @code{all}, which means to make available the latest +installed version of any package not named by the other list elements. +The default value is just @code{'(all)}. For example, if you set @code{package-load-list} to @code{'((muse -"3.20") all)}, then Emacs only loads version 3.20 of the @samp{muse} -package, plus any installed version of packages other than +"3.20") all)}, then Emacs only makes available version 3.20 of the +@samp{muse} package, plus any installed version of packages other than @samp{muse}. Any other version of @samp{muse} that happens to be installed will be ignored. The @samp{muse} package will be listed in the package menu with the @samp{held} status. diff --git a/doc/lispref/os.texi b/doc/lispref/os.texi index 42be60449d..cac5bfa067 100644 --- a/doc/lispref/os.texi +++ b/doc/lispref/os.texi @@ -95,6 +95,21 @@ Startup Summary @item It does some basic parsing of the command-line arguments. +@item +It loads your early init file (@pxref{Early Init File}). This is not +done if the options @samp{-q}, @samp{-Q}, or @samp{--batch} were +specified. If the @samp{-u} option was specified, Emacs looks for the +init file in that user's home directory instead. + +@item +It calls the function @code{package-initialize} to activate any +optional Emacs Lisp package that has been installed. @xref{Packaging +Basics}. However, Emacs doesn't initialize packages when +@code{package-enable-at-startup} is @code{nil} or when it's started +with one of the options @samp{-q}, @samp{-Q}, or @samp{--batch}. To +initialize packages in the latter case, @code{package-initialize} +should be called explicitly (e.g., via the @samp{--funcall} option). + @vindex initial-window-system@r{, and startup} @vindex window-system-initialization-alist @item @@ -154,15 +169,6 @@ Startup Summary (@pxref{Abbrev Files, abbrev-file-name}). This is not done if the option @samp{--batch} was specified. -@item -It calls the function @code{package-initialize} to activate any -optional Emacs Lisp package that has been installed. @xref{Packaging -Basics}. However, Emacs doesn't initialize packages when -@code{package-enable-at-startup} is @code{nil} or when it's started -with one of the options @samp{-q}, @samp{-Q}, or @samp{--batch}. To -initialize packages in the latter case, @code{package-initialize} -should be called explicitly (e.g., via the @samp{--funcall} option). - @vindex after-init-time @item It sets the variable @code{after-init-time} to the value of @@ -361,6 +367,7 @@ Init File @cindex init file @cindex @file{.emacs} @cindex @file{init.el} +@cindex @file{early-init.el} When you start Emacs, it normally attempts to load your @dfn{init file}. This is either a file named @file{.emacs} or @file{.emacs.el} @@ -384,6 +391,19 @@ Init File file. If those environment variables are absent, though, Emacs uses your user-id to find your home directory. +@cindex early init file + Emacs also attempts to load a second init file, called the +@dfn{early init file}, if it exists. This is a file named +@file{early-init.el} in your @file{~/.emacs.d} directory. The +difference between the early init file and the regular init file is +that the early init file is loaded much earlier during the startup +process, so you can use it to customize some things that are +initialized before loading the regular init file. For example, you +can customize the process of initializing the package system, by +setting variables such as @var{package-load-list} or +@var{package-enable-at-startup}. @xref{Package Installation,,, +emacs,The GNU Emacs Manual}. + @cindex default init file An Emacs installation may have a @dfn{default init file}, which is a Lisp library named @file{default.el}. Emacs finds this file through diff --git a/doc/lispref/package.texi b/doc/lispref/package.texi index 21dfe1c271..877aaf89a3 100644 --- a/doc/lispref/package.texi +++ b/doc/lispref/package.texi @@ -105,24 +105,32 @@ Packaging Basics evaluates the autoload definitions in @file{@var{name}-autoloads.el}. Whenever Emacs starts up, it automatically calls the function -@code{package-initialize} to load installed packages. This is done -after loading the init file and abbrev file (if any) and before -running @code{after-init-hook} (@pxref{Startup Summary}). Automatic -package loading is disabled if the user option -@code{package-enable-at-startup} is @code{nil}. +@code{package-initialize} to make installed packages available to the +current session. This is done after loading the early init file, but +before loading the regular init file (@pxref{Startup Summary}). +Packages are not automatically made available if the user option +@code{package-enable-at-startup} is set to @code{nil} in the early +init file. @deffn Command package-initialize &optional no-activate This function initializes Emacs' internal record of which packages are -installed, and loads them. The user option @code{package-load-list} -specifies which packages to load; by default, all installed packages -are loaded. If called during startup, this function also sets +installed, and makes the packages available to the current session. +The user option @code{package-load-list} specifies which packages to +make available; by default, all installed packages are made available. +If called during startup, this function also sets @code{package-enable-at-startup} to @code{nil}, to avoid accidentally -loading the packages twice. @xref{Package Installation,,, emacs, The -GNU Emacs Manual}. +evaluating package autoloads more than once. @xref{Package +Installation,,, emacs, The GNU Emacs Manual}. The optional argument @var{no-activate}, if non-@code{nil}, causes Emacs to update its record of installed packages without actually -loading them; it is for internal use only. +making them available; it is for internal use only. + +In most cases, you should not need to call @code{package-initialize}, +as this is done automatically during startup. Simply make sure to put +any code that should run before @code{package-initialize} in the early +init file, and any code that should run after it in the primary init +file (@xref{Init File,,, emacs, The GNU Emacs Manual}). @end deffn @node Simple Packages diff --git a/doc/misc/org.texi b/doc/misc/org.texi index aa3b029ab7..68aa01ca18 100644 --- a/doc/misc/org.texi +++ b/doc/misc/org.texi @@ -890,9 +890,7 @@ Installation been visited, i.e., where no Org built-in function have been loaded. Otherwise autoload Org functions will mess up the installation. -Then, to make sure your Org configuration is taken into account, initialize -the package system with @code{(package-initialize)} in your Emacs init file -before setting any Org option. If you want to use Org's package repository, +If you want to use Org's package repository, check out the @uref{http://orgmode.org/elpa.html, Org ELPA page}. @subsubheading Downloading Org as an archive diff --git a/etc/NEWS b/etc/NEWS index 71569c95ad..b6b884b816 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -49,6 +49,25 @@ to reduce differences between developer and production builds. \f * Startup Changes in Emacs 27.1 ++++ +** Emacs can now be configured using an early init file. +The file is called 'early-init.el', in 'user-emacs-directory'. It is +loaded very early in the startup process: before graphical elements +such as the tool bar are initialized, and before the package manager +is initialized. The primary purpose is to allow customizing how the +package system is initialized given that initialization now happens +before loading the regular init file (see below). + ++++ +** Emacs now calls 'package-initialize' before loading the init file. +This is part of a change intended to eliminate the behavior of +package.el inserting a call to 'package-initialize' into the init +file, which was previously done when Emacs was started. As a result +of this change, it is no longer necessary to call 'package-initialize' +in your init file. However, if your init file changes the values of +'package-load-list' or 'package-user-dir', then that code needs to be +moved to the early init file (see above). + \f * Changes in Emacs 27.1 diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el index 71d1c41ec3..ab02d4255b 100644 --- a/lisp/emacs-lisp/package.el +++ b/lisp/emacs-lisp/package.el @@ -1431,16 +1431,11 @@ package-read-all-archive-contents ;; available on disk. (defvar package--initialized nil) -(defvar package--init-file-ensured nil - "Whether we know the init file has package-initialize.") - ;;;###autoload (defun package-initialize (&optional no-activate) "Load Emacs Lisp packages, and activate them. The variable `package-load-list' controls which packages to load. If optional arg NO-ACTIVATE is non-nil, don't activate packages. -If `user-init-file' does not mention `(package-initialize)', add -it to the file. If called as part of loading `user-init-file', set `package-enable-at-startup' to nil, to prevent accidentally loading packages twice. @@ -1449,13 +1444,7 @@ package-initialize taken care of by `package-initialize'." (interactive) (setq package-alist nil) - (if after-init-time - (package--ensure-init-file) - ;; If `package-initialize' is before we finished loading the init - ;; file, it's obvious we don't need to ensure-init. - (setq package--init-file-ensured t - ;; And likely we don't need to run it again after init. - package-enable-at-startup nil)) + (setq package-enable-at-startup nil) (package-load-all-descriptors) (package-read-all-archive-contents) (unless no-activate @@ -1872,64 +1861,6 @@ package-download-transaction using `package-compute-transaction'." (mapc #'package-install-from-archive packages)) -(defun package--ensure-init-file () - "Ensure that the user's init file has `package-initialize'. -`package-initialize' doesn't have to be called, as long as it is -present somewhere in the file, even as a comment. If it is not, -add a call to it along with some explanatory comments." - ;; Don't mess with the init-file from "emacs -Q". - (when (and (stringp user-init-file) - (not package--init-file-ensured) - (file-readable-p user-init-file) - (file-writable-p user-init-file)) - (let* ((buffer (find-buffer-visiting user-init-file)) - buffer-name - (contains-init - (if buffer - (with-current-buffer buffer - (save-excursion - (save-restriction - (widen) - (goto-char (point-min)) - (re-search-forward "(package-initialize\\_>" nil 'noerror)))) - ;; Don't visit the file if we don't have to. - (with-temp-buffer - (insert-file-contents user-init-file) - (goto-char (point-min)) - (re-search-forward "(package-initialize\\_>" nil 'noerror))))) - (unless contains-init - (with-current-buffer (or buffer - (let ((delay-mode-hooks t) - (find-file-visit-truename t)) - (find-file-noselect user-init-file))) - (when buffer - (setq buffer-name (buffer-file-name)) - (set-visited-file-name (file-chase-links user-init-file))) - (save-excursion - (save-restriction - (widen) - (goto-char (point-min)) - (while (and (looking-at-p "[[:blank:]]*\\(;\\|$\\)") - (not (eobp))) - (forward-line 1)) - (insert - "\n" - ";; Added by Package.el. This must come before configurations of\n" - ";; installed packages. Don't delete this line. If you don't want it,\n" - ";; just comment it out by adding a semicolon to the start of the line.\n" - ";; You may delete these explanatory comments.\n" - "(package-initialize)\n") - (unless (looking-at-p "$") - (insert "\n")) - (let ((file-precious-flag t)) - (save-buffer)) - (if buffer - (progn - (set-visited-file-name buffer-name) - (set-buffer-modified-p nil)) - (kill-buffer (current-buffer))))))))) - (setq package--init-file-ensured t)) - ;;;###autoload (defun package-install (pkg &optional dont-select) "Install the package PKG. diff --git a/lisp/startup.el b/lisp/startup.el index 8c36c19e82..69bc8fa781 100644 --- a/lisp/startup.el +++ b/lisp/startup.el @@ -312,6 +312,12 @@ inhibit-startup-hooks Currently this applies to: `emacs-startup-hook', `term-setup-hook', and `window-setup-hook'.") +(defvar early-init-file nil + "File name, including directory, of user's early init file. +See `user-init-file'. The only difference is that +`early-init-file' is not set during the course of evaluating the +early init file.") + (defvar keyboard-type nil "The brand of keyboard you are using. This variable is used to define the proper function and keypad @@ -870,6 +876,103 @@ startup--setup-quote-display (when standard-display-table (aset standard-display-table char nil))))))) +(defun load-user-init-file + (filename-function &optional alternate-filename-function load-defaults) + "Load a user init-file. +FILENAME-FUNCTION is called with no arguments and should return +the name of the init-file to load. If this file cannot be +loaded, and ALTERNATE-FILENAME-FUNCTION is non-nil, then it is +called with no arguments and should return the name of an +alternate init-file to load. If LOAD-DEFAULTS is non-nil, then +load default.el after the init-file. + +This function sets `user-init-file' to the name of the loaded +init-file, or to a default value if loading is not possible." + (let ((debug-on-error-from-init-file nil) + (debug-on-error-should-be-set nil) + (debug-on-error-initial + (if (eq init-file-debug t) + 'startup + init-file-debug))) + (let ((debug-on-error debug-on-error-initial) + ;; We create an anonymous function here so that we can call + ;; it in different contexts depending on the value of + ;; `debug-on-error'. + (read-init-file + (lambda () + (when init-file-user + (let ((init-file-name (funcall filename-function))) + + ;; If `user-init-file' is t, then `load' will store + ;; the name of the file that it loads into + ;; `user-init-file'. + (setq user-init-file t) + (load init-file-name 'noerror 'nomessage) + + (when (and (eq user-init-file t) alternate-filename-function) + (load (funcall alternate-filename-function) + 'noerror 'nomessage)) + + ;; If we did not find the user's init file, set + ;; user-init-file conclusively. Don't let it be + ;; set from default.el. + (when (eq user-init-file t) + (setq user-init-file init-file-name))) + + ;; If we loaded a compiled file, set `user-init-file' to + ;; the source version if that exists. + (when (equal (file-name-extension user-init-file) + "elc") + (let* ((source (file-name-sans-extension user-init-file)) + (alt (concat source ".el"))) + (setq source (cond ((file-exists-p alt) alt) + ((file-exists-p source) source) + (t nil))) + (when source + (when (file-newer-than-file-p source user-init-file) + (message "Warning: %s is newer than %s" + source user-init-file) + (sit-for 1)) + (setq user-init-file source)))) + + (when load-defaults + + ;; Prevent default.el from changing the value of + ;; `inhibit-startup-screen'. + (let ((inhibit-startup-screen nil)) + (load "default" 'noerror 'nomessage))))))) + ;; Now call our anonymous function. + (if init-file-debug + ;; Do this without a `condition-case' if the user wants to + ;; debug. + (funcall read-init-file) + (condition-case error + (funcall read-init-file) + (error + (display-warning + 'initialization + (format-message "\ +An error occurred while loading `%s':\n\n%s%s%s\n\n\ +To ensure normal operation, you should investigate and remove the +cause of the error in your initialization file. Start Emacs with +the `--debug-init' option to view a complete error backtrace." + user-init-file + (get (car error) 'error-message) + (if (cdr error) ": " "") + (mapconcat (lambda (s) (prin1-to-string s t)) + (cdr error) ", ")) + :warning) + (setq init-file-had-error t)))) + + ;; If we can tell that the init file altered debug-on-error, + ;; arrange to preserve the value that it set up. + (or (eq debug-on-error debug-on-error-initial) + (setq debug-on-error-should-be-set t + debug-on-error-from-init-file debug-on-error))) + + (when debug-on-error-should-be-set + (setq debug-on-error debug-on-error-from-init-file)))) + (defun command-line () "A subroutine of `normal-top-level'. Amongst another things, it parses the command-line arguments." @@ -1021,6 +1124,69 @@ command-line (and command-line-args (setcdr command-line-args args))) + ;; Warn for invalid user name. + (when init-file-user + (if (string-match "[~/:\n]" init-file-user) + (display-warning 'initialization + (format "Invalid user name %s" + init-file-user) + :error) + (if (file-directory-p (expand-file-name + ;; We don't support ~USER on MS-Windows + ;; and MS-DOS except for the current + ;; user, and always load .emacs from + ;; the current user's home directory + ;; (see below). So always check "~", + ;; even if invoked with "-u USER", or + ;; if $USER or $LOGNAME are set to + ;; something different. + (if (memq system-type '(windows-nt ms-dos)) + "~" + (concat "~" init-file-user)))) + nil + (display-warning 'initialization + (format "User %s has no home directory" + (if (equal init-file-user "") + (user-real-login-name) + init-file-user)) + :error)))) + + ;; Load the early init file, if found. + (load-user-init-file + (lambda () + (expand-file-name + "early-init" + (file-name-as-directory + (concat "~" init-file-user "/.emacs.d"))))) + (setq early-init-file user-init-file) + + ;; If any package directory exists, initialize the package system. + (and user-init-file + package-enable-at-startup + (catch 'package-dir-found + (let (dirs) + (if (boundp 'package-directory-list) + (setq dirs package-directory-list) + (dolist (f load-path) + (and (stringp f) + (equal (file-name-nondirectory f) "site-lisp") + (push (expand-file-name "elpa" f) dirs)))) + (push (if (boundp 'package-user-dir) + package-user-dir + (locate-user-emacs-file "elpa")) + dirs) + (dolist (dir dirs) + (when (file-directory-p dir) + (dolist (subdir (directory-files dir)) + (when (let ((subdir (expand-file-name subdir dir))) + (and (file-directory-p subdir) + (file-exists-p + (expand-file-name + (package--description-file subdir) + subdir)))) + (throw 'package-dir-found t))))))) + (package-initialize)) + ;; Make sure window system's init file was loaded in loadup.el if ;; using a window system. ;; Initialize the window-system only after processing the command-line @@ -1128,153 +1294,47 @@ command-line ;; the startup screen. (setq inhibit-startup-screen nil) - ;; Warn for invalid user name. - (when init-file-user - (if (string-match "[~/:\n]" init-file-user) - (display-warning 'initialization - (format "Invalid user name %s" - init-file-user) - :error) - (if (file-directory-p (expand-file-name - ;; We don't support ~USER on MS-Windows - ;; and MS-DOS except for the current - ;; user, and always load .emacs from - ;; the current user's home directory - ;; (see below). So always check "~", - ;; even if invoked with "-u USER", or - ;; if $USER or $LOGNAME are set to - ;; something different. - (if (memq system-type '(windows-nt ms-dos)) - "~" - (concat "~" init-file-user)))) - nil - (display-warning 'initialization - (format "User %s has no home directory" - (if (equal init-file-user "") - (user-real-login-name) - init-file-user)) - :error)))) - ;; Load that user's init file, or the default one, or none. - (let (debug-on-error-from-init-file - debug-on-error-should-be-set - (debug-on-error-initial - (if (eq init-file-debug t) 'startup init-file-debug))) - (let ((debug-on-error debug-on-error-initial) - ;; This function actually reads the init files. - (inner - (function - (lambda () - (if init-file-user - (let ((user-init-file-1 - (cond - ((eq system-type 'ms-dos) - (concat "~" init-file-user "/_emacs")) - ((not (eq system-type 'windows-nt)) - (concat "~" init-file-user "/.emacs")) - ;; Else deal with the Windows situation - ((directory-files "~" nil "^\\.emacs\\(\\.elc?\\)?$") - ;; Prefer .emacs on Windows. - "~/.emacs") - ((directory-files "~" nil "^_emacs\\(\\.elc?\\)?$") - ;; Also support _emacs for compatibility, but warn about it. - (push `(initialization - ,(format-message - "`_emacs' init file is deprecated, please use `.emacs'")) - delayed-warnings-list) - "~/_emacs") - (t ;; But default to .emacs if _emacs does not exist. - "~/.emacs")))) - ;; This tells `load' to store the file name found - ;; into user-init-file. - (setq user-init-file t) - (load user-init-file-1 t t) - - (when (eq user-init-file t) - ;; If we did not find ~/.emacs, try - ;; ~/.emacs.d/init.el. - (let ((otherfile - (expand-file-name - "init" - (file-name-as-directory - (concat "~" init-file-user "/.emacs.d"))))) - (load otherfile t t) - - ;; If we did not find the user's init file, - ;; set user-init-file conclusively. - ;; Don't let it be set from default.el. - (when (eq user-init-file t) - (setq user-init-file user-init-file-1)))) - - ;; If we loaded a compiled file, set - ;; `user-init-file' to the source version if that - ;; exists. - (when (and user-init-file - (equal (file-name-extension user-init-file) - "elc")) - (let* ((source (file-name-sans-extension user-init-file)) - (alt (concat source ".el"))) - (setq source (cond ((file-exists-p alt) alt) - ((file-exists-p source) source) - (t nil))) - (when source - (when (file-newer-than-file-p source user-init-file) - (message "Warning: %s is newer than %s" - source user-init-file) - (sit-for 1)) - (setq user-init-file source)))) - - (unless inhibit-default-init - (let ((inhibit-startup-screen nil)) - ;; Users are supposed to be told their rights. - ;; (Plus how to get help and how to undo.) - ;; Don't you dare turn this off for anyone - ;; except yourself. - (load "default" t t))))))))) - (if init-file-debug - ;; Do this without a condition-case if the user wants to debug. - (funcall inner) - (condition-case error - (progn - (funcall inner) - (setq init-file-had-error nil)) - (error - (display-warning - 'initialization - (format-message "\ -An error occurred while loading `%s':\n\n%s%s%s\n\n\ -To ensure normal operation, you should investigate and remove the -cause of the error in your initialization file. Start Emacs with -the `--debug-init' option to view a complete error backtrace." - user-init-file - (get (car error) 'error-message) - (if (cdr error) ": " "") - (mapconcat (lambda (s) (prin1-to-string s t)) - (cdr error) ", ")) - :warning) - (setq init-file-had-error t)))) - - (if (and deactivate-mark transient-mark-mode) - (with-current-buffer (window-buffer) - (deactivate-mark))) - - ;; If the user has a file of abbrevs, read it (unless -batch). - (when (and (not noninteractive) - (file-exists-p abbrev-file-name) - (file-readable-p abbrev-file-name)) - (quietly-read-abbrev-file abbrev-file-name)) - - ;; If the abbrevs came entirely from the init file or the - ;; abbrevs file, they do not need saving. - (setq abbrevs-changed nil) - - ;; If we can tell that the init file altered debug-on-error, - ;; arrange to preserve the value that it set up. - (or (eq debug-on-error debug-on-error-initial) - (setq debug-on-error-should-be-set t - debug-on-error-from-init-file debug-on-error))) - (if debug-on-error-should-be-set - (setq debug-on-error debug-on-error-from-init-file))) + (load-user-init-file + (lambda () + (cond + ((eq system-type 'ms-dos) + (concat "~" init-file-user "/_emacs")) + ((not (eq system-type 'windows-nt)) + (concat "~" init-file-user "/.emacs")) + ;; Else deal with the Windows situation. + ((directory-files "~" nil "^\\.emacs\\(\\.elc?\\)?$") + ;; Prefer .emacs on Windows. + "~/.emacs") + ((directory-files "~" nil "^_emacs\\(\\.elc?\\)?$") + ;; Also support _emacs for compatibility, but warn about it. + (push `(initialization + ,(format-message + "`_emacs' init file is deprecated, please use `.emacs'")) + delayed-warnings-list) + "~/_emacs") + (t ;; But default to .emacs if _emacs does not exist. + "~/.emacs"))) + (lambda () + (expand-file-name + "init" + (file-name-as-directory + (concat "~" init-file-user "/.emacs.d")))) + (not inhibit-default-init)) + + (when (and deactivate-mark transient-mark-mode) + (with-current-buffer (window-buffer) + (deactivate-mark))) + + ;; If the user has a file of abbrevs, read it (unless -batch). + (when (and (not noninteractive) + (file-exists-p abbrev-file-name) + (file-readable-p abbrev-file-name)) + (quietly-read-abbrev-file abbrev-file-name)) + + ;; If the abbrevs came entirely from the init file or the + ;; abbrevs file, they do not need saving. + (setq abbrevs-changed nil) ;; Do this here in case the init file sets mail-host-address. (and mail-host-address @@ -1296,33 +1356,6 @@ command-line (eq face-ignored-fonts old-face-ignored-fonts)) (clear-face-cache))) - ;; If any package directory exists, initialize the package system. - (and user-init-file - package-enable-at-startup - (catch 'package-dir-found - (let (dirs) - (if (boundp 'package-directory-list) - (setq dirs package-directory-list) - (dolist (f load-path) - (and (stringp f) - (equal (file-name-nondirectory f) "site-lisp") - (push (expand-file-name "elpa" f) dirs)))) - (push (if (boundp 'package-user-dir) - package-user-dir - (locate-user-emacs-file "elpa")) - dirs) - (dolist (dir dirs) - (when (file-directory-p dir) - (dolist (subdir (directory-files dir)) - (when (let ((subdir (expand-file-name subdir dir))) - (and (file-directory-p subdir) - (file-exists-p - (expand-file-name - (package--description-file subdir) - subdir)))) - (throw 'package-dir-found t))))))) - (package-initialize)) - (setq after-init-time (current-time)) ;; Display any accumulated warnings after all functions in ;; `after-init-hook' like `desktop-read' have finalized possible diff --git a/src/lread.c b/src/lread.c index 7cacd47d51..d009bd0cd2 100644 --- a/src/lread.c +++ b/src/lread.c @@ -4922,7 +4922,7 @@ directory. These file names are converted to absolute at startup. */); If the file loaded had extension `.elc', and the corresponding source file exists, this variable contains the name of source file, suitable for use by functions like `custom-save-all' which edit the init file. -While Emacs loads and evaluates the init file, value is the real name +While Emacs loads and evaluates any init file, value is the real name of the file, regardless of whether or not it has the `.elc' extension. */); Vuser_init_file = Qnil; -- 2.16.1 ^ permalink raw reply related [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-26 19:24 ` Radon Rosborough 2018-01-26 20:02 ` Eli Zaretskii @ 2018-01-27 20:44 ` Richard Stallman 2018-01-28 6:30 ` Radon Rosborough 1 sibling, 1 reply; 838+ messages in thread From: Richard Stallman @ 2018-01-27 20:44 UTC (permalink / raw) To: Radon Rosborough; +Cc: emacs-devel [[[ 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. ]]] > Perhaps some better terminology would be in order? I would suggest > that we never refer to "loading" a package, and instead say: > * "activating a package" means evaluating its autoloads > * "loading a file/feature" means evaluating some particular file of > Lisp code, which is possibly part of a package I think it is ok to talk about "loading a package" if that means loading its files. However, if you evaluate its autoloads, you won't need to explicitly load its files ever, since the autoloads will do that. Thus, the manual may only need to talk about activating it. I think there should be a way to activate a package explicitly for the current session _without_ automatically activating it for future sessions. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-27 20:44 ` Richard Stallman @ 2018-01-28 6:30 ` Radon Rosborough 2018-01-28 9:33 ` Charles A. Roelli 2018-01-28 13:21 ` Stefan Monnier 0 siblings, 2 replies; 838+ messages in thread From: Radon Rosborough @ 2018-01-28 6:30 UTC (permalink / raw) To: rms; +Cc: emacs-devel > I think there should be a way to activate a package explicitly for the > current session _without_ automatically activating it for future > sessions. The failure of package.el to support this use case is (one reason) why I wrote straight.el [1]. Another tool which is designed to extend package.el to allow for temporary activation of packages is Try [2]. If functionality in this area were added directly to package.el, I think it would be a great improvement. [1]: https://github.com/raxod502/straight.el [2]: https://github.com/larstvei/Try ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-28 6:30 ` Radon Rosborough @ 2018-01-28 9:33 ` Charles A. Roelli 2018-01-28 13:21 ` Stefan Monnier 1 sibling, 0 replies; 838+ messages in thread From: Charles A. Roelli @ 2018-01-28 9:33 UTC (permalink / raw) To: Radon Rosborough; +Cc: rms, emacs-devel > From: Radon Rosborough <radon.neon@gmail.com> > Date: Sat, 27 Jan 2018 22:30:14 -0800 > > > I think there should be a way to activate a package explicitly for the > > current session _without_ automatically activating it for future > > sessions. > > The failure of package.el to support this use case is (one reason) why > I wrote straight.el [1]. Another tool which is designed to extend > package.el to allow for temporary activation of packages is Try [2]. > If functionality in this area were added directly to package.el, I > think it would be a great improvement. > > [1]: https://github.com/raxod502/straight.el > [2]: https://github.com/larstvei/Try One of the proposals listed in an earlier message was to not insert the call to package-initialize anymore: > URL: https://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00023.html > > ==> Proposal H: Make the user do it manually > Summary: > - make it so that package.el doesn't modify the init-file, but don't > change anything else > - this is how it worked before the first "solution" to this problem > was implemented > Advantages: > - Emacs does not modify the user's init-file > Disadvantages: > - package.el does not work out of the box, since package > customizations will fail when put into the init-file > - consequently we get lots of superfluous bug reports FWIW, taking this route would allow people to install packages in a session without affecting their initialization file, so it would be the user's burden to arrange activating the package in future sessions. It could at least lead to a better understanding of package.el for the average user, but as stated, it would probably be the cause of at least a few "superfluous bug reports". ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-28 6:30 ` Radon Rosborough 2018-01-28 9:33 ` Charles A. Roelli @ 2018-01-28 13:21 ` Stefan Monnier 2018-01-28 17:32 ` Radon Rosborough 2018-01-29 1:50 ` Richard Stallman 1 sibling, 2 replies; 838+ messages in thread From: Stefan Monnier @ 2018-01-28 13:21 UTC (permalink / raw) To: emacs-devel >> I think there should be a way to activate a package explicitly for the >> current session _without_ automatically activating it for future >> sessions. > The failure of package.el to support this use case FWIW, package.el does support this case: - one way is to prevent package-initialize from activating packages, and then activating the ones you want by explicit calls to package-active. - another is to set package-load-list. E.g. (setq package-load-list '((auctex nil) all)) This said, if a package's activation gets in the way of the user, I'd generally consider it to be a bug in that package (similar to the fact that if (require <foo>) has undesirable effects it's usually a bug in <foo>). E.g. packages providing some kind of global minor mode should never have that minor mode enabled just by activating the package: instead the activation should do nothing more than autoload the minor mode function. Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-28 13:21 ` Stefan Monnier @ 2018-01-28 17:32 ` Radon Rosborough 2018-01-28 22:11 ` Stefan Monnier 2018-01-29 1:50 ` Richard Stallman 1 sibling, 1 reply; 838+ messages in thread From: Radon Rosborough @ 2018-01-28 17:32 UTC (permalink / raw) To: Stefan Monnier; +Cc: John Wiegley, emacs-devel > This said, if a package's activation gets in the way of the user, I'd > generally consider it to be a bug in that package (similar to the fact > that if (require <foo>) has undesirable effects it's usually a bug in > <foo>). Activation of packages is a significant performance hit. It's therefore not a good idea to be activating superfluous packages. JW has told me that one of the reasons his Emacs configuration does not use package.el is that activating packages was too slow. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-28 17:32 ` Radon Rosborough @ 2018-01-28 22:11 ` Stefan Monnier 2018-01-29 1:08 ` T.V Raman ` (2 more replies) 0 siblings, 3 replies; 838+ messages in thread From: Stefan Monnier @ 2018-01-28 22:11 UTC (permalink / raw) To: Radon Rosborough; +Cc: John Wiegley, George Plymale II, emacs-devel >> This said, if a package's activation gets in the way of the user, I'd >> generally consider it to be a bug in that package (similar to the fact >> that if (require <foo>) has undesirable effects it's usually a bug in >> <foo>). > Activation of packages is a significant performance hit. > It's therefore not a good idea to be activating superfluous packages. > JW has told me that one of the reasons his Emacs configuration does > not use package.el is that activating packages was too slow. The performance impact is indeed something that probably deserves a bit more work. But we need to clarify what are the expected use cases and sources of problems. E.g.: - In the case of JW, why does he have so many packages installed to slow down his startup, yet he doesn't want them activated? Are these packages that he does use, but just rarely? Or does he just have lots of packages installed that he doesn't use (e.g. that's my case: I always have all GNU ELPA packages installed, even though I use very few of them)? If so, why does he have so many packages installed even tho he doesn't use them? - In my case I have around 200 packages installed and I measured the startup cost of package-initialize to be 0.9s (with a warm cache). That's plenty fast for my use case (where I rarely start a new Emacs session), but I understand it may not be for people who like to use Emacs for quick one-off editing sessions. Still, what kind of slowdown is JW talking about: is it also in the order of 1s? more? If the slowdown is significant, could it be due to packages that do "too much work" in the <pkg>-autoloads.el or is it really just the sheer number of <pkg>-autoloads.el and <pkg>-pkg.el to process? The issue came up recently on stackexchange and I whipped up a quick&dirty patch to experiment (see below) which shows that my 0.9s can be brought down to 0.3s by pre-computing a "big autoloads file", which can then be brought down to 0.2s by loading it with load-source-file-function bound to nil and can be reduced further to 0.1s by byte-compiling it. Another thing we could do is add support for activating a package without calling package-initialize beforehand (since just calling (package-initialize t) can already take a non-negligible amount of time, reading all the <pkg>-pkg.el files). This way, a user could simply skip package-initialize completely and just "manually" activate those few packages he wants to activate. It should be fairly easy to implement. Stefan diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el index 71d1c41ec3..63ec6f40f7 100644 --- a/lisp/emacs-lisp/package.el +++ b/lisp/emacs-lisp/package.el @@ -676,6 +676,8 @@ package--activate-autoloads-and-load-path (defvar Info-directory-list) (declare-function info-initialize "info" ()) +(defvar package--fastpath-pkgs t) + (defun package--load-files-for-activation (pkg-desc reload) "Load files for activating a package given by PKG-DESC. Load the autoloads file, and ensure `load-path' is setup. If @@ -718,16 +720,19 @@ package-activate-1 (message "Unable to activate package `%s'.\nRequired package `%s-%s' is unavailable" name (car req) (package-version-join (cadr req))) (throw 'exit nil)))) - (package--load-files-for-activation pkg-desc reload) - ;; Add info node. - (when (file-exists-p (expand-file-name "dir" pkg-dir)) - ;; FIXME: not the friendliest, but simple. - (require 'info) - (info-initialize) - (push pkg-dir Info-directory-list)) - (push name package-activated-list) - ;; Don't return nil. - t))) + (if (listp package--fastpath-pkgs) + ;; We're only collecting the set of packages to activate! + (push pkg-desc package--fastpath-pkgs) + (package--load-files-for-activation pkg-desc reload) + ;; Add info node. + (when (file-exists-p (expand-file-name "dir" pkg-dir)) + ;; FIXME: not the friendliest, but simple. + (require 'info) + (info-initialize) + (push pkg-dir Info-directory-list)) + (push name package-activated-list) + ;; Don't return nil. + t)))) (declare-function find-library-name "find-func" (library)) @@ -3468,6 +3473,49 @@ package-list-packages-no-fetch (interactive) (list-packages t)) +;;;; Fast-path for activation! + +(defcustom package-fastpath-file (locate-user-emacs-file "package-fastpath.el") + "Location of the file used to speed up activation of packages at startup." + :type 'file) + +(defun package-fastpath-refresh () + "(Re)Generate the `package-fastpath-file'." + (interactive) + (package-initialize 'no-activate) + (let ((package--fastpath-pkgs ()) + ;; Pretend we haven't activated anything yet! + (package-activated-list ())) + (dolist (elt package-alist) + (condition-case err + (package-activate (car elt)) + ;; Don't let failure of activation of a package arbitrarily stop + ;; activation of further packages. + (error (message "%s" (error-message-string err))))) + (with-temp-file package-fastpath-file + (insert ";;; FastPath file to speed up package activation at startup -*- lexical-binding:t -*-\n") + (insert ";; ¡¡ This file is autogenerated, DO NOT EDIT !!\n\n") + (dolist (pkg package--fastpath-pkgs) + (let* ((file (locate-library (package--autoloads-file-name pkg))) + (pfile (prin1-to-string file))) + (insert "(let ((load-file-name " pfile "))\n") + (insert-file-contents file) + (while (search-forward "#$" nil 'move) + (replace-match pfile t t)) + (unless (bolp) (insert "\n")) + (insert ")\n"))) + (pp `(setq package-activated-list + (append ',(mapcar #'package-desc-name package--fastpath-pkgs) + package-activated-list)) + (current-buffer)) + (insert "\f +;; Local Variables: +;; version-control: never +;; no-byte-compile: nil +;; no-update-autoloads: t +;; End: +")))) + (provide 'package) ;;; package.el ends here ^ permalink raw reply related [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-28 22:11 ` Stefan Monnier @ 2018-01-29 1:08 ` T.V Raman 2018-01-29 5:53 ` Radon Rosborough 2018-01-29 6:55 ` John Wiegley 2 siblings, 0 replies; 838+ messages in thread From: T.V Raman @ 2018-01-29 1:08 UTC (permalink / raw) To: Stefan Monnier Cc: John Wiegley, Radon Rosborough, George Plymale II, emacs-devel The trick re load-source-file-function is one I did not know. A few months ago I discovered that let-binding file-name-handler-alist to nil during startup significantly sped things up. -- ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-28 22:11 ` Stefan Monnier 2018-01-29 1:08 ` T.V Raman @ 2018-01-29 5:53 ` Radon Rosborough 2018-01-29 7:21 ` John Wiegley 2018-01-29 18:54 ` Stefan Monnier 2018-01-29 6:55 ` John Wiegley 2 siblings, 2 replies; 838+ messages in thread From: Radon Rosborough @ 2018-01-29 5:53 UTC (permalink / raw) To: Stefan Monnier; +Cc: John Wiegley, George Plymale II, emacs-devel > - In the case of JW, why does he have so many packages installed to slow > down his startup, yet he doesn't want them activated? Are these > packages that he does use, but just rarely? Or does he just have lots of > packages installed that he doesn't use (e.g. that's my case: I always > have all GNU ELPA packages installed, even though I use very few of > them)? If so, why does he have so many packages installed even tho he > doesn't use them? JW does not use package.el. Instead he uses git-subtree to manage the packages and use-package to autoload them. The point I was trying to demonstrate by bringing this up was that package activation is not cheap. > Still, what kind of slowdown is JW talking about: is it also in the > order of 1s? I quote: Especially when working on modes with complex state, I frequently restart Emacs, sometimes hundreds of times a day. Before use-package, my load times were upwards of 10-20 seconds. Today, even with >300 declarations, it's down to 0.44 seconds, without any loss of functionality. -- Radon ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-29 5:53 ` Radon Rosborough @ 2018-01-29 7:21 ` John Wiegley 2018-01-29 18:54 ` Stefan Monnier 1 sibling, 0 replies; 838+ messages in thread From: John Wiegley @ 2018-01-29 7:21 UTC (permalink / raw) To: Radon Rosborough; +Cc: emacs-devel, Stefan Monnier, George Plymale II >>>>> "RR" == Radon Rosborough <radon.neon@gmail.com> writes: RR> JW does not use package.el. Instead he uses git-subtree to manage the RR> packages and use-package to autoload them. The point I was trying to RR> demonstrate by bringing this up was that package activation is not cheap. As of tow weeks ago, I now use Nix to manage my environment, instead of subtrees. :) This makes it easier to vary what is installed based on the combination of Emacs and OS version, and also I can pin individual packages at specific versions, install custom patches, or add installation details for packages not in ELPA or MELPA. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-29 5:53 ` Radon Rosborough 2018-01-29 7:21 ` John Wiegley @ 2018-01-29 18:54 ` Stefan Monnier 2018-01-29 19:19 ` John Wiegley 1 sibling, 1 reply; 838+ messages in thread From: Stefan Monnier @ 2018-01-29 18:54 UTC (permalink / raw) To: Radon Rosborough; +Cc: John Wiegley, George Plymale II, emacs-devel >> Still, what kind of slowdown is JW talking about: is it also in the >> order of 1s? > I quote: > Especially when working on modes with complex state, I frequently > restart Emacs, sometimes hundreds of times a day. Before use-package, > my load times were upwards of 10-20 seconds. Today, even with >300 > declarations, it's down to 0.44 seconds, without any loss of > functionality. Hopefully John will chime in to correct me, but my vague understanding is that his 10-20s were not due to package-initialize, but rather to "manual installation" methods and configuration. Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-29 18:54 ` Stefan Monnier @ 2018-01-29 19:19 ` John Wiegley 2018-01-29 19:55 ` Stefan Monnier 0 siblings, 1 reply; 838+ messages in thread From: John Wiegley @ 2018-01-29 19:19 UTC (permalink / raw) To: Stefan Monnier; +Cc: Radon Rosborough, George Plymale II, emacs-devel >>>>> "SM" == Stefan Monnier <monnier@IRO.UMontreal.CA> writes: SM> Hopefully John will chime in to correct me, but my vague understanding is SM> that his 10-20s were not due to package-initialize, but rather to "manual SM> installation" methods and configuration. It's not entirely due to package-initialize, but that accounted for about 5 seconds of it. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-29 19:19 ` John Wiegley @ 2018-01-29 19:55 ` Stefan Monnier 0 siblings, 0 replies; 838+ messages in thread From: Stefan Monnier @ 2018-01-29 19:55 UTC (permalink / raw) To: Radon Rosborough; +Cc: George Plymale II, emacs-devel > SM> Hopefully John will chime in to correct me, but my vague understanding is > SM> that his 10-20s were not due to package-initialize, but rather to "manual > SM> installation" methods and configuration. > It's not entirely due to package-initialize, but that accounted for about 5 > seconds of it. Hmm... since my 200 packages take 0.9s on my Thinkpad T61, there's a good chance that those 5s with your <400 packages are linked to some poorly packaged packages (more specifically, packages which do too much work in their <pkg>-autoloads.el, most likely leading not only to a slow startup but also to undesirable side-effects for those users who have the package installed yet don't want to use it). Maybe we should make more efforts at documenting/promoting good practices in this regard (tho, we should likely first try and figure out where those 5s are spent, to make sure we don't bark up the wrong tree). I'd also be interested to know how much time it takes your machine to load the "package-fastpath" file that my patch builds (both in source form and in compiled form). To distinguish the time taken by the packages's activation itself from the time taken by package-initialize to find and fetch that package activation code. Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-28 22:11 ` Stefan Monnier 2018-01-29 1:08 ` T.V Raman 2018-01-29 5:53 ` Radon Rosborough @ 2018-01-29 6:55 ` John Wiegley 2018-01-29 19:08 ` Stefan Monnier 2 siblings, 1 reply; 838+ messages in thread From: John Wiegley @ 2018-01-29 6:55 UTC (permalink / raw) To: Stefan Monnier; +Cc: Radon Rosborough, George Plymale II, emacs-devel [-- Attachment #1: Type: text/plain, Size: 2514 bytes --] >>>>> "SM" == Stefan Monnier <monnier@IRO.UMontreal.CA> writes: SM> - In the case of JW, why does he have so many packages installed to slow SM> down his startup, yet he doesn't want them activated? Are these packages SM> that he does use, but just rarely? Or does he just have lots of packages SM> installed that he doesn't use (e.g. that's my case: I always have all GNU SM> ELPA packages installed, even though I use very few of them)? If so, why SM> does he have so many packages installed even tho he doesn't use them? I do use them, all of them. At present there are just over 385 in my local configuration. However, they don't all need to be active and available immediately after startup. They fall into several categories, all of which can be deferred: 1. A set of keybinding(s) that should "activate" the package and make its functionality available. Until I press one of those keys, the package can stay dormant, and no time should be spent on it. 2. An entry in auto-mode-alist, interpreter-mode-list, etc. 3. A command I must invoke via M-x to trigger autoload. 4. Some other condition, like the loading of one of the aforementioned packages. 5. Waiting until some amount of idle time has passed, since the mode in question is just a "bell & whistle", and I shouldn't need to wait for it to start using Emacs. In fact, the packages I require to be immediately available, the instant Emacs becomes ready, are incredibly few (I'm not even sure there are any!). By deferring absolutely everything, and autoloading only precisely what is needed to trigger activation, I can have Emacs available within 0.4 seconds after startup, with all the other functionality coming online as I perform the actions that cause them to lazy load. And before you ask: Yes, I do restart my Emacs. A lot. This is the whole reason I evolved this technique. Sometimes I restart Emacs over a 100 times a day, simply because it's the only way I can be completely sure that my state has been reset (which includes Emacs state, Nix state, shell state, OS state). Thanks to use-package, I don't need to think very hard to make such a setup work. And since there's almost no cost to adding in more functionality to my Emacs, I add tons and tons: all within easy reach should I need it. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 658 bytes --] ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-29 6:55 ` John Wiegley @ 2018-01-29 19:08 ` Stefan Monnier 2018-01-29 19:55 ` John Wiegley 2018-01-29 20:18 ` Clément Pit-Claudel 0 siblings, 2 replies; 838+ messages in thread From: Stefan Monnier @ 2018-01-29 19:08 UTC (permalink / raw) To: Radon Rosborough; +Cc: George Plymale II, emacs-devel > Thanks to use-package, I don't need to think very hard to make such a setup > work. And since there's almost no cost to adding in more functionality to my > Emacs, I add tons and tons: all within easy reach should I need it. We were talking about package activation rather than configuration, so use-package is not an apples-to-apples comparison. `package-initialize` is supposed to do things like: > 1. A set of keybinding(s) that should "activate" the package and make its > functionality available. Until I press one of those keys, the package > can stay dormant, and no time should be spent on it. > > 2. An entry in auto-mode-alist, interpreter-mode-list, etc. > > 3. A command I must invoke via M-x to trigger autoload. and pretty much nothing else, i.e. a subset of what use-package is often used for. AFAIK for packages installed with package.el, this part of use-package only makes sense when the packages is not properly packaged (i.e. doesn't do 1/2/3 correctly in their <pkg>-autoloads.el). Regarding the other two points: > 4. Some other condition, like the loading of one of the aforementioned > packages. > > 5. Waiting until some amount of idle time has passed, since the mode in > question is just a "bell & whistle", and I shouldn't need to wait for > it to start using Emacs. These have to do with configuration, not with activation, so package-initialize should never do any of that nor prevent doing any of that. This part of use-package is just as useful for ELPA-installed packages as for any others. > I do use them, all of them. At present there are just over 385 in my local > configuration. [...] > to trigger activation, I can have Emacs available within 0.4 seconds after > startup, with all the other functionality coming online as I perform the I don't think I can easily bring down the speed of package-initialize much below 0.1s for my 200 packages on my Thinkpad T61. Whether that would still let you startup in 0.4s with your config, I can't tell. There's no doubt that with use-package you have a finer control about what happens when, so you can delay some of the things done during package-initialize, but without looking more deeply into it, it's hard to tell whether that would really be needed. Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-29 19:08 ` Stefan Monnier @ 2018-01-29 19:55 ` John Wiegley 2018-01-29 21:50 ` Stefan Monnier 2018-01-29 20:18 ` Clément Pit-Claudel 1 sibling, 1 reply; 838+ messages in thread From: John Wiegley @ 2018-01-29 19:55 UTC (permalink / raw) To: Stefan Monnier; +Cc: Radon Rosborough, George Plymale II, emacs-devel >>>>> "SM" == Stefan Monnier <monnier@IRO.UMontreal.CA> writes: SM> I don't think I can easily bring down the speed of package-initialize much SM> below 0.1s for my 200 packages on my Thinkpad T61. Whether that would SM> still let you startup in 0.4s with your config, I can't tell. SM> There's no doubt that with use-package you have a finer control about what SM> happens when, so you can delay some of the things done during SM> package-initialize, but without looking more deeply into it, it's hard to SM> tell whether that would really be needed. True. Note that I did shave an entire second from my startup time just by adding: (setq package-enable-at-startup nil) I determined this was slowing things down considerably (at least, in my environment) by running profiler-start as the very first thing in my init file. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-29 19:55 ` John Wiegley @ 2018-01-29 21:50 ` Stefan Monnier 2018-01-29 23:13 ` Clément Pit-Claudel 2018-01-30 1:37 ` T.V Raman 0 siblings, 2 replies; 838+ messages in thread From: Stefan Monnier @ 2018-01-29 21:50 UTC (permalink / raw) To: Radon Rosborough; +Cc: George Plymale II, emacs-devel > True. Note that I did shave an entire second from my startup time just by > adding: > (setq package-enable-at-startup nil) My experiments indicate that we might be able to divide this time by almost a factor 10 if we pre-compute and byte-compile one big autoloads file, so it would only shave 0.1s of your startup time. Given that it would also let you simplify the rest of your startup, there's a chance the result would be pretty competitive with your current setup. Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-29 21:50 ` Stefan Monnier @ 2018-01-29 23:13 ` Clément Pit-Claudel 2018-01-30 1:37 ` T.V Raman 1 sibling, 0 replies; 838+ messages in thread From: Clément Pit-Claudel @ 2018-01-29 23:13 UTC (permalink / raw) To: emacs-devel On 2018-01-29 16:50, Stefan Monnier wrote: > My experiments indicate that we might be able to divide this time by > almost a factor 10 if we pre-compute and byte-compile one big autoloads > file Yes please :) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-29 21:50 ` Stefan Monnier 2018-01-29 23:13 ` Clément Pit-Claudel @ 2018-01-30 1:37 ` T.V Raman 1 sibling, 0 replies; 838+ messages in thread From: T.V Raman @ 2018-01-30 1:37 UTC (permalink / raw) To: Stefan Monnier; +Cc: Radon Rosborough, George Plymale II, emacs-devel How would something like (make-thread #'package-initialize) do in comparison? Effectively that should run on a separate thread and contribute little to startup time as measured by when emacs is ready to use? -- ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-29 19:08 ` Stefan Monnier 2018-01-29 19:55 ` John Wiegley @ 2018-01-29 20:18 ` Clément Pit-Claudel 2018-01-30 15:11 ` Stefan Monnier 1 sibling, 1 reply; 838+ messages in thread From: Clément Pit-Claudel @ 2018-01-29 20:18 UTC (permalink / raw) To: emacs-devel On 2018-01-29 14:08, Stefan Monnier wrote: > I don't think I can easily bring down the speed of package-initialize > much below 0.1s for my 200 packages on my Thinkpad T61. FWIW, activating about 100 packages in my config takes about .4s: - package-initialize 232 89% + package-activate 136 52% + package-read-all-archive-contents 64 24% + package-load-all-descriptors 24 9% + package--build-compatibility-table 8 3% More precisely: - package-initialize 232 89% - package-activate 136 52% - package-activate-1 136 52% - package--load-files-for-activation 96 36% - package--activate-autoloads-and-load-path 68 26% + load 68 26% + file-truename 28 10% - package-activate 32 12% + package-activate-1 32 12% - require 8 3% + defvar 4 1% - package-read-all-archive-contents 64 24% - package-read-archive-contents 64 24% - package--add-to-archive-contents 44 16% + package--append-to-alist 4 1% package--read-archive-file 20 7% - package-load-all-descriptors 24 9% - package-load-descriptor 24 9% + package-process-define-package 8 3% #<compiled 0xd255c5> 4 1% + package--build-compatibility-table 8 3% The reverse tree is also interesting: + file-truename 60 23% + package--add-to-archive-contents 40 15% Automatic GC 24 9% + package--read-archive-file 20 7% + load-with-code-conversion 16 6% + eval-buffer 16 6% + package-load-descriptor 12 4% + package--mapc 8 3% + let 4 1% + #<compiled 0xd255c5> 4 1% + package-desc-from-define 4 1% + version-to-list 4 1% + package-desc-priority-version 4 1% It looks likes package--add-to-archive-contents is linear in the number of packages, and called once per package? I'm not sure why file-truename is called that much. Clément. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-29 20:18 ` Clément Pit-Claudel @ 2018-01-30 15:11 ` Stefan Monnier 2018-01-30 22:33 ` George Plymale II 0 siblings, 1 reply; 838+ messages in thread From: Stefan Monnier @ 2018-01-30 15:11 UTC (permalink / raw) To: emacs-devel >> I don't think I can easily bring down the speed of package-initialize >> much below 0.1s for my 200 packages on my Thinkpad T61. > FWIW, activating about 100 packages in my config takes about .4s: That's consistent with my 0.9s for 200 packages (tho not with John's 1s for almost 400 packages), but it of course depends a lot on the details of your machine (e.g. mine is almost 10 years old, John's is only 3). > It looks likes package--add-to-archive-contents is linear in the > number of packages, and called once per package? I'm not sure why > file-truename is called that much. Note that my attempt to bring it down to 0.1s circumvents all that code (or rather, pre-runs it offline to generate a single "mega-autoloads" file, so that activation of all packages reduces to loading that one file). Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-30 15:11 ` Stefan Monnier @ 2018-01-30 22:33 ` George Plymale II 2018-01-30 22:56 ` George Plymale II ` (2 more replies) 0 siblings, 3 replies; 838+ messages in thread From: George Plymale II @ 2018-01-30 22:33 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Hi all, I'm the one who posted the question on Stack Exchange, which Stefan mentioned the other day. My specific question is detailed here: https://emacs.stackexchange.com/q/38368/10761 So, I've tried out Stefan's patch and it's definitely an improvement on startup time, but the improvement is not huge for me. Specifically, I've done the following in my startup files: (setq package-enable-at-startup nil) (load "~/.emacs.d/package-fastpath.el") (setq package--initialized t) I put that code in my files after running Stefan's `package-fastpath-refresh'. I also set `load-source-file-function' to nil as per Stefan's suggestion. Unfortunately, I couldn't byte-compile my package-fastpath.el file due to some packages which already byte-compile their autoload files, such as SLIME. Now, I do see some improvement in my startup time, but to reiterate, it is not huge. When I run Emacs with my startup commented out, `emacs-init-time' yields 1.2 seconds. When I run it with my startup intact, it yields 1.3 or 1.4 seconds. This contrasts with my previous `emacs-init-time' which was 1.6 or 1.7 seconds, but as you can see, it's not a really big difference. It is possible that this sub-par time is due to something on my own system, but I'm not sure nor convinced of that. Moreover, Stefan's patch certainly can use some improvements and some notes on how to use his changes, as it is a bit vexing to figure it out by reading the diff ;) I did notice a few bugs with Stefan's changes. One bug was that `package-installed-p' no longer yields correct results on installed packages. I believe that this is because `package-desc-p' is also broken by these changes. This broke some code in my startup which I used to check whether I need to install new packages. Another bug was that some packages were placed in bad order in package-fastpath.el. In other words, if a dependency's autoloads are written to this file after its dependent package, the dependent package will err, saying that it couldn't require one of its dependencies. There is obviously some work to do on making sure that dependencies are placed in the correct order or to change the code so that package-fastpath.el is order-agnostic. As a side note and a bit of an opinion, Radon Rosborough made an interesting remark in one of his messages. He mentioned pip and how things are done in Python, which really struck me. You never really think about using a package in a language like Python or Ruby. You just `require' or `import' it and that's that. It's really simple and the amount of packages that you have never hurts the startup of the main program. I know that Emacs is a bit more complicated since it's more of a text editor than a language and we have somewhat more intricacies to worry about. But I think that this kind of a model is the kind we need to be headed for. A user should be able to have a million packages and not have to worry about the subsequent startup time. Heck, in my own Ruby installation I have 436 gems and I've never even thought about startup time till now. In any case, I think Stefan's ideas and proposed changes are a good idea and I am in much the same boat as John Wiegley in that I restart Emacs often enough that startup time gets on my nerves. So I hope that we'll have some real progress on this issue and make package.el more robust. Thanks, - George Plymale II ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-30 22:33 ` George Plymale II @ 2018-01-30 22:56 ` George Plymale II 2018-01-31 3:47 ` Stefan Monnier 2018-01-31 3:51 ` T.V Raman 2 siblings, 0 replies; 838+ messages in thread From: George Plymale II @ 2018-01-30 22:56 UTC (permalink / raw) To: George Plymale II; +Cc: monnier, emacs-devel [-- Attachment #1: Type: text/plain, Size: 338 bytes --] One more thing in addition to my last message, I noticed that Stefan's patch does not work on Emacs 25.3, as the second hunk fails. It looks like the code is different there so I can only assume that Stefan is on a newer version of Emacs. I have attached the patch that should work on Emacs 25.3 in case anyone wants to try it on 25.3. [-- Attachment #2: Stefan's patch adapted for Emacs 25.3 --] [-- Type: text/x-patch, Size: 3777 bytes --] diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el index 32200227de..1fa6ce4758 100644 --- a/lisp/emacs-lisp/package.el +++ b/lisp/emacs-lisp/package.el @@ -656,6 +656,8 @@ PKG-DESC is a `package-desc' object." (defvar Info-directory-list) (declare-function info-initialize "info" ()) +(defvar package--fastpath-pkgs t) + (defun package--load-files-for-activation (pkg-desc reload) "Load files for activating a package given by PKG-DESC. Load the autoloads file, and ensure `load-path' is setup. If @@ -696,16 +698,19 @@ correspond to previously loaded files (those returned by (unless (package-activate (car req)) (error "Unable to activate package `%s'.\nRequired package `%s-%s' is unavailable" name (car req) (package-version-join (cadr req)))))) - (package--load-files-for-activation pkg-desc reload) - ;; Add info node. - (when (file-exists-p (expand-file-name "dir" pkg-dir)) - ;; FIXME: not the friendliest, but simple. - (require 'info) - (info-initialize) - (push pkg-dir Info-directory-list)) - (push name package-activated-list) - ;; Don't return nil. - t)) + (if (listp package--fastpath-pkgs) + ;; We're only collecting the set of packages to activate! + (push pkg-desc package--fastpath-pkgs) + (package--load-files-for-activation pkg-desc reload) + ;; Add info node. + (when (file-exists-p (expand-file-name "dir" pkg-dir)) + ;; FIXME: not the friendliest, but simple. + (require 'info) + (info-initialize) + (push pkg-dir Info-directory-list)) + (push name package-activated-list) + ;; Don't return nil. + t))) (declare-function find-library-name "find-func" (library)) @@ -3437,6 +3442,51 @@ The list is displayed in a buffer named `*Packages*'." (interactive) (list-packages t)) +;;;; Fast-path for activation! + +(defcustom package-fastpath-file (locate-user-emacs-file "package-fastpath.el") + "Location of the file used to speed up activation of packages at startup." + :type 'file) + +(defun package-fastpath-refresh () + "(Re)Generate the `package-fastpath-file'." + (interactive) + (package-initialize 'no-activate) + (let ((package--fastpath-pkgs ()) + ;; Pretend we haven't activated anything yet! + (package-activated-list ())) + (dolist (elt package-alist) + (condition-case err + (package-activate (car elt)) + ;; Don't let failure of activation of a package arbitrarily stop + ;; activation of further packages. + (error (message "%s" (error-message-string err))))) + (with-temp-file package-fastpath-file + (insert ";;; FastPath file to speed up package activation at startup -*- lexical-binding:t -*-\n") + (insert ";; ¡¡ This file is autogenerated, DO NOT EDIT !!\n\n") + (dolist (pkg package--fastpath-pkgs) + (let* ((file (locate-library (package--autoloads-file-name pkg))) + (pfile (prin1-to-string file))) + (insert "(let ((load-file-name " pfile "))\n") + (insert-file-contents file) + (while (search-forward "#$" nil 'move) + (replace-match pfile t t)) + (unless (bolp) (insert "\n")) + (insert ")\n"))) + (pp `(setq package-activated-list + (append ',(mapcar #'package-desc-name package--fastpath-pkgs) + package-activated-list)) + (current-buffer)) + (insert "\f +;; Local Variables: +;; version-control: never +;; no-byte-compile: nil +;; no-update-autoloads: t +;; End: +")))) + + + (provide 'package) ;;; package.el ends here ^ permalink raw reply related [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-30 22:33 ` George Plymale II 2018-01-30 22:56 ` George Plymale II @ 2018-01-31 3:47 ` Stefan Monnier 2018-01-31 5:17 ` George Plymale II 2018-01-31 3:51 ` T.V Raman 2 siblings, 1 reply; 838+ messages in thread From: Stefan Monnier @ 2018-01-31 3:47 UTC (permalink / raw) To: George Plymale II; +Cc: emacs-devel > (setq package-enable-at-startup nil) > (load "~/.emacs.d/package-fastpath.el") > (setq package--initialized t) I think setting package--initialized to t is wrong, here (IIRC package--initialized means that we've filled the tables keeping track of which packages are available and such). Not a problem when you're just trying to test the speed of my proof-of-concept patch, of course. > Unfortunately, I couldn't byte-compile my package-fastpath.el file due > to some packages which already byte-compile their autoload files, such > as SLIME. Hmm... are you saying that my code ends up fetching code for slime-autoloads.elc instead of slime-autoloads.el? Or that slime-autoloads.el contains (pre)compiled code? Also, I'm not 100% surprised that byte-compiling byte-compiled code would fail, but I can't see any immediate reason why it should fail, so it's quite possible to it'd be easy to make it work. > Now, I do see some improvement in my startup time, but to reiterate, it > is not huge. When I run Emacs with my startup commented out, > `emacs-init-time' yields 1.2 seconds. Not quite sure what "my startup commented out" means. I'll assume it means a more or less empty ~/.emacs, or maybe the use of -Q ? In any case I guess it means that 1.2s is the "speed of light", i.e. the holy grail of package.el on your machine. > When I run it with my startup intact, it yields 1.3 or 1.4 > seconds. This contrasts with my previous `emacs-init-time' which was > 1.6 or 1.7 seconds, but as you can see, it's not a really > big difference. If you subtract the 1.2s taken by "other things", it means that your config used to take 0.4-0.5s of startup time, and that the use of a big precomputed autoloads file reduced that to 0.1-0.2s, so sped it up by factor between 2.5 and 4, which I find a bit disappointing but still respectable (and it depends which proportion was taken by package-initialize vs which proportion was taken by your particular customizations). > It is possible that this sub-par time is due to something on my own > system, but I'm not sure nor convinced of that. Moreover, Stefan's patch > certainly can use some improvements and some notes on how to use his > changes, as it is a bit vexing to figure it out by reading the diff ;) Yes, it needs work. It's just a quick experiment to see the potential gains. > I did notice a few bugs with Stefan's changes. One bug was that > `package-installed-p' no longer yields correct results on installed > packages. As it stands, my patch only pre-sets package-activated-list, whereas package-installed-p requires other things set up by package-initialize. If you don't set package--initialized to t, you'll see that package-installed-p will rightfully complain that you haven't called package-initialize. I guess my patch could also add a setting for `package-alist` to the package-fastpath.el, but I'm not sure I like the idea (it increases the consequences of having an out-of-date package-fastpath.el). > I believe that this is because `package-desc-p' is also broken > by these changes. This broke some code in my startup which I used to > check whether I need to install new packages. Wouldn't it be better for your code to assume that if there's a package-fastpath.el, then those checks have already been performed (and to re-execute those checks in package-fastpath-refresh instead)? Or maybe package-installed-p should be changed such that when it's called with a symbol argument, it should first check if it's in package-activated-list, and if it's not, then it should call package-initialize before checking package-alist. > Another bug was that some packages were placed in bad order in > package-fastpath.el. In other words, if a dependency's autoloads are > written to this file after its dependent package, the dependent package > will err, saying that it couldn't require one of its dependencies. Hmm... I thought this can't happen because the files are concatenated in the same order that they are normally loaded by `package-initialize`. I guess something doesn't work the way I thought it does. Can you investigate to see when or even why it happens? > As a side note and a bit of an opinion, Radon Rosborough made an > interesting remark in one of his messages. He mentioned pip and how > things are done in Python, which really struck me. You never really > think about using a package in a language like Python or Ruby. You just > `require' or `import' it and that's that. It's really simple and the > amount of packages that you have never hurts the startup of the main > program. I know that Emacs is a bit more complicated since it's more of > a text editor than a language and we have somewhat more intricacies to > worry about. But I think that this kind of a model is the kind we need > to be headed for. The fact that it's a text editor shouldn't make any difference in this respect. I'm not sure exactly what you mean by "the amount of packages that you have never hurts the startup of the main program", I guess you mean that program A is not slowed down when you install extra packages. In Emacs the corresponding behavior happens if you install a package by hand and don't activate/use it. `package.el` by default tries to auto-activate all your packages, so indeed it's slowed down by the mere presence of extra packages. I think a key element that lets Python and Ruby work that way is the namespacing and its tight binding to the filesystem. Currently, while conventions are "similar" (e.g. function toto-titi is likely found in file toto*.el in package toto), they're just vague conventions. Making them more strict would indeed make it possible to change `require` so that a (require 'toto-tata) will automatically look for a file toto-tata.el in a package toto without having to "activate" that package beforehand and it would let us have a "missing function handler" which would automatically try to find the function toto-titi in one of the files of the titi package (e.g. by activating this package). This might make it possible to activate some packages lazily, but There'd still be aspects of auto-activation that would go missing, tho: e.g. registering jgraph-mode as a handler for *.jgr files. So some packages would still need some form of auto-activation. > A user should be able to have a million packages and not have to worry > about the subsequent startup time. Heck, in my own Ruby installation I > have 436 gems and I've never even thought about startup time till now. The downside is that you have to explicitly `import` those gems when you need them. In Emacs you could do the same: call (package-initialize t) in your ~/.emacs and then call `package-activate` when you need a particular package. > In any case, I think Stefan's ideas and proposed changes are a good idea > and I am in much the same boat as John Wiegley in that I restart Emacs > often enough that startup time gets on my nerves. IIUC there are 1.2s of your startup time which are spent without even running a single line of package.el code, so speeding up package.el might not be good enough (at least it seems to me that if 1.6s is too slow, then 1.2s is likely to also be too slow). The usual answer in Emacs for those problem is "don't do that" (i.e. use emacsclient instead). I understand it's not always an option. Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-31 3:47 ` Stefan Monnier @ 2018-01-31 5:17 ` George Plymale II 2018-01-31 20:49 ` George Plymale II 2018-02-01 19:47 ` Stefan Monnier 0 siblings, 2 replies; 838+ messages in thread From: George Plymale II @ 2018-01-31 5:17 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel > I think setting package--initialized to t is wrong, here (IIRC > package--initialized means that we've filled the tables keeping track > of which packages are available and such). Not a problem when you're > just trying to test the speed of my proof-of-concept patch, of course. Ok, thank you for letting me know the implications of doing that. I had to do it because I got some complaints from Emacs about my packages not being initialized. I can post the exact errors if you'd like. > Hmm... are you saying that my code ends up fetching code for > slime-autoloads.elc instead of slime-autoloads.el? > Or that slime-autoloads.el contains (pre)compiled code? It looks like your code is fetching slime-autoloads.elc: (let ((load-file-name "/Users/my_username/.emacs.d/elpa/slime-20180126.1033/slime-autoloads.elc")) ;; ... bunches of bytecode ) > Also, I'm not 100% surprised that byte-compiling byte-compiled code would > fail, but I can't see any immediate reason why it should fail, so it's > quite possible to it'd be easy to make it work. Not sure why it would fail either, but this is the error that I see for that specific chunk of bytecode: package-fastpath.el:899:1:Error: Wrong type argument: sequencep, 1004 I could attach the bytecode in another message if you'd like to see it, but I'm not sure whether you do. > Not quite sure what "my startup commented out" means. I'll assume it > means a more or less empty ~/.emacs, or maybe the use of -Q ? > In any case I guess it means that 1.2s is the "speed of light", i.e. the > holy grail of package.el on your machine. I mean that I commented out my ~/.emacs file, which disables all initialization code that I run, including in other files. It does _not_ mean using -Q, which brings my startup time to 0.5 seconds (FYI, I have recently been using the Emacs Mac Port by Yamamoto Mitsuharu so my startup is a bit slower than vanilla GNU Emacs). That therefore means that 1.2s is how fast Emacs is with no customizations from myself in effect. -Q and -q have other implications, which are detailed in the Elisp manual under "38.1.1 Summary: Sequence of Actions at Startup" I actually just realized those 1.2 seconds include running `package-initialize', as per usual. In other words, it was not taking advantage of package-fastpath.el. I just ran a modified version of my ~/.emacs file which comments out almost everything except: (load-library "package") ;; I need this else Emacs says that ;; `package-activated-list' is void (setq package-enable-at-startup nil) (load "~/.emacs.d/package-fastpath.el") (setq package--initialized t) And lo and behold, `emacs-init-time' yields 0.7 seconds. Which is just 0.2 seconds higher than what I get with -Q, which I believe is Emacs' peak startup time. I also verified that I have access to all my packages so it is using package-fastpath.el. So that means your patch has actually increased startup time a lot more than I initially thought and it's actually my own initialization code which is bogging things down. > If you subtract the 1.2s taken by "other things", it means that your > config used to take 0.4-0.5s of startup time, and that the use of a big > precomputed autoloads file reduced that to 0.1-0.2s, so sped it up by > factor between 2.5 and 4, which I find a bit disappointing but still > respectable (and it depends which proportion was taken by > package-initialize vs which proportion was taken by your particular > customizations). Well, actually those figures are better than what you're saying as per my information above. I guess that makes your patch even more respectable for a first stab! :) I guess since my startup time with my initialization code is 1.3 seconds, and running Emacs with package-fastpath.el is 0.7 seconds, my own code is taking up about 0.5 to 0.6 seconds. > As it stands, my patch only pre-sets package-activated-list, whereas > package-installed-p requires other things set up by package-initialize. > If you don't set package--initialized to t, you'll see that > package-installed-p will rightfully complain that you haven't called > package-initialize. Ok, thank you for clarifying that issue. Although, as I mentioned above, I had to set package--initialized to t, otherwise Emacs would halt startup and complain about me not calling `package-initialize'. > I guess my patch could also add a setting for `package-alist` to the > package-fastpath.el, but I'm not sure I like the idea (it increases the > consequences of having an out-of-date package-fastpath.el). I'm not sure on that either. Although, we could make it so that `package-fastpath-refresh' is run more often or in more places so as to lessen that risk. > Wouldn't it be better for your code to assume that if there's > a package-fastpath.el, then those checks have already been performed > (and to re-execute those checks in package-fastpath-refresh instead)? Yes, it would likely be better for my code to do that instead. > Or maybe package-installed-p should be changed such that when it's > called with a symbol argument, it should first check if it's in > package-activated-list, and if it's not, then it should call > package-initialize before checking package-alist. I can't give a strong opinion on that. Perhaps someone else who is better-versed on package.el could shed some light here? > Hmm... I thought this can't happen because the files are concatenated in > the same order that they are normally loaded by `package-initialize`. > I guess something doesn't work the way I thought it does. > Can you investigate to see when or even why it happens? It specifically happened with gh.el (https://github.com/sigma/gh.el), which is dependent on marshal.el (https://github.com/sigma/marshal.el) Apparently gh-autoloads.el uses a `gh-defclass' macro, which in turn uses a `marshal-defclass' macro. There is definitely some strangeness that could be going on here. > The fact that it's a text editor shouldn't make any difference in this > respect. I'm not sure exactly what you mean by "the amount of packages > that you have never hurts the startup of the main program", I guess you > mean that program A is not slowed down when you install extra packages. Yes, I mean that program A is not slowed down by extra packages. > In Emacs the corresponding behavior happens if you install a package by > hand and don't activate/use it. `package.el` by default tries to > auto-activate all your packages, so indeed it's slowed down by the mere > presence of extra packages. Right. > I think a key element that lets Python and Ruby work that way is the > namespacing and its tight binding to the filesystem. Currently, while > conventions are "similar" (e.g. function toto-titi is likely found in > file toto*.el in package toto), they're just vague conventions. Yes, Ruby and Python have a simpler "path" system for finding packages than Emacs does currently. > Making them more strict would indeed make it possible to change > `require` so that a (require 'toto-tata) will automatically look for > a file toto-tata.el in a package toto without having to "activate" that > package beforehand and it would let us have a "missing function handler" > which would automatically try to find the function toto-titi in one of > the files of the titi package (e.g. by activating this package). > This might make it possible to activate some packages lazily, but > There'd still be aspects of auto-activation that would go missing, tho: > e.g. registering jgraph-mode as a handler for *.jgr files. > So some packages would still need some form of auto-activation. Right, your last point is what I meant by "we have somewhat more intricacies to worry about." > The downside is that you have to explicitly `import` those gems when you > need them. In Emacs you could do the same: call (package-initialize t) > in your ~/.emacs and then call `package-activate` when you need > a particular package. Yes, this is true. Still, I think we need some more simplicity in this system of autoloads and so forth. > IIUC there are 1.2s of your startup time which are spent without even > running a single line of package.el code, so speeding up package.el > might not be good enough (at least it seems to me that if 1.6s is too > slow, then 1.2s is likely to also be too slow). Well, those 1.2 seconds which I mentioned are just starting up Emacs without any _initialization_ code. And that also means that `package-initialize' is running and not taking advantage of package-fastpath.el. Again, as I mentioned above, the startup time which takes advantage of package-fastpath.el is ~0.7 seconds so we have already sped up package.el by a lot and with noticeable effect. > The usual answer in Emacs for those problem is "don't do that" > (i.e. use emacsclient instead). I understand it's not always an > option. Yes, I actually am an avid user of the Emacs client and server. I think it's a great feature which helps me do a lot of useful things. Unfortunately, it is not the panacea for startup time woes that it is often touted as. I know it is that way for a lot of people, but I unfortunately push Emacs too hard most of the time to be able to leave it running for weeks or months. If that were the case, I wouldn't have this itch to scratch. - George Plymale II ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-31 5:17 ` George Plymale II @ 2018-01-31 20:49 ` George Plymale II 2018-01-31 21:35 ` Stefan Monnier 2018-02-01 19:47 ` Stefan Monnier 1 sibling, 1 reply; 838+ messages in thread From: George Plymale II @ 2018-01-31 20:49 UTC (permalink / raw) To: George Plymale II; +Cc: monnier, emacs-devel Stefan, As an addition to my last message, I noticed another bug with your patch that I did not notice yesterday. The info files for my packages from ELPA are all missing in the info Directory node. When I use `(package-initialize)' rather than package-fastpath.el, those info nodes are all there. `(package-initialize t)' also did not bring those info nodes back. Evidently it is the package activation which is significant here. There is clearly a lot of work done regarding package activation from `package-initialize' which we need to incorporate. I would like to contribute some fixes to your code, but I am a bit hesitant because of copyright. If I send improvements of your patch, will it be able to get back into package.el? Because I will not sign any papers which give my rights to the FSF nor will I license any code that I write under the GPL. I am fine with licensing any code that I write under a permissive or free license such as New BSD, MIT, or public domain, but I will not put it under the GPL. I hate to bring up such a sticky topic, but I would rather get it out of the way now, before I write a bunch of code which could ultimately be useless because of copyright disagreements. Thanks, - George Plymale II ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-31 20:49 ` George Plymale II @ 2018-01-31 21:35 ` Stefan Monnier 2018-01-31 21:58 ` George Plymale II 0 siblings, 1 reply; 838+ messages in thread From: Stefan Monnier @ 2018-01-31 21:35 UTC (permalink / raw) To: George Plymale II; +Cc: emacs-devel > I would like to contribute some fixes to your code, but I am a bit > hesitant because of copyright. If I send improvements of your patch, > will it be able to get back into package.el? Because I will not sign any > papers which give my rights to the FSF nor will I license any code that > I write under the GPL. Unless your code is sufficiently trivial, we require a copyright assignment to incorporate your code into Emacs. Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-31 21:35 ` Stefan Monnier @ 2018-01-31 21:58 ` George Plymale II 2018-01-31 22:06 ` George Plymale II 0 siblings, 1 reply; 838+ messages in thread From: George Plymale II @ 2018-01-31 21:58 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel > Unless your code is sufficiently trivial, we require a copyright > assignment to incorporate your code into Emacs. Right, that's what I was afraid of. Unfortunately, my improvements to your code would quite likely be greater than 15 lines so I doubt I'll be able to help you aside from giving ideas and feedback. It's a real shame that the FSF has put this policy in place, but I'll stop myself there before this becomes a rant. - George Plymale II ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-31 21:58 ` George Plymale II @ 2018-01-31 22:06 ` George Plymale II 2018-02-01 14:48 ` Stefan Monnier 2018-02-01 19:24 ` Richard Stallman 0 siblings, 2 replies; 838+ messages in thread From: George Plymale II @ 2018-01-31 22:06 UTC (permalink / raw) To: George Plymale II; +Cc: monnier, emacs-devel Also, I am legally under-age to sign any such copyright waivers. So I couldn't do it even if I wanted to. Another reason that this is a fruitless policy. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-31 22:06 ` George Plymale II @ 2018-02-01 14:48 ` Stefan Monnier 2018-02-01 17:47 ` George Plymale II 2018-02-02 2:13 ` Loading a package applies automatically to future sessions? Richard Stallman 2018-02-01 19:24 ` Richard Stallman 1 sibling, 2 replies; 838+ messages in thread From: Stefan Monnier @ 2018-02-01 14:48 UTC (permalink / raw) To: George Plymale II; +Cc: emacs-devel > Also, I am legally under-age to sign any such copyright waivers. Since it's the second time this issue shows up, I finally asked the copyright clerk at the FSF and he says that it works as follows: If the person is under 18 years old their parent needs to also sign the contract. The biggest sticking point is that the assignment is only valid up until that person's 18th birthday. > So I couldn't do it even if I wanted to. Apparently you could, but it's kind of a pain, indeed. > Another reason that this is a fruitless policy. I also find it fruitless/useless/annoying, but for having tried to fight it, I know that it's just as fruitless trying to change Richard's mind about it. And I find it very hard to imagine how signing such paperwork for one's Emacs code could harm one, so I sometimes get stuck this way between Richard who stubbornly wants copyright paperwork and the contributor who stubbornly refuses to sign it. Both positions are only "a matter of principle" and are fruitless. Anyway, happy hacking to you, Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-01 14:48 ` Stefan Monnier @ 2018-02-01 17:47 ` George Plymale II 2018-02-01 19:11 ` Stefan Monnier 2018-02-01 19:19 ` Stephen Berman 2018-02-02 2:13 ` Loading a package applies automatically to future sessions? Richard Stallman 1 sibling, 2 replies; 838+ messages in thread From: George Plymale II @ 2018-02-01 17:47 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel > > Also, I am legally under-age to sign any such copyright waivers. > Since it's the second time this issue shows up, I finally asked the > copyright clerk at the FSF and he says that it works as follows: > If the person is under 18 years old their parent needs to also sign > the contract. The biggest sticking point is that the assignment is > only valid up until that person's 18th birthday. > > So I couldn't do it even if I wanted to. > Apparently you could, but it's kind of a pain, indeed. Yes, that is certainly a pain to say the least. In some cases it makes contribution an impossibility. > I also find it fruitless/useless/annoying, but for having tried to fight > it, I know that it's just as fruitless trying to change Richard's mind > about it. > And I find it very hard to imagine how signing such paperwork for one's > Emacs code could harm one, so I sometimes get stuck this way between > Richard who stubbornly wants copyright paperwork and the contributor who > stubbornly refuses to sign it. > Both positions are only "a matter of principle" and are fruitless. I sympathize with your difficulties in this regard. Honestly, I wouldn't have much of a problem contributing code which would be licensed under the GPL if the paperwork were not involved. I still think the GPL is too problematic and restrictive, but to each his own. This paperwork is really just over-the-top and it's not right to force someone to give you the rights to their code while in the same breath talking about freedom. This kind of stuff doesn't encourage any openness or "hacker culture." It just makes people shy away from the project. I guess all of that is a matter of principle on my part, but aside from that I also do not want to encourage the FSF's continuation of this policy by signing the papers (which I still cannot anyway). Anyhow, happy hacking to you as well. I'd rather get back on the topic of your patch now that we've gotten this issue out of the way. Do you need any more feedback or assistance in solving the bugs that I mentioned? Thanks, - George Plymale II ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-01 17:47 ` George Plymale II @ 2018-02-01 19:11 ` Stefan Monnier 2018-02-01 19:19 ` Stephen Berman 1 sibling, 0 replies; 838+ messages in thread From: Stefan Monnier @ 2018-02-01 19:11 UTC (permalink / raw) To: George Plymale II; +Cc: emacs-devel > I'd rather get back on the topic of your patch now that we've gotten > this issue out of the way. Do you need any more feedback or assistance > in solving the bugs that I mentioned? Yes (but I haven't gotten to it yet, sorry), Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-01 17:47 ` George Plymale II 2018-02-01 19:11 ` Stefan Monnier @ 2018-02-01 19:19 ` Stephen Berman 2018-02-01 19:28 ` Stephen Berman ` (2 more replies) 1 sibling, 3 replies; 838+ messages in thread From: Stephen Berman @ 2018-02-01 19:19 UTC (permalink / raw) To: George Plymale II; +Cc: Stefan Monnier, emacs-devel On Thu, 01 Feb 2018 12:47:23 -0500 George Plymale II <georgedp@orbitalimpact.com> wrote: > This paperwork is really just over-the-top and it's not right to force > someone to give you the rights to their code while in the same breath > talking about freedom. Assigning copyright to the FSF does not prevent the assignee from doing anything with their code (except claiming copyright ownership of it), see <https://www.fsf.org/bulletin/2014/spring/copyright-assignment-at-the-fsf>. in particular: Sometimes contributors are concerned about giving up rights to their work. As the assignment is a gift to the free software community, they don't want it to come at the expense of having flexibility in the use of their own code. Thus, we grant back to contributors a license to use their work as they see fit. This means they are free to modify, share, and sublicense their own work under terms of their choice. This enables contributors to redistribute their work under another free software license. While this technically also permits distributing their work under a proprietary license, we hope they won't. > This kind of stuff doesn't encourage any openness > or "hacker culture." It just makes people shy away from the project. I > guess all of that is a matter of principle on my part, but aside from > that I also do not want to encourage the FSF's continuation of this > policy by signing the papers (which I still cannot anyway). Are you sure you understand the FSF policy? Steve Berman ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-01 19:19 ` Stephen Berman @ 2018-02-01 19:28 ` Stephen Berman 2018-02-01 21:44 ` George Plymale II 2018-02-02 2:12 ` Richard Stallman 2 siblings, 0 replies; 838+ messages in thread From: Stephen Berman @ 2018-02-01 19:28 UTC (permalink / raw) To: George Plymale II; +Cc: Stefan Monnier, emacs-devel On Thu, 01 Feb 2018 20:19:01 +0100 Stephen Berman <stephen.berman@gmx.net> wrote: > On Thu, 01 Feb 2018 12:47:23 -0500 George Plymale II > <georgedp@orbitalimpact.com> wrote: > >> This paperwork is really just over-the-top and it's not right to force >> someone to give you the rights to their code while in the same breath >> talking about freedom. > > Assigning copyright to the FSF does not prevent the assignee from doing oops: assigner > anything with their code (except claiming copyright ownership of it), see Steve Berman ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-01 19:19 ` Stephen Berman 2018-02-01 19:28 ` Stephen Berman @ 2018-02-01 21:44 ` George Plymale II 2018-02-01 22:16 ` Stephen Berman ` (2 more replies) 2018-02-02 2:12 ` Richard Stallman 2 siblings, 3 replies; 838+ messages in thread From: George Plymale II @ 2018-02-01 21:44 UTC (permalink / raw) To: Stephen Berman; +Cc: monnier, emacs-devel > [...] Thus, we grant back to contributors a license to use > their work as they see fit. This means they are free to modify, share, > and sublicense their own work under terms of their choice. This enables > contributors to redistribute their work under another free software > license. While this technically also permits distributing their work > under a proprietary license, we hope they won't. That sounds interesting, but I would like to know more of the specifics about that. Is there a place where I can find very detailed information about this specific "license" which is "granted back to contributors?" > Are you sure you understand the FSF policy? I'm not sure what you're implying. - George Plymale II ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-01 21:44 ` George Plymale II @ 2018-02-01 22:16 ` Stephen Berman 2018-02-01 23:02 ` George Plymale II 2018-02-02 22:53 ` Richard Stallman 2018-02-02 2:14 ` Loading a package applies automatically to future sessions? Richard Stallman 2018-02-02 8:39 ` Eli Zaretskii 2 siblings, 2 replies; 838+ messages in thread From: Stephen Berman @ 2018-02-01 22:16 UTC (permalink / raw) To: George Plymale II; +Cc: monnier, emacs-devel On Thu, 01 Feb 2018 16:44:04 -0500 George Plymale II <georgedp@orbitalimpact.com> wrote: >> [...] Thus, we grant back to contributors a license to use >> their work as they see fit. This means they are free to modify, share, >> and sublicense their own work under terms of their choice. This enables >> contributors to redistribute their work under another free software >> license. While this technically also permits distributing their work >> under a proprietary license, we hope they won't. > > That sounds interesting, but I would like to know more of the specifics > about that. Is there a place where I can find very detailed information > about this specific "license" which is "granted back to contributors?" I don't know of an online resource with such details, but maybe it's somewhere in the FSF website. There is a statement to that effect in the assignment agreement itself, at least in the paper version I received when I made my assignment many years ago: FSF agrees to grant back to Developer, and does hereby grant, non-exclusive, royalty-free and non-cancellable rights to use the Works (i.e., Developer's changes and/or enhancements, not the Program that they enhance), as Developer sees fit [...] >> Are you sure you understand the FSF policy? > > I'm not sure what you're implying. Your wording ("it's not right to force someone to give you the rights to their code while in the same breath talking about freedom", "This kind of stuff doesn't encourage any openness or 'hacker culture.'") suggests a different understanding of the FSF policy than what the FSF itself expounds, as exemplified by the passage I quoted above. Steve Berman ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-01 22:16 ` Stephen Berman @ 2018-02-01 23:02 ` George Plymale II 2018-02-02 8:43 ` Eli Zaretskii ` (3 more replies) 2018-02-02 22:53 ` Richard Stallman 1 sibling, 4 replies; 838+ messages in thread From: George Plymale II @ 2018-02-01 23:02 UTC (permalink / raw) To: Stephen Berman; +Cc: monnier, emacs-devel > I don't know of an online resource with such details, but maybe it's > somewhere in the FSF website. There is a statement to that effect in > the assignment agreement itself, at least in the paper version I > received when I made my assignment many years ago: > FSF agrees to grant back to Developer, and does hereby grant, > non-exclusive, royalty-free and non-cancellable rights to use the Works > (i.e., Developer's changes and/or enhancements, not the Program that > they enhance), as Developer sees fit [...] Huh, well I wasn't aware of that and it sounds fine to me. Are you sure that there's no strings attached? > Your wording ("it's not right to force someone to give you the rights to > their code while in the same breath talking about freedom", "This kind > of stuff doesn't encourage any openness or 'hacker culture.'") suggests > a different understanding of the FSF policy than what the FSF itself > expounds, as exemplified by the passage I quoted above. Well, my understanding of the policy was that one's _contributions_ are owned by the FSF. I.e., that you have to sign waivers which tell the FSF, "Hey, I give up all rights to own any code that I give you guys in these certain projects." To me, that seems hypocritical and it seemed that indeed the actual FSF policy versus what the FSF itself expounds were in disagreement. But, maybe I'm incorrect about that if that above passage is really what it sounds like. - George Plymale II ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-01 23:02 ` George Plymale II @ 2018-02-02 8:43 ` Eli Zaretskii 2018-02-02 17:19 ` George Plymale II 2018-02-02 12:19 ` Phillip Lord ` (2 subsequent siblings) 3 siblings, 1 reply; 838+ messages in thread From: Eli Zaretskii @ 2018-02-02 8:43 UTC (permalink / raw) To: George Plymale II; +Cc: stephen.berman, monnier, emacs-devel > From: George Plymale II <georgedp@orbitalimpact.com> > Date: Thu, 01 Feb 2018 18:02:12 -0500 > Cc: monnier@IRO.UMontreal.CA, emacs-devel@gnu.org > > > I don't know of an online resource with such details, but maybe it's > > somewhere in the FSF website. There is a statement to that effect in > > the assignment agreement itself, at least in the paper version I > > received when I made my assignment many years ago: > > > FSF agrees to grant back to Developer, and does hereby grant, > > non-exclusive, royalty-free and non-cancellable rights to use the Works > > (i.e., Developer's changes and/or enhancements, not the Program that > > they enhance), as Developer sees fit [...] > > Huh, well I wasn't aware of that and it sounds fine to me. Are you sure > that there's no strings attached? There's no other wording related to that, and the text is pretty clear. So I see no other strings that could be attached. You, as the author, retain full rights to do anything you like with the code. > Well, my understanding of the policy was that one's _contributions_ are > owned by the FSF. I.e., that you have to sign waivers which tell the > FSF, "Hey, I give up all rights to own any code that I give you guys in > these certain projects." Given the above, I believe you now realize that this was a mistaken interpretation. You retain all the rights, you just give the FSF the ability to enforce the copyright if needed. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-02 8:43 ` Eli Zaretskii @ 2018-02-02 17:19 ` George Plymale II 2018-02-02 17:57 ` Stefan Monnier 2018-02-02 18:06 ` Eli Zaretskii 0 siblings, 2 replies; 838+ messages in thread From: George Plymale II @ 2018-02-02 17:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: stephen.berman, monnier, emacs-devel > There's no other wording related to that, and the text is pretty > clear. So I see no other strings that could be attached. You, as the > author, retain full rights to do anything you like with the code. Ok, that sounds good. I'd still like to take a look at this myself so that I can verify for myself that there are no strings attached. > Given the above, I believe you now realize that this was a mistaken > interpretation. You retain all the rights, you just give the FSF the > ability to enforce the copyright if needed. Which copyright does one give the FSF the ability to enforce? And what does that entail? ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-02 17:19 ` George Plymale II @ 2018-02-02 17:57 ` Stefan Monnier 2018-02-02 18:06 ` Eli Zaretskii 1 sibling, 0 replies; 838+ messages in thread From: Stefan Monnier @ 2018-02-02 17:57 UTC (permalink / raw) To: George Plymale II; +Cc: Eli Zaretskii, stephen.berman, emacs-devel >> Given the above, I believe you now realize that this was a mistaken >> interpretation. You retain all the rights, you just give the FSF the >> ability to enforce the copyright if needed. > Which copyright does one give the FSF the ability to enforce? Only the copyright holder can sue someone for infringement. AFAIK the things you lose when transferring your copyright to the FSF are: - the ability to transfer your copyright to someone else (because only the copyright holder can transfer his copyright to someone else (note that the copyright holder cannot not "copy" his copyright he can only transfer it)). This is not something the FSF really needs/wants which is why there is that clause that says that the FSF gives you the right to do anything you like with your work (i.e. to gives you back as much of the copyright holder's rights as it legally can). - the ability to sue someone for infringement (because only the copyright holder can do that) which is one of the main reasons the FSF wants to have the copyright. - the ability to prevent the FSF from licensing your work under some licence with which you happen to disagree (tho, IIRC, the paperwork you sign does include some clause promising that your work will stay under some kind of Free licence, tho, to try and make sure that there's not much point for <yourfavoriteevilcompany> to buy/infiltrate the FSF, since changing the licenses to be non-Free would break all those copyright assignments). Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-02 17:19 ` George Plymale II 2018-02-02 17:57 ` Stefan Monnier @ 2018-02-02 18:06 ` Eli Zaretskii 1 sibling, 0 replies; 838+ messages in thread From: Eli Zaretskii @ 2018-02-02 18:06 UTC (permalink / raw) To: George Plymale II; +Cc: stephen.berman, monnier, emacs-devel > From: George Plymale II <georgedp@orbitalimpact.com> > Cc: stephen.berman@gmx.net, monnier@IRO.UMontreal.CA, > emacs-devel@gnu.org > Date: Fri, 02 Feb 2018 12:19:25 -0500 > > > Given the above, I believe you now realize that this was a mistaken > > interpretation. You retain all the rights, you just give the FSF the > > ability to enforce the copyright if needed. > > Which copyright does one give the FSF the ability to enforce? And what > does that entail? By assigning the copyright to your code to the FSF, you give them the ability to enforce adherence to the GPL for the package to which you contributed. That's because, since the FSF holds the copyright to every line of code in the package, it can prosecute anyone who violates the GPL for that package. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-01 23:02 ` George Plymale II 2018-02-02 8:43 ` Eli Zaretskii @ 2018-02-02 12:19 ` Phillip Lord 2018-02-02 19:20 ` Radon Rosborough 2018-02-02 22:53 ` Richard Stallman 2018-02-06 15:06 ` Loading a package applies automatically to future sessions? Sam Steingold 3 siblings, 1 reply; 838+ messages in thread From: Phillip Lord @ 2018-02-02 12:19 UTC (permalink / raw) To: George Plymale II; +Cc: Stephen Berman, monnier, emacs-devel George Plymale II <georgedp@orbitalimpact.com> writes: >> FSF agrees to grant back to Developer, and does hereby grant, >> non-exclusive, royalty-free and non-cancellable rights to use the Works >> (i.e., Developer's changes and/or enhancements, not the Program that >> they enhance), as Developer sees fit [...] > > Huh, well I wasn't aware of that and it sounds fine to me. Are you sure > that there's no strings attached? There are some strings -- for instance, you are guaranteeing that you actually own the copyright in the first place. I didn't know about the grant back, incidentally. For Emacs, it makes not practical difference. As far as I can see, it's not possible to release Emacs code that is not GPL or public domain anyway, since it automatically links with Emacs. > >> Your wording ("it's not right to force someone to give you the rights to >> their code while in the same breath talking about freedom", "This kind >> of stuff doesn't encourage any openness or 'hacker culture.'") suggests >> a different understanding of the FSF policy than what the FSF itself >> expounds, as exemplified by the passage I quoted above. > > Well, my understanding of the policy was that one's _contributions_ are > owned by the FSF. I.e., that you have to sign waivers which tell the > FSF, "Hey, I give up all rights to own any code that I give you guys in > these certain projects." To me, that seems hypocritical and it seemed > that indeed the actual FSF policy versus what the FSF itself expounds > were in disagreement. But, maybe I'm incorrect about that if that above > passage is really what it sounds like. It does require copyright assignment, yes. Whether that is hypocritical or not is up to you. For Emacs, copyright assignment makes little or not difference to what you can do with the code. So I don't think that's an issue. It is a significant practical issue for sure and involves a lot of book-keeping for package maintainers. Phil ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-02 12:19 ` Phillip Lord @ 2018-02-02 19:20 ` Radon Rosborough 0 siblings, 0 replies; 838+ messages in thread From: Radon Rosborough @ 2018-02-02 19:20 UTC (permalink / raw) To: Phillip Lord Cc: Stephen Berman, emacs-devel, George Plymale II, Stefan Monnier [-- Attachment #1: Type: text/plain, Size: 232 bytes --] > As far as I can see, it's not possible to release Emacs code > that is not GPL or public domain anyway, since it automatically links > with Emacs. That's a matter of opinion. My Emacs packages are released under the MIT License. [-- Attachment #2: Type: text/html, Size: 336 bytes --] ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-01 23:02 ` George Plymale II 2018-02-02 8:43 ` Eli Zaretskii 2018-02-02 12:19 ` Phillip Lord @ 2018-02-02 22:53 ` Richard Stallman 2018-02-05 9:17 ` A response to RMS (was Loading a package applies automatically to future sessions?) George Plymale II 2018-02-06 15:06 ` Loading a package applies automatically to future sessions? Sam Steingold 3 siblings, 1 reply; 838+ messages in thread From: Richard Stallman @ 2018-02-02 22:53 UTC (permalink / raw) To: George Plymale II; +Cc: stephen.berman, monnier, emacs-devel [[[ 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. ]]] > Well, my understanding of the policy was that one's _contributions_ are > owned by the FSF. I.e., that you have to sign waivers which tell the > FSF, "Hey, I give up all rights to own any code that I give you guys in > these certain projects." To me, that seems hypocritical and it seemed > that indeed the actual FSF policy versus what the FSF itself expounds > were in disagreement. If you accuse us of hypocrisy, you should be prepared to present particulars. What is the principle that the FSF stands for, that conflicts with our practices? My hunch is that you've been misinformed about our principles. If you say what you believe our principles to be, we can compare them with our real principles. Our main principle is: users should have control of the software they use. Therefore, a nonfree program is an injustice. To eliminate that injustice, we release free software and encourage others to do so. We use copyleft to prevent our free software from being perverted by middlemen into nonfree software and thus used to subjugate others. As for copyright, we do not consider that an issue of principle, not directly. We consider it a sort of weapon that can be used for good or for bad. When it is used to subjugate people, that is bad. When it is used, through copyleft, to protect people from subjugation, that is good. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 838+ messages in thread
* A response to RMS (was Loading a package applies automatically to future sessions?) 2018-02-02 22:53 ` Richard Stallman @ 2018-02-05 9:17 ` George Plymale II 2018-02-05 12:55 ` Clément Pit-Claudel ` (3 more replies) 0 siblings, 4 replies; 838+ messages in thread From: George Plymale II @ 2018-02-05 9:17 UTC (permalink / raw) To: rms; +Cc: stephen.berman, monnier, emacs-devel > > Well, my understanding of the policy was that one's _contributions_ are > > owned by the FSF. I.e., that you have to sign waivers which tell the > > FSF, "Hey, I give up all rights to own any code that I give you guys in > > these certain projects." To me, that seems hypocritical and it seemed > > that indeed the actual FSF policy versus what the FSF itself expounds > > were in disagreement. > If you accuse us of hypocrisy, you should be prepared to present > particulars. What is the principle that the FSF stands for, that > conflicts with our practices? Well, one of the principles which I believed you to be in contradiction of was this: "You should also have the freedom to make modifications and use them privately in your own work or play, without even mentioning that they exist. If you do publish your changes, you should not be required to notify anyone in particular, or in any particular way." ( from https://www.gnu.org/philosophy/free-sw.html ) According to my understanding of the FSF's copyright policy, I have to notify the FSF when I want to distribute my changes because they're no longer mine; they're theirs. Moreover, I believed you to be in contradiction of this principle as well: "I cannot in good conscience sign a nondisclosure agreement or a software license agreement." ( from https://www.gnu.org/gnu/manifesto.en.html ) To me, the signing of a waiver feels like it's in much the same vein as either of those. If not a bit worse in some ways. In light of the new information that I received from others on this mailing list, it may not be as bad as I thought. Regardless, that is what I meant by "hypocrisy" and it is not a word that I use lightly nor without cause. > My hunch is that you've been misinformed about our principles. Your hunch is incorrect. I ascertained my opinions on the GNU project and the FSF mainly via objective analysis of their own documents and manifestos. It was also coupled with some examination of how their values worked out in reality, along with comparisons to other philosophies and facts. My conclusion of these analyses was mostly what I have already related in previous messages. > Our main principle is: users should have control of the software > they use. Therefore, a nonfree program is an injustice. > To eliminate that injustice, we release free software and encourage > others to do so. We use copyleft to prevent our free software from > being perverted by middlemen into nonfree software and thus used to > subjugate others. > As for copyright, we do not consider that an issue of principle, not > directly. We consider it a sort of weapon that can be used for good > or for bad. When it is used to subjugate people, that is bad. When > it is used, through copyleft, to protect people from subjugation, that > is good. All users have control over the software that they use. Oftentimes, even hardware cannot stop one from modifying the software which runs atop it. Enough ingenuity and craftiness trumps even the likes of Tivo. Whether or not this is legal is an entirely different question and forms the basis of the GNU campaign. I know that many will read my statement and scoff. Ask yourself, though: what stops a user from modifying the bits that run on their computer? Not the law. It is knowledge. Knowledge of how a computer works and how well its machine code can be understood. Indeed, the GNU project's efforts and funds would be far better spent creating tools that would allow users to universally understand machine code that would truly allow them to control any software that they have, regardless of its underlying machinery. This would enable freedom of software in a much more tangible and truer sense than anything that anyone has done. Ever. But instead the whole affair has become an argument of copyright or copyleft. The ability to own capital and sell it or to have that capital controlled and dolled out by one big entity (or maybe a few) who claim to be in the interests of the people. Or we may call those people "users." Sound familiar? If not, I would highly suggest reading John Wiegley's poignant and cogent letter to the FSF: http://newartisans.com/2011/04/letter-to-the-fsf/ I didn't even want to write all of this until you stipulated that my opinions are based on misinformation and smear campaigns done by others to the GNU project. Such a presumption insults the intellect of very intelligent people who I know that share my opinion and who formed the same opinion based on rational, moral, and objective analysis. In any case, I no longer desire to discuss these things. My opinion and your opinion have both been stated. I doubt that either of us will change them based on the words of the other. I am no longer as dissatisfied or upset with the FSF's policy as I was, although I will still need to investigate the agreement for myself to determine whether it is indeed a fair agreement. That does not, however, convince me of the merits of copyleft nor the philosophies which I have already expressed disagreement with. Thanks, - George Plymale II ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: A response to RMS (was Loading a package applies automatically to future sessions?) 2018-02-05 9:17 ` A response to RMS (was Loading a package applies automatically to future sessions?) George Plymale II @ 2018-02-05 12:55 ` Clément Pit-Claudel 2018-02-06 23:34 ` George Plymale II 2018-02-05 20:36 ` Richard Stallman ` (2 subsequent siblings) 3 siblings, 1 reply; 838+ messages in thread From: Clément Pit-Claudel @ 2018-02-05 12:55 UTC (permalink / raw) To: emacs-devel On 2018-02-05 04:17, George Plymale II wrote: > According to my understanding of the FSF's copyright policy, I have > to notify the FSF when I want to distribute my changes because > they're no longer mine; they're theirs. I think you misunderstood. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: A response to RMS (was Loading a package applies automatically to future sessions?) 2018-02-05 12:55 ` Clément Pit-Claudel @ 2018-02-06 23:34 ` George Plymale II 0 siblings, 0 replies; 838+ messages in thread From: George Plymale II @ 2018-02-06 23:34 UTC (permalink / raw) To: Clément Pit-Claudel; +Cc: emacs-devel Clément Pit-Claudel <cpitclaudel@gmail.com> writes: > On 2018-02-05 04:17, George Plymale II wrote: >> According to my understanding of the FSF's copyright policy, I have >> to notify the FSF when I want to distribute my changes because >> they're no longer mine; they're theirs. > > I think you misunderstood. Sorry, I meant to write that sentence in the past tense. I incorrectly wrote it in the present tense, as that statement _was_ my understanding, but it is no longer. It was clarified to me by other messages on this thread that this is not part of the policy. Hence, I wrote the word "hypocritical" at the time when I did not have that clarified to me. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: A response to RMS (was Loading a package applies automatically to future sessions?) 2018-02-05 9:17 ` A response to RMS (was Loading a package applies automatically to future sessions?) George Plymale II 2018-02-05 12:55 ` Clément Pit-Claudel @ 2018-02-05 20:36 ` Richard Stallman 2018-02-06 23:42 ` George Plymale II 2018-02-05 20:36 ` Richard Stallman 2018-02-05 20:36 ` Richard Stallman 3 siblings, 1 reply; 838+ messages in thread From: Richard Stallman @ 2018-02-05 20:36 UTC (permalink / raw) To: George Plymale II; +Cc: stephen.berman, monnier, emacs-devel [[[ 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. ]]] > "You should also have the freedom to make modifications and use them > privately in your own work or play, without even mentioning that they > exist. If you do publish your changes, you should not be required to > notify anyone in particular, or in any particular way." > ( from https://www.gnu.org/philosophy/free-sw.html ) All our software releaes give you this; they give this to the public at large. > According to my understanding of the FSF's copyright policy, I have to > notify the FSF when I want to distribute my changes because they're no > longer mine; they're theirs. You don't have to notify the FSF to redistribute our software releases under the GPL. The unlimited nonexclusive license in the assignment contracts concerns using that code in other ways, not necessarily in accord with the GPL. Some of our assignment contracts say that the author has to explicitly activate the nonexclusive license. Others say that the nonexclusive license starts right away. If the author prefers the latter form, we always use it. You seem to be bending over backwards to put us in the wrong. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: A response to RMS (was Loading a package applies automatically to future sessions?) 2018-02-05 20:36 ` Richard Stallman @ 2018-02-06 23:42 ` George Plymale II 2018-02-07 20:45 ` Richard Stallman 0 siblings, 1 reply; 838+ messages in thread From: George Plymale II @ 2018-02-06 23:42 UTC (permalink / raw) To: rms; +Cc: stephen.berman, monnier, emacs-devel > All our software releaes give you this; they give this > to the public at large. > > According to my understanding of the FSF's copyright policy, I have to > > notify the FSF when I want to distribute my changes because they're no > > longer mine; they're theirs. Sorry, as I said to Clement Pit-Claudel, I should have (and intended to) write this sentence in the past tense. I mistakenly wrote it in the present tense. It was clarified to me by other messages on this thread that this is not part of the FSF's policy. When I wrote the word "hypocritical," that was not clarified to me. > You don't have to notify the FSF to redistribute our software releases > under the GPL. > The unlimited nonexclusive license in the assignment contracts > concerns using that code in other ways, not necessarily in accord with > the GPL. > Some of our assignment contracts say that the author has to explicitly > activate the nonexclusive license. Others say that the nonexclusive > license starts right away. If the author prefers the latter form, we > always use it. Right, this is what I was not aware of in my original message where I used the word "hypocritical." > You seem to be bending over backwards to put us in the wrong. I am not trying to put anyone "in the wrong." If I were, this would be a rather different (uglier) debate. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: A response to RMS (was Loading a package applies automatically to future sessions?) 2018-02-06 23:42 ` George Plymale II @ 2018-02-07 20:45 ` Richard Stallman 0 siblings, 0 replies; 838+ messages in thread From: Richard Stallman @ 2018-02-07 20:45 UTC (permalink / raw) To: George Plymale II; +Cc: stephen.berman, monnier, emacs-devel [[[ 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. ]]] > It was clarified to me by other messages on this thread > that this is not part of the FSF's policy. When I wrote the word > "hypocritical," that was not clarified to me. I'm glad that is cleared up. I won't hold criticism against you, now that you no longer believe that. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: A response to RMS (was Loading a package applies automatically to future sessions?) 2018-02-05 9:17 ` A response to RMS (was Loading a package applies automatically to future sessions?) George Plymale II 2018-02-05 12:55 ` Clément Pit-Claudel 2018-02-05 20:36 ` Richard Stallman @ 2018-02-05 20:36 ` Richard Stallman 2018-02-05 20:36 ` Richard Stallman 3 siblings, 0 replies; 838+ messages in thread From: Richard Stallman @ 2018-02-05 20:36 UTC (permalink / raw) To: George Plymale II; +Cc: stephen.berman, monnier, emacs-devel [[[ 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. ]]] > Ask yourself, though: > what stops a user from modifying the bits that run on their computer? > Not the law. It is knowledge. Knowledge of how a computer works and how > well its machine code can be understood. With all due respect, you're mistaken about the reasons for this. Common obstacles include the user has no access to the source code. the system or the hardware is designed to refuse to run modified versions. But the most common reason is, the user is not a programmer, and can't ask the development community for help because the proprietary nature of a program prevents the existence of one. Changing a large program at the machine code level, without the comments that help programmes understand the code, is too hard to be feasible -- except for quite small changes, which are merely a great pain in the neck. > Indeed, the GNU project's > efforts and funds would be far better spent creating tools that would > allow users to universally understand machine code that would truly > allow them to control any software that they have, regardless of its > underlying machinery. That would be a superhuman AI. If you succeed at this, I agree it would be a great advance. I'd rather spend our funds on areas where I expect that effort can result in progress. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: A response to RMS (was Loading a package applies automatically to future sessions?) 2018-02-05 9:17 ` A response to RMS (was Loading a package applies automatically to future sessions?) George Plymale II ` (2 preceding siblings ...) 2018-02-05 20:36 ` Richard Stallman @ 2018-02-05 20:36 ` Richard Stallman 3 siblings, 0 replies; 838+ messages in thread From: Richard Stallman @ 2018-02-05 20:36 UTC (permalink / raw) To: George Plymale II; +Cc: stephen.berman, monnier, emacs-devel [[[ 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. ]]] > I didn't even want to write all of this until you stipulated that my > opinions are based on misinformation and smear campaigns done by others > to the GNU project. Such a presumption insults the intellect of very > intelligent people who I know that share my opinion and who formed the > same opinion based on rational, moral, and objective analysis. If they share your opinion and your reasoning, they are mistaken for the same reasons. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-01 23:02 ` George Plymale II ` (2 preceding siblings ...) 2018-02-02 22:53 ` Richard Stallman @ 2018-02-06 15:06 ` Sam Steingold 3 siblings, 0 replies; 838+ messages in thread From: Sam Steingold @ 2018-02-06 15:06 UTC (permalink / raw) To: emacs-devel > * George Plymale II <trbetrqc@beovgnyvzcnpg.pbz> [2018-02-01 18:02:12 -0500]: > > Well, my understanding of the policy was that one's _contributions_ > are owned by the FSF. I.e., that you have to sign waivers which tell > the FSF, "Hey, I give up all rights to own any code that I give you > guys in these certain projects." To me, that seems hypocritical and it > seemed that indeed the actual FSF policy versus what the FSF itself > expounds were in disagreement. But, maybe I'm incorrect about that if > that above passage is really what it sounds like. This is a very common misunderstanding. You _can_ distribute GNU software with your own changes under the GNU GPL - this is called "forking", and has been done many times. The most notable example is Lucid/X Emacs. However, if you want the FSF to accept your changes into their source code repository, you will have to assign them the copyright so that you (or your heirs) will not be able to sabotage the FSF software development by revoking your license to use your changes. This also happened before (Gosling Emacs), and the FSF is now understandably paranoid. So, to repeat: you _can_ distribute your changes yourself. If you want _the FSF_ to do that, you have to sign the papers. HTH. -- Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1561 http://steingoldpsychology.com http://www.childpsy.net http://iris.org.il http://mideasttruth.com http://honestreporting.com https://jihadwatch.org Complete tolerance is impossible: it is insulting to bigots. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-01 22:16 ` Stephen Berman 2018-02-01 23:02 ` George Plymale II @ 2018-02-02 22:53 ` Richard Stallman 2018-02-02 23:12 ` Stephen Berman 1 sibling, 1 reply; 838+ messages in thread From: Richard Stallman @ 2018-02-02 22:53 UTC (permalink / raw) To: Stephen Berman; +Cc: emacs-devel, georgedp, monnier [[[ 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. ]]] > I don't know of an online resource with such details, but maybe it's > somewhere in the FSF website. I think we should post an explanation of this. It appears that we don't have one on gnu.org. Would you like to check fsf.org? -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-02 22:53 ` Richard Stallman @ 2018-02-02 23:12 ` Stephen Berman 2018-02-03 19:13 ` Richard Stallman ` (2 more replies) 0 siblings, 3 replies; 838+ messages in thread From: Stephen Berman @ 2018-02-02 23:12 UTC (permalink / raw) To: Richard Stallman; +Cc: emacs-devel, georgedp, monnier On Fri, 02 Feb 2018 17:53:53 -0500 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. ]]] > > > I don't know of an online resource with such details, but maybe it's > > somewhere in the FSF website. > > I think we should post an explanation of this. > > It appears that we don't have one on gnu.org. Would you like to check > fsf.org? I probably cannot make a systematic check any time soon, but if I do find the time, or happen to notice a relevant page by chance, I'll be sure to point it out. Steve Berman ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-02 23:12 ` Stephen Berman @ 2018-02-03 19:13 ` Richard Stallman 2018-02-03 20:40 ` Stephen Berman 2018-02-05 9:22 ` Finding an online resource for the agreement (was Loading a package applies automatically to future sessions?) George Plymale II 2 siblings, 0 replies; 838+ messages in thread From: Richard Stallman @ 2018-02-03 19:13 UTC (permalink / raw) To: Stephen Berman; +Cc: emacs-devel, georgedp, monnier [[[ 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. ]]] > > > I don't know of an online resource with such details, but maybe it's > > > somewhere in the FSF website. > > > > I think we should post an explanation of this. > > > > It appears that we don't have one on gnu.org. Would you like to check > > fsf.org? Can someone look for one now on fsf.org? Because the first step to posting one is finding out if we already have one. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-02 23:12 ` Stephen Berman 2018-02-03 19:13 ` Richard Stallman @ 2018-02-03 20:40 ` Stephen Berman 2018-02-04 3:07 ` Richard Stallman 2018-02-05 9:26 ` George Plymale II 2018-02-05 9:22 ` Finding an online resource for the agreement (was Loading a package applies automatically to future sessions?) George Plymale II 2 siblings, 2 replies; 838+ messages in thread From: Stephen Berman @ 2018-02-03 20:40 UTC (permalink / raw) To: Richard Stallman; +Cc: emacs-devel, georgedp, monnier On Sat, 03 Feb 2018 00:12:12 +0100 Stephen Berman <stephen.berman@gmx.net> wrote: > On Fri, 02 Feb 2018 17:53:53 -0500 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. ]]] >> >> > I don't know of an online resource with such details, but maybe it's >> > somewhere in the FSF website. >> >> I think we should post an explanation of this. >> >> It appears that we don't have one on gnu.org. Would you like to check >> fsf.org? > > I probably cannot make a systematic check any time soon, but if I do > find the time, or happen to notice a relevant page by chance, I'll be > sure to point it out. I don't have the time to manually look through every page of the FSF website but I did enter "assign" in the site's search form; it returned 55 hits, most of which are lists of new copyright assigners. But the following pages have some information about what copyright assignment means: https://www.fsf.org/licensing/index_html FSF Licensing & Compliance Team by Joshua Gay — published Mar 13, 2013 — last modified Aug 11, 2017 03:13 PM [...] Copyright & Compliance The Free Software Foundation holds the copyright to many GNU packages, such as GCC and EMACS. When hackers contribute to these projects, we ask that they assign their copyright to enable us to enforce the license. For questions about assigning to the FSF, please contact us at assign@gnu.org. https://www.fsf.org/blogs/rms/assigning-copyright When a company asks for your copyright by Richard Stallman — published Sep 29, 2010 — last modified Nov 05, 2010 09:46 AM [...] The company will probably invite you to assign or license your copyright to the company. That in itself is not inherently bad; for instance, many GNU software developers have assigned copyrights to the FSF. However, the FSF never sells exceptions, and its assignment contracts include a commitment to distribute the contributor's code only with source and only permitting redistribution. https://www.fsf.org/licensing/assignunisrule.html Assignment University by jacobson — published Sep 19, 2006 — last modified Jul 29, 2013 02:55 PM [...] Although the FSF does not require the assignment of copyright on new GNU project programs, on existing programs where it already holds copyright, the FSF does collect assignments and register copyrights. [...] some reasons why a university might like to assign copyright to the FSF: -> University assignment of code allows the university freedom from the burden of protecting the work created by the developers at the university. The FSF accepts copyright so that it can do its enforcement work. [...] https://www.fsf.org/licensing/20050325novalis.html The Basics by novalis — published Mar 25, 2005 — last modified Mar 12, 2010 10:06 AM [...] 5. You can also assign your copyright. By way of analogy, licensing software to someone is like inviting them to visit your house; assigning copyright to someone is like selling them your house. a. You might want to assign your copyright to someone else if they promise to do the work of enforcing the license, or they otherwise won't take your patches. Steve Berman ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-03 20:40 ` Stephen Berman @ 2018-02-04 3:07 ` Richard Stallman 2018-02-05 9:26 ` George Plymale II 1 sibling, 0 replies; 838+ messages in thread From: Richard Stallman @ 2018-02-04 3:07 UTC (permalink / raw) To: Stephen Berman; +Cc: emacs-devel, georgedp, monnier [[[ 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. ]]] Thanks for the search results. It looks like we don't have a FAQ about the topic of copyright assignments, so we will work on one, over time. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-03 20:40 ` Stephen Berman 2018-02-04 3:07 ` Richard Stallman @ 2018-02-05 9:26 ` George Plymale II 1 sibling, 0 replies; 838+ messages in thread From: George Plymale II @ 2018-02-05 9:26 UTC (permalink / raw) To: Stephen Berman; +Cc: emacs-devel, rms, monnier Oops, I didn't see this message before sending my other message to you which read: > Yes, I would appreciate knowing about this as well. Apologies! - George Plymale II ^ permalink raw reply [flat|nested] 838+ messages in thread
* Finding an online resource for the agreement (was Loading a package applies automatically to future sessions?) 2018-02-02 23:12 ` Stephen Berman 2018-02-03 19:13 ` Richard Stallman 2018-02-03 20:40 ` Stephen Berman @ 2018-02-05 9:22 ` George Plymale II 2 siblings, 0 replies; 838+ messages in thread From: George Plymale II @ 2018-02-05 9:22 UTC (permalink / raw) To: Stephen Berman; +Cc: emacs-devel, rms, monnier Stephen Berman <stephen.berman@gmx.net> writes: > On Fri, 02 Feb 2018 17:53:53 -0500 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. ]]] >> >> > I don't know of an online resource with such details, but maybe it's >> > somewhere in the FSF website. >> >> I think we should post an explanation of this. >> >> It appears that we don't have one on gnu.org. Would you like to check >> fsf.org? > > I probably cannot make a systematic check any time soon, but if I do > find the time, or happen to notice a relevant page by chance, I'll be > sure to point it out. > > Steve Berman Yes, I would appreciate knowing about this as well. Thanks, - George Plymale II ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-01 21:44 ` George Plymale II 2018-02-01 22:16 ` Stephen Berman @ 2018-02-02 2:14 ` Richard Stallman 2018-02-02 7:25 ` George Plymale II 2018-02-02 9:39 ` Eli Zaretskii 2018-02-02 8:39 ` Eli Zaretskii 2 siblings, 2 replies; 838+ messages in thread From: Richard Stallman @ 2018-02-02 2:14 UTC (permalink / raw) To: George Plymale II; +Cc: stephen.berman, monnier, emacs-devel [[[ 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. ]]] > That sounds interesting, but I would like to know more of the specifics > about that. Is there a place where I can find very detailed information > about this specific "license" which is "granted back to contributors?" It is an unlimited nonexclusive license; it says you can use your own code/text "as you see fit". It may say you need to inform us the first time you want to do this, and then you get the unlimited nonexclusive license forever after. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-02 2:14 ` Loading a package applies automatically to future sessions? Richard Stallman @ 2018-02-02 7:25 ` George Plymale II 2018-02-02 9:39 ` Eli Zaretskii 1 sibling, 0 replies; 838+ messages in thread From: George Plymale II @ 2018-02-02 7:25 UTC (permalink / raw) To: rms; +Cc: stephen.berman, monnier, emacs-devel 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. ]]] > > > That sounds interesting, but I would like to know more of the specifics > > about that. Is there a place where I can find very detailed information > > about this specific "license" which is "granted back to contributors?" > > It is an unlimited nonexclusive license; it says you can use your own > code/text "as you see fit". It may say you need to inform us the > first time you want to do this, and then you get the unlimited > nonexclusive license forever after. Well that sounds much better than I originally thought. Thank you for clarifying that. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-02 2:14 ` Loading a package applies automatically to future sessions? Richard Stallman 2018-02-02 7:25 ` George Plymale II @ 2018-02-02 9:39 ` Eli Zaretskii 2018-02-02 17:07 ` George Plymale II ` (3 more replies) 1 sibling, 4 replies; 838+ messages in thread From: Eli Zaretskii @ 2018-02-02 9:39 UTC (permalink / raw) To: rms; +Cc: stephen.berman, emacs-devel, georgedp, monnier > From: Richard Stallman <rms@gnu.org> > Date: Thu, 01 Feb 2018 21:14:53 -0500 > Cc: stephen.berman@gmx.net, monnier@IRO.UMontreal.CA, emacs-devel@gnu.org > > It is an unlimited nonexclusive license; it says you can use your own > code/text "as you see fit". It may say you need to inform us the > first time you want to do this, and then you get the unlimited > nonexclusive license forever after. In my assignments, both those from 20 years ago, and those from the recent years, there's no such caveat as described in the last sentence above. I'm just given "nonexclusive, royalty-free, fully paid up and non-cancellable worldwide rights to use [the code I developed], as Developer sees fit." ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-02 9:39 ` Eli Zaretskii @ 2018-02-02 17:07 ` George Plymale II 2018-02-02 17:59 ` Stefan Monnier ` (2 subsequent siblings) 3 siblings, 0 replies; 838+ messages in thread From: George Plymale II @ 2018-02-02 17:07 UTC (permalink / raw) To: Eli Zaretskii; +Cc: stephen.berman, emacs-devel, rms, monnier Eli Zaretskii <eliz@gnu.org> writes: >> From: Richard Stallman <rms@gnu.org> >> Date: Thu, 01 Feb 2018 21:14:53 -0500 >> Cc: stephen.berman@gmx.net, monnier@IRO.UMontreal.CA, emacs-devel@gnu.org >> >> It is an unlimited nonexclusive license; it says you can use your own >> code/text "as you see fit". It may say you need to inform us the >> first time you want to do this, and then you get the unlimited >> nonexclusive license forever after. > > In my assignments, both those from 20 years ago, and those from the > recent years, there's no such caveat as described in the last sentence > above. I'm just given "nonexclusive, royalty-free, fully paid up and > non-cancellable worldwide rights to use [the code I developed], as > Developer sees fit." Thanks for expounding on Richard's last point with your observations. I'll probably have to look at one of these assignments myself so that I can know exactly what it stipulates. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-02 9:39 ` Eli Zaretskii 2018-02-02 17:07 ` George Plymale II @ 2018-02-02 17:59 ` Stefan Monnier 2018-02-02 22:56 ` Richard Stallman 2018-02-14 22:28 ` Richard Stallman 3 siblings, 0 replies; 838+ messages in thread From: Stefan Monnier @ 2018-02-02 17:59 UTC (permalink / raw) To: emacs-devel > In my assignments, both those from 20 years ago, and those from the > recent years, there's no such caveat as described in the last sentence > above. Can't remember what mine l;ooked like, but I've just found one (called assign.ncurses) in fencepost which says: Upon thirty days' prior written notice(s), the Foundation agrees to grant to any one or more, or all, of us non-exclusive rights to use the Package as we see fit; (and the Foundation's rights shall otherwise continue unchanged). -- Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-02 9:39 ` Eli Zaretskii 2018-02-02 17:07 ` George Plymale II 2018-02-02 17:59 ` Stefan Monnier @ 2018-02-02 22:56 ` Richard Stallman 2018-02-14 22:28 ` Richard Stallman 3 siblings, 0 replies; 838+ messages in thread From: Richard Stallman @ 2018-02-02 22:56 UTC (permalink / raw) To: Eli Zaretskii; +Cc: stephen.berman, emacs-devel, georgedp, monnier [[[ 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. ]]] > > It is an unlimited nonexclusive license; it says you can use your own > > code/text "as you see fit". It may say you need to inform us the > > first time you want to do this, and then you get the unlimited > > nonexclusive license forever after. > In my assignments, both those from 20 years ago, and those from the > recent years, there's no such caveat as described in the last sentence > above. I'm just given "nonexclusive, royalty-free, fully paid up and > non-cancellable worldwide rights to use [the code I developed], as > Developer sees fit." I recall that SOME of our assignments used to say the developer had to ask for the nonexclusive license, and would then automatically receive it. But it has been many years since I signed the assignments myself, and I don't know whether we ever use that wording nowadays. It doesn't make a difference in practice. With the other wording that make sit an option to request the nonexclusive license, the contributor can immediately exercise the option. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-02 9:39 ` Eli Zaretskii ` (2 preceding siblings ...) 2018-02-02 22:56 ` Richard Stallman @ 2018-02-14 22:28 ` Richard Stallman 2018-02-14 23:18 ` George Plymale II 3 siblings, 1 reply; 838+ messages in thread From: Richard Stallman @ 2018-02-14 22:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: stephen.berman, emacs-devel, georgedp, monnier [[[ 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. ]]] The FSF staff checked. We have not included that 30-day notice provision in our copyright assignments since some time before 2000. (They didn't check further back than that.) The assignments since then give the contributor unlimited nonexclusive rights starting immediately. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-14 22:28 ` Richard Stallman @ 2018-02-14 23:18 ` George Plymale II 0 siblings, 0 replies; 838+ messages in thread From: George Plymale II @ 2018-02-14 23:18 UTC (permalink / raw) To: rms; +Cc: eliz, stephen.berman, monnier, emacs-devel Richard Stallman <rms@gnu.org> writes: > The FSF staff checked. We have not included that 30-day notice > provision in our copyright assignments since some time before 2000. > (They didn't check further back than that.) The assignments since > then give the contributor unlimited nonexclusive rights starting > immediately. Ok, thank you very much for providing that information. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-01 21:44 ` George Plymale II 2018-02-01 22:16 ` Stephen Berman 2018-02-02 2:14 ` Loading a package applies automatically to future sessions? Richard Stallman @ 2018-02-02 8:39 ` Eli Zaretskii 2018-02-02 17:21 ` George Plymale II 2 siblings, 1 reply; 838+ messages in thread From: Eli Zaretskii @ 2018-02-02 8:39 UTC (permalink / raw) To: George Plymale II; +Cc: stephen.berman, monnier, emacs-devel > From: George Plymale II <georgedp@orbitalimpact.com> > Date: Thu, 01 Feb 2018 16:44:04 -0500 > Cc: monnier@IRO.UMontreal.CA, emacs-devel@gnu.org > > > [...] Thus, we grant back to contributors a license to use > > their work as they see fit. This means they are free to modify, share, > > and sublicense their own work under terms of their choice. This enables > > contributors to redistribute their work under another free software > > license. While this technically also permits distributing their work > > under a proprietary license, we hope they won't. > > That sounds interesting, but I would like to know more of the specifics > about that. Is there a place where I can find very detailed information > about this specific "license" which is "granted back to contributors?" When you sign the copyright assignment, the text of that assignment includes the above-mentioned permissions. If you want, I can cite the text as it appears in my assignment agreements, I don't believe that text is any kind of secret. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-02 8:39 ` Eli Zaretskii @ 2018-02-02 17:21 ` George Plymale II 2018-02-02 18:08 ` Eli Zaretskii 0 siblings, 1 reply; 838+ messages in thread From: George Plymale II @ 2018-02-02 17:21 UTC (permalink / raw) To: Eli Zaretskii; +Cc: stephen.berman, monnier, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: George Plymale II <georgedp@orbitalimpact.com> >> Date: Thu, 01 Feb 2018 16:44:04 -0500 >> Cc: monnier@IRO.UMontreal.CA, emacs-devel@gnu.org >> >> > [...] Thus, we grant back to contributors a license to use >> > their work as they see fit. This means they are free to modify, share, >> > and sublicense their own work under terms of their choice. This enables >> > contributors to redistribute their work under another free software >> > license. While this technically also permits distributing their work >> > under a proprietary license, we hope they won't. >> >> That sounds interesting, but I would like to know more of the specifics >> about that. Is there a place where I can find very detailed information >> about this specific "license" which is "granted back to contributors?" > > When you sign the copyright assignment, the text of that assignment > includes the above-mentioned permissions. If you want, I can cite the > text as it appears in my assignment agreements, I don't believe that > text is any kind of secret. I would appreciate such a citation if you don't mind. You can also send it to me privately, if you'd like. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-02 17:21 ` George Plymale II @ 2018-02-02 18:08 ` Eli Zaretskii 0 siblings, 0 replies; 838+ messages in thread From: Eli Zaretskii @ 2018-02-02 18:08 UTC (permalink / raw) To: George Plymale II; +Cc: stephen.berman, monnier, emacs-devel > From: George Plymale II <georgedp@orbitalimpact.com> > Cc: stephen.berman@gmx.net, monnier@IRO.UMontreal.CA, > emacs-devel@gnu.org > Date: Fri, 02 Feb 2018 12:21:33 -0500 > > >> That sounds interesting, but I would like to know more of the specifics > >> about that. Is there a place where I can find very detailed information > >> about this specific "license" which is "granted back to contributors?" > > > > When you sign the copyright assignment, the text of that assignment > > includes the above-mentioned permissions. If you want, I can cite the > > text as it appears in my assignment agreements, I don't believe that > > text is any kind of secret. > > I would appreciate such a citation if you don't mind. You can also send > it to me privately, if you'd like. I meanwhile already cited that. Here it is again: > [...] I'm just given "nonexclusive, royalty-free, fully paid up and > non-cancellable worldwide rights to use [the code I developed], as > Developer sees fit." ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-01 19:19 ` Stephen Berman 2018-02-01 19:28 ` Stephen Berman 2018-02-01 21:44 ` George Plymale II @ 2018-02-02 2:12 ` Richard Stallman 2018-02-02 6:15 ` George Plymale II 2 siblings, 1 reply; 838+ messages in thread From: Richard Stallman @ 2018-02-02 2:12 UTC (permalink / raw) To: georgedp; +Cc: Stephen Berman, monnier, emacs-devel [[[ 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. ]]] > This kind of stuff doesn't encourage any openness Our goal is freedom for all users of software -- much more than "openness". We release programs under a copyleft license such as the GNU GPL in order to defend freedom for all users. We ask for copyright assignments so we can enforce the GPL better in court. It's all part of a careful plan for achieving freedom. See https://gnu.org/licenses/copyleft.html for more explanation, and https://gnu.org/licenses/why-assign.html. Our goal is not "openness" -- we don't use that word. We campaign for users' freedom, specifically to control the software they use. See https://gnu.org/philosophy/open-source-misses-the-point.html for more explanation of the difference between free software and open source. See also https://thebaffler.com/salvos/the-meme-hustler for Evgeny Morozov's article on the same point. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-02 2:12 ` Richard Stallman @ 2018-02-02 6:15 ` George Plymale II 2018-02-04 3:07 ` Richard Stallman 0 siblings, 1 reply; 838+ messages in thread From: George Plymale II @ 2018-02-02 6:15 UTC (permalink / raw) To: rms; +Cc: stephen.berman, monnier, emacs-devel Richard Stallman <rms@gnu.org> writes: > Our goal is freedom for all users of software -- much more than > "openness". > > We release programs under a copyleft license such as the GNU GPL in > order to defend freedom for all users. We ask for copyright > assignments so we can enforce the GPL better in court. It's all part > of a careful plan for achieving freedom. > > See https://gnu.org/licenses/copyleft.html for more explanation, > and https://gnu.org/licenses/why-assign.html. > > Our goal is not "openness" -- we don't use that word. We campaign for > users' freedom, specifically to control the software they use. > > See https://gnu.org/philosophy/open-source-misses-the-point.html > for more explanation of the difference between free software and open > source. See also https://thebaffler.com/salvos/the-meme-hustler for > Evgeny Morozov's article on the same point. By using the word "openness," I wasn't specifically referring to the open-source movement. I just meant that this policy decreases general openness in the community since there is a certain gate, if you will, which one must pass through in order to contribute to Emacs. The other thing which I meant regarding "openness" is succinctly expressed by Nikos Mavrogiannopoulos, one of the developers of GnuTLS: "(b) The feeling of participation in the GNU project is very low, as even expressing a different opinion in the internal mailing lists is hard if not impossible. (c) There is no process for decision making or transparency in GNU. The only existing process I saw is "Stallman said so" (this may not be bad, unless some threshold of disagreement has been reached - but then it is fair to be able to disassociate myself from the project)." ( from https://lwn.net/Articles/529565/ ) - George Plymale II ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-02 6:15 ` George Plymale II @ 2018-02-04 3:07 ` Richard Stallman 2018-02-05 9:35 ` Another response to RMS (was Loading a package applies automatically to future sessions?) George Plymale II 0 siblings, 1 reply; 838+ messages in thread From: Richard Stallman @ 2018-02-04 3:07 UTC (permalink / raw) To: George Plymale II; +Cc: stephen.berman, monnier, emacs-devel [[[ 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. ]]] > By using the word "openness," I wasn't specifically referring to the > open-source movement. I just meant that this policy decreases general > openness in the community since there is a certain gate, if you will, > which one must pass through in order to contribute to Emacs. Freedom sometimes requires a sacrifice, and this is one example. "Openness" is not a priority for us -- freedom is our goal. > (c) There is no process for decision making or transparency in GNU. Do you mean, that the contributors can't change the goals and the philosophy of the project. That's true, and it has to be that way. Most free software projects don't have a commitment to any particular political goal or philosophy. Those questions are simply up to the main developers of the project. They can change goals as thery see fit. GNU is different. It has a commitment to a particular political philosophy, and that never changes. People who expect the other way may be surprised when they see GNU is different. They expect to be able to argue about the basic goal and get it changed. However, the goal of GNU came before GNU, so they cannot change it. You have a right to criticize various aspects of GNU, but please don't use this list for that; that is off-topic here. This list is for developing Emacs. Explaining our assignment policies was just barely on-topic, but this is not. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Another response to RMS (was Loading a package applies automatically to future sessions?) 2018-02-04 3:07 ` Richard Stallman @ 2018-02-05 9:35 ` George Plymale II 2018-02-05 20:37 ` Richard Stallman 0 siblings, 1 reply; 838+ messages in thread From: George Plymale II @ 2018-02-05 9:35 UTC (permalink / raw) To: rms; +Cc: stephen.berman, monnier, emacs-devel > Freedom sometimes requires a sacrifice, and this is one example. > "Openness" is not a priority for us -- freedom is our goal. Ok. I am of the opinion that these virtues go hand in hand. > Most free software projects don't have a commitment to any particular > political goal or philosophy. Those questions are simply up to the > main developers of the project. They can change goals as thery see > fit. > GNU is different. It has a commitment to a particular political > philosophy, and that never changes. > People who expect the other way may be surprised when they see GNU is > different. They expect to be able to argue about the basic goal > and get it changed. However, the goal of GNU came before GNU, > so they cannot change it. Ok, I understand and respect that. > You have a right to criticize various aspects of GNU, but please don't > use this list for that; that is off-topic here. This list is for > developing Emacs. Explaining our assignment policies was just barely > on-topic, but this is not. I apologize, I only brought this up as a genuine concern for improving some code which was relevant. My subsequent messages about this were responses to others who in turn messaged me about this issue (including you). If you want, I will stop discussing all such issues regarding this on this list from henceforth. If that is the case, where may relevantly I take such concerns should they arise again? ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Another response to RMS (was Loading a package applies automatically to future sessions?) 2018-02-05 9:35 ` Another response to RMS (was Loading a package applies automatically to future sessions?) George Plymale II @ 2018-02-05 20:37 ` Richard Stallman 2018-02-06 23:47 ` George Plymale II 0 siblings, 1 reply; 838+ messages in thread From: Richard Stallman @ 2018-02-05 20:37 UTC (permalink / raw) To: George Plymale II; +Cc: stephen.berman, monnier, emacs-devel [[[ 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. ]]] > If that is the case, where may relevantly I take such concerns should > they arise again? We have a mailing list for the purpose, gnu-misc-discuss@gnu.org. Nowadays it is not used much. I gather that people mostly discuss their agreement or disagreement with the free software movement in various large forum sites which I don't use at all. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Another response to RMS (was Loading a package applies automatically to future sessions?) 2018-02-05 20:37 ` Richard Stallman @ 2018-02-06 23:47 ` George Plymale II 0 siblings, 0 replies; 838+ messages in thread From: George Plymale II @ 2018-02-06 23:47 UTC (permalink / raw) To: rms; +Cc: stephen.berman, monnier, emacs-devel 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. ]]] > > > If that is the case, where may relevantly I take such concerns should > > they arise again? > > We have a mailing list for the purpose, gnu-misc-discuss@gnu.org. > Nowadays it is not used much. I gather that people mostly discuss > their agreement or disagreement with the free software movement in > various large forum sites which I don't use at all. Thanks for the info. I apologize again for cluttering up this mailing list with this sort of discussion. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-01 14:48 ` Stefan Monnier 2018-02-01 17:47 ` George Plymale II @ 2018-02-02 2:13 ` Richard Stallman 1 sibling, 0 replies; 838+ messages in thread From: Richard Stallman @ 2018-02-02 2:13 UTC (permalink / raw) To: Stefan Monnier; +Cc: georgedp, emacs-devel [[[ 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. ]]] > I also find it fruitless/useless/annoying, When you say it is "annoying", that describes your feelings. I can't argue with your feelings, but to get annoyed by a little work that one needs to do at most twice in a lifetime seems to me excessive. On the other hand, saying it is "fruitless" and "useless" is simply incorrect. It helps us enforce the GNU GPL. > Both positions are only "a matter of principle" Our policy of requiring copyright assignments is entirely a practical matter -- to help us enforce the GPL. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-31 22:06 ` George Plymale II 2018-02-01 14:48 ` Stefan Monnier @ 2018-02-01 19:24 ` Richard Stallman 2018-02-01 21:36 ` George Plymale II 1 sibling, 1 reply; 838+ messages in thread From: Richard Stallman @ 2018-02-01 19:24 UTC (permalink / raw) To: George Plymale II; +Cc: emacs-devel, georgedp, monnier [[[ 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. ]]] > Also, I am legally under-age to sign any such copyright waivers. So I > couldn't do it even if I wanted to. Another reason that this is a > fruitless policy. This policy gives us (1) confidence we have the right to put the code into Emacs, and (2) a firm basis for enforcing the GPL. It is sometimes inconvenient, but it is hardly fruitless. On the contrary, it is very important. If you are too young to sign, you could ask your parents to sign on your behalf. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-01 19:24 ` Richard Stallman @ 2018-02-01 21:36 ` George Plymale II 2018-02-02 2:08 ` Tim Landscheidt ` (5 more replies) 0 siblings, 6 replies; 838+ messages in thread From: George Plymale II @ 2018-02-01 21:36 UTC (permalink / raw) To: rms; +Cc: monnier, emacs-devel > This policy gives us (1) confidence we have the right to put the code > into Emacs, Is not a statement of my permission in an email enough? If an issue came up in a court of law, couldn't you just subpoena the email message where I (or whoever else) granted you permission to have my code? At least, that would take away the hassle factor of paperwork. Heck, in your FAQ about the GPL, you say: "We [keep the copyright status of the program as simple as possible] by asking each contributor to either assign the copyright on contributions to the FSF, or disclaim copyright on contributions." https://www.gnu.org/licenses/gpl-faq.en.html#AssignCopyright As I told Stefan in my initial message about this, I would be fine with releasing my contributions into the public domain. I think that makes a lot of sense; I'm giving the code away so anyone can use it however they like. Of course, all of this would probably not be necessary were it not for the controversial nature of the GPL which leads to lawsuits a lot more than other open-source licenses. > (2) a firm basis for enforcing the GPL. > It is sometimes inconvenient, but it is hardly fruitless. > On the contrary, it is very important. All that you can do to enforce the GPL is sue people. Isn't there enough litigiousness in the world today? Moreover, there is no other fruit borne by these restrictions than that won in a court battle. You certainly aren't recruiting more developers in any projects which are subject to this policy. That is worrisome when you have core developers, such as Eli, saying that the Emacs core is falling by the wayside because there are too few newcomers who will delve into the guts of the project. And there are few newcomers at all. > If you are too young to sign, you could ask your parents to sign on > your behalf. What if they can't? What if I don't have parents? What if I live in foster homes and my legal guardian is frequently changed? I don't see how a policy which prevents such people from contributing to the project is very helpful. - George Plymale II ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-01 21:36 ` George Plymale II @ 2018-02-02 2:08 ` Tim Landscheidt 2018-02-02 22:53 ` Richard Stallman 2018-02-02 2:17 ` Richard Stallman ` (4 subsequent siblings) 5 siblings, 1 reply; 838+ messages in thread From: Tim Landscheidt @ 2018-02-02 2:08 UTC (permalink / raw) To: emacs-devel George Plymale II <georgedp@orbitalimpact.com> wrote: > […] >> If you are too young to sign, you could ask your parents to sign on >> your behalf. > What if they can't? What if I don't have parents? What if I live in > foster homes and my legal guardian is frequently changed? I don't see > how a policy which prevents such people from contributing to the project > is very helpful. I doubt that under those conditions someone could legally release one's code under any licence or into the public do- main; i. e. "a policy" means "every policy" in that context. Tim ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-02 2:08 ` Tim Landscheidt @ 2018-02-02 22:53 ` Richard Stallman 0 siblings, 0 replies; 838+ messages in thread From: Richard Stallman @ 2018-02-02 22:53 UTC (permalink / raw) To: Tim Landscheidt; +Cc: emacs-devel [[[ 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. ]]] > > What if they can't? What if I don't have parents? What if I live in > > foster homes and my legal guardian is frequently changed? I don't see > > how a policy which prevents such people from contributing to the project > > is very helpful. > I doubt that under those conditions someone could legally > release one's code under any licence or into the public do- > main; i. e. "a policy" means "every policy" in that context. I think you are right. (Though I hesitate to say it is _impossible_; there may be a legal avenue, but we'd need to ask a lawyer what it may be.) Our policy does not create the problem, but rather helps us avoid being oblivious to it.) -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-01 21:36 ` George Plymale II 2018-02-02 2:08 ` Tim Landscheidt @ 2018-02-02 2:17 ` Richard Stallman 2018-02-02 6:26 ` George Plymale II 2018-02-02 9:26 ` Eli Zaretskii 2018-02-02 2:17 ` Richard Stallman ` (3 subsequent siblings) 5 siblings, 2 replies; 838+ messages in thread From: Richard Stallman @ 2018-02-02 2:17 UTC (permalink / raw) To: George Plymale II; +Cc: monnier, emacs-devel [[[ 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. ]]] > As I told Stefan in my initial message about this, I would be fine with > releasing my contributions into the public domain. That would be sufficient for us to use the code. We want to have something we can point at, to show a court that you have did put it in the public domain. You can do that by signing a copyright disclaimer. Please write to assign@gnu,org saying you'd like to disclaim copyright on a contribution to Emacs, and they will say how. I think you'd still need your parent or guardian to sign it, but it wouldn't assign the copyright. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-02 2:17 ` Richard Stallman @ 2018-02-02 6:26 ` George Plymale II 2018-02-02 9:26 ` Eli Zaretskii 1 sibling, 0 replies; 838+ messages in thread From: George Plymale II @ 2018-02-02 6:26 UTC (permalink / raw) To: rms; +Cc: monnier, emacs-devel 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. ]]] > > > As I told Stefan in my initial message about this, I would be fine with > > releasing my contributions into the public domain. > > That would be sufficient for us to use the code. > > We want to have something we can point at, to show a court that you > have did put it in the public domain. You can do that by signing a > copyright disclaimer. Please write to assign@gnu,org saying you'd > like to disclaim copyright on a contribution to Emacs, and they will > say how. > > I think you'd still need your parent or guardian to sign it, > but it wouldn't assign the copyright. That sounds like it is sufficient (or at least an improvement on what I originally thought). Thanks, - George Plymale II ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-02 2:17 ` Richard Stallman 2018-02-02 6:26 ` George Plymale II @ 2018-02-02 9:26 ` Eli Zaretskii 2018-02-02 17:14 ` George Plymale II 2018-02-02 22:56 ` Richard Stallman 1 sibling, 2 replies; 838+ messages in thread From: Eli Zaretskii @ 2018-02-02 9:26 UTC (permalink / raw) To: rms; +Cc: emacs-devel, georgedp, monnier > From: Richard Stallman <rms@gnu.org> > Date: Thu, 01 Feb 2018 21:17:15 -0500 > Cc: monnier@IRO.UMontreal.CA, emacs-devel@gnu.org > > > As I told Stefan in my initial message about this, I would be fine with > > releasing my contributions into the public domain. > > That would be sufficient for us to use the code. However, AFAIU and AFAIR, this is impossible to do once and for all the future contributions, as we do with copyright assignments. Which means that every single contribution will need a separate disclaimer. People who choose that way should be aware of that caveat (assuming I'm not confused about that, in which case apologies in advance). ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-02 9:26 ` Eli Zaretskii @ 2018-02-02 17:14 ` George Plymale II 2018-02-02 22:56 ` Richard Stallman 1 sibling, 0 replies; 838+ messages in thread From: George Plymale II @ 2018-02-02 17:14 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel, rms, monnier Eli Zaretskii <eliz@gnu.org> writes: >> From: Richard Stallman <rms@gnu.org> >> Date: Thu, 01 Feb 2018 21:17:15 -0500 >> Cc: monnier@IRO.UMontreal.CA, emacs-devel@gnu.org >> >> > As I told Stefan in my initial message about this, I would be fine with >> > releasing my contributions into the public domain. >> >> That would be sufficient for us to use the code. > > However, AFAIU and AFAIR, this is impossible to do once and for all > the future contributions, as we do with copyright assignments. Which > means that every single contribution will need a separate disclaimer. > People who choose that way should be aware of that caveat (assuming > I'm not confused about that, in which case apologies in advance). Ok. Thanks for clarifying that. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-02 9:26 ` Eli Zaretskii 2018-02-02 17:14 ` George Plymale II @ 2018-02-02 22:56 ` Richard Stallman 2018-02-05 9:19 ` George Plymale II 1 sibling, 1 reply; 838+ messages in thread From: Richard Stallman @ 2018-02-02 22:56 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel, georgedp, monnier [[[ 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. ]]] We don't have a way to do a disclaimer for future changes. We have not had many contributors who wanted to disclaim instead of assigning, so we haven't tried. But it might be possible. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-02 22:56 ` Richard Stallman @ 2018-02-05 9:19 ` George Plymale II 2018-02-05 20:36 ` Richard Stallman 0 siblings, 1 reply; 838+ messages in thread From: George Plymale II @ 2018-02-05 9:19 UTC (permalink / raw) To: rms; +Cc: eliz, monnier, emacs-devel 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. ]]] > > We don't have a way to do a disclaimer for future changes. We have > not had many contributors who wanted to disclaim instead of assigning, > so we haven't tried. But it might be possible. That sounds like a great idea. It's definitely something to be looked into. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-05 9:19 ` George Plymale II @ 2018-02-05 20:36 ` Richard Stallman 2018-02-06 23:44 ` George Plymale II 0 siblings, 1 reply; 838+ messages in thread From: Richard Stallman @ 2018-02-05 20:36 UTC (permalink / raw) To: George Plymale II; +Cc: eliz, monnier, emacs-devel [[[ 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. ]]] > > We don't have a way to do a disclaimer for future changes. We have > > not had many contributors who wanted to disclaim instead of assigning, > > so we haven't tried. But it might be possible. > That sounds like a great idea. It's definitely something to be looked into. I will ask a lawyer whether in principle this should be possible. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-05 20:36 ` Richard Stallman @ 2018-02-06 23:44 ` George Plymale II 0 siblings, 0 replies; 838+ messages in thread From: George Plymale II @ 2018-02-06 23:44 UTC (permalink / raw) To: rms; +Cc: eliz, monnier, emacs-devel 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. ]]] > > > > We don't have a way to do a disclaimer for future changes. We have > > > not had many contributors who wanted to disclaim instead of assigning, > > > so we haven't tried. But it might be possible. > > > That sounds like a great idea. It's definitely something to be looked into. > > I will ask a lawyer whether in principle this should be possible. Thanks. Please let me know if it is. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-01 21:36 ` George Plymale II 2018-02-02 2:08 ` Tim Landscheidt 2018-02-02 2:17 ` Richard Stallman @ 2018-02-02 2:17 ` Richard Stallman 2018-02-02 7:33 ` George Plymale II 2018-02-02 2:17 ` Richard Stallman ` (2 subsequent siblings) 5 siblings, 1 reply; 838+ messages in thread From: Richard Stallman @ 2018-02-02 2:17 UTC (permalink / raw) To: George Plymale II; +Cc: monnier, emacs-devel [[[ 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. ]]] > What if they can't? What if I don't have parents? What if I live in > foster homes and my legal guardian is frequently changed? If that happens, I will worry about what to do. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-02 2:17 ` Richard Stallman @ 2018-02-02 7:33 ` George Plymale II 2018-02-02 18:38 ` Drew Adams 2018-02-02 20:36 ` Loading a package applies automatically to future sessions? Phillip Lord 0 siblings, 2 replies; 838+ messages in thread From: George Plymale II @ 2018-02-02 7:33 UTC (permalink / raw) To: rms; +Cc: monnier, emacs-devel 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. ]]] > > > What if they can't? What if I don't have parents? What if I live in > > foster homes and my legal guardian is frequently changed? > > If that happens, I will worry about what to do. Well, I don't think I could convince any of my parents to sign copyright waivers. And I don't want to subject them to such concerns. Moreover, it is possible that there is further ambiguity because of things that I cannot divulge publicly. In any case, this policy is certainly a pain for minors. ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Loading a package applies automatically to future sessions? 2018-02-02 7:33 ` George Plymale II @ 2018-02-02 18:38 ` Drew Adams 2018-02-02 19:05 ` Generations (was: Loading a package applies automatically to future sessions?) Stefan Monnier 2018-02-02 20:36 ` Loading a package applies automatically to future sessions? Phillip Lord 1 sibling, 1 reply; 838+ messages in thread From: Drew Adams @ 2018-02-02 18:38 UTC (permalink / raw) To: George Plymale II, rms; +Cc: monnier, emacs-devel > Well, I don't think I could convince any of my parents to sign copyright > waivers. And I don't want to subject them to such concerns. Moreover, it > is possible that there is further ambiguity because of things that I > cannot divulge publicly. > > In any case, this policy is certainly a pain for minors. It's parents et al who are a pain for minors. ;-) Only one (partial) cure for that. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Generations (was: Loading a package applies automatically to future sessions?) 2018-02-02 18:38 ` Drew Adams @ 2018-02-02 19:05 ` Stefan Monnier 2018-02-02 21:40 ` Drew Adams 2018-02-02 22:57 ` Richard Stallman 0 siblings, 2 replies; 838+ messages in thread From: Stefan Monnier @ 2018-02-02 19:05 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-devel, George Plymale II, rms > It's parents et al who are a pain for minors. ;-) I think you have this backward! Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Generations (was: Loading a package applies automatically to future sessions?) 2018-02-02 19:05 ` Generations (was: Loading a package applies automatically to future sessions?) Stefan Monnier @ 2018-02-02 21:40 ` Drew Adams 2018-02-02 22:57 ` Richard Stallman 1 sibling, 0 replies; 838+ messages in thread From: Drew Adams @ 2018-02-02 21:40 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel, George Plymale II, rms > > It's parents et al who are a pain for minors. ;-) > > I think you have this backward! Both are true. Mine was a reply to a minor complaint. ;-) Yours is a major complaint. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Generations (was: Loading a package applies automatically to future sessions?) 2018-02-02 19:05 ` Generations (was: Loading a package applies automatically to future sessions?) Stefan Monnier 2018-02-02 21:40 ` Drew Adams @ 2018-02-02 22:57 ` Richard Stallman 2018-02-02 23:03 ` Drew Adams 1 sibling, 1 reply; 838+ messages in thread From: Richard Stallman @ 2018-02-02 22:57 UTC (permalink / raw) To: Stefan Monnier; +Cc: georgedp, drew.adams, emacs-devel [[[ 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. ]]] > > It's parents et al who are a pain for minors. ;-) > I think you have this backward! However, parents do have the ability to avoid having children. Children don't have a way to avoid having parents. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Generations (was: Loading a package applies automatically to future sessions?) 2018-02-02 22:57 ` Richard Stallman @ 2018-02-02 23:03 ` Drew Adams 0 siblings, 0 replies; 838+ messages in thread From: Drew Adams @ 2018-02-02 23:03 UTC (permalink / raw) To: rms, Stefan Monnier; +Cc: georgedp, emacs-devel > > > It's parents et al who are a pain for minors. ;-) > > > I think you have this backward! > > However, parents do have the ability to avoid having > children. Children don't have a way to avoid having > parents. Interesting research project, no doubt. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-02 7:33 ` George Plymale II 2018-02-02 18:38 ` Drew Adams @ 2018-02-02 20:36 ` Phillip Lord 1 sibling, 0 replies; 838+ messages in thread From: Phillip Lord @ 2018-02-02 20:36 UTC (permalink / raw) To: George Plymale II; +Cc: emacs-devel, rms, monnier George Plymale II <georgedp@orbitalimpact.com> writes: > 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. ]]] >> >> > What if they can't? What if I don't have parents? What if I live in >> > foster homes and my legal guardian is frequently changed? >> >> If that happens, I will worry about what to do. > > Well, I don't think I could convince any of my parents to sign copyright > waivers. And I don't want to subject them to such concerns. Moreover, it > is possible that there is further ambiguity because of things that I > cannot divulge publicly. > > In any case, this policy is certainly a pain for minors. Indeed. But, without the copyright policy, you should still be asking your parents about your ability to licence your software under GPL. Because who ever uses your software is, effectively, entering into a contract with you, that gives them the right to use your softawre Now the contractual terms of the GPL state that is irrevocable. I don't know how it is in the US, but in the UK, my understanding anyway, is that while as a minor you can make a contract, you can revoke that contract before you reach 18 or shortly after. Even if that disadvantages the other party. So, I don't think the assignment policy is the issue here. The law is with respect to minors is difficult; it's not meant to be a pain, it's meant to be a protection. Either way, the complexities of being a minor do apply to an assignment policy, but they also apply to licencing. Usual "I am not a lawyer" restrictions apply to anything I say here. Phil ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-01 21:36 ` George Plymale II ` (2 preceding siblings ...) 2018-02-02 2:17 ` Richard Stallman @ 2018-02-02 2:17 ` Richard Stallman 2018-02-02 7:24 ` George Plymale II 2018-02-02 13:37 ` Clément Pit-Claudel 2018-02-05 4:51 ` Herring, Davis 5 siblings, 1 reply; 838+ messages in thread From: Richard Stallman @ 2018-02-02 2:17 UTC (permalink / raw) To: George Plymale II; +Cc: monnier, emacs-devel [[[ 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. ]]] I'm responding to the points you raised so as to educate you and others about what we do and where we stand. You don't have to agree, but I want incorrect statements about us to be corrected. > All that you can do to enforce the GPL is sue people. On the contrary, most of our enforcement actions don't go as far as a court case. But we need to have that option as a last resort in order to win most of the time without suing. Isn't there enough > litigiousness in the world today? Yes, but that doesn't imply that any given lawsuit is wrong. For instance, look at the ACLU's lawsuits. The ACLU is constantly suing to overturn unjust laws and protect human rights. I support the ACLU because I support those lawsuits. The FSF's GPL enforcement is also a way of protecting human rights: specifically, every user's right to change and redistribute certain code. Moreover, there is no other fruit > borne by these restrictions No, it's the other way around. We use the GNU GPL to STOP those who redistribute our code from placing restrictions on subsequent users of it. than that won in a court battle. Usually we succeed without a court battle. However, if do go to court and win, that's still good -- it protects the users' freedom. > You > certainly aren't recruiting more developers in any projects which are > subject to this policy. Yes we are. There are several Emacs contributors that weren't involved a few years ago. However, Emacs would fail to give people freedom if we gave up on defending it. > Of course, all of this would probably not be necessary were it not for > the controversial nature of the GPL which leads to lawsuits a lot more > than Our defense of freedom is controversial, but we don't mind. The GPL sometimes leads to lawsuits because it defends users' freedom. If we gave up without a fight, we'd never have a fight, but that would not be better. other open-source licenses. This is the free software movement. We believe that nonfree software is an injustice because it denies users freedom. We don't just wish everyone had software freedom; we work and campaign and when necessary fight for it. Open source is a different idea; the term was coined specifically to reject our views. They disagree with us, and we disagree with them. See https://gnu.org/philosophy/open-source-misses-the-point.html for more explanation of the difference between free software and open source. See also https://thebaffler.com/salvos/the-meme-hustler for Evgeny Morozov's article on the same point. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-02 2:17 ` Richard Stallman @ 2018-02-02 7:24 ` George Plymale II 2018-02-02 22:28 ` Paul Eggert 2018-02-04 3:09 ` Richard Stallman 0 siblings, 2 replies; 838+ messages in thread From: George Plymale II @ 2018-02-02 7:24 UTC (permalink / raw) To: rms; +Cc: monnier, emacs-devel > I'm responding to the points you raised so as to educate you and > others about what we do and where we stand. You don't have to agree, > but I want incorrect statements about us to be corrected. I don't agree on some of your points and I would like to respond to some of those points to clarify to you where I stand and others who share similar opinions. I don't want to respond to all of them since I do not desire a flame war. But I will respond to some which I feel will not incite ill feelings. > Yes, but that doesn't imply that any given lawsuit is wrong. You are correct. Yet I find that most lawsuits regarding software are frivolous and ultimately a waste of time for everyone involved (including society at large). There are much more serious crimes and problems in the world today and wasting a court's time on stuff involving electrical pulses in metal boxes just seems totally silly, at best. No matter if it's about copyright or copyleft. > No, it's the other way around. We use the GNU GPL to STOP those who > redistribute our code from placing restrictions on subsequent users of > it. I understand the enforcing nature of the GPL. What I meant is that there is no fruit for the project in terms of new manpower or technical improvement. Honestly, though, the GPL is just a different set of restrictions. And, contrary to popular belief, it restricts users as well as developers. Users are restricted from sharing or modifying this program, except under certain conditions, by the barrier of copyright issues. These restrictions are supposed to prevent other restrictions, but honestly you could say the same thing about some proprietary software licenses. > Yes we are. There are several Emacs contributors that weren't > involved a few years ago. I would like to see Emacs get more recruitment which is more appreciable in terms of numbers, though. The excitement around Emacs is surprisingly growing. I believe it is in large part due to Spacemacs ( http://spacemacs.org/ ) and similar projects which appeal to those who are used to modern text editors. I also believe that Emacs would see significantly more contributors improving the project if they weren't scared off by murmurs of copyright issues and philosophical disagreements. > However, Emacs would fail to give people freedom if we gave up on > defending it. Emacs has suffered from this defense, though. lldb still hasn't gotten proper support in Emacs because of Apple's mere association with its parent project. Eli went on their mailing list some months ago and tried to resolve some technical disagreements with the project, but lldb probably would have been supported in Emacs a long time ago were it not for the political brouhaha surrounding it. People have tried to make improvements to GCC to allow the creation of development modes in Emacs which are now supported by Clang instead. E.g. https://github.com/Sarcasm/irony-mode Those improvements to GCC were denied also in the name of defending freedom. Sometimes it seems that in the free software world, you have to fly the GNU banner or else you're an enemy. > Open source is a different idea; the term was coined specifically to > reject our views. They disagree with us, and we disagree with them. This division is unproductive at best. > See https://gnu.org/philosophy/open-source-misses-the-point.html > for more explanation of the difference between free software and open > source. See also https://thebaffler.com/salvos/the-meme-hustler for > Evgeny Morozov's article on the same point. Thank you, I'm aware of the philosophy of the GNU project. In any case, the copyright issues which I was worried about do not seem as bad as they did to me initially. It seems that there is more flexibility than I thought so that is good. I just hope that perhaps we can get to a point someday where Emacs (and other GNU programs) will be able to exist without the burdens of copyright worries. I know that those worries seem helpful to some, but it's hard to believe that when looking at things as a whole. Thanks, - George Plymale II ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-02 7:24 ` George Plymale II @ 2018-02-02 22:28 ` Paul Eggert 2018-02-05 8:21 ` George Plymale II 2018-02-04 3:09 ` Richard Stallman 1 sibling, 1 reply; 838+ messages in thread From: Paul Eggert @ 2018-02-02 22:28 UTC (permalink / raw) To: George Plymale II, rms; +Cc: monnier, emacs-devel On 02/01/2018 11:24 PM, George Plymale II wrote: > most lawsuits regarding software are > frivolous and ultimately a waste of time for everyone involved Having been the target of a frivolous software lawsuit myself <https://www.eff.org/press/releases/eff-wins-protection-time-zone-database> I am sympathetic to this argument. However, such lawsuits don't mean we should give up on the legal system entirely; that would be throwing out the baby with the bathwater. Instead, we should use the legal system as best we can, and work to improve it where it has significant flaws. And this is what the Free Software Foundation is trying to do. > In any case, the copyright issues which I was worried about do not seem > as bad as they did to me initially. Yes, that's often the case. A lot of FUD has been spread about the GPL and the GNU project. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-02 22:28 ` Paul Eggert @ 2018-02-05 8:21 ` George Plymale II 2018-02-05 20:36 ` Richard Stallman 0 siblings, 1 reply; 838+ messages in thread From: George Plymale II @ 2018-02-05 8:21 UTC (permalink / raw) To: Paul Eggert; +Cc: emacs-devel, rms, monnier > Having been the target of a frivolous software lawsuit myself > <https://www.eff.org/press/releases/eff-wins-protection-time-zone-database> > I am sympathetic to this argument. However, such lawsuits don't mean we > should give up on the legal system entirely; that would be throwing out > the baby with the bathwater. Instead, we should use the legal system as > best we can, and work to improve it where it has significant flaws. Totally in agreement with you. I just dislike myself (or others) having to worry about these kinds of things at all. But I guess that's just the world we live in today. > Yes, that's often the case. A lot of FUD has been spread about the GPL > and the GNU project. Well, I actually distilled this opinion from information that I got from the FSF's website and gnu.org. So I doubt I was reading any GPL FUD from them ;) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-05 8:21 ` George Plymale II @ 2018-02-05 20:36 ` Richard Stallman 0 siblings, 0 replies; 838+ messages in thread From: Richard Stallman @ 2018-02-05 20:36 UTC (permalink / raw) To: George Plymale II; +Cc: eggert, monnier, emacs-devel [[[ 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. ]]] > Well, I actually distilled this opinion from information that I got from > the FSF's website and gnu.org. So I doubt I was reading any GPL FUD from > them ;) I would guess that you reacted to what you read there based on ideas you have heard others express. "Don't you dare restrict me from putting restrictions on others" is an idea that I've seen for 20 years, from those opposed to copyleft. I wrote this haiku back then to show why it is misguided. Using GPL Is encroaching on our rights To encroach on yours -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-02 7:24 ` George Plymale II 2018-02-02 22:28 ` Paul Eggert @ 2018-02-04 3:09 ` Richard Stallman 1 sibling, 0 replies; 838+ messages in thread From: Richard Stallman @ 2018-02-04 3:09 UTC (permalink / raw) To: George Plymale II; +Cc: monnier, emacs-devel [[[ 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. ]]] > Honestly, though, the GPL is just a different set of restrictions. And, > contrary to popular belief, it restricts users as well as > developers. Users are restricted from sharing or modifying this program, > except under certain conditions, by the barrier of copyright > issues. It's just the opposite: the GNU GPL _prevents_ restrictions. It assures that all users can freely redistribute the program, by stopping middlemen from putting on restrictions. You look at freedom as a word game, so you say, "Hay, if I can't put on restrictions, that's a restriction on me." That paradox doesn't bother us because we understand freedom as a matter of substance, not a matter of form. We judge by the substantive question: are users free to do the things that give them control over the program? You don't have to agree with us, but arguing against our philosophy is outside the purpose of this list. This list is for Emacs development. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-01 21:36 ` George Plymale II ` (3 preceding siblings ...) 2018-02-02 2:17 ` Richard Stallman @ 2018-02-02 13:37 ` Clément Pit-Claudel 2018-02-02 17:20 ` Drew Adams 2018-02-05 4:51 ` Herring, Davis 5 siblings, 1 reply; 838+ messages in thread From: Clément Pit-Claudel @ 2018-02-02 13:37 UTC (permalink / raw) To: emacs-devel On 2018-02-01 16:36, George Plymale II wrote: > What if they can't? What if I don't have parents? What if I live in > foster homes and my legal guardian is frequently changed? Note that (depending on where you live) you most likely need a parent's or guardian's approval to release your code into the public domain (or under any license that grants rights to others). The GPL and Emacs' copyright policy are not different in that regard. Please remember to change the title of the thread when you change the topic, too: it makes it easier for others to filter discussions by topic :) Clément. ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Loading a package applies automatically to future sessions? 2018-02-02 13:37 ` Clément Pit-Claudel @ 2018-02-02 17:20 ` Drew Adams 0 siblings, 0 replies; 838+ messages in thread From: Drew Adams @ 2018-02-02 17:20 UTC (permalink / raw) To: Clément Pit-Claudel, emacs-devel > Please remember to change the title of the thread when you change the > topic, too: it makes it easier for others to filter discussions by topic > :) +1 ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-01 21:36 ` George Plymale II ` (4 preceding siblings ...) 2018-02-02 13:37 ` Clément Pit-Claudel @ 2018-02-05 4:51 ` Herring, Davis 5 siblings, 0 replies; 838+ messages in thread From: Herring, Davis @ 2018-02-05 4:51 UTC (permalink / raw) To: George Plymale II, rms@gnu.org Cc: monnier@IRO.UMontreal.CA, emacs-devel@gnu.org > Of course, all of this would probably not be necessary were it not for > the controversial nature of the GPL which leads to lawsuits a lot more > than other open-source licenses. While we're about clarifying these issues: the reason that fewer lawsuits are pursued over software subject to permissive licenses is of course their lack of provisions which anyone would expect to profit by violating. (Innocent mistakes are made, of course, but they are not litigated.) The controversy over the GPL of course also results from its provisions, but that makes it a sister effect to the lawsuits, not a cause of them. Davis ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-31 5:17 ` George Plymale II 2018-01-31 20:49 ` George Plymale II @ 2018-02-01 19:47 ` Stefan Monnier 2018-02-01 22:10 ` George Plymale II 1 sibling, 1 reply; 838+ messages in thread From: Stefan Monnier @ 2018-02-01 19:47 UTC (permalink / raw) To: George Plymale II; +Cc: emacs-devel > It looks like your code is fetching slime-autoloads.elc: > (let ((load-file-name "/Users/my_username/.emacs.d/elpa/slime-20180126.1033/slime-autoloads.elc")) > ;; ... bunches of bytecode > ) Hmm... good catch. I just added a corresponding FIXME in the code (hopefully M-x dwim will figure out how to fix it). >> Also, I'm not 100% surprised that byte-compiling byte-compiled code would >> fail, but I can't see any immediate reason why it should fail, so it's >> quite possible to it'd be easy to make it work. > Not sure why it would fail either, but this is the error that I see for > that specific chunk of bytecode: > package-fastpath.el:899:1:Error: Wrong type argument: sequencep, 1004 I'll see if I can reproduce it (it's probably better to try and use the .el file instead, tho). > And lo and behold, `emacs-init-time' yields 0.7 seconds. Which is just > 0.2 seconds higher than what I get with -Q, which I believe is Emacs' > peak startup time. I also verified that I have access to all my packages > so it is using package-fastpath.el. Good, thanks. Now the numbers correspond better to my expectations. > So that means your patch has actually increased startup time a lot more ^^^^^^^^^ improved > Well, actually those figures are better than what you're saying as per > my information above. I guess that makes your patch even more > respectable for a first stab! :) FWIW "a first stab" often ends up being faster than the end product, because the first stab was too optimistic. >> Hmm... I thought this can't happen because the files are concatenated in >> the same order that they are normally loaded by `package-initialize`. >> I guess something doesn't work the way I thought it does. >> Can you investigate to see when or even why it happens? > It specifically happened with gh.el (https://github.com/sigma/gh.el), > which is dependent on marshal.el (https://github.com/sigma/marshal.el) > > Apparently gh-autoloads.el uses a `gh-defclass' macro, which in turn > uses a `marshal-defclass' macro. There is definitely some strangeness > that could be going on here. Could you try and give some more details about this problem? E.g. check the fastpath file to see in which order the two packages's autoloads are placed. If gh-autoloads.el comes before marshal-autoloads.el, could you try and figure out why (e.g. maybe starting with `M-x trace-function RET package-activate RET` and `M-x trace-function RET package-activate-1 RET`)? Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-01 19:47 ` Stefan Monnier @ 2018-02-01 22:10 ` George Plymale II 2018-02-01 22:44 ` George Plymale II 0 siblings, 1 reply; 838+ messages in thread From: George Plymale II @ 2018-02-01 22:10 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel > Hmm... good catch. I just added a corresponding FIXME in the code > (hopefully M-x dwim will figure out how to fix it). Sounds good. > I'll see if I can reproduce it (it's probably better to try and use the > .el file instead, tho). Ok, let me know if you need help from my end. > FWIW "a first stab" often ends up being faster than the end product, > because the first stab was too optimistic. Hopefully it won't come to that ;) > Could you try and give some more details about this problem? > E.g. check the fastpath file to see in which order the two packages's > autoloads are placed. If gh-autoloads.el comes before > marshal-autoloads.el, could you try and figure out why (e.g. maybe > starting with `M-x trace-function RET package-activate RET` > and `M-x trace-function RET package-activate-1 RET`)? gh-autoloads.el does indeed come before marshal-autoloads.el (although I currently have them switched around to prevent init errors). I did those `trace-function' invocations that you suggested, but I can't quite make heads or tails out of them so I will just send you the *trace-output* dumps to look at it yourself. I will send said dumps in a private email since I don't want to post all of my installed packages publicly. Thanks, - George Plymale II ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-01 22:10 ` George Plymale II @ 2018-02-01 22:44 ` George Plymale II 2018-02-02 1:54 ` Stefan Monnier 0 siblings, 1 reply; 838+ messages in thread From: George Plymale II @ 2018-02-01 22:44 UTC (permalink / raw) To: George Plymale II; +Cc: monnier, emacs-devel One more thing regarding my bug about info nodes from ELPA, I noticed that all my info nodes were back after upgrading my packages in `package-list-packages'. Do you have any idea about why that is, Stefan? Thanks, - George Plymale II ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-01 22:44 ` George Plymale II @ 2018-02-02 1:54 ` Stefan Monnier 2018-02-02 20:32 ` George Plymale II 0 siblings, 1 reply; 838+ messages in thread From: Stefan Monnier @ 2018-02-02 1:54 UTC (permalink / raw) To: emacs-devel > One more thing regarding my bug about info nodes from ELPA, Oh, I didn't respond to that part, but this is a "known issue" (the patch I sent doesn't bother to keep track and reproduce changes to Info-directory-list). > I noticed that all my info nodes were back after upgrading my packages > in `package-list-packages'. Do you have any idea about why that is, > Stefan? Hmm... no I can't explain how/why the problem disappeared when you did that. Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-02 1:54 ` Stefan Monnier @ 2018-02-02 20:32 ` George Plymale II 0 siblings, 0 replies; 838+ messages in thread From: George Plymale II @ 2018-02-02 20:32 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> One more thing regarding my bug about info nodes from ELPA, > > Oh, I didn't respond to that part, but this is a "known issue" (the > patch I sent doesn't bother to keep track and reproduce changes to > Info-directory-list). > >> I noticed that all my info nodes were back after upgrading my packages >> in `package-list-packages'. Do you have any idea about why that is, >> Stefan? > > Hmm... no I can't explain how/why the problem disappeared when you did that. > > > Stefan Ok, please consider fixing this even though it's a known issue. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-30 22:33 ` George Plymale II 2018-01-30 22:56 ` George Plymale II 2018-01-31 3:47 ` Stefan Monnier @ 2018-01-31 3:51 ` T.V Raman 2018-01-31 5:18 ` George Plymale II 2 siblings, 1 reply; 838+ messages in thread From: T.V Raman @ 2018-01-31 3:51 UTC (permalink / raw) To: George Plymale II; +Cc: Stefan Monnier, emacs-devel George Plymale II <georgedp@orbitalimpact.com> writes: try let-binding file-name-handler-alist to nil -- in my case, that gave a significant speed-up a few months ago > Hi all, > > I'm the one who posted the question on Stack Exchange, which Stefan > mentioned the other day. My specific question is detailed here: > https://emacs.stackexchange.com/q/38368/10761 > > So, I've tried out Stefan's patch and it's definitely an improvement on > startup time, but the improvement is not huge for me. Specifically, I've > done the following in my startup files: > > (setq package-enable-at-startup nil) > (load "~/.emacs.d/package-fastpath.el") > (setq package--initialized t) > > I put that code in my files after running Stefan's > `package-fastpath-refresh'. I also set `load-source-file-function' to > nil as per Stefan's suggestion. Unfortunately, I couldn't byte-compile > my package-fastpath.el file due to some packages which already > byte-compile their autoload files, such as SLIME. > > Now, I do see some improvement in my startup time, but to reiterate, it > is not huge. When I run Emacs with my startup commented out, > `emacs-init-time' yields 1.2 seconds. When I run it with my startup > intact, it yields 1.3 or 1.4 seconds. This contrasts with my previous > `emacs-init-time' which was 1.6 or 1.7 seconds, but as you can see, it's > not a really big difference. > > It is possible that this sub-par time is due to something on my own > system, but I'm not sure nor convinced of that. Moreover, Stefan's patch > certainly can use some improvements and some notes on how to use his > changes, as it is a bit vexing to figure it out by reading the diff ;) > > I did notice a few bugs with Stefan's changes. One bug was that > `package-installed-p' no longer yields correct results on installed > packages. I believe that this is because `package-desc-p' is also broken > by these changes. This broke some code in my startup which I used to > check whether I need to install new packages. > > Another bug was that some packages were placed in bad order in > package-fastpath.el. In other words, if a dependency's autoloads are > written to this file after its dependent package, the dependent package > will err, saying that it couldn't require one of its dependencies. There > is obviously some work to do on making sure that dependencies are placed > in the correct order or to change the code so that package-fastpath.el > is order-agnostic. > > As a side note and a bit of an opinion, Radon Rosborough made an > interesting remark in one of his messages. He mentioned pip and how > things are done in Python, which really struck me. You never really > think about using a package in a language like Python or Ruby. You just > `require' or `import' it and that's that. It's really simple and the > amount of packages that you have never hurts the startup of the main > program. I know that Emacs is a bit more complicated since it's more of > a text editor than a language and we have somewhat more intricacies to > worry about. But I think that this kind of a model is the kind we need > to be headed for. > > A user should be able to have a million packages and not have to worry > about the subsequent startup time. Heck, in my own Ruby installation I > have 436 gems and I've never even thought about startup time till now. > > In any case, I think Stefan's ideas and proposed changes are a good idea > and I am in much the same boat as John Wiegley in that I restart Emacs > often enough that startup time gets on my nerves. So I hope that we'll > have some real progress on this issue and make package.el more robust. > > Thanks, > - George Plymale II > -- ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-31 3:51 ` T.V Raman @ 2018-01-31 5:18 ` George Plymale II 2018-01-31 6:56 ` Tim Cross 0 siblings, 1 reply; 838+ messages in thread From: George Plymale II @ 2018-01-31 5:18 UTC (permalink / raw) To: T.V Raman; +Cc: monnier, emacs-devel > try let-binding file-name-handler-alist to nil -- in my case, that gave > a significant speed-up a few months ago I have done that. It did help my startup time as well, but I still have the issues which I've described. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-31 5:18 ` George Plymale II @ 2018-01-31 6:56 ` Tim Cross 2018-01-31 7:07 ` George Plymale II 2018-01-31 8:05 ` John Wiegley 0 siblings, 2 replies; 838+ messages in thread From: Tim Cross @ 2018-01-31 6:56 UTC (permalink / raw) To: George Plymale II; +Cc: Emacs developers, Stefan Monnier, T.V Raman [-- Attachment #1: Type: text/plain, Size: 530 bytes --] Can I ask what would be considered an acceptable startup time? Times under 2 seconds seem pretty good to me. I'm just curious to know what the general expectation is? Tim On 31 January 2018 at 16:18, George Plymale II <georgedp@orbitalimpact.com> wrote: > > try let-binding file-name-handler-alist to nil -- in my case, that gave > > a significant speed-up a few months ago > > I have done that. It did help my startup time as well, but I still have > the issues which I've described. > > -- regards, Tim -- Tim Cross [-- Attachment #2: Type: text/html, Size: 1140 bytes --] ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-31 6:56 ` Tim Cross @ 2018-01-31 7:07 ` George Plymale II 2018-01-31 8:05 ` John Wiegley 1 sibling, 0 replies; 838+ messages in thread From: George Plymale II @ 2018-01-31 7:07 UTC (permalink / raw) To: Tim Cross; +Cc: emacs-devel, monnier, raman > Can I ask what would be considered an acceptable startup time? Times > under 2 seconds seem pretty good to me. I'm just curious to know what > the general expectation is? I'm hoping to get my startup time at least under 1 second, say 0.7 or 0.8 seconds. I used to have it under half a second, but that doesn't seem possible on the Emacs Mac Port given that `emacs -Q' is already 0.5 seconds. Of course, I would be most happy if I could somehow make that happen. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-31 6:56 ` Tim Cross 2018-01-31 7:07 ` George Plymale II @ 2018-01-31 8:05 ` John Wiegley 2018-02-01 7:26 ` Tim Cross 1 sibling, 1 reply; 838+ messages in thread From: John Wiegley @ 2018-01-31 8:05 UTC (permalink / raw) To: Tim Cross; +Cc: T.V Raman, George Plymale II, Stefan Monnier, Emacs developers >>>>> "TC" == Tim Cross <theophilusx@gmail.com> writes: TC> Can I ask what would be considered an acceptable startup time? Times under TC> 2 seconds seem pretty good to me. I'm just curious to know what the TC> general expectation is? My ideal is .25 (I've gotten it as low as 0.14 on GNU/Linux). I don't complain if it's below 2. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-31 8:05 ` John Wiegley @ 2018-02-01 7:26 ` Tim Cross 2018-02-01 15:00 ` Stefan Monnier 2018-02-01 16:23 ` T.V Raman 0 siblings, 2 replies; 838+ messages in thread From: Tim Cross @ 2018-02-01 7:26 UTC (permalink / raw) To: Tim Cross, George Plymale II, Emacs developers, Stefan Monnier, T.V Raman [-- Attachment #1: Type: text/plain, Size: 1279 bytes --] I dunno, perhaps I'm just slow, but I know my emacs startup is certainly more than 2 seconds and the time has never bothered me. As I rarely hack on elisp these days, I don't find it necessary to restart very often and I've got everything integrated using emacsclient, so once I'm running, I forget about startup time. However, I will put some timing code in just to see (out of interest) what my startup is like. For me, I'm more frustrated by modes like helm, which seem to offer benefits, but I find such add-ons tend to slow down my use of emacs, which I find more frustrating than startup times. The slowest component in my setup is definitely me though! Tim On 31 January 2018 at 19:05, John Wiegley <johnw@gnu.org> wrote: > >>>>> "TC" == Tim Cross <theophilusx@gmail.com> writes: > > TC> Can I ask what would be considered an acceptable startup time? Times > under > TC> 2 seconds seem pretty good to me. I'm just curious to know what the > TC> general expectation is? > > My ideal is .25 (I've gotten it as low as 0.14 on GNU/Linux). I don't > complain if it's below 2. > > -- > John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F > http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 > -- regards, Tim -- Tim Cross [-- Attachment #2: Type: text/html, Size: 2150 bytes --] ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-01 7:26 ` Tim Cross @ 2018-02-01 15:00 ` Stefan Monnier 2018-02-01 16:23 ` T.V Raman 1 sibling, 0 replies; 838+ messages in thread From: Stefan Monnier @ 2018-02-01 15:00 UTC (permalink / raw) To: emacs-devel > I dunno, perhaps I'm just slow, but I know my emacs startup is certainly > more than 2 seconds and the time has never bothered me. It very much depends on your usage pattern. My Emacs's startup time doesn't bother me either, but I understand that it can be annoying for other users. Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-01 7:26 ` Tim Cross 2018-02-01 15:00 ` Stefan Monnier @ 2018-02-01 16:23 ` T.V Raman 2018-02-03 0:39 ` Tim Cross 1 sibling, 1 reply; 838+ messages in thread From: T.V Raman @ 2018-02-01 16:23 UTC (permalink / raw) To: Tim Cross; +Cc: George Plymale II, Stefan Monnier, Emacs developers M-x emacs-init-time will show your startup time. You can find some code for more fine-grained instrumentation in tvr/emacs-startup.el in the emacspeak Github repo. -- ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-01 16:23 ` T.V Raman @ 2018-02-03 0:39 ` Tim Cross 2018-02-05 9:24 ` George Plymale II 0 siblings, 1 reply; 838+ messages in thread From: Tim Cross @ 2018-02-03 0:39 UTC (permalink / raw) To: T.V Raman; +Cc: George Plymale II, Stefan Monnier, Emacs developers [-- Attachment #1: Type: text/plain, Size: 641 bytes --] Thanks Raman, I was actually looking at that this morning. The danger for me is that every time I look at my emacs init, I always find things I can improve or cleanup. Not a complaint, but it is often a source of procrastination. There are way too many weekends I've wasted tweaking my emacs setup rather than getting on with my always large todo list! Tim On 2 February 2018 at 03:23, T.V Raman <raman@google.com> wrote: > M-x emacs-init-time will show your startup time. > > You can find some code for more fine-grained instrumentation in > tvr/emacs-startup.el in the emacspeak Github repo. > -- > -- regards, Tim -- Tim Cross [-- Attachment #2: Type: text/html, Size: 1271 bytes --] ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-02-03 0:39 ` Tim Cross @ 2018-02-05 9:24 ` George Plymale II 0 siblings, 0 replies; 838+ messages in thread From: George Plymale II @ 2018-02-05 9:24 UTC (permalink / raw) To: Tim Cross; +Cc: emacs-devel, monnier, raman > The danger for me is that every time I look at my emacs init, I always find things I can improve or cleanup. Not a complaint, but it is often a source of procrastination. > There are way too many weekends I've wasted tweaking my emacs setup rather than getting on with my always large todo list! Ah, I know the feeling all too well. Hence my initial involvement in this thread :) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Loading a package applies automatically to future sessions? 2018-01-28 13:21 ` Stefan Monnier 2018-01-28 17:32 ` Radon Rosborough @ 2018-01-29 1:50 ` Richard Stallman 1 sibling, 0 replies; 838+ messages in thread From: Richard Stallman @ 2018-01-29 1:50 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel [[[ 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. ]]] > >> I think there should be a way to activate a package explicitly for the > >> current session _without_ automatically activating it for future > >> sessions. > > The failure of package.el to support this use case > FWIW, package.el does support this case: > - one way is to prevent package-initialize from activating packages, > and then activating the ones you want by explicit calls to package-active. > - another is to set package-load-list. E.g. This means a user _can_ do it -- but it isn't naturak and easy. I suggest adding a convenient interface for it. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-01-25 4:35 ` Radon Rosborough 2018-01-25 15:43 ` Clément Pit-Claudel @ 2018-01-25 17:07 ` Stefan Monnier 2018-01-28 19:42 ` Radon Rosborough 1 sibling, 1 reply; 838+ messages in thread From: Stefan Monnier @ 2018-01-25 17:07 UTC (permalink / raw) To: emacs-devel > Since it has been more than a month with no response, I am re-posting > the patch which fixes the problems previously discussed [1] [2] [3] > with `package-initialize' by adding a second (optional) init-file > `early-init.el'. This patch includes some refactoring of the code in > `startup.el' to provide for loading any number of init-files in an > extensible way. I hope that the change can be included in Emacs 26.2 > or Emacs 27. Sorry for the delay, here are my comments (I doubt it's appropriate for Emacs-26.2 since I think 26.N should be kept exclusively for bug-fixes). Once you fix the two minor problems I mention below, looks good to me, Stefan > * lisp/startup.el (early-init-file): New variable, for the filename of > the early init file after it has been loaded. > > * lisp/startup.el (load-user-init-file): New function, used to > eliminate duplicate code in loading the early and regular init > files. > > * lisp/startup.el (command-line): Load the early init file using > `load-user-init-file'. Move the check for an invalid username to > just before that, and move the initialization of the package system > to just after. Load the regular init file using > `load-user-init-file'. The format for commit messages wants to combine those as follows (notice also that we use double-spaces after "."): * lisp/startup.el (early-init-file): New variable, for the filename of the early init file after it has been loaded. (load-user-init-file): New function, used to eliminate duplicate code in loading the early and regular init files. (command-line): Load the early init file using `load-user-init-file'. Move the check for an invalid username to just before that, and move the initialization of the package system to just after. Load the regular init file using `load-user-init-file'. > * src/lread.c (Vuser_init_file): Note change in semantics due to its > usage while loading the early init file. > > * lisp/emacs-lisp/package.el (package--ensure-init-file): Remove > definition, usage, and documentation. > > * lisp/emacs-lisp/package.el (package--init-file-ensured): Remove > definition and usage. Same here, please combine the two messages about lisp/emacs-lisp/package.el. > * etc/NEWS: Document changes to startup and package.el. No need to mention these changes to NEWS here. > diff --git a/lisp/startup.el b/lisp/startup.el > index 4575f1f94d..de85933983 100644 > --- a/lisp/startup.el > +++ b/lisp/startup.el > @@ -312,6 +312,15 @@ inhibit-startup-hooks > Currently this applies to: `emacs-startup-hook', `term-setup-hook', > and `window-setup-hook'.") > > +(defvar early-init-file nil > + "File name, including directory, of user's early init file. > +If the file loaded had extension `.elc', and the corresponding > +source file exists, this variable contains the name of source > +file, suitable for use by functions like `custom-save-all' which > +edit the init file. While Emacs loads and evaluates the init > +file, value is the real name of the file, regardless of whether > +or not it has the `.elc' extension.") This duplicates the doc of user-init-file, basically. I think it'd be better to refer to user-init-file and just explains in which way it's different. Also, IIUC the above is not true: while loading the early init file, `early-init-file` will not be bound to the file being loaded, instead it will be `user-init-file` which will be bound to it (and I'd rather not document that quirk). > +(defun load-user-init-file > + (compute-filename &optional compute-alternate-filename load-defaults) We usually use names like `filename-function` rather than `compute-filename` (the function itself could be named `compute-filename` since a function *does* something, but a variable doesn't *do* it just contains a value, in this case a function value). > + "Load a user init-file. > +COMPUTE-FILENAME is called with no arguments and should return > +the name of the init-file to load. If this file cannot be loaded, > +and COMPUTE-ALTERNATE-FILENAME is non-nil, then it is called with > +no arguments and should return the name of an alternate init-file > +to load. If LOAD-DEFAULTS is non-nil, then load default.el after > +the init-file. > + > +This function sets `user-init-file' to the name of the loaded > +init-file, or to a default value if loading is not possible." > + (let ((debug-on-error-from-init-file nil) > + (debug-on-error-should-be-set nil) > + (debug-on-error-initial > + (if (eq init-file-debug t) > + 'startup > + init-file-debug)) > + (orig-enable-multibyte (default-value 'enable-multibyte-characters))) > + (let ((debug-on-error debug-on-error-initial) > + ;; We create an anonymous function here so that we can call > + ;; it in different contexts depending on the value of > + ;; `debug-on-error'. > + (read-init-file > + (lambda () > + (when init-file-user > + (let ((init-file-name (funcall compute-filename))) > + > + ;; If `user-init-file' is t, then `load' will store > + ;; the name of the file that it loads into > + ;; `user-init-file'. > + (setq user-init-file t) > + (load init-file-name 'noerror 'nomessage) > + > + (when (eq user-init-file t) > + (let ((alt-file-name (funcall compute-alternate-filename))) > + (load alt-file-name 'noerror 'nomessage) You could directly do (load (funcall compute-alternate-filename) 'noerror 'nomessage) here. But more significantly, compute-alternate-filename is an optional arg yet you forget to check if it's nil! > + ;; If a previous init-file had an error, don't forget > + ;; about that. > + (unless init-file-had-error > + (setq init-file-had-error nil))) There's a problem here, since this is a nop. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-01-25 17:07 ` [PATCH] Fixing package-initialize, adding early init file Stefan Monnier @ 2018-01-28 19:42 ` Radon Rosborough 2018-01-30 15:02 ` Stefan Monnier 2018-02-10 11:56 ` Eli Zaretskii 0 siblings, 2 replies; 838+ messages in thread From: Radon Rosborough @ 2018-01-28 19:42 UTC (permalink / raw) To: Stefan Monnier, Clément Pit-Claudel; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 127 bytes --] I've fixed all the problems noted by Stefan and Clément, and rebased onto the latest master. The revised patch is attached. [-- Attachment #2: 0001-Add-early-init-file-stop-package-initialize-insertio.patch --] [-- Type: application/octet-stream, Size: 31675 bytes --] From 7e45f0e4ee1eb666c096ed12435f5edb434bb2bf Mon Sep 17 00:00:00 2001 From: Radon Rosborough <radon.neon@gmail.com> Date: Sun, 17 Dec 2017 17:31:17 -0700 Subject: [PATCH] Add early init file, stop package-initialize insertion * lisp/startup.el (early-init-file): New variable, for the filename of the early init file after it has been loaded. (load-user-init-file): New function, used to eliminate duplicate code in loading the early and regular init files. (command-line): Load the early init file using `load-user-init-file'. Move the check for an invalid username to just before that, and move the initialization of the package system to just after. Load the regular init file using `load-user-init-file'. * src/lread.c (Vuser_init_file): Note change in semantics due to its usage while loading the early init file. * lisp/emacs-lisp/package.el (package--ensure-init-file): Remove definition, usage, and documentation. (package--init-file-ensured): Remove definition and usage. * doc/lispref/os.texi: Document early init file. * doc/lispref/package.texi: Document changes to when package-initialize is called, and advise against calling it in the init file. * doc/emacs/package.texi: Document changes to when package-initialize is called. * doc/misc/org.texi: Don't recommend to call package-initialize in the init file. Discussion on emacs-devel leading up to this change (approximately 150 messages): - https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00154.html - https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00433.html - https://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00023.html - https://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00599.html - https://lists.gnu.org/archive/html/emacs-devel/2017-10/msg00332.html --- doc/emacs/package.texi | 31 ++-- doc/lispref/os.texi | 14 ++ doc/lispref/package.texi | 16 +- doc/misc/org.texi | 4 +- etc/NEWS | 20 +++ lisp/emacs-lisp/package.el | 71 +-------- lisp/startup.el | 379 ++++++++++++++++++++++++--------------------- src/lread.c | 2 +- 8 files changed, 264 insertions(+), 273 deletions(-) diff --git a/doc/emacs/package.texi b/doc/emacs/package.texi index 5f05bc0f9e..9629f41c80 100644 --- a/doc/emacs/package.texi +++ b/doc/emacs/package.texi @@ -250,31 +250,18 @@ Package Installation wide-ranging effects on the Emacs session. For such information, consult the package's help buffer. - By default, Emacs also automatically loads all installed packages in -subsequent Emacs sessions. This happens at startup, after processing -the init file (@pxref{Init File}). As an exception, Emacs does not -load packages at startup if invoked with the @samp{-q} or -@samp{--no-init-file} options (@pxref{Initial Options}). + After a package is installed, it is automatically loaded by Emacs in +all subsequent sessions. This happens at startup, before processing +the init file but after processing the early init file (@pxref{Early +Init File,,, elisp, The Emacs Lisp Reference Manual}). As an +exception, Emacs does not load packages at startup if invoked with the +@samp{-q} or @samp{--no-init-file} options (@xref{Initial Options}). @vindex package-enable-at-startup To disable automatic package loading, change the variable -@code{package-enable-at-startup} to @code{nil}. - -@findex package-initialize - The reason automatic package loading occurs after loading the init -file is that user options only receive their customized values after -loading the init file, including user options which affect the -packaging system. In some circumstances, you may want to load -packages explicitly in your init file (usually because some other code -in your init file depends on a package). In that case, your init file -should call the function @code{package-initialize}. It is up to you -to ensure that relevant user options, such as @code{package-load-list} -(see below), are set up prior to the @code{package-initialize} call. -This will automatically set @code{package-enable-at-startup} to @code{nil}, to -avoid loading the packages again after processing the init file. -Alternatively, you may choose to completely inhibit package loading at -startup, and invoke the command @kbd{M-x package-initialize} to load -your packages manually. +@code{package-enable-at-startup} to @code{nil}. You must do this in +the early init file, as the variable is read before loading the +regular init file. Currently it cannot be done via Customize. @vindex package-load-list For finer control over package loading, you can use the variable diff --git a/doc/lispref/os.texi b/doc/lispref/os.texi index 0854468835..209e450fbd 100644 --- a/doc/lispref/os.texi +++ b/doc/lispref/os.texi @@ -361,6 +361,7 @@ Init File @cindex init file @cindex @file{.emacs} @cindex @file{init.el} +@cindex @file{early-init.el} When you start Emacs, it normally attempts to load your @dfn{init file}. This is either a file named @file{.emacs} or @file{.emacs.el} @@ -384,6 +385,19 @@ Init File file. If those environment variables are absent, though, Emacs uses your user-id to find your home directory. +@cindex early init file + Emacs also attempts to load a second init file, called the + @dfn{early init file}, if it exists. This is a file named + @file{early-init.el} in a subdirectory named @file{.emacs.d} in your + home directory. The difference is that the early init file is + loaded much earlier during the startup process, so you can use it to + customize some things that are initialized before loading the + regular init file. For example, you can customize the process of + loading installed packages, by setting variables such as + @var{package-load-list} or + @var{package-enable-at-startup}. @xref{Package Installation,,, + emacs,The GNU Emacs Manual}. + @cindex default init file An Emacs installation may have a @dfn{default init file}, which is a Lisp library named @file{default.el}. Emacs finds this file through diff --git a/doc/lispref/package.texi b/doc/lispref/package.texi index 21dfe1c271..d5ee4cbd47 100644 --- a/doc/lispref/package.texi +++ b/doc/lispref/package.texi @@ -106,10 +106,12 @@ Packaging Basics Whenever Emacs starts up, it automatically calls the function @code{package-initialize} to load installed packages. This is done -after loading the init file and abbrev file (if any) and before -running @code{after-init-hook} (@pxref{Startup Summary}). Automatic -package loading is disabled if the user option -@code{package-enable-at-startup} is @code{nil}. +after loading the early init file, but before loading the regular init +file and abbrev file (if any) and before running +@code{after-init-hook} (@pxref{Startup Summary}). Automatic package +loading is disabled if the user option +@code{package-enable-at-startup} is set to @code{nil} in the early +init file. @deffn Command package-initialize &optional no-activate This function initializes Emacs' internal record of which packages are @@ -123,6 +125,12 @@ Packaging Basics The optional argument @var{no-activate}, if non-@code{nil}, causes Emacs to update its record of installed packages without actually loading them; it is for internal use only. + +In most cases, you should not need to call @code{package-initialize}, +as this is done automatically during startup. Simply make sure to put +any code that should run before @code{package-initialize} in the early +init file, and any code that should run after it in the primary init +file (@xref{Init File,,, emacs, The GNU Emacs Manual}). @end deffn @node Simple Packages diff --git a/doc/misc/org.texi b/doc/misc/org.texi index 762dfafdda..ef2c931b6d 100644 --- a/doc/misc/org.texi +++ b/doc/misc/org.texi @@ -890,9 +890,7 @@ Installation been visited, i.e., where no Org built-in function have been loaded. Otherwise autoload Org functions will mess up the installation. -Then, to make sure your Org configuration is taken into account, initialize -the package system with @code{(package-initialize)} in your Emacs init file -before setting any Org option. If you want to use Org's package repository, +If you want to use Org's package repository, check out the @uref{http://orgmode.org/elpa.html, Org ELPA page}. @subsubheading Downloading Org as an archive diff --git a/etc/NEWS b/etc/NEWS index ad31553603..97f08dc0d9 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -49,6 +49,26 @@ to reduce differences between developer and production builds. \f * Startup Changes in Emacs 27.1 ++++ +** Emacs can now be configured using an early init file. +The file is called 'early-init.el', in 'user-emacs-directory'. It is +loaded very early in the startup process: before graphical elements +such as the tool bar are initialized, and before the package manager +is initialized. + ++++ +** Emacs now calls 'package-initialize' before loading the init file. +This is part of a change intended to eliminate the behavior of +package.el inserting a call to 'package-initialize' into the init +file, which was previously done when Emacs was started. You only need +to make changes to your configuration if some of it needs to be run +before 'package-initialize' is called (for example, if you set +'package-load-list' or 'package-user-dir'). In that case, place the +configuration that needs to be run before 'package-initialize' into +the early init file. Note that variables like 'package-archives' can +be set after 'package-initialize', so they can still be customized in +the regular init file. + \f * Changes in Emacs 27.1 diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el index 71d1c41ec3..ab02d4255b 100644 --- a/lisp/emacs-lisp/package.el +++ b/lisp/emacs-lisp/package.el @@ -1431,16 +1431,11 @@ package-read-all-archive-contents ;; available on disk. (defvar package--initialized nil) -(defvar package--init-file-ensured nil - "Whether we know the init file has package-initialize.") - ;;;###autoload (defun package-initialize (&optional no-activate) "Load Emacs Lisp packages, and activate them. The variable `package-load-list' controls which packages to load. If optional arg NO-ACTIVATE is non-nil, don't activate packages. -If `user-init-file' does not mention `(package-initialize)', add -it to the file. If called as part of loading `user-init-file', set `package-enable-at-startup' to nil, to prevent accidentally loading packages twice. @@ -1449,13 +1444,7 @@ package-initialize taken care of by `package-initialize'." (interactive) (setq package-alist nil) - (if after-init-time - (package--ensure-init-file) - ;; If `package-initialize' is before we finished loading the init - ;; file, it's obvious we don't need to ensure-init. - (setq package--init-file-ensured t - ;; And likely we don't need to run it again after init. - package-enable-at-startup nil)) + (setq package-enable-at-startup nil) (package-load-all-descriptors) (package-read-all-archive-contents) (unless no-activate @@ -1872,64 +1861,6 @@ package-download-transaction using `package-compute-transaction'." (mapc #'package-install-from-archive packages)) -(defun package--ensure-init-file () - "Ensure that the user's init file has `package-initialize'. -`package-initialize' doesn't have to be called, as long as it is -present somewhere in the file, even as a comment. If it is not, -add a call to it along with some explanatory comments." - ;; Don't mess with the init-file from "emacs -Q". - (when (and (stringp user-init-file) - (not package--init-file-ensured) - (file-readable-p user-init-file) - (file-writable-p user-init-file)) - (let* ((buffer (find-buffer-visiting user-init-file)) - buffer-name - (contains-init - (if buffer - (with-current-buffer buffer - (save-excursion - (save-restriction - (widen) - (goto-char (point-min)) - (re-search-forward "(package-initialize\\_>" nil 'noerror)))) - ;; Don't visit the file if we don't have to. - (with-temp-buffer - (insert-file-contents user-init-file) - (goto-char (point-min)) - (re-search-forward "(package-initialize\\_>" nil 'noerror))))) - (unless contains-init - (with-current-buffer (or buffer - (let ((delay-mode-hooks t) - (find-file-visit-truename t)) - (find-file-noselect user-init-file))) - (when buffer - (setq buffer-name (buffer-file-name)) - (set-visited-file-name (file-chase-links user-init-file))) - (save-excursion - (save-restriction - (widen) - (goto-char (point-min)) - (while (and (looking-at-p "[[:blank:]]*\\(;\\|$\\)") - (not (eobp))) - (forward-line 1)) - (insert - "\n" - ";; Added by Package.el. This must come before configurations of\n" - ";; installed packages. Don't delete this line. If you don't want it,\n" - ";; just comment it out by adding a semicolon to the start of the line.\n" - ";; You may delete these explanatory comments.\n" - "(package-initialize)\n") - (unless (looking-at-p "$") - (insert "\n")) - (let ((file-precious-flag t)) - (save-buffer)) - (if buffer - (progn - (set-visited-file-name buffer-name) - (set-buffer-modified-p nil)) - (kill-buffer (current-buffer))))))))) - (setq package--init-file-ensured t)) - ;;;###autoload (defun package-install (pkg &optional dont-select) "Install the package PKG. diff --git a/lisp/startup.el b/lisp/startup.el index 8c36c19e82..69bc8fa781 100644 --- a/lisp/startup.el +++ b/lisp/startup.el @@ -312,6 +312,12 @@ inhibit-startup-hooks Currently this applies to: `emacs-startup-hook', `term-setup-hook', and `window-setup-hook'.") +(defvar early-init-file nil + "File name, including directory, of user's early init file. +See `user-init-file'. The only difference is that +`early-init-file' is not set during the course of evaluating the +early init file.") + (defvar keyboard-type nil "The brand of keyboard you are using. This variable is used to define the proper function and keypad @@ -870,6 +876,103 @@ startup--setup-quote-display (when standard-display-table (aset standard-display-table char nil))))))) +(defun load-user-init-file + (filename-function &optional alternate-filename-function load-defaults) + "Load a user init-file. +FILENAME-FUNCTION is called with no arguments and should return +the name of the init-file to load. If this file cannot be +loaded, and ALTERNATE-FILENAME-FUNCTION is non-nil, then it is +called with no arguments and should return the name of an +alternate init-file to load. If LOAD-DEFAULTS is non-nil, then +load default.el after the init-file. + +This function sets `user-init-file' to the name of the loaded +init-file, or to a default value if loading is not possible." + (let ((debug-on-error-from-init-file nil) + (debug-on-error-should-be-set nil) + (debug-on-error-initial + (if (eq init-file-debug t) + 'startup + init-file-debug))) + (let ((debug-on-error debug-on-error-initial) + ;; We create an anonymous function here so that we can call + ;; it in different contexts depending on the value of + ;; `debug-on-error'. + (read-init-file + (lambda () + (when init-file-user + (let ((init-file-name (funcall filename-function))) + + ;; If `user-init-file' is t, then `load' will store + ;; the name of the file that it loads into + ;; `user-init-file'. + (setq user-init-file t) + (load init-file-name 'noerror 'nomessage) + + (when (and (eq user-init-file t) alternate-filename-function) + (load (funcall alternate-filename-function) + 'noerror 'nomessage)) + + ;; If we did not find the user's init file, set + ;; user-init-file conclusively. Don't let it be + ;; set from default.el. + (when (eq user-init-file t) + (setq user-init-file init-file-name))) + + ;; If we loaded a compiled file, set `user-init-file' to + ;; the source version if that exists. + (when (equal (file-name-extension user-init-file) + "elc") + (let* ((source (file-name-sans-extension user-init-file)) + (alt (concat source ".el"))) + (setq source (cond ((file-exists-p alt) alt) + ((file-exists-p source) source) + (t nil))) + (when source + (when (file-newer-than-file-p source user-init-file) + (message "Warning: %s is newer than %s" + source user-init-file) + (sit-for 1)) + (setq user-init-file source)))) + + (when load-defaults + + ;; Prevent default.el from changing the value of + ;; `inhibit-startup-screen'. + (let ((inhibit-startup-screen nil)) + (load "default" 'noerror 'nomessage))))))) + ;; Now call our anonymous function. + (if init-file-debug + ;; Do this without a `condition-case' if the user wants to + ;; debug. + (funcall read-init-file) + (condition-case error + (funcall read-init-file) + (error + (display-warning + 'initialization + (format-message "\ +An error occurred while loading `%s':\n\n%s%s%s\n\n\ +To ensure normal operation, you should investigate and remove the +cause of the error in your initialization file. Start Emacs with +the `--debug-init' option to view a complete error backtrace." + user-init-file + (get (car error) 'error-message) + (if (cdr error) ": " "") + (mapconcat (lambda (s) (prin1-to-string s t)) + (cdr error) ", ")) + :warning) + (setq init-file-had-error t)))) + + ;; If we can tell that the init file altered debug-on-error, + ;; arrange to preserve the value that it set up. + (or (eq debug-on-error debug-on-error-initial) + (setq debug-on-error-should-be-set t + debug-on-error-from-init-file debug-on-error))) + + (when debug-on-error-should-be-set + (setq debug-on-error debug-on-error-from-init-file)))) + (defun command-line () "A subroutine of `normal-top-level'. Amongst another things, it parses the command-line arguments." @@ -1021,6 +1124,69 @@ command-line (and command-line-args (setcdr command-line-args args))) + ;; Warn for invalid user name. + (when init-file-user + (if (string-match "[~/:\n]" init-file-user) + (display-warning 'initialization + (format "Invalid user name %s" + init-file-user) + :error) + (if (file-directory-p (expand-file-name + ;; We don't support ~USER on MS-Windows + ;; and MS-DOS except for the current + ;; user, and always load .emacs from + ;; the current user's home directory + ;; (see below). So always check "~", + ;; even if invoked with "-u USER", or + ;; if $USER or $LOGNAME are set to + ;; something different. + (if (memq system-type '(windows-nt ms-dos)) + "~" + (concat "~" init-file-user)))) + nil + (display-warning 'initialization + (format "User %s has no home directory" + (if (equal init-file-user "") + (user-real-login-name) + init-file-user)) + :error)))) + + ;; Load the early init file, if found. + (load-user-init-file + (lambda () + (expand-file-name + "early-init" + (file-name-as-directory + (concat "~" init-file-user "/.emacs.d"))))) + (setq early-init-file user-init-file) + + ;; If any package directory exists, initialize the package system. + (and user-init-file + package-enable-at-startup + (catch 'package-dir-found + (let (dirs) + (if (boundp 'package-directory-list) + (setq dirs package-directory-list) + (dolist (f load-path) + (and (stringp f) + (equal (file-name-nondirectory f) "site-lisp") + (push (expand-file-name "elpa" f) dirs)))) + (push (if (boundp 'package-user-dir) + package-user-dir + (locate-user-emacs-file "elpa")) + dirs) + (dolist (dir dirs) + (when (file-directory-p dir) + (dolist (subdir (directory-files dir)) + (when (let ((subdir (expand-file-name subdir dir))) + (and (file-directory-p subdir) + (file-exists-p + (expand-file-name + (package--description-file subdir) + subdir)))) + (throw 'package-dir-found t))))))) + (package-initialize)) + ;; Make sure window system's init file was loaded in loadup.el if ;; using a window system. ;; Initialize the window-system only after processing the command-line @@ -1128,153 +1294,47 @@ command-line ;; the startup screen. (setq inhibit-startup-screen nil) - ;; Warn for invalid user name. - (when init-file-user - (if (string-match "[~/:\n]" init-file-user) - (display-warning 'initialization - (format "Invalid user name %s" - init-file-user) - :error) - (if (file-directory-p (expand-file-name - ;; We don't support ~USER on MS-Windows - ;; and MS-DOS except for the current - ;; user, and always load .emacs from - ;; the current user's home directory - ;; (see below). So always check "~", - ;; even if invoked with "-u USER", or - ;; if $USER or $LOGNAME are set to - ;; something different. - (if (memq system-type '(windows-nt ms-dos)) - "~" - (concat "~" init-file-user)))) - nil - (display-warning 'initialization - (format "User %s has no home directory" - (if (equal init-file-user "") - (user-real-login-name) - init-file-user)) - :error)))) - ;; Load that user's init file, or the default one, or none. - (let (debug-on-error-from-init-file - debug-on-error-should-be-set - (debug-on-error-initial - (if (eq init-file-debug t) 'startup init-file-debug))) - (let ((debug-on-error debug-on-error-initial) - ;; This function actually reads the init files. - (inner - (function - (lambda () - (if init-file-user - (let ((user-init-file-1 - (cond - ((eq system-type 'ms-dos) - (concat "~" init-file-user "/_emacs")) - ((not (eq system-type 'windows-nt)) - (concat "~" init-file-user "/.emacs")) - ;; Else deal with the Windows situation - ((directory-files "~" nil "^\\.emacs\\(\\.elc?\\)?$") - ;; Prefer .emacs on Windows. - "~/.emacs") - ((directory-files "~" nil "^_emacs\\(\\.elc?\\)?$") - ;; Also support _emacs for compatibility, but warn about it. - (push `(initialization - ,(format-message - "`_emacs' init file is deprecated, please use `.emacs'")) - delayed-warnings-list) - "~/_emacs") - (t ;; But default to .emacs if _emacs does not exist. - "~/.emacs")))) - ;; This tells `load' to store the file name found - ;; into user-init-file. - (setq user-init-file t) - (load user-init-file-1 t t) - - (when (eq user-init-file t) - ;; If we did not find ~/.emacs, try - ;; ~/.emacs.d/init.el. - (let ((otherfile - (expand-file-name - "init" - (file-name-as-directory - (concat "~" init-file-user "/.emacs.d"))))) - (load otherfile t t) - - ;; If we did not find the user's init file, - ;; set user-init-file conclusively. - ;; Don't let it be set from default.el. - (when (eq user-init-file t) - (setq user-init-file user-init-file-1)))) - - ;; If we loaded a compiled file, set - ;; `user-init-file' to the source version if that - ;; exists. - (when (and user-init-file - (equal (file-name-extension user-init-file) - "elc")) - (let* ((source (file-name-sans-extension user-init-file)) - (alt (concat source ".el"))) - (setq source (cond ((file-exists-p alt) alt) - ((file-exists-p source) source) - (t nil))) - (when source - (when (file-newer-than-file-p source user-init-file) - (message "Warning: %s is newer than %s" - source user-init-file) - (sit-for 1)) - (setq user-init-file source)))) - - (unless inhibit-default-init - (let ((inhibit-startup-screen nil)) - ;; Users are supposed to be told their rights. - ;; (Plus how to get help and how to undo.) - ;; Don't you dare turn this off for anyone - ;; except yourself. - (load "default" t t))))))))) - (if init-file-debug - ;; Do this without a condition-case if the user wants to debug. - (funcall inner) - (condition-case error - (progn - (funcall inner) - (setq init-file-had-error nil)) - (error - (display-warning - 'initialization - (format-message "\ -An error occurred while loading `%s':\n\n%s%s%s\n\n\ -To ensure normal operation, you should investigate and remove the -cause of the error in your initialization file. Start Emacs with -the `--debug-init' option to view a complete error backtrace." - user-init-file - (get (car error) 'error-message) - (if (cdr error) ": " "") - (mapconcat (lambda (s) (prin1-to-string s t)) - (cdr error) ", ")) - :warning) - (setq init-file-had-error t)))) - - (if (and deactivate-mark transient-mark-mode) - (with-current-buffer (window-buffer) - (deactivate-mark))) - - ;; If the user has a file of abbrevs, read it (unless -batch). - (when (and (not noninteractive) - (file-exists-p abbrev-file-name) - (file-readable-p abbrev-file-name)) - (quietly-read-abbrev-file abbrev-file-name)) - - ;; If the abbrevs came entirely from the init file or the - ;; abbrevs file, they do not need saving. - (setq abbrevs-changed nil) - - ;; If we can tell that the init file altered debug-on-error, - ;; arrange to preserve the value that it set up. - (or (eq debug-on-error debug-on-error-initial) - (setq debug-on-error-should-be-set t - debug-on-error-from-init-file debug-on-error))) - (if debug-on-error-should-be-set - (setq debug-on-error debug-on-error-from-init-file))) + (load-user-init-file + (lambda () + (cond + ((eq system-type 'ms-dos) + (concat "~" init-file-user "/_emacs")) + ((not (eq system-type 'windows-nt)) + (concat "~" init-file-user "/.emacs")) + ;; Else deal with the Windows situation. + ((directory-files "~" nil "^\\.emacs\\(\\.elc?\\)?$") + ;; Prefer .emacs on Windows. + "~/.emacs") + ((directory-files "~" nil "^_emacs\\(\\.elc?\\)?$") + ;; Also support _emacs for compatibility, but warn about it. + (push `(initialization + ,(format-message + "`_emacs' init file is deprecated, please use `.emacs'")) + delayed-warnings-list) + "~/_emacs") + (t ;; But default to .emacs if _emacs does not exist. + "~/.emacs"))) + (lambda () + (expand-file-name + "init" + (file-name-as-directory + (concat "~" init-file-user "/.emacs.d")))) + (not inhibit-default-init)) + + (when (and deactivate-mark transient-mark-mode) + (with-current-buffer (window-buffer) + (deactivate-mark))) + + ;; If the user has a file of abbrevs, read it (unless -batch). + (when (and (not noninteractive) + (file-exists-p abbrev-file-name) + (file-readable-p abbrev-file-name)) + (quietly-read-abbrev-file abbrev-file-name)) + + ;; If the abbrevs came entirely from the init file or the + ;; abbrevs file, they do not need saving. + (setq abbrevs-changed nil) ;; Do this here in case the init file sets mail-host-address. (and mail-host-address @@ -1296,33 +1356,6 @@ command-line (eq face-ignored-fonts old-face-ignored-fonts)) (clear-face-cache))) - ;; If any package directory exists, initialize the package system. - (and user-init-file - package-enable-at-startup - (catch 'package-dir-found - (let (dirs) - (if (boundp 'package-directory-list) - (setq dirs package-directory-list) - (dolist (f load-path) - (and (stringp f) - (equal (file-name-nondirectory f) "site-lisp") - (push (expand-file-name "elpa" f) dirs)))) - (push (if (boundp 'package-user-dir) - package-user-dir - (locate-user-emacs-file "elpa")) - dirs) - (dolist (dir dirs) - (when (file-directory-p dir) - (dolist (subdir (directory-files dir)) - (when (let ((subdir (expand-file-name subdir dir))) - (and (file-directory-p subdir) - (file-exists-p - (expand-file-name - (package--description-file subdir) - subdir)))) - (throw 'package-dir-found t))))))) - (package-initialize)) - (setq after-init-time (current-time)) ;; Display any accumulated warnings after all functions in ;; `after-init-hook' like `desktop-read' have finalized possible diff --git a/src/lread.c b/src/lread.c index 28d4bf9a4f..0f674803f2 100644 --- a/src/lread.c +++ b/src/lread.c @@ -4897,7 +4897,7 @@ directory. These file names are converted to absolute at startup. */); If the file loaded had extension `.elc', and the corresponding source file exists, this variable contains the name of source file, suitable for use by functions like `custom-save-all' which edit the init file. -While Emacs loads and evaluates the init file, value is the real name +While Emacs loads and evaluates any init file, value is the real name of the file, regardless of whether or not it has the `.elc' extension. */); Vuser_init_file = Qnil; -- 2.16.1 ^ permalink raw reply related [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-01-28 19:42 ` Radon Rosborough @ 2018-01-30 15:02 ` Stefan Monnier 2018-01-30 15:44 ` Eli Zaretskii 2018-01-30 19:30 ` Radon Rosborough 2018-02-10 11:56 ` Eli Zaretskii 1 sibling, 2 replies; 838+ messages in thread From: Stefan Monnier @ 2018-01-30 15:02 UTC (permalink / raw) To: emacs-devel > I've fixed all the problems noted by Stefan and Clément, and rebased > onto the latest master. The revised patch is attached. LGTM Do you have write access or do you need someone to push this for you? Eli&John, any objection to installing this into master? Stefan PS: In the mean time, some more comments to keep us busy: > * lisp/startup.el (early-init-file): New variable, for the filename of > the early init file after it has been loaded. "New variable" is enough, the rest is described in the code already. > (load-user-init-file): New function, used to eliminate duplicate code > in loading the early and regular init files. Same here. Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-01-30 15:02 ` Stefan Monnier @ 2018-01-30 15:44 ` Eli Zaretskii 2018-02-01 3:12 ` Mark Oteiza 2018-02-08 5:54 ` Radon Rosborough 2018-01-30 19:30 ` Radon Rosborough 1 sibling, 2 replies; 838+ messages in thread From: Eli Zaretskii @ 2018-01-30 15:44 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel > From: Stefan Monnier <monnier@iro.umontreal.ca> > Date: Tue, 30 Jan 2018 10:02:53 -0500 > > > I've fixed all the problems noted by Stefan and Clément, and rebased > > onto the latest master. The revised patch is attached. > > LGTM > Do you have write access or do you need someone to push this for you? > Eli&John, any objection to installing this into master? I didn't yet have time to read the patch, will do in the following days, and get back. I don't expect to object, but I might have some comments. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-01-30 15:44 ` Eli Zaretskii @ 2018-02-01 3:12 ` Mark Oteiza 2018-02-01 4:22 ` Radon Rosborough 2018-02-08 5:54 ` Radon Rosborough 1 sibling, 1 reply; 838+ messages in thread From: Mark Oteiza @ 2018-02-01 3:12 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Stefan Monnier, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: Stefan Monnier <monnier@iro.umontreal.ca> >> Date: Tue, 30 Jan 2018 10:02:53 -0500 >> >> > I've fixed all the problems noted by Stefan and Clément, and rebased >> > onto the latest master. The revised patch is attached. >> >> LGTM >> Do you have write access or do you need someone to push this for you? >> Eli&John, any objection to installing this into master? > > I didn't yet have time to read the patch, will do in the following > days, and get back. I don't expect to object, but I might have some > comments. ISTR there being no answer to the question posed here https://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00994.html except for a workaround suggested by Stefan to set package-user-dir, which implies that we have to run package-initialize twice. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-02-01 3:12 ` Mark Oteiza @ 2018-02-01 4:22 ` Radon Rosborough 2018-02-01 13:36 ` Stefan Monnier 0 siblings, 1 reply; 838+ messages in thread From: Radon Rosborough @ 2018-02-01 4:22 UTC (permalink / raw) To: Mark Oteiza; +Cc: Eli Zaretskii, Stefan Monnier, emacs-devel [-- Attachment #1: Type: text/plain, Size: 920 bytes --] > ISTR there being no answer to the question posed here > https://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00994.html > except for a workaround suggested by Stefan to set package-user-dir, > which implies that we have to run package-initialize twice. Sorry, could you elaborate on what the problem is? As it is I don't see any problem: most configurations will work with no changes, and advanced configurations will require only trivial changes (namely moving a few 'setq' forms from init.el into early-init.el). People whose configurations are advanced enough to set `package-load-list' and `package-user-dir' will find this change trivial to make. There's certainly no running of `package-initialize' twice in the proposed patch. `package-initialize' is run between early-init.el and init.el, just once. (But this can be suppressed by setting `package-enable-at-startup' to nil in early-init.el.) -- Radon [-- Attachment #2: Type: text/html, Size: 2024 bytes --] ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-02-01 4:22 ` Radon Rosborough @ 2018-02-01 13:36 ` Stefan Monnier 2018-02-18 5:40 ` Stefan Monnier 0 siblings, 1 reply; 838+ messages in thread From: Stefan Monnier @ 2018-02-01 13:36 UTC (permalink / raw) To: Radon Rosborough; +Cc: Mark Oteiza, Eli Zaretskii, emacs-devel > forms from init.el into early-init.el). People whose configurations are > advanced enough to set `package-load-list' and `package-user-dir' will find > this change trivial to make. FWIW, I do set package-user-dir in my config, and I resolve the problem by moving my whole config from .emacs.d/init.el to .emacs.d/early-init.el. This comes with a few constraints, but these already existed for users of --daemon. Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-02-01 13:36 ` Stefan Monnier @ 2018-02-18 5:40 ` Stefan Monnier 0 siblings, 0 replies; 838+ messages in thread From: Stefan Monnier @ 2018-02-18 5:40 UTC (permalink / raw) To: emacs-devel >> forms from init.el into early-init.el). People whose configurations are >> advanced enough to set `package-load-list' and `package-user-dir' will find >> this change trivial to make. > FWIW, I do set package-user-dir in my config, and I resolve the problem > by moving my whole config from .emacs.d/init.el to > .emacs.d/early-init.el. Another option is to use my package-quickstart thingy: it uses package-load-list and package-user-dir to build one big autoloads file which not only can be quickly loaded by Emacs at startup but it can do so before package-load-list and package-user-dir have been set! Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-01-30 15:44 ` Eli Zaretskii 2018-02-01 3:12 ` Mark Oteiza @ 2018-02-08 5:54 ` Radon Rosborough 2018-02-08 15:27 ` Eli Zaretskii 1 sibling, 1 reply; 838+ messages in thread From: Radon Rosborough @ 2018-02-08 5:54 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Stefan Monnier, emacs-devel > I didn't yet have time to read the patch, will do in the following > days, and get back. I don't expect to object, but I might have some > comments. Have you had the chance to take a look yet? Thanks, -- Radon ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-02-08 5:54 ` Radon Rosborough @ 2018-02-08 15:27 ` Eli Zaretskii 0 siblings, 0 replies; 838+ messages in thread From: Eli Zaretskii @ 2018-02-08 15:27 UTC (permalink / raw) To: Radon Rosborough; +Cc: monnier, emacs-devel > From: Radon Rosborough <radon.neon@gmail.com> > Date: Wed, 7 Feb 2018 21:54:54 -0800 > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel <emacs-devel@gnu.org> > > > I didn't yet have time to read the patch, will do in the following > > days, and get back. I don't expect to object, but I might have some > > comments. > > Have you had the chance to take a look yet? Not yet, sorry. I hope to find time for that during the next few days. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-01-30 15:02 ` Stefan Monnier 2018-01-30 15:44 ` Eli Zaretskii @ 2018-01-30 19:30 ` Radon Rosborough 1 sibling, 0 replies; 838+ messages in thread From: Radon Rosborough @ 2018-01-30 19:30 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel [-- Attachment #1.1: Type: text/plain, Size: 442 bytes --] > Do you have write access or do you need someone to push this for you? The latter. > > * lisp/startup.el (early-init-file): New variable, for the filename of > > the early init file after it has been loaded. > > "New variable" is enough, the rest is described in the code already. > > > (load-user-init-file): New function, used to eliminate duplicate code > > in loading the early and regular init files. > > Same here. Fixed. -- Radon [-- Attachment #1.2: Type: text/html, Size: 1228 bytes --] [-- Attachment #2: 0001-Add-early-init-file-stop-package-initialize-insertio.patch --] [-- Type: application/octet-stream, Size: 31531 bytes --] From dfe5ebd007c2fdab8b6e7d72891ef3acf3f31df6 Mon Sep 17 00:00:00 2001 From: Radon Rosborough <radon.neon@gmail.com> Date: Sun, 17 Dec 2017 17:31:17 -0700 Subject: [PATCH] Add early init file, stop package-initialize insertion * lisp/startup.el (early-init-file): New variable. (load-user-init-file): New function. (command-line): Load the early init file using `load-user-init-file'. Move the check for an invalid username to just before that, and move the initialization of the package system to just after. Load the regular init file using `load-user-init-file'. * src/lread.c (Vuser_init_file): Note change in semantics due to its usage while loading the early init file. * lisp/emacs-lisp/package.el (package--ensure-init-file): Remove definition, usage, and documentation. (package--init-file-ensured): Remove definition and usage. * doc/lispref/os.texi: Document early init file. * doc/lispref/package.texi: Document changes to when package-initialize is called, and advise against calling it in the init file. * doc/emacs/package.texi: Document changes to when package-initialize is called. * doc/misc/org.texi: Don't recommend to call package-initialize in the init file. Discussion on emacs-devel leading up to this change (approximately 150 messages): - https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00154.html - https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00433.html - https://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00023.html - https://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00599.html - https://lists.gnu.org/archive/html/emacs-devel/2017-10/msg00332.html --- doc/emacs/package.texi | 31 ++-- doc/lispref/os.texi | 14 ++ doc/lispref/package.texi | 16 +- doc/misc/org.texi | 4 +- etc/NEWS | 20 +++ lisp/emacs-lisp/package.el | 71 +-------- lisp/startup.el | 379 ++++++++++++++++++++++++--------------------- src/lread.c | 2 +- 8 files changed, 264 insertions(+), 273 deletions(-) diff --git a/doc/emacs/package.texi b/doc/emacs/package.texi index 5f05bc0f9e..9629f41c80 100644 --- a/doc/emacs/package.texi +++ b/doc/emacs/package.texi @@ -250,31 +250,18 @@ Package Installation wide-ranging effects on the Emacs session. For such information, consult the package's help buffer. - By default, Emacs also automatically loads all installed packages in -subsequent Emacs sessions. This happens at startup, after processing -the init file (@pxref{Init File}). As an exception, Emacs does not -load packages at startup if invoked with the @samp{-q} or -@samp{--no-init-file} options (@pxref{Initial Options}). + After a package is installed, it is automatically loaded by Emacs in +all subsequent sessions. This happens at startup, before processing +the init file but after processing the early init file (@pxref{Early +Init File,,, elisp, The Emacs Lisp Reference Manual}). As an +exception, Emacs does not load packages at startup if invoked with the +@samp{-q} or @samp{--no-init-file} options (@xref{Initial Options}). @vindex package-enable-at-startup To disable automatic package loading, change the variable -@code{package-enable-at-startup} to @code{nil}. - -@findex package-initialize - The reason automatic package loading occurs after loading the init -file is that user options only receive their customized values after -loading the init file, including user options which affect the -packaging system. In some circumstances, you may want to load -packages explicitly in your init file (usually because some other code -in your init file depends on a package). In that case, your init file -should call the function @code{package-initialize}. It is up to you -to ensure that relevant user options, such as @code{package-load-list} -(see below), are set up prior to the @code{package-initialize} call. -This will automatically set @code{package-enable-at-startup} to @code{nil}, to -avoid loading the packages again after processing the init file. -Alternatively, you may choose to completely inhibit package loading at -startup, and invoke the command @kbd{M-x package-initialize} to load -your packages manually. +@code{package-enable-at-startup} to @code{nil}. You must do this in +the early init file, as the variable is read before loading the +regular init file. Currently it cannot be done via Customize. @vindex package-load-list For finer control over package loading, you can use the variable diff --git a/doc/lispref/os.texi b/doc/lispref/os.texi index 9352a929a7..c76c4d80b6 100644 --- a/doc/lispref/os.texi +++ b/doc/lispref/os.texi @@ -361,6 +361,7 @@ Init File @cindex init file @cindex @file{.emacs} @cindex @file{init.el} +@cindex @file{early-init.el} When you start Emacs, it normally attempts to load your @dfn{init file}. This is either a file named @file{.emacs} or @file{.emacs.el} @@ -384,6 +385,19 @@ Init File file. If those environment variables are absent, though, Emacs uses your user-id to find your home directory. +@cindex early init file + Emacs also attempts to load a second init file, called the + @dfn{early init file}, if it exists. This is a file named + @file{early-init.el} in a subdirectory named @file{.emacs.d} in your + home directory. The difference is that the early init file is + loaded much earlier during the startup process, so you can use it to + customize some things that are initialized before loading the + regular init file. For example, you can customize the process of + loading installed packages, by setting variables such as + @var{package-load-list} or + @var{package-enable-at-startup}. @xref{Package Installation,,, + emacs,The GNU Emacs Manual}. + @cindex default init file An Emacs installation may have a @dfn{default init file}, which is a Lisp library named @file{default.el}. Emacs finds this file through diff --git a/doc/lispref/package.texi b/doc/lispref/package.texi index 21dfe1c271..d5ee4cbd47 100644 --- a/doc/lispref/package.texi +++ b/doc/lispref/package.texi @@ -106,10 +106,12 @@ Packaging Basics Whenever Emacs starts up, it automatically calls the function @code{package-initialize} to load installed packages. This is done -after loading the init file and abbrev file (if any) and before -running @code{after-init-hook} (@pxref{Startup Summary}). Automatic -package loading is disabled if the user option -@code{package-enable-at-startup} is @code{nil}. +after loading the early init file, but before loading the regular init +file and abbrev file (if any) and before running +@code{after-init-hook} (@pxref{Startup Summary}). Automatic package +loading is disabled if the user option +@code{package-enable-at-startup} is set to @code{nil} in the early +init file. @deffn Command package-initialize &optional no-activate This function initializes Emacs' internal record of which packages are @@ -123,6 +125,12 @@ Packaging Basics The optional argument @var{no-activate}, if non-@code{nil}, causes Emacs to update its record of installed packages without actually loading them; it is for internal use only. + +In most cases, you should not need to call @code{package-initialize}, +as this is done automatically during startup. Simply make sure to put +any code that should run before @code{package-initialize} in the early +init file, and any code that should run after it in the primary init +file (@xref{Init File,,, emacs, The GNU Emacs Manual}). @end deffn @node Simple Packages diff --git a/doc/misc/org.texi b/doc/misc/org.texi index aa3b029ab7..68aa01ca18 100644 --- a/doc/misc/org.texi +++ b/doc/misc/org.texi @@ -890,9 +890,7 @@ Installation been visited, i.e., where no Org built-in function have been loaded. Otherwise autoload Org functions will mess up the installation. -Then, to make sure your Org configuration is taken into account, initialize -the package system with @code{(package-initialize)} in your Emacs init file -before setting any Org option. If you want to use Org's package repository, +If you want to use Org's package repository, check out the @uref{http://orgmode.org/elpa.html, Org ELPA page}. @subsubheading Downloading Org as an archive diff --git a/etc/NEWS b/etc/NEWS index b28f284116..a440c187c4 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -49,6 +49,26 @@ to reduce differences between developer and production builds. \f * Startup Changes in Emacs 27.1 ++++ +** Emacs can now be configured using an early init file. +The file is called 'early-init.el', in 'user-emacs-directory'. It is +loaded very early in the startup process: before graphical elements +such as the tool bar are initialized, and before the package manager +is initialized. + ++++ +** Emacs now calls 'package-initialize' before loading the init file. +This is part of a change intended to eliminate the behavior of +package.el inserting a call to 'package-initialize' into the init +file, which was previously done when Emacs was started. You only need +to make changes to your configuration if some of it needs to be run +before 'package-initialize' is called (for example, if you set +'package-load-list' or 'package-user-dir'). In that case, place the +configuration that needs to be run before 'package-initialize' into +the early init file. Note that variables like 'package-archives' can +be set after 'package-initialize', so they can still be customized in +the regular init file. + \f * Changes in Emacs 27.1 diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el index 71d1c41ec3..ab02d4255b 100644 --- a/lisp/emacs-lisp/package.el +++ b/lisp/emacs-lisp/package.el @@ -1431,16 +1431,11 @@ package-read-all-archive-contents ;; available on disk. (defvar package--initialized nil) -(defvar package--init-file-ensured nil - "Whether we know the init file has package-initialize.") - ;;;###autoload (defun package-initialize (&optional no-activate) "Load Emacs Lisp packages, and activate them. The variable `package-load-list' controls which packages to load. If optional arg NO-ACTIVATE is non-nil, don't activate packages. -If `user-init-file' does not mention `(package-initialize)', add -it to the file. If called as part of loading `user-init-file', set `package-enable-at-startup' to nil, to prevent accidentally loading packages twice. @@ -1449,13 +1444,7 @@ package-initialize taken care of by `package-initialize'." (interactive) (setq package-alist nil) - (if after-init-time - (package--ensure-init-file) - ;; If `package-initialize' is before we finished loading the init - ;; file, it's obvious we don't need to ensure-init. - (setq package--init-file-ensured t - ;; And likely we don't need to run it again after init. - package-enable-at-startup nil)) + (setq package-enable-at-startup nil) (package-load-all-descriptors) (package-read-all-archive-contents) (unless no-activate @@ -1872,64 +1861,6 @@ package-download-transaction using `package-compute-transaction'." (mapc #'package-install-from-archive packages)) -(defun package--ensure-init-file () - "Ensure that the user's init file has `package-initialize'. -`package-initialize' doesn't have to be called, as long as it is -present somewhere in the file, even as a comment. If it is not, -add a call to it along with some explanatory comments." - ;; Don't mess with the init-file from "emacs -Q". - (when (and (stringp user-init-file) - (not package--init-file-ensured) - (file-readable-p user-init-file) - (file-writable-p user-init-file)) - (let* ((buffer (find-buffer-visiting user-init-file)) - buffer-name - (contains-init - (if buffer - (with-current-buffer buffer - (save-excursion - (save-restriction - (widen) - (goto-char (point-min)) - (re-search-forward "(package-initialize\\_>" nil 'noerror)))) - ;; Don't visit the file if we don't have to. - (with-temp-buffer - (insert-file-contents user-init-file) - (goto-char (point-min)) - (re-search-forward "(package-initialize\\_>" nil 'noerror))))) - (unless contains-init - (with-current-buffer (or buffer - (let ((delay-mode-hooks t) - (find-file-visit-truename t)) - (find-file-noselect user-init-file))) - (when buffer - (setq buffer-name (buffer-file-name)) - (set-visited-file-name (file-chase-links user-init-file))) - (save-excursion - (save-restriction - (widen) - (goto-char (point-min)) - (while (and (looking-at-p "[[:blank:]]*\\(;\\|$\\)") - (not (eobp))) - (forward-line 1)) - (insert - "\n" - ";; Added by Package.el. This must come before configurations of\n" - ";; installed packages. Don't delete this line. If you don't want it,\n" - ";; just comment it out by adding a semicolon to the start of the line.\n" - ";; You may delete these explanatory comments.\n" - "(package-initialize)\n") - (unless (looking-at-p "$") - (insert "\n")) - (let ((file-precious-flag t)) - (save-buffer)) - (if buffer - (progn - (set-visited-file-name buffer-name) - (set-buffer-modified-p nil)) - (kill-buffer (current-buffer))))))))) - (setq package--init-file-ensured t)) - ;;;###autoload (defun package-install (pkg &optional dont-select) "Install the package PKG. diff --git a/lisp/startup.el b/lisp/startup.el index 8c36c19e82..69bc8fa781 100644 --- a/lisp/startup.el +++ b/lisp/startup.el @@ -312,6 +312,12 @@ inhibit-startup-hooks Currently this applies to: `emacs-startup-hook', `term-setup-hook', and `window-setup-hook'.") +(defvar early-init-file nil + "File name, including directory, of user's early init file. +See `user-init-file'. The only difference is that +`early-init-file' is not set during the course of evaluating the +early init file.") + (defvar keyboard-type nil "The brand of keyboard you are using. This variable is used to define the proper function and keypad @@ -870,6 +876,103 @@ startup--setup-quote-display (when standard-display-table (aset standard-display-table char nil))))))) +(defun load-user-init-file + (filename-function &optional alternate-filename-function load-defaults) + "Load a user init-file. +FILENAME-FUNCTION is called with no arguments and should return +the name of the init-file to load. If this file cannot be +loaded, and ALTERNATE-FILENAME-FUNCTION is non-nil, then it is +called with no arguments and should return the name of an +alternate init-file to load. If LOAD-DEFAULTS is non-nil, then +load default.el after the init-file. + +This function sets `user-init-file' to the name of the loaded +init-file, or to a default value if loading is not possible." + (let ((debug-on-error-from-init-file nil) + (debug-on-error-should-be-set nil) + (debug-on-error-initial + (if (eq init-file-debug t) + 'startup + init-file-debug))) + (let ((debug-on-error debug-on-error-initial) + ;; We create an anonymous function here so that we can call + ;; it in different contexts depending on the value of + ;; `debug-on-error'. + (read-init-file + (lambda () + (when init-file-user + (let ((init-file-name (funcall filename-function))) + + ;; If `user-init-file' is t, then `load' will store + ;; the name of the file that it loads into + ;; `user-init-file'. + (setq user-init-file t) + (load init-file-name 'noerror 'nomessage) + + (when (and (eq user-init-file t) alternate-filename-function) + (load (funcall alternate-filename-function) + 'noerror 'nomessage)) + + ;; If we did not find the user's init file, set + ;; user-init-file conclusively. Don't let it be + ;; set from default.el. + (when (eq user-init-file t) + (setq user-init-file init-file-name))) + + ;; If we loaded a compiled file, set `user-init-file' to + ;; the source version if that exists. + (when (equal (file-name-extension user-init-file) + "elc") + (let* ((source (file-name-sans-extension user-init-file)) + (alt (concat source ".el"))) + (setq source (cond ((file-exists-p alt) alt) + ((file-exists-p source) source) + (t nil))) + (when source + (when (file-newer-than-file-p source user-init-file) + (message "Warning: %s is newer than %s" + source user-init-file) + (sit-for 1)) + (setq user-init-file source)))) + + (when load-defaults + + ;; Prevent default.el from changing the value of + ;; `inhibit-startup-screen'. + (let ((inhibit-startup-screen nil)) + (load "default" 'noerror 'nomessage))))))) + ;; Now call our anonymous function. + (if init-file-debug + ;; Do this without a `condition-case' if the user wants to + ;; debug. + (funcall read-init-file) + (condition-case error + (funcall read-init-file) + (error + (display-warning + 'initialization + (format-message "\ +An error occurred while loading `%s':\n\n%s%s%s\n\n\ +To ensure normal operation, you should investigate and remove the +cause of the error in your initialization file. Start Emacs with +the `--debug-init' option to view a complete error backtrace." + user-init-file + (get (car error) 'error-message) + (if (cdr error) ": " "") + (mapconcat (lambda (s) (prin1-to-string s t)) + (cdr error) ", ")) + :warning) + (setq init-file-had-error t)))) + + ;; If we can tell that the init file altered debug-on-error, + ;; arrange to preserve the value that it set up. + (or (eq debug-on-error debug-on-error-initial) + (setq debug-on-error-should-be-set t + debug-on-error-from-init-file debug-on-error))) + + (when debug-on-error-should-be-set + (setq debug-on-error debug-on-error-from-init-file)))) + (defun command-line () "A subroutine of `normal-top-level'. Amongst another things, it parses the command-line arguments." @@ -1021,6 +1124,69 @@ command-line (and command-line-args (setcdr command-line-args args))) + ;; Warn for invalid user name. + (when init-file-user + (if (string-match "[~/:\n]" init-file-user) + (display-warning 'initialization + (format "Invalid user name %s" + init-file-user) + :error) + (if (file-directory-p (expand-file-name + ;; We don't support ~USER on MS-Windows + ;; and MS-DOS except for the current + ;; user, and always load .emacs from + ;; the current user's home directory + ;; (see below). So always check "~", + ;; even if invoked with "-u USER", or + ;; if $USER or $LOGNAME are set to + ;; something different. + (if (memq system-type '(windows-nt ms-dos)) + "~" + (concat "~" init-file-user)))) + nil + (display-warning 'initialization + (format "User %s has no home directory" + (if (equal init-file-user "") + (user-real-login-name) + init-file-user)) + :error)))) + + ;; Load the early init file, if found. + (load-user-init-file + (lambda () + (expand-file-name + "early-init" + (file-name-as-directory + (concat "~" init-file-user "/.emacs.d"))))) + (setq early-init-file user-init-file) + + ;; If any package directory exists, initialize the package system. + (and user-init-file + package-enable-at-startup + (catch 'package-dir-found + (let (dirs) + (if (boundp 'package-directory-list) + (setq dirs package-directory-list) + (dolist (f load-path) + (and (stringp f) + (equal (file-name-nondirectory f) "site-lisp") + (push (expand-file-name "elpa" f) dirs)))) + (push (if (boundp 'package-user-dir) + package-user-dir + (locate-user-emacs-file "elpa")) + dirs) + (dolist (dir dirs) + (when (file-directory-p dir) + (dolist (subdir (directory-files dir)) + (when (let ((subdir (expand-file-name subdir dir))) + (and (file-directory-p subdir) + (file-exists-p + (expand-file-name + (package--description-file subdir) + subdir)))) + (throw 'package-dir-found t))))))) + (package-initialize)) + ;; Make sure window system's init file was loaded in loadup.el if ;; using a window system. ;; Initialize the window-system only after processing the command-line @@ -1128,153 +1294,47 @@ command-line ;; the startup screen. (setq inhibit-startup-screen nil) - ;; Warn for invalid user name. - (when init-file-user - (if (string-match "[~/:\n]" init-file-user) - (display-warning 'initialization - (format "Invalid user name %s" - init-file-user) - :error) - (if (file-directory-p (expand-file-name - ;; We don't support ~USER on MS-Windows - ;; and MS-DOS except for the current - ;; user, and always load .emacs from - ;; the current user's home directory - ;; (see below). So always check "~", - ;; even if invoked with "-u USER", or - ;; if $USER or $LOGNAME are set to - ;; something different. - (if (memq system-type '(windows-nt ms-dos)) - "~" - (concat "~" init-file-user)))) - nil - (display-warning 'initialization - (format "User %s has no home directory" - (if (equal init-file-user "") - (user-real-login-name) - init-file-user)) - :error)))) - ;; Load that user's init file, or the default one, or none. - (let (debug-on-error-from-init-file - debug-on-error-should-be-set - (debug-on-error-initial - (if (eq init-file-debug t) 'startup init-file-debug))) - (let ((debug-on-error debug-on-error-initial) - ;; This function actually reads the init files. - (inner - (function - (lambda () - (if init-file-user - (let ((user-init-file-1 - (cond - ((eq system-type 'ms-dos) - (concat "~" init-file-user "/_emacs")) - ((not (eq system-type 'windows-nt)) - (concat "~" init-file-user "/.emacs")) - ;; Else deal with the Windows situation - ((directory-files "~" nil "^\\.emacs\\(\\.elc?\\)?$") - ;; Prefer .emacs on Windows. - "~/.emacs") - ((directory-files "~" nil "^_emacs\\(\\.elc?\\)?$") - ;; Also support _emacs for compatibility, but warn about it. - (push `(initialization - ,(format-message - "`_emacs' init file is deprecated, please use `.emacs'")) - delayed-warnings-list) - "~/_emacs") - (t ;; But default to .emacs if _emacs does not exist. - "~/.emacs")))) - ;; This tells `load' to store the file name found - ;; into user-init-file. - (setq user-init-file t) - (load user-init-file-1 t t) - - (when (eq user-init-file t) - ;; If we did not find ~/.emacs, try - ;; ~/.emacs.d/init.el. - (let ((otherfile - (expand-file-name - "init" - (file-name-as-directory - (concat "~" init-file-user "/.emacs.d"))))) - (load otherfile t t) - - ;; If we did not find the user's init file, - ;; set user-init-file conclusively. - ;; Don't let it be set from default.el. - (when (eq user-init-file t) - (setq user-init-file user-init-file-1)))) - - ;; If we loaded a compiled file, set - ;; `user-init-file' to the source version if that - ;; exists. - (when (and user-init-file - (equal (file-name-extension user-init-file) - "elc")) - (let* ((source (file-name-sans-extension user-init-file)) - (alt (concat source ".el"))) - (setq source (cond ((file-exists-p alt) alt) - ((file-exists-p source) source) - (t nil))) - (when source - (when (file-newer-than-file-p source user-init-file) - (message "Warning: %s is newer than %s" - source user-init-file) - (sit-for 1)) - (setq user-init-file source)))) - - (unless inhibit-default-init - (let ((inhibit-startup-screen nil)) - ;; Users are supposed to be told their rights. - ;; (Plus how to get help and how to undo.) - ;; Don't you dare turn this off for anyone - ;; except yourself. - (load "default" t t))))))))) - (if init-file-debug - ;; Do this without a condition-case if the user wants to debug. - (funcall inner) - (condition-case error - (progn - (funcall inner) - (setq init-file-had-error nil)) - (error - (display-warning - 'initialization - (format-message "\ -An error occurred while loading `%s':\n\n%s%s%s\n\n\ -To ensure normal operation, you should investigate and remove the -cause of the error in your initialization file. Start Emacs with -the `--debug-init' option to view a complete error backtrace." - user-init-file - (get (car error) 'error-message) - (if (cdr error) ": " "") - (mapconcat (lambda (s) (prin1-to-string s t)) - (cdr error) ", ")) - :warning) - (setq init-file-had-error t)))) - - (if (and deactivate-mark transient-mark-mode) - (with-current-buffer (window-buffer) - (deactivate-mark))) - - ;; If the user has a file of abbrevs, read it (unless -batch). - (when (and (not noninteractive) - (file-exists-p abbrev-file-name) - (file-readable-p abbrev-file-name)) - (quietly-read-abbrev-file abbrev-file-name)) - - ;; If the abbrevs came entirely from the init file or the - ;; abbrevs file, they do not need saving. - (setq abbrevs-changed nil) - - ;; If we can tell that the init file altered debug-on-error, - ;; arrange to preserve the value that it set up. - (or (eq debug-on-error debug-on-error-initial) - (setq debug-on-error-should-be-set t - debug-on-error-from-init-file debug-on-error))) - (if debug-on-error-should-be-set - (setq debug-on-error debug-on-error-from-init-file))) + (load-user-init-file + (lambda () + (cond + ((eq system-type 'ms-dos) + (concat "~" init-file-user "/_emacs")) + ((not (eq system-type 'windows-nt)) + (concat "~" init-file-user "/.emacs")) + ;; Else deal with the Windows situation. + ((directory-files "~" nil "^\\.emacs\\(\\.elc?\\)?$") + ;; Prefer .emacs on Windows. + "~/.emacs") + ((directory-files "~" nil "^_emacs\\(\\.elc?\\)?$") + ;; Also support _emacs for compatibility, but warn about it. + (push `(initialization + ,(format-message + "`_emacs' init file is deprecated, please use `.emacs'")) + delayed-warnings-list) + "~/_emacs") + (t ;; But default to .emacs if _emacs does not exist. + "~/.emacs"))) + (lambda () + (expand-file-name + "init" + (file-name-as-directory + (concat "~" init-file-user "/.emacs.d")))) + (not inhibit-default-init)) + + (when (and deactivate-mark transient-mark-mode) + (with-current-buffer (window-buffer) + (deactivate-mark))) + + ;; If the user has a file of abbrevs, read it (unless -batch). + (when (and (not noninteractive) + (file-exists-p abbrev-file-name) + (file-readable-p abbrev-file-name)) + (quietly-read-abbrev-file abbrev-file-name)) + + ;; If the abbrevs came entirely from the init file or the + ;; abbrevs file, they do not need saving. + (setq abbrevs-changed nil) ;; Do this here in case the init file sets mail-host-address. (and mail-host-address @@ -1296,33 +1356,6 @@ command-line (eq face-ignored-fonts old-face-ignored-fonts)) (clear-face-cache))) - ;; If any package directory exists, initialize the package system. - (and user-init-file - package-enable-at-startup - (catch 'package-dir-found - (let (dirs) - (if (boundp 'package-directory-list) - (setq dirs package-directory-list) - (dolist (f load-path) - (and (stringp f) - (equal (file-name-nondirectory f) "site-lisp") - (push (expand-file-name "elpa" f) dirs)))) - (push (if (boundp 'package-user-dir) - package-user-dir - (locate-user-emacs-file "elpa")) - dirs) - (dolist (dir dirs) - (when (file-directory-p dir) - (dolist (subdir (directory-files dir)) - (when (let ((subdir (expand-file-name subdir dir))) - (and (file-directory-p subdir) - (file-exists-p - (expand-file-name - (package--description-file subdir) - subdir)))) - (throw 'package-dir-found t))))))) - (package-initialize)) - (setq after-init-time (current-time)) ;; Display any accumulated warnings after all functions in ;; `after-init-hook' like `desktop-read' have finalized possible diff --git a/src/lread.c b/src/lread.c index 3b0a17c90b..ac1b3da7b7 100644 --- a/src/lread.c +++ b/src/lread.c @@ -4886,7 +4886,7 @@ directory. These file names are converted to absolute at startup. */); If the file loaded had extension `.elc', and the corresponding source file exists, this variable contains the name of source file, suitable for use by functions like `custom-save-all' which edit the init file. -While Emacs loads and evaluates the init file, value is the real name +While Emacs loads and evaluates any init file, value is the real name of the file, regardless of whether or not it has the `.elc' extension. */); Vuser_init_file = Qnil; -- 2.16.1 ^ permalink raw reply related [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-01-28 19:42 ` Radon Rosborough 2018-01-30 15:02 ` Stefan Monnier @ 2018-02-10 11:56 ` Eli Zaretskii 2018-02-10 23:37 ` Stefan Monnier 2018-02-15 4:38 ` Radon Rosborough 1 sibling, 2 replies; 838+ messages in thread From: Eli Zaretskii @ 2018-02-10 11:56 UTC (permalink / raw) To: Radon Rosborough; +Cc: cpitclaudel, monnier, emacs-devel > From: Radon Rosborough <radon.neon@gmail.com> > Date: Sun, 28 Jan 2018 11:42:53 -0800 > Cc: emacs-devel <emacs-devel@gnu.org> > > I've fixed all the problems noted by Stefan and Clément, and rebased > onto the latest master. The revised patch is attached. Thanks, I have a few minor comments below about the documentation parts. > --- a/doc/emacs/package.texi > +++ b/doc/emacs/package.texi > @@ -250,31 +250,18 @@ Package Installation > wide-ranging effects on the Emacs session. For such information, > consult the package's help buffer. > > - By default, Emacs also automatically loads all installed packages in > -subsequent Emacs sessions. This happens at startup, after processing > -the init file (@pxref{Init File}). As an exception, Emacs does not > -load packages at startup if invoked with the @samp{-q} or > -@samp{--no-init-file} options (@pxref{Initial Options}). > + After a package is installed, it is automatically loaded by Emacs in > +all subsequent sessions. Is "automatically loaded" here accurate? Wouldn't it be better to say "it is available in all subsequent sessions, in that its functions and variables will be automatically loaded when needed"? > +the init file but after processing the early init file (@pxref{Early > +Init File,,, elisp, The Emacs Lisp Reference Manual}). As an We cannot document the early init file, which is a user-level feature, only in the ELisp manual. it should be documented in the Emacs user manual, where the "regular" init file is described. > -@findex package-initialize It looks like we are removing the index entry for package-initialize, although it is a command? > +@code{package-enable-at-startup} to @code{nil}. You must do this in > +the early init file, as the variable is read before loading the > +regular init file. There should be a cross-reference here to where the early init file is described. > +@cindex early init file > + Emacs also attempts to load a second init file, called the > + @dfn{early init file}, if it exists. This is a file named There's indentation here which is contrary to how we write stuff in the manual sources. > + @file{early-init.el} in a subdirectory named @file{.emacs.d} in your > + home directory. It's better and shorter to say @file{early-init.el} in your @file{~/.emacs.d} directory Btw, is it only looked up in .emacs.d, or also in the directory where .emacs is searched (which could be just the home directory)? > The difference is that the early init file is ^^^^^^^^^^^^^^^^^ Difference between what and what? > +after loading the early init file, but before loading the regular init > +file and abbrev file (if any) and before running ^ You need a comma here. > +In most cases, you should not need to call @code{package-initialize}, > +as this is done automatically during startup. Simply make sure to put > +any code that should run before @code{package-initialize} in the early > +init file, and any code that should run after it in the primary init > +file (@xref{Init File,,, emacs, The GNU Emacs Manual}). This is for users, so it should be in the user manual, not in ELisp manual. > --- a/doc/misc/org.texi > +++ b/doc/misc/org.texi > @@ -890,9 +890,7 @@ Installation > been visited, i.e., where no Org built-in function have been loaded. > Otherwise autoload Org functions will mess up the installation. > > -Then, to make sure your Org configuration is taken into account, initialize > -the package system with @code{(package-initialize)} in your Emacs init file > -before setting any Org option. If you want to use Org's package repository, > +If you want to use Org's package repository, > check out the @uref{http://orgmode.org/elpa.html, Org ELPA page}. Why was this hunk necessary? > +** Emacs can now be configured using an early init file. > +The file is called 'early-init.el', in 'user-emacs-directory'. It is > +loaded very early in the startup process: before graphical elements > +such as the tool bar are initialized, and before the package manager > +is initialized. Please add here a sentence regarding the purpose of this file (to configure package.el initialization). > +** Emacs now calls 'package-initialize' before loading the init file. > +This is part of a change intended to eliminate the behavior of > +package.el inserting a call to 'package-initialize' into the init > +file, which was previously done when Emacs was started. You only need > +to make changes to your configuration if some of it needs to be run > +before 'package-initialize' is called (for example, if you set > +'package-load-list' or 'package-user-dir'). In that case, place the > +configuration that needs to be run before 'package-initialize' into > +the early init file. Note that variables like 'package-archives' can > +be set after 'package-initialize', so they can still be customized in > +the regular init file. The part starting with "You only need to make changes" sounds unrelated to what precedes it. You should probably insert there something which explains that calling package-initialize before loading the init file eliminates the need for such changes in most cases? ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-02-10 11:56 ` Eli Zaretskii @ 2018-02-10 23:37 ` Stefan Monnier 2018-02-11 3:26 ` Radon Rosborough 2018-02-11 13:31 ` Basil L. Contovounesios 2018-02-15 4:38 ` Radon Rosborough 1 sibling, 2 replies; 838+ messages in thread From: Stefan Monnier @ 2018-02-10 23:37 UTC (permalink / raw) To: emacs-devel >> + After a package is installed, it is automatically loaded by Emacs in >> +all subsequent sessions. > Is "automatically loaded" here accurate? Indeed not. > Wouldn't it be better to say "it is available in all subsequent > sessions, in that its functions and variables will be automatically > loaded when needed"? I use the term "activated" to describe this (what activation does depends on the package). Whether we stick to this word or pick another, I think it's important we pick a word for that and define it in the manual. >> -@findex package-initialize > It looks like we are removing the index entry for package-initialize, > although it is a command? [ ...looking up package-initialize... ] OMG, you're right it's interactive. Does it make sense to use it interactively, really? Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-02-10 23:37 ` Stefan Monnier @ 2018-02-11 3:26 ` Radon Rosborough 2018-02-11 14:45 ` Stefan Monnier 2018-02-11 13:31 ` Basil L. Contovounesios 1 sibling, 1 reply; 838+ messages in thread From: Radon Rosborough @ 2018-02-11 3:26 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel > [ ...looking up package-initialize... ] OMG, you're right > it's interactive. Does it make sense to use it interactively, really? Yes, I've done so dozens of times when I'm testing package.el. The purpose of the command is to activate all installed packages, without doing anything else. And that's what I use it for (as someone who disables `package-enable-at-startup'). ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-02-11 3:26 ` Radon Rosborough @ 2018-02-11 14:45 ` Stefan Monnier 0 siblings, 0 replies; 838+ messages in thread From: Stefan Monnier @ 2018-02-11 14:45 UTC (permalink / raw) To: Radon Rosborough; +Cc: emacs-devel >> [ ...looking up package-initialize... ] OMG, you're right >> it's interactive. Does it make sense to use it interactively, really? > Yes, I've done so dozens of times when I'm testing package.el. I consider that for such purposes `M-: (package-initialize) RET` (or the same done from IELM) is quite sufficient. "Use it interactively" here is meant for "normal users", not for someone hacking on package.el. > The purpose of the command is to activate all installed packages, > without doing anything else. Actually, it has 2 purposes. Activating the packages is only one of the two: in order to speed up startup by caching the autoloads like I do in my package-fastpath patch, we will need to separate those two purposes. Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-02-10 23:37 ` Stefan Monnier 2018-02-11 3:26 ` Radon Rosborough @ 2018-02-11 13:31 ` Basil L. Contovounesios 1 sibling, 0 replies; 838+ messages in thread From: Basil L. Contovounesios @ 2018-02-11 13:31 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: > [ ...looking up package-initialize... ] OMG, you're right > it's interactive. Does it make sense to use it interactively, really? Judging from personal experience, I would guess the main users of its interactivity are those working on or debugging packages following an emacs -Q, which in some work sessions can happen multiple times (until they cop on and try to automate this, that is :). Apart from backward compatibility and M-x p-ini RET being slightly faster than M-: M-( p-ini RET in these cases, I don't think there is much else to be said for it. -- Basil ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-02-10 11:56 ` Eli Zaretskii 2018-02-10 23:37 ` Stefan Monnier @ 2018-02-15 4:38 ` Radon Rosborough 2018-02-15 15:54 ` Drew Adams 2018-02-17 11:38 ` Eli Zaretskii 1 sibling, 2 replies; 838+ messages in thread From: Radon Rosborough @ 2018-02-15 4:38 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Clément Pit-Claudel, Stefan Monnier, emacs-devel [-- Attachment #1.1: Type: text/plain, Size: 1444 bytes --] Unless otherwise noted, I have integrated your comments, Eli. Let me know if more changes are needed before merging. I also noticed that the startup summary was not updated to reflect the early init file and new timing of `package-initialize'. That's fixed now. > Btw, is it only looked up in .emacs.d, or also in the directory where > .emacs is searched (which could be just the home directory)? No, since .emacs is deprecated in favor of ~/.emacs.d/init.el. > This is for users, so it should be in the user manual, not in ELisp > manual. While re-adding the index entry for `package-initialize', I also partially re-added the paragraph on `package-initialize' in the user manual. The user manual now documents `package-initialize' as only something that is useful to call if you set `package-enable-at-startup' to nil, so this paragraph is not really needed in the user manual. I think it is still useful to have it in the Elisp manual, since unlike the user manual, the Elisp manual actually does document `package-initialize' in some detail, so users might be misled into thinking that it is a useful function when in fact they probably should not be using it. > Why was this hunk necessary? Because the description was wrong and needed to be removed. It advised that users call `package-initialize' in their init file, which is wrong advice if `package-initialize' is called automatically before loading the init file. Best, Radon [-- Attachment #1.2: Type: text/html, Size: 3279 bytes --] [-- Attachment #2: 0001-Add-early-init-file-stop-package-initialize-insertio.patch --] [-- Type: application/octet-stream, Size: 38832 bytes --] From aaf0192d3da753df1f5e0dab1907affc719e191c Mon Sep 17 00:00:00 2001 From: Radon Rosborough <radon.neon@gmail.com> Date: Sun, 17 Dec 2017 17:31:17 -0700 Subject: [PATCH] Add early init file, stop package-initialize insertion * lisp/startup.el (early-init-file): New variable. (load-user-init-file): New function. (command-line): Load the early init file using `load-user-init-file'. Move the check for an invalid username to just before that, and move the initialization of the package system to just after. Load the regular init file using `load-user-init-file'. * src/lread.c (Vuser_init_file): Note change in semantics due to its usage while loading the early init file. * lisp/emacs-lisp/package.el (package--ensure-init-file): Remove definition, usage, and documentation. (package--init-file-ensured): Remove definition and usage. * doc/emacs/custom.texi: Document early init file. * doc/lispref/os.texi: Document early init file. Update startup summary. * doc/lispref/package.texi: Document changes to when package-initialize is called, and advise against calling it in the init file. Change terminology for package 'loading'. * doc/emacs/package.texi: Document changes to when package-initialize is called. Change terminology for package 'loading'. * doc/misc/org.texi: Don't recommend to call package-initialize in the init file. Discussion on emacs-devel leading up to this change (approximately 150 messages): - https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00154.html - https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00433.html - https://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00023.html - https://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00599.html - https://lists.gnu.org/archive/html/emacs-devel/2017-10/msg00332.html --- doc/emacs/custom.texi | 17 ++ doc/emacs/package.texi | 78 +++++----- doc/lispref/os.texi | 38 +++-- doc/lispref/package.texi | 30 ++-- doc/misc/org.texi | 4 +- etc/NEWS | 19 +++ lisp/emacs-lisp/package.el | 71 +-------- lisp/startup.el | 379 ++++++++++++++++++++++++--------------------- src/lread.c | 2 +- 9 files changed, 331 insertions(+), 307 deletions(-) diff --git a/doc/emacs/custom.texi b/doc/emacs/custom.texi index e27760b379..263dff7cb0 100644 --- a/doc/emacs/custom.texi +++ b/doc/emacs/custom.texi @@ -2575,3 +2575,20 @@ Init Non-ASCII coding system, for your init file as well as the files you edit. For example, don't mix the @samp{latin-1} and @samp{latin-9} coding systems. + +@node Early Init File +@subsection The Early Init File +@cindex early init file + + Most customizations for Emacs can be put in the normal init file, +@file{.emacs} or @file{~/.emacs.d/init.el}. However, it is sometimes +desirable to have customizations that take effect during Emacs startup +earlier than the normal init file is processed. Such customizations +can be put in the early init file, @file{~/.emacs.d/early-init.el}. +This file is loaded before the package system is initialized, so in it +you can customize variables that affect the initialization process, +such as @code{package-enable-at-startup} and @code{package-load-list}. +@xref{Package Installation}. + + For more information on the early init file, @pxref{Early Init +File,,, elisp, The Emacs Lisp Reference Manual}. diff --git a/doc/emacs/package.texi b/doc/emacs/package.texi index bc6afb7966..d5339e9124 100644 --- a/doc/emacs/package.texi +++ b/doc/emacs/package.texi @@ -241,57 +241,55 @@ Package Installation package is available from a higher-priority archive. (This is controlled by the value of @code{package-menu-hide-low-priority}.) - Once a package is downloaded and installed, it is @dfn{loaded} into -the current Emacs session. Loading a package is not quite the same as -loading a Lisp library (@pxref{Lisp Libraries}); loading a package -adds its directory to @code{load-path} and loads its autoloads. The -effect of a package's autoloads varies from package to package. Most -packages just make some new commands available, while others have more + Once a package is downloaded and installed, it is made available to +the current Emacs session. Making a package available adds its +directory to @code{load-path} and loads its autoloads. The effect of +a package's autoloads varies from package to package. Most packages +just make some new commands available, while others have more wide-ranging effects on the Emacs session. For such information, consult the package's help buffer. - By default, Emacs also automatically loads all installed packages in -subsequent Emacs sessions. This happens at startup, after processing -the init file (@pxref{Init File}). As an exception, Emacs does not -load packages at startup if invoked with the @samp{-q} or -@samp{--no-init-file} options (@pxref{Initial Options}). + After a package is installed, it is automatically made available by +Emacs in all subsequent sessions. This happens at startup, before +processing the init file but after processing the early init file +(@pxref{Early Init File,,, elisp, The Emacs Lisp Reference Manual}). +As an exception, Emacs does not make packages available at startup if +invoked with the @samp{-q} or @samp{--no-init-file} options +(@xref{Initial Options}). @vindex package-enable-at-startup - To disable automatic package loading, change the variable -@code{package-enable-at-startup} to @code{nil}. + To keep Emacs from automatically making packages available at +startup, change the variable @code{package-enable-at-startup} to +@code{nil}. You must do this in the early init file (@pxref{Early +Init File,,, elisp, The Emacs Lisp Reference Manual}), as the variable +is read before loading the regular init file. Currently this variable +cannot be set via Customize. @findex package-initialize - The reason automatic package loading occurs after loading the init -file is that user options only receive their customized values after -loading the init file, including user options which affect the -packaging system. In some circumstances, you may want to load -packages explicitly in your init file (usually because some other code -in your init file depends on a package). In that case, your init file -should call the function @code{package-initialize}. It is up to you -to ensure that relevant user options, such as @code{package-load-list} -(see below), are set up prior to the @code{package-initialize} call. -This will automatically set @code{package-enable-at-startup} to @code{nil}, to -avoid loading the packages again after processing the init file. -Alternatively, you may choose to completely inhibit package loading at -startup, and invoke the command @kbd{M-x package-initialize} to load -your packages manually. + If you have set @code{package-enable-at-startup} to @code{nil}, you +can still make packages available either during or after startup. To +make installed packages available during startup, call the function +@code{package-initialize} in your init file. To make installed +packages available after startup, invoke the command @kbd{M-x +package-initialize}. @vindex package-load-list - For finer control over package loading, you can use the variable -@code{package-load-list}. Its value should be a list. A list element -of the form @code{(@var{name} @var{version})} tells Emacs to load -version @var{version} of the package named @var{name}. Here, -@var{version} should be a version string (corresponding to a specific -version of the package), or @code{t} (which means to load any -installed version), or @code{nil} (which means no version; this -disables the package, preventing it from being loaded). A list -element can also be the symbol @code{all}, which means to load the -latest installed version of any package not named by the other list -elements. The default value is just @code{'(all)}. + For finer control over which packages are made available at startup, +you can use the variable @code{package-load-list}. Its value should +be a list. A list element of the form @code{(@var{name} +@var{version})} tells Emacs to make available version @var{version} of +the package named @var{name}. Here, @var{version} should be a version +string (corresponding to a specific version of the package), or +@code{t} (which means to make available any installed version), or +@code{nil} (which means no version; this disables the package, +preventing it from being made available). A list element can also be +the symbol @code{all}, which means to make available the latest +installed version of any package not named by the other list elements. +The default value is just @code{'(all)}. For example, if you set @code{package-load-list} to @code{'((muse -"3.20") all)}, then Emacs only loads version 3.20 of the @samp{muse} -package, plus any installed version of packages other than +"3.20") all)}, then Emacs only makes available version 3.20 of the +@samp{muse} package, plus any installed version of packages other than @samp{muse}. Any other version of @samp{muse} that happens to be installed will be ignored. The @samp{muse} package will be listed in the package menu with the @samp{held} status. diff --git a/doc/lispref/os.texi b/doc/lispref/os.texi index 42be60449d..cac5bfa067 100644 --- a/doc/lispref/os.texi +++ b/doc/lispref/os.texi @@ -95,6 +95,21 @@ Startup Summary @item It does some basic parsing of the command-line arguments. +@item +It loads your early init file (@pxref{Early Init File}). This is not +done if the options @samp{-q}, @samp{-Q}, or @samp{--batch} were +specified. If the @samp{-u} option was specified, Emacs looks for the +init file in that user's home directory instead. + +@item +It calls the function @code{package-initialize} to activate any +optional Emacs Lisp package that has been installed. @xref{Packaging +Basics}. However, Emacs doesn't initialize packages when +@code{package-enable-at-startup} is @code{nil} or when it's started +with one of the options @samp{-q}, @samp{-Q}, or @samp{--batch}. To +initialize packages in the latter case, @code{package-initialize} +should be called explicitly (e.g., via the @samp{--funcall} option). + @vindex initial-window-system@r{, and startup} @vindex window-system-initialization-alist @item @@ -154,15 +169,6 @@ Startup Summary (@pxref{Abbrev Files, abbrev-file-name}). This is not done if the option @samp{--batch} was specified. -@item -It calls the function @code{package-initialize} to activate any -optional Emacs Lisp package that has been installed. @xref{Packaging -Basics}. However, Emacs doesn't initialize packages when -@code{package-enable-at-startup} is @code{nil} or when it's started -with one of the options @samp{-q}, @samp{-Q}, or @samp{--batch}. To -initialize packages in the latter case, @code{package-initialize} -should be called explicitly (e.g., via the @samp{--funcall} option). - @vindex after-init-time @item It sets the variable @code{after-init-time} to the value of @@ -361,6 +367,7 @@ Init File @cindex init file @cindex @file{.emacs} @cindex @file{init.el} +@cindex @file{early-init.el} When you start Emacs, it normally attempts to load your @dfn{init file}. This is either a file named @file{.emacs} or @file{.emacs.el} @@ -384,6 +391,19 @@ Init File file. If those environment variables are absent, though, Emacs uses your user-id to find your home directory. +@cindex early init file + Emacs also attempts to load a second init file, called the +@dfn{early init file}, if it exists. This is a file named +@file{early-init.el} in your @file{~/.emacs.d} directory. The +difference between the early init file and the regular init file is +that the early init file is loaded much earlier during the startup +process, so you can use it to customize some things that are +initialized before loading the regular init file. For example, you +can customize the process of initializing the package system, by +setting variables such as @var{package-load-list} or +@var{package-enable-at-startup}. @xref{Package Installation,,, +emacs,The GNU Emacs Manual}. + @cindex default init file An Emacs installation may have a @dfn{default init file}, which is a Lisp library named @file{default.el}. Emacs finds this file through diff --git a/doc/lispref/package.texi b/doc/lispref/package.texi index 21dfe1c271..877aaf89a3 100644 --- a/doc/lispref/package.texi +++ b/doc/lispref/package.texi @@ -105,24 +105,32 @@ Packaging Basics evaluates the autoload definitions in @file{@var{name}-autoloads.el}. Whenever Emacs starts up, it automatically calls the function -@code{package-initialize} to load installed packages. This is done -after loading the init file and abbrev file (if any) and before -running @code{after-init-hook} (@pxref{Startup Summary}). Automatic -package loading is disabled if the user option -@code{package-enable-at-startup} is @code{nil}. +@code{package-initialize} to make installed packages available to the +current session. This is done after loading the early init file, but +before loading the regular init file (@pxref{Startup Summary}). +Packages are not automatically made available if the user option +@code{package-enable-at-startup} is set to @code{nil} in the early +init file. @deffn Command package-initialize &optional no-activate This function initializes Emacs' internal record of which packages are -installed, and loads them. The user option @code{package-load-list} -specifies which packages to load; by default, all installed packages -are loaded. If called during startup, this function also sets +installed, and makes the packages available to the current session. +The user option @code{package-load-list} specifies which packages to +make available; by default, all installed packages are made available. +If called during startup, this function also sets @code{package-enable-at-startup} to @code{nil}, to avoid accidentally -loading the packages twice. @xref{Package Installation,,, emacs, The -GNU Emacs Manual}. +evaluating package autoloads more than once. @xref{Package +Installation,,, emacs, The GNU Emacs Manual}. The optional argument @var{no-activate}, if non-@code{nil}, causes Emacs to update its record of installed packages without actually -loading them; it is for internal use only. +making them available; it is for internal use only. + +In most cases, you should not need to call @code{package-initialize}, +as this is done automatically during startup. Simply make sure to put +any code that should run before @code{package-initialize} in the early +init file, and any code that should run after it in the primary init +file (@xref{Init File,,, emacs, The GNU Emacs Manual}). @end deffn @node Simple Packages diff --git a/doc/misc/org.texi b/doc/misc/org.texi index aa3b029ab7..68aa01ca18 100644 --- a/doc/misc/org.texi +++ b/doc/misc/org.texi @@ -890,9 +890,7 @@ Installation been visited, i.e., where no Org built-in function have been loaded. Otherwise autoload Org functions will mess up the installation. -Then, to make sure your Org configuration is taken into account, initialize -the package system with @code{(package-initialize)} in your Emacs init file -before setting any Org option. If you want to use Org's package repository, +If you want to use Org's package repository, check out the @uref{http://orgmode.org/elpa.html, Org ELPA page}. @subsubheading Downloading Org as an archive diff --git a/etc/NEWS b/etc/NEWS index 71569c95ad..b6b884b816 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -49,6 +49,25 @@ to reduce differences between developer and production builds. \f * Startup Changes in Emacs 27.1 ++++ +** Emacs can now be configured using an early init file. +The file is called 'early-init.el', in 'user-emacs-directory'. It is +loaded very early in the startup process: before graphical elements +such as the tool bar are initialized, and before the package manager +is initialized. The primary purpose is to allow customizing how the +package system is initialized given that initialization now happens +before loading the regular init file (see below). + ++++ +** Emacs now calls 'package-initialize' before loading the init file. +This is part of a change intended to eliminate the behavior of +package.el inserting a call to 'package-initialize' into the init +file, which was previously done when Emacs was started. As a result +of this change, it is no longer necessary to call 'package-initialize' +in your init file. However, if your init file changes the values of +'package-load-list' or 'package-user-dir', then that code needs to be +moved to the early init file (see above). + \f * Changes in Emacs 27.1 diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el index 71d1c41ec3..ab02d4255b 100644 --- a/lisp/emacs-lisp/package.el +++ b/lisp/emacs-lisp/package.el @@ -1431,16 +1431,11 @@ package-read-all-archive-contents ;; available on disk. (defvar package--initialized nil) -(defvar package--init-file-ensured nil - "Whether we know the init file has package-initialize.") - ;;;###autoload (defun package-initialize (&optional no-activate) "Load Emacs Lisp packages, and activate them. The variable `package-load-list' controls which packages to load. If optional arg NO-ACTIVATE is non-nil, don't activate packages. -If `user-init-file' does not mention `(package-initialize)', add -it to the file. If called as part of loading `user-init-file', set `package-enable-at-startup' to nil, to prevent accidentally loading packages twice. @@ -1449,13 +1444,7 @@ package-initialize taken care of by `package-initialize'." (interactive) (setq package-alist nil) - (if after-init-time - (package--ensure-init-file) - ;; If `package-initialize' is before we finished loading the init - ;; file, it's obvious we don't need to ensure-init. - (setq package--init-file-ensured t - ;; And likely we don't need to run it again after init. - package-enable-at-startup nil)) + (setq package-enable-at-startup nil) (package-load-all-descriptors) (package-read-all-archive-contents) (unless no-activate @@ -1872,64 +1861,6 @@ package-download-transaction using `package-compute-transaction'." (mapc #'package-install-from-archive packages)) -(defun package--ensure-init-file () - "Ensure that the user's init file has `package-initialize'. -`package-initialize' doesn't have to be called, as long as it is -present somewhere in the file, even as a comment. If it is not, -add a call to it along with some explanatory comments." - ;; Don't mess with the init-file from "emacs -Q". - (when (and (stringp user-init-file) - (not package--init-file-ensured) - (file-readable-p user-init-file) - (file-writable-p user-init-file)) - (let* ((buffer (find-buffer-visiting user-init-file)) - buffer-name - (contains-init - (if buffer - (with-current-buffer buffer - (save-excursion - (save-restriction - (widen) - (goto-char (point-min)) - (re-search-forward "(package-initialize\\_>" nil 'noerror)))) - ;; Don't visit the file if we don't have to. - (with-temp-buffer - (insert-file-contents user-init-file) - (goto-char (point-min)) - (re-search-forward "(package-initialize\\_>" nil 'noerror))))) - (unless contains-init - (with-current-buffer (or buffer - (let ((delay-mode-hooks t) - (find-file-visit-truename t)) - (find-file-noselect user-init-file))) - (when buffer - (setq buffer-name (buffer-file-name)) - (set-visited-file-name (file-chase-links user-init-file))) - (save-excursion - (save-restriction - (widen) - (goto-char (point-min)) - (while (and (looking-at-p "[[:blank:]]*\\(;\\|$\\)") - (not (eobp))) - (forward-line 1)) - (insert - "\n" - ";; Added by Package.el. This must come before configurations of\n" - ";; installed packages. Don't delete this line. If you don't want it,\n" - ";; just comment it out by adding a semicolon to the start of the line.\n" - ";; You may delete these explanatory comments.\n" - "(package-initialize)\n") - (unless (looking-at-p "$") - (insert "\n")) - (let ((file-precious-flag t)) - (save-buffer)) - (if buffer - (progn - (set-visited-file-name buffer-name) - (set-buffer-modified-p nil)) - (kill-buffer (current-buffer))))))))) - (setq package--init-file-ensured t)) - ;;;###autoload (defun package-install (pkg &optional dont-select) "Install the package PKG. diff --git a/lisp/startup.el b/lisp/startup.el index 8c36c19e82..69bc8fa781 100644 --- a/lisp/startup.el +++ b/lisp/startup.el @@ -312,6 +312,12 @@ inhibit-startup-hooks Currently this applies to: `emacs-startup-hook', `term-setup-hook', and `window-setup-hook'.") +(defvar early-init-file nil + "File name, including directory, of user's early init file. +See `user-init-file'. The only difference is that +`early-init-file' is not set during the course of evaluating the +early init file.") + (defvar keyboard-type nil "The brand of keyboard you are using. This variable is used to define the proper function and keypad @@ -870,6 +876,103 @@ startup--setup-quote-display (when standard-display-table (aset standard-display-table char nil))))))) +(defun load-user-init-file + (filename-function &optional alternate-filename-function load-defaults) + "Load a user init-file. +FILENAME-FUNCTION is called with no arguments and should return +the name of the init-file to load. If this file cannot be +loaded, and ALTERNATE-FILENAME-FUNCTION is non-nil, then it is +called with no arguments and should return the name of an +alternate init-file to load. If LOAD-DEFAULTS is non-nil, then +load default.el after the init-file. + +This function sets `user-init-file' to the name of the loaded +init-file, or to a default value if loading is not possible." + (let ((debug-on-error-from-init-file nil) + (debug-on-error-should-be-set nil) + (debug-on-error-initial + (if (eq init-file-debug t) + 'startup + init-file-debug))) + (let ((debug-on-error debug-on-error-initial) + ;; We create an anonymous function here so that we can call + ;; it in different contexts depending on the value of + ;; `debug-on-error'. + (read-init-file + (lambda () + (when init-file-user + (let ((init-file-name (funcall filename-function))) + + ;; If `user-init-file' is t, then `load' will store + ;; the name of the file that it loads into + ;; `user-init-file'. + (setq user-init-file t) + (load init-file-name 'noerror 'nomessage) + + (when (and (eq user-init-file t) alternate-filename-function) + (load (funcall alternate-filename-function) + 'noerror 'nomessage)) + + ;; If we did not find the user's init file, set + ;; user-init-file conclusively. Don't let it be + ;; set from default.el. + (when (eq user-init-file t) + (setq user-init-file init-file-name))) + + ;; If we loaded a compiled file, set `user-init-file' to + ;; the source version if that exists. + (when (equal (file-name-extension user-init-file) + "elc") + (let* ((source (file-name-sans-extension user-init-file)) + (alt (concat source ".el"))) + (setq source (cond ((file-exists-p alt) alt) + ((file-exists-p source) source) + (t nil))) + (when source + (when (file-newer-than-file-p source user-init-file) + (message "Warning: %s is newer than %s" + source user-init-file) + (sit-for 1)) + (setq user-init-file source)))) + + (when load-defaults + + ;; Prevent default.el from changing the value of + ;; `inhibit-startup-screen'. + (let ((inhibit-startup-screen nil)) + (load "default" 'noerror 'nomessage))))))) + ;; Now call our anonymous function. + (if init-file-debug + ;; Do this without a `condition-case' if the user wants to + ;; debug. + (funcall read-init-file) + (condition-case error + (funcall read-init-file) + (error + (display-warning + 'initialization + (format-message "\ +An error occurred while loading `%s':\n\n%s%s%s\n\n\ +To ensure normal operation, you should investigate and remove the +cause of the error in your initialization file. Start Emacs with +the `--debug-init' option to view a complete error backtrace." + user-init-file + (get (car error) 'error-message) + (if (cdr error) ": " "") + (mapconcat (lambda (s) (prin1-to-string s t)) + (cdr error) ", ")) + :warning) + (setq init-file-had-error t)))) + + ;; If we can tell that the init file altered debug-on-error, + ;; arrange to preserve the value that it set up. + (or (eq debug-on-error debug-on-error-initial) + (setq debug-on-error-should-be-set t + debug-on-error-from-init-file debug-on-error))) + + (when debug-on-error-should-be-set + (setq debug-on-error debug-on-error-from-init-file)))) + (defun command-line () "A subroutine of `normal-top-level'. Amongst another things, it parses the command-line arguments." @@ -1021,6 +1124,69 @@ command-line (and command-line-args (setcdr command-line-args args))) + ;; Warn for invalid user name. + (when init-file-user + (if (string-match "[~/:\n]" init-file-user) + (display-warning 'initialization + (format "Invalid user name %s" + init-file-user) + :error) + (if (file-directory-p (expand-file-name + ;; We don't support ~USER on MS-Windows + ;; and MS-DOS except for the current + ;; user, and always load .emacs from + ;; the current user's home directory + ;; (see below). So always check "~", + ;; even if invoked with "-u USER", or + ;; if $USER or $LOGNAME are set to + ;; something different. + (if (memq system-type '(windows-nt ms-dos)) + "~" + (concat "~" init-file-user)))) + nil + (display-warning 'initialization + (format "User %s has no home directory" + (if (equal init-file-user "") + (user-real-login-name) + init-file-user)) + :error)))) + + ;; Load the early init file, if found. + (load-user-init-file + (lambda () + (expand-file-name + "early-init" + (file-name-as-directory + (concat "~" init-file-user "/.emacs.d"))))) + (setq early-init-file user-init-file) + + ;; If any package directory exists, initialize the package system. + (and user-init-file + package-enable-at-startup + (catch 'package-dir-found + (let (dirs) + (if (boundp 'package-directory-list) + (setq dirs package-directory-list) + (dolist (f load-path) + (and (stringp f) + (equal (file-name-nondirectory f) "site-lisp") + (push (expand-file-name "elpa" f) dirs)))) + (push (if (boundp 'package-user-dir) + package-user-dir + (locate-user-emacs-file "elpa")) + dirs) + (dolist (dir dirs) + (when (file-directory-p dir) + (dolist (subdir (directory-files dir)) + (when (let ((subdir (expand-file-name subdir dir))) + (and (file-directory-p subdir) + (file-exists-p + (expand-file-name + (package--description-file subdir) + subdir)))) + (throw 'package-dir-found t))))))) + (package-initialize)) + ;; Make sure window system's init file was loaded in loadup.el if ;; using a window system. ;; Initialize the window-system only after processing the command-line @@ -1128,153 +1294,47 @@ command-line ;; the startup screen. (setq inhibit-startup-screen nil) - ;; Warn for invalid user name. - (when init-file-user - (if (string-match "[~/:\n]" init-file-user) - (display-warning 'initialization - (format "Invalid user name %s" - init-file-user) - :error) - (if (file-directory-p (expand-file-name - ;; We don't support ~USER on MS-Windows - ;; and MS-DOS except for the current - ;; user, and always load .emacs from - ;; the current user's home directory - ;; (see below). So always check "~", - ;; even if invoked with "-u USER", or - ;; if $USER or $LOGNAME are set to - ;; something different. - (if (memq system-type '(windows-nt ms-dos)) - "~" - (concat "~" init-file-user)))) - nil - (display-warning 'initialization - (format "User %s has no home directory" - (if (equal init-file-user "") - (user-real-login-name) - init-file-user)) - :error)))) - ;; Load that user's init file, or the default one, or none. - (let (debug-on-error-from-init-file - debug-on-error-should-be-set - (debug-on-error-initial - (if (eq init-file-debug t) 'startup init-file-debug))) - (let ((debug-on-error debug-on-error-initial) - ;; This function actually reads the init files. - (inner - (function - (lambda () - (if init-file-user - (let ((user-init-file-1 - (cond - ((eq system-type 'ms-dos) - (concat "~" init-file-user "/_emacs")) - ((not (eq system-type 'windows-nt)) - (concat "~" init-file-user "/.emacs")) - ;; Else deal with the Windows situation - ((directory-files "~" nil "^\\.emacs\\(\\.elc?\\)?$") - ;; Prefer .emacs on Windows. - "~/.emacs") - ((directory-files "~" nil "^_emacs\\(\\.elc?\\)?$") - ;; Also support _emacs for compatibility, but warn about it. - (push `(initialization - ,(format-message - "`_emacs' init file is deprecated, please use `.emacs'")) - delayed-warnings-list) - "~/_emacs") - (t ;; But default to .emacs if _emacs does not exist. - "~/.emacs")))) - ;; This tells `load' to store the file name found - ;; into user-init-file. - (setq user-init-file t) - (load user-init-file-1 t t) - - (when (eq user-init-file t) - ;; If we did not find ~/.emacs, try - ;; ~/.emacs.d/init.el. - (let ((otherfile - (expand-file-name - "init" - (file-name-as-directory - (concat "~" init-file-user "/.emacs.d"))))) - (load otherfile t t) - - ;; If we did not find the user's init file, - ;; set user-init-file conclusively. - ;; Don't let it be set from default.el. - (when (eq user-init-file t) - (setq user-init-file user-init-file-1)))) - - ;; If we loaded a compiled file, set - ;; `user-init-file' to the source version if that - ;; exists. - (when (and user-init-file - (equal (file-name-extension user-init-file) - "elc")) - (let* ((source (file-name-sans-extension user-init-file)) - (alt (concat source ".el"))) - (setq source (cond ((file-exists-p alt) alt) - ((file-exists-p source) source) - (t nil))) - (when source - (when (file-newer-than-file-p source user-init-file) - (message "Warning: %s is newer than %s" - source user-init-file) - (sit-for 1)) - (setq user-init-file source)))) - - (unless inhibit-default-init - (let ((inhibit-startup-screen nil)) - ;; Users are supposed to be told their rights. - ;; (Plus how to get help and how to undo.) - ;; Don't you dare turn this off for anyone - ;; except yourself. - (load "default" t t))))))))) - (if init-file-debug - ;; Do this without a condition-case if the user wants to debug. - (funcall inner) - (condition-case error - (progn - (funcall inner) - (setq init-file-had-error nil)) - (error - (display-warning - 'initialization - (format-message "\ -An error occurred while loading `%s':\n\n%s%s%s\n\n\ -To ensure normal operation, you should investigate and remove the -cause of the error in your initialization file. Start Emacs with -the `--debug-init' option to view a complete error backtrace." - user-init-file - (get (car error) 'error-message) - (if (cdr error) ": " "") - (mapconcat (lambda (s) (prin1-to-string s t)) - (cdr error) ", ")) - :warning) - (setq init-file-had-error t)))) - - (if (and deactivate-mark transient-mark-mode) - (with-current-buffer (window-buffer) - (deactivate-mark))) - - ;; If the user has a file of abbrevs, read it (unless -batch). - (when (and (not noninteractive) - (file-exists-p abbrev-file-name) - (file-readable-p abbrev-file-name)) - (quietly-read-abbrev-file abbrev-file-name)) - - ;; If the abbrevs came entirely from the init file or the - ;; abbrevs file, they do not need saving. - (setq abbrevs-changed nil) - - ;; If we can tell that the init file altered debug-on-error, - ;; arrange to preserve the value that it set up. - (or (eq debug-on-error debug-on-error-initial) - (setq debug-on-error-should-be-set t - debug-on-error-from-init-file debug-on-error))) - (if debug-on-error-should-be-set - (setq debug-on-error debug-on-error-from-init-file))) + (load-user-init-file + (lambda () + (cond + ((eq system-type 'ms-dos) + (concat "~" init-file-user "/_emacs")) + ((not (eq system-type 'windows-nt)) + (concat "~" init-file-user "/.emacs")) + ;; Else deal with the Windows situation. + ((directory-files "~" nil "^\\.emacs\\(\\.elc?\\)?$") + ;; Prefer .emacs on Windows. + "~/.emacs") + ((directory-files "~" nil "^_emacs\\(\\.elc?\\)?$") + ;; Also support _emacs for compatibility, but warn about it. + (push `(initialization + ,(format-message + "`_emacs' init file is deprecated, please use `.emacs'")) + delayed-warnings-list) + "~/_emacs") + (t ;; But default to .emacs if _emacs does not exist. + "~/.emacs"))) + (lambda () + (expand-file-name + "init" + (file-name-as-directory + (concat "~" init-file-user "/.emacs.d")))) + (not inhibit-default-init)) + + (when (and deactivate-mark transient-mark-mode) + (with-current-buffer (window-buffer) + (deactivate-mark))) + + ;; If the user has a file of abbrevs, read it (unless -batch). + (when (and (not noninteractive) + (file-exists-p abbrev-file-name) + (file-readable-p abbrev-file-name)) + (quietly-read-abbrev-file abbrev-file-name)) + + ;; If the abbrevs came entirely from the init file or the + ;; abbrevs file, they do not need saving. + (setq abbrevs-changed nil) ;; Do this here in case the init file sets mail-host-address. (and mail-host-address @@ -1296,33 +1356,6 @@ command-line (eq face-ignored-fonts old-face-ignored-fonts)) (clear-face-cache))) - ;; If any package directory exists, initialize the package system. - (and user-init-file - package-enable-at-startup - (catch 'package-dir-found - (let (dirs) - (if (boundp 'package-directory-list) - (setq dirs package-directory-list) - (dolist (f load-path) - (and (stringp f) - (equal (file-name-nondirectory f) "site-lisp") - (push (expand-file-name "elpa" f) dirs)))) - (push (if (boundp 'package-user-dir) - package-user-dir - (locate-user-emacs-file "elpa")) - dirs) - (dolist (dir dirs) - (when (file-directory-p dir) - (dolist (subdir (directory-files dir)) - (when (let ((subdir (expand-file-name subdir dir))) - (and (file-directory-p subdir) - (file-exists-p - (expand-file-name - (package--description-file subdir) - subdir)))) - (throw 'package-dir-found t))))))) - (package-initialize)) - (setq after-init-time (current-time)) ;; Display any accumulated warnings after all functions in ;; `after-init-hook' like `desktop-read' have finalized possible diff --git a/src/lread.c b/src/lread.c index 7cacd47d51..d009bd0cd2 100644 --- a/src/lread.c +++ b/src/lread.c @@ -4922,7 +4922,7 @@ directory. These file names are converted to absolute at startup. */); If the file loaded had extension `.elc', and the corresponding source file exists, this variable contains the name of source file, suitable for use by functions like `custom-save-all' which edit the init file. -While Emacs loads and evaluates the init file, value is the real name +While Emacs loads and evaluates any init file, value is the real name of the file, regardless of whether or not it has the `.elc' extension. */); Vuser_init_file = Qnil; -- 2.16.1 ^ permalink raw reply related [flat|nested] 838+ messages in thread
* RE: [PATCH] Fixing package-initialize, adding early init file 2018-02-15 4:38 ` Radon Rosborough @ 2018-02-15 15:54 ` Drew Adams 2018-02-15 16:25 ` Stefan Monnier 2018-02-15 19:32 ` John Wiegley 2018-02-17 11:38 ` Eli Zaretskii 1 sibling, 2 replies; 838+ messages in thread From: Drew Adams @ 2018-02-15 15:54 UTC (permalink / raw) To: Radon Rosborough; +Cc: emacs-devel >> Btw, is it only looked up in .emacs.d, or also in the directory where >> .emacs is searched (which could be just the home directory)? > > No, since .emacs is deprecated in favor of ~/.emacs.d/init.el. Huh? Deprecation does not mean desupport. Emacs still supports ~/.emacs, AFAIK. (And why should ~/.emacs have been deprecated? It's fine to recommend ~/.emacs.d/init.el, of course.) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-02-15 15:54 ` Drew Adams @ 2018-02-15 16:25 ` Stefan Monnier 2018-02-15 19:32 ` John Wiegley 1 sibling, 0 replies; 838+ messages in thread From: Stefan Monnier @ 2018-02-15 16:25 UTC (permalink / raw) To: emacs-devel >>> Btw, is it only looked up in .emacs.d, or also in the directory where >>> .emacs is searched (which could be just the home directory)? >> No, since .emacs is deprecated in favor of ~/.emacs.d/init.el. > Huh? Deprecation does not mean desupport. > Emacs still supports ~/.emacs, AFAIK. He just means that he didn't find it necessary to provide a ~/.<foo> alternative to the ~/.emacs,.d/early-init.el file. FWIW I completely agree that it doesn't seem to be worthwhile to add support for an alternate ~/.<foo> name: it would only make sense to do that in order to provide backward compatibility with a preexisting such ~/.<foo>, but in this case there's no such preexisting file. Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-02-15 15:54 ` Drew Adams 2018-02-15 16:25 ` Stefan Monnier @ 2018-02-15 19:32 ` John Wiegley 2018-02-15 21:13 ` Stefan Monnier 1 sibling, 1 reply; 838+ messages in thread From: John Wiegley @ 2018-02-15 19:32 UTC (permalink / raw) To: Drew Adams; +Cc: Radon Rosborough, emacs-devel >>>>> "DA" == Drew Adams <drew.adams@oracle.com> writes: DA> Huh? Deprecation does not mean desupport. DA> Emacs still supports ~/.emacs, AFAIK. DA> (And why should ~/.emacs have been deprecated? DA> It's fine to recommend ~/.emacs.d/init.el, of course.) I see we have an xdg.el package. Is ~/.config/emacs/init.el a possibility yet? -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-02-15 19:32 ` John Wiegley @ 2018-02-15 21:13 ` Stefan Monnier 2018-02-16 7:00 ` John Wiegley 0 siblings, 1 reply; 838+ messages in thread From: Stefan Monnier @ 2018-02-15 21:13 UTC (permalink / raw) To: emacs-devel > DA> Huh? Deprecation does not mean desupport. > DA> Emacs still supports ~/.emacs, AFAIK. > DA> (And why should ~/.emacs have been deprecated? > DA> It's fine to recommend ~/.emacs.d/init.el, of course.) > I see we have an xdg.el package. Is ~/.config/emacs/init.el a possibility yet? As long as xdg.el is not preloaded in the dumped Emacs, I think not. Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-02-15 21:13 ` Stefan Monnier @ 2018-02-16 7:00 ` John Wiegley 0 siblings, 0 replies; 838+ messages in thread From: John Wiegley @ 2018-02-16 7:00 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel >>>>> "SM" == Stefan Monnier <monnier@iro.umontreal.ca> writes: SM> As long as xdg.el is not preloaded in the dumped Emacs, I think not. Then may I suggest that we... -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-02-15 4:38 ` Radon Rosborough 2018-02-15 15:54 ` Drew Adams @ 2018-02-17 11:38 ` Eli Zaretskii 2018-02-17 14:14 ` Clément Pit-Claudel 2018-02-17 18:17 ` Radon Rosborough 1 sibling, 2 replies; 838+ messages in thread From: Eli Zaretskii @ 2018-02-17 11:38 UTC (permalink / raw) To: Radon Rosborough; +Cc: cpitclaudel, monnier, emacs-devel > From: Radon Rosborough <radon.neon@gmail.com> > Date: Wed, 14 Feb 2018 20:38:14 -0800 > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, > Clément Pit-Claudel <cpitclaudel@gmail.com>, > emacs-devel <emacs-devel@gnu.org> > > Unless otherwise noted, I have integrated your comments, Eli. Let > me know if more changes are needed before merging. Thanks, I pushed this to the master branch. A few minor nits about the docs, for the future: . when you add new nodes to a manual, you need to update higher-level menus accordingly, in the parent section/chapter and in the top-level menu in emacs.texi or elisp.texi . @xref is inappropriate for parenthesized notes; use @pxref instead . there were a couple of places with only one blank between sentences. . long expressions with embedded whitespace should be included in @w{..}, to prevent breaking them between lines, which makes them less readable ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-02-17 11:38 ` Eli Zaretskii @ 2018-02-17 14:14 ` Clément Pit-Claudel 2018-02-17 18:17 ` Radon Rosborough 1 sibling, 0 replies; 838+ messages in thread From: Clément Pit-Claudel @ 2018-02-17 14:14 UTC (permalink / raw) To: Eli Zaretskii, Radon Rosborough; +Cc: monnier, emacs-devel On 2018-02-17 06:38, Eli Zaretskii wrote: > Thanks, I pushed this to the master branch. Radon, congratulations for the awesome work! And thanks Eli (and everyone else) for proofreading and merging. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-02-17 11:38 ` Eli Zaretskii 2018-02-17 14:14 ` Clément Pit-Claudel @ 2018-02-17 18:17 ` Radon Rosborough 2018-02-18 18:26 ` Basil L. Contovounesios 1 sibling, 1 reply; 838+ messages in thread From: Radon Rosborough @ 2018-02-17 18:17 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Clément Pit-Claudel, Stefan Monnier, emacs-devel [-- Attachment #1: Type: text/plain, Size: 219 bytes --] > Thanks, I pushed this to the master branch. [ confetti ] > A few minor nits about the docs, for the future Thanks, this is very helpful. I never did anything with texinfo before this, so good to know. [-- Attachment #2: Type: text/html, Size: 539 bytes --] ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-02-17 18:17 ` Radon Rosborough @ 2018-02-18 18:26 ` Basil L. Contovounesios 2018-02-18 18:55 ` Radon Rosborough 2018-02-19 3:10 ` Stefan Monnier 0 siblings, 2 replies; 838+ messages in thread From: Basil L. Contovounesios @ 2018-02-18 18:26 UTC (permalink / raw) To: Radon Rosborough Cc: Eli Zaretskii, emacs-devel, Clément Pit-Claudel, Stefan Monnier This feature ("Add early init file, stop package-initialize insertion", commit 24acb31c04) seems to cause the following behaviour for me: 1. cd 2. mv .emacs.d .emacs.d.bak (My user-init-file lives under user-emacs-directory, so this is like erasing user-init-file and uninstalling all packages.) 3. emacs --no-site-file 4. M-x package-install RET bbdb RET (I think any package with a "dir" file will do - lmc.el does not cause any issues, for example.) 5. C-x C-c 6. emacs --no-site-file 7. C-h e The first line in the *Messages* buffer reads Symbol’s value as variable is void: Info-default-directory-list followed by "[N times]" where N (I guess) is proportional to the number of packages installed in package-user-dir. Repeating step 6 with --debug-init doesn't change anything, and neither does Stefan's latest "Use condition-case-unless-debug" commit eb3337cdb3. Any ideas on what is happening and how to debug/fix this? Thanks, -- Basil ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-02-18 18:26 ` Basil L. Contovounesios @ 2018-02-18 18:55 ` Radon Rosborough 2018-02-19 3:10 ` Stefan Monnier 1 sibling, 0 replies; 838+ messages in thread From: Radon Rosborough @ 2018-02-18 18:55 UTC (permalink / raw) To: Basil L. Contovounesios Cc: Eli Zaretskii, emacs-devel, Clément Pit-Claudel, Stefan Monnier > Any ideas on what is happening and how to debug/fix this? I saw this error before, but for some reason concluded that it wasn't due to my change. Thus I didn't look too much into it, but I would assume that it is because package initialization happens earlier now, and package.el does not take care to initialize the Info system if it's not done already. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-02-18 18:26 ` Basil L. Contovounesios 2018-02-18 18:55 ` Radon Rosborough @ 2018-02-19 3:10 ` Stefan Monnier 2018-02-20 19:13 ` Basil L. Contovounesios 1 sibling, 1 reply; 838+ messages in thread From: Stefan Monnier @ 2018-02-19 3:10 UTC (permalink / raw) To: Basil L. Contovounesios Cc: Eli Zaretskii, Radon Rosborough, Clément Pit-Claudel, emacs-devel > The first line in the *Messages* buffer reads > Symbol’s value as variable is void: Info-default-directory-list Hmm... indeed, I see the problem: in `command-line`, we do: - load early-init.el - activate all packages - do various frame initializations (e.g. create the GUI frame) - run custom-reevaluate-setting on the custom-delayed-init-variables - load init.el and until we run custom-reevaluate-setting, those delayed vars are still unbound. I don't know if it's safe to do the custom-reevaluate-setting before the frame initializations. If it is, then we could move it to before loading early-init.el, and that would be my favorite choice. If that can't be done, then the second best option is to move the package-activation to after we run custom-reevaluate-setting (so early-init.el still can't (require 'info) because Info-default-directory-list is unbound, but at least the problem at hand should be fixed). Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-02-19 3:10 ` Stefan Monnier @ 2018-02-20 19:13 ` Basil L. Contovounesios 2018-02-20 19:26 ` Basil L. Contovounesios 0 siblings, 1 reply; 838+ messages in thread From: Basil L. Contovounesios @ 2018-02-20 19:13 UTC (permalink / raw) To: Stefan Monnier Cc: Eli Zaretskii, Radon Rosborough, Clément Pit-Claudel, emacs-devel >> The first line in the *Messages* buffer reads >> Symbol’s value as variable is void: Info-default-directory-list A knock-on effect is a near-twofold increase in my startup time, from ~0.4s to ~0.7s, but hopefully this is due only to the unintended 34 times the error is logged while activating 146 packages on my side. Sorry I can't be of any help at this time; I haven't been keeping up with this feature. -- Basil ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-02-20 19:13 ` Basil L. Contovounesios @ 2018-02-20 19:26 ` Basil L. Contovounesios 2018-02-20 20:35 ` Radon Rosborough 2018-02-21 3:43 ` T.V Raman 0 siblings, 2 replies; 838+ messages in thread From: Basil L. Contovounesios @ 2018-02-20 19:26 UTC (permalink / raw) To: Stefan Monnier Cc: Eli Zaretskii, Radon Rosborough, Clément Pit-Claudel, emacs-devel "Basil L. Contovounesios" <contovob@tcd.ie> writes: >>> The first line in the *Messages* buffer reads >>> Symbol’s value as variable is void: Info-default-directory-list > > A knock-on effect is a near-twofold increase in my startup time, from > ~0.4s to ~0.7s, but hopefully this is due only to the unintended 34 > times the error is logged while activating 146 packages on my side. Indeed, I spoke too soon - I think the slowdown was being caused by a repeated call to package-initialize, which I now avoid by disabling package-enable-at-startup in early-init-file. Sorry about the noise. -- Basil ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-02-20 19:26 ` Basil L. Contovounesios @ 2018-02-20 20:35 ` Radon Rosborough 2018-02-21 3:48 ` T.V Raman 2018-02-21 8:16 ` Stefan Monnier 2018-02-21 3:43 ` T.V Raman 1 sibling, 2 replies; 838+ messages in thread From: Radon Rosborough @ 2018-02-20 20:35 UTC (permalink / raw) To: Basil L. Contovounesios Cc: Eli Zaretskii, Clément Pit-Claudel, Stefan Monnier, emacs-devel [-- Attachment #1: Type: text/plain, Size: 766 bytes --] > I think the slowdown was being caused by a > repeated call to package-initialize, which I now avoid by disabling > package-enable-at-startup in early-init-file. Might it be a good idea to have `package-initialize' signal a warning if it's called multiple times? I hadn't considered this side effect of the change, but at least it's easier to get users to remove a duplicate call than to add a missing one. Are there ever circumstances where calling `package-initialize' more than once makes sense? Perhaps we can allow for those by introducing a variable `package-warn-on-reinitialization' or somesuch, which would be set to non-nil in `package-initialize', and then next time around produce a warning, but then could be set back to nil to suppress the warning. [-- Attachment #2: Type: text/html, Size: 1574 bytes --] ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-02-20 20:35 ` Radon Rosborough @ 2018-02-21 3:48 ` T.V Raman 2018-02-21 8:16 ` Stefan Monnier 1 sibling, 0 replies; 838+ messages in thread From: T.V Raman @ 2018-02-21 3:48 UTC (permalink / raw) To: Radon Rosborough Cc: Basil L. Contovounesios, Eli Zaretskii, emacs-devel, Clément Pit-Claudel, Stefan Monnier Also the documentation for variable package-enable-at-startup may need updating, present doc-string no longer feels right: package-enable-at-startup is a variable defined in `package.el'. Its value is nil Original value was t Documentation: Whether to activate installed packages when Emacs starts. If non-nil, packages are activated after reading the init file and before `after-init-hook'. Activation is not done if `user-init-file' is nil (e.g. Emacs was started with "-q"). Even if the value is nil, you can type M-x package-initialize to activate the package system at any time. You can customize this variable. This variable was introduced, or its default value was changed, in version 24.1 of Emacs. -- ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-02-20 20:35 ` Radon Rosborough 2018-02-21 3:48 ` T.V Raman @ 2018-02-21 8:16 ` Stefan Monnier 2018-02-21 20:48 ` Radon Rosborough 1 sibling, 1 reply; 838+ messages in thread From: Stefan Monnier @ 2018-02-21 8:16 UTC (permalink / raw) To: Radon Rosborough Cc: Basil L. Contovounesios, Eli Zaretskii, Clément Pit-Claudel, emacs-devel > Might it be a good idea to have `package-initialize' signal a warning > if it's called multiple times? I hadn't considered this side effect of > the change, but at least it's easier to get users to remove > a duplicate call than to add a missing one. > > Are there ever circumstances where calling `package-initialize' more than > once makes sense? It can make sense if packages were added/removed/updated without Emacs's knowledge. So maybe we need something more targeted to ~/.emacs, by temporarily let-binding a package--within-init.el variable (this would also allow us to not only emit a message but even skip the execution of such a second call to package-initialize). Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-02-21 8:16 ` Stefan Monnier @ 2018-02-21 20:48 ` Radon Rosborough 2018-02-21 21:26 ` Stefan Monnier 0 siblings, 1 reply; 838+ messages in thread From: Radon Rosborough @ 2018-02-21 20:48 UTC (permalink / raw) To: Stefan Monnier Cc: Basil L. Contovounesios, Eli Zaretskii, Clément Pit-Claudel, emacs-devel > So maybe we need something more targeted to > ~/.emacs, by temporarily let-binding a package--within-init.el variable > (this would also allow us to not only emit a message but even skip the > execution of such a second call to package-initialize). So then if you actually do want to run `package-initialize', you would let-bind `package--within-init.el' to nil? I feel like that's a little odd, since it would require you to introduce a workaround even if `package-initialize' was only called once (i.e. you set `package-enable-at-startup' to nil in early-init.el). Whereas with what I suggested, you'd only need to introduce a workaround if `package-initialize' was actually called twice. (If you were concerned about a warning being signaled after startup, we could just condition it on `after-init-time' being nil.) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-02-21 20:48 ` Radon Rosborough @ 2018-02-21 21:26 ` Stefan Monnier 0 siblings, 0 replies; 838+ messages in thread From: Stefan Monnier @ 2018-02-21 21:26 UTC (permalink / raw) To: emacs-devel > So then if you actually do want to run `package-initialize', you would > let-bind `package--within-init.el' to nil? I feel like that's a little > odd, since it would require you to introduce a workaround even if > `package-initialize' was only called once (i.e. you set > `package-enable-at-startup' to nil in early-init.el). Whereas with > what I suggested, you'd only need to introduce a workaround if > `package-initialize' was actually called twice. Clearly, we would not want to warn and/or skip one the first call (e.g. when the user set package-enable-at-startup to nil in early-init.el). > (If you were concerned about a warning being signaled after startup, > we could just condition it on `after-init-time' being nil.) That would work as well, yes, Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2018-02-20 19:26 ` Basil L. Contovounesios 2018-02-20 20:35 ` Radon Rosborough @ 2018-02-21 3:43 ` T.V Raman 1 sibling, 0 replies; 838+ messages in thread From: T.V Raman @ 2018-02-21 3:43 UTC (permalink / raw) To: Basil L. Contovounesios Cc: Eli Zaretskii, Radon Rosborough, Clément Pit-Claudel, Stefan Monnier, emacs-devel But that error re Info-default-directory is still annoying. Interestingly, declaring it as a defvar in early-init.el doesn't seem to help -- ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2017-10-10 16:52 ` Robert Weiner 2017-10-10 16:59 ` Eli Zaretskii @ 2017-10-10 19:03 ` Radon Rosborough 2017-10-10 19:31 ` Robert Weiner 1 sibling, 1 reply; 838+ messages in thread From: Radon Rosborough @ 2017-10-10 19:03 UTC (permalink / raw) To: rswgnu; +Cc: emacs-devel > 1. For most Emacs users who do not program in Elisp, there should be > only a single init file that they would personalize, generally as > they find snippets of code they can cut and paste for their use. The entire reason these solutions are being proposed is because we want to avoid the situation where people cut and paste snippets into their init file, and they fail to work, which is what used to happen. See [1]. And, as Eli already pointed out, for most Emacs users there *is* only a single init file. It's only if you want to do advanced programming that you need to use the second one, which need not exist at all. > it should be solved without requiring the use of a 2nd init file. Many, many possible solutions have already been discussed and dismissed; see [2]. It's nice to hope for a better one, but I don't think this should be considered a blocker unless someone actually comes up with a better solution. Best, Radon [1]: https://lists.gnu.org/archive/html/emacs-devel/2015-03/msg01016.html [2]: https://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00023.html ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2017-10-10 19:03 ` Radon Rosborough @ 2017-10-10 19:31 ` Robert Weiner 2017-10-10 19:41 ` Radon Rosborough 0 siblings, 1 reply; 838+ messages in thread From: Robert Weiner @ 2017-10-10 19:31 UTC (permalink / raw) To: Radon Rosborough; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 541 bytes --] On Tue, Oct 10, 2017 at 3:03 PM, Radon Rosborough <radon.neon@gmail.com> wrote: > > And, as Eli already pointed out, for most Emacs users there *is* only > a single init file. It's only if you want to do advanced programming > that you need to use the second one, which need not exist at all. > That sounds fine. When I mentioned 'package-initialize', I meant that users of packages who would call that in their init files should not need to have a second init file just to use packages and have them load properly. Bob [-- Attachment #2: Type: text/html, Size: 1359 bytes --] ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2017-10-10 19:31 ` Robert Weiner @ 2017-10-10 19:41 ` Radon Rosborough 2017-10-13 21:29 ` John Wiegley 0 siblings, 1 reply; 838+ messages in thread From: Radon Rosborough @ 2017-10-10 19:41 UTC (permalink / raw) To: rswgnu; +Cc: emacs-devel > When I mentioned 'package-initialize', I meant that users of > packages who would call that in their init files should not need to > have a second init file just to use packages and have them load > properly. Indeed, you need only have a second init file if you would like to customize `package-load-list', `package-enable-at-startup', `package-user-dir', or other such low-level variables. (In particular, `package-archives' can be set in the regular init file.) In fact, with this patch, you don't even need to have any package-related code at all in your init-file: not even `package-initialize'. Packages can be installed, and they will "just work", including if customizations are them are blindly pasted into the regular init file. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2017-10-10 19:41 ` Radon Rosborough @ 2017-10-13 21:29 ` John Wiegley 2017-10-14 0:49 ` Radon Rosborough 0 siblings, 1 reply; 838+ messages in thread From: John Wiegley @ 2017-10-13 21:29 UTC (permalink / raw) To: Radon Rosborough; +Cc: rswgnu, emacs-devel >>>>> "RR" == Radon Rosborough <radon.neon@gmail.com> writes: RR> In fact, with this patch, you don't even need to have any RR> package-related code at all in your init-file: not even RR> `package-initialize'. Packages can be installed, and they will "just RR> work", including if customizations are them are blindly pasted into RR> the regular init file. And if I never use packages, I'll never have this second file, right? Because right now, every once in a while, I find (package-initialize) getting inserted into my init.el, even though I never once have used packages. Still haven't figured out what's doing that. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2017-10-13 21:29 ` John Wiegley @ 2017-10-14 0:49 ` Radon Rosborough 2017-10-14 5:15 ` João Távora 0 siblings, 1 reply; 838+ messages in thread From: Radon Rosborough @ 2017-10-14 0:49 UTC (permalink / raw) To: Radon Rosborough, rswgnu, emacs-devel [-- Attachment #1: Type: text/plain, Size: 361 bytes --] > And if I never use packages, I'll never have this second file, > right? Correct. > Because right now, every once in a while, I find > (package-initialize) getting inserted into my init.el, even though I > never once have used packages. Literally the entire point of this patch is to stop that from happening without sacrificing any existing functionality. [-- Attachment #2: Type: text/html, Size: 551 bytes --] ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2017-10-14 0:49 ` Radon Rosborough @ 2017-10-14 5:15 ` João Távora 2017-10-14 6:19 ` Radon Rosborough 2017-10-14 13:47 ` Stefan Monnier 0 siblings, 2 replies; 838+ messages in thread From: João Távora @ 2017-10-14 5:15 UTC (permalink / raw) To: Radon Rosborough; +Cc: rswgnu, emacs-devel [-- Attachment #1: Type: text/plain, Size: 545 bytes --] On Sat, Oct 14, 2017 at 1:49 AM, Radon Rosborough <radon.neon@gmail.com> wrote: > > > And if I never use packages, I'll never have this second file, > > right? > > Correct. A follow up: if I do use packages but never mess with its "advanced options" (or even customize by that matter), will I also never have this second file? (Excuse me if the question is ignorant in the "advanced options" part, I remember reading something about that in these very big threads, about configuring the package's location and such.) João [-- Attachment #2: Type: text/html, Size: 864 bytes --] ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2017-10-14 5:15 ` João Távora @ 2017-10-14 6:19 ` Radon Rosborough 2017-10-14 9:04 ` João Távora 2017-10-14 13:47 ` Stefan Monnier 1 sibling, 1 reply; 838+ messages in thread From: Radon Rosborough @ 2017-10-14 6:19 UTC (permalink / raw) To: João Távora; +Cc: rswgnu, emacs-devel [-- Attachment #1: Type: text/plain, Size: 529 bytes --] > A follow up: if I do use packages but never mess with its "advanced > options" (or even customize by that matter), will I also never have > this second file? Correct. If you don't have to customize `package-user-dir' or `package-load-list', and you don't need to stop package.el from loading packages that you already installed, then there is no need for the early init file. Note also that with this patch, unlike in the current situation, Emacs doesn't do anything automatically. No files are created or modified by Emacs. [-- Attachment #2: Type: text/html, Size: 745 bytes --] ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2017-10-14 6:19 ` Radon Rosborough @ 2017-10-14 9:04 ` João Távora 0 siblings, 0 replies; 838+ messages in thread From: João Távora @ 2017-10-14 9:04 UTC (permalink / raw) To: Radon Rosborough; +Cc: rswgnu, emacs-devel Radon Rosborough <radon.neon@gmail.com> writes: >> A follow up: if I do use packages but never mess with its "advanced >> options" (or even customize by that matter), will I also never have >> this second file? > > Correct. If you don't have to customize `package-user-dir' or > `package-load-list', and you don't need to stop package.el from > loading packages that you already installed, then there is no need for > the early init file. > > Note also that with this patch, unlike in the current situation, Emacs > doesn't do anything automatically. No files are created or modified by > Emacs. Thank you. Sounds reasonable, then. João ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: [PATCH] Fixing package-initialize, adding early init file 2017-10-14 5:15 ` João Távora 2017-10-14 6:19 ` Radon Rosborough @ 2017-10-14 13:47 ` Stefan Monnier 1 sibling, 0 replies; 838+ messages in thread From: Stefan Monnier @ 2017-10-14 13:47 UTC (permalink / raw) To: emacs-devel > A follow up: if I do use packages but never mess with its "advanced > options" (or even customize by that matter), will I also never have > this second file? The core of the change is to call package-initialize *before* loading ~/.emacs. So you'll need the other file in the specific case where you need to do something *before* the call to package-initialize. Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* bounds-of-thing-at-point for paragraphs
@ 2020-11-01 16:08 Christopher Dimech
2020-11-01 18:22 ` Jean Louis
0 siblings, 1 reply; 838+ messages in thread
From: Christopher Dimech @ 2020-11-01 16:08 UTC (permalink / raw)
To: Help Gnu Emacs
Been trying to write a function to transpose two paragraphs but keep the cursor
at the same position. How is it that bounds-of-thing-at-point does not take
paragraph as argument?
(defun Skip-Over-Paragraphs (arg)
(let ((Prg-Bounds (bounds-of-thing-at-point 'paragraph)))
;; ----------------------------------------------------------------
(when Wrd-Bounds
(let*
( (Beg (point))
(End (cdr Prg-Bounds))
(Shift (- Beg End))
;; --------------------------------------------------------
(Cursor-Psn
(save-excursion
(goto-char End) ; [#A]
(if (condition-case err
(progn ; bodyform
(transpose-paragraphs arg) ; [#B]
t
)
(message err) ; Handler when [#B] fails
)
;; ----------------------------------------------
(+ (point) Shift) ; Shift after executing [#B]
nil ; [#B] failed
;; ----------------------------------------------
)
)
)
;; --------------------------------------------------------
)
(when Cursor-Psn (goto-char Cursor-Psn))
)
)
;;-----------------------------------------------------------------
) ; let bounds (start and end locations of word)
)
^ permalink raw reply [flat|nested] 838+ messages in thread* Re: bounds-of-thing-at-point for paragraphs 2020-11-01 16:08 bounds-of-thing-at-point for paragraphs Christopher Dimech @ 2020-11-01 18:22 ` Jean Louis 2020-11-01 18:34 ` Christopher Dimech 0 siblings, 1 reply; 838+ messages in thread From: Jean Louis @ 2020-11-01 18:22 UTC (permalink / raw) To: Christopher Dimech; +Cc: Help Gnu Emacs * Christopher Dimech <dimech@gmx.com> [2020-11-01 19:09]: > Been trying to write a function to transpose two paragraphs but keep the cursor > at the same position. How is it that bounds-of-thing-at-point does not take > paragraph as argument? That is very nice. I like ivy-mode from GNU ELPA, it is package for automatic completion of many functions. There are many various completion packages. It may help you faster explore which functions are available. I was looking if such function already exists by doing {C-h f} and then I get list of functions, I have tried typing "trans" and "para" and I can find function `transpose-paragraphs' You may spare your efforts by finding some probably already existing functions. If you wish to make your own function out of `transpose-paragraphs' you may come with cursor on the function name, above here ^ and type {C-h f} then you press TAB and enter into file `paragraphs.el' where you can find how function is written. Then you may copy the same function and name it `my-transpose-paragraphs' and try modifying it as you wish. You could as well modify original function to do what you wish and save it in your configuration. See below: > (defun Skip-Over-Paragraphs (arg) I understand that some programming languages have mixture of upper case and lower case function names, in Lisp that is not so common. I believe it is common in some versions of Lisp, not in Emacs lisp. As: (setq A 1) (setq a 2) are not same so, so it is better writing all lower case letters. > (let ((Prg-Bounds (bounds-of-thing-at-point 'paragraph))) > > ;; ---------------------------------------------------------------- > (when Wrd-Bounds > (let* > ( (Beg (point)) > (End (cdr Prg-Bounds)) > (Shift (- Beg End)) I understand you may need now for visibility or orientation some space at ( (Beg)) yet by convention there is no such space. You better not make new lines after let* to make it easier readable for people who are familiar to different style. Lisp is great, you may write it anyhow, but for readability there are some conventions. You may mark the function and simply press TAB and it will indent it for you. Please see the Emacs Lisp manual as it is built into Emacs. There is section "Tips" where you can read various conventions. > ;; -------------------------------------------------------- > (Cursor-Psn > (save-excursion > (goto-char End) ; [#A] > (if (condition-case err > (progn ; bodyform > (transpose-paragraphs arg) ; [#B] > t > ) Normally ending parenthesis you put straight after t. I suggest you use Options -> Highlight matching parenthesis to help you see where you are. -- There are 50 messages yet in my incoming mailbox. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-01 18:22 ` Jean Louis @ 2020-11-01 18:34 ` Christopher Dimech 2020-11-01 18:45 ` Drew Adams 2020-11-01 18:45 ` Jean Louis 0 siblings, 2 replies; 838+ messages in thread From: Christopher Dimech @ 2020-11-01 18:34 UTC (permalink / raw) To: Jean Louis; +Cc: Help Gnu Emacs Yes, but transpose-paragraph does not keep at the same point position. I was asking how bounds-of-thing-at-point does not take paragraph as argument as well, since it does for word, sentence, line. Can paragraph be included as well? > Sent: Sunday, November 01, 2020 at 7:22 PM > From: "Jean Louis" <bugs@gnu.support> > To: "Christopher Dimech" <dimech@gmx.com> > Cc: "Help Gnu Emacs" <help-gnu-emacs@gnu.org> > Subject: Re: bounds-of-thing-at-point for paragraphs > > * Christopher Dimech <dimech@gmx.com> [2020-11-01 19:09]: > > Been trying to write a function to transpose two paragraphs but keep the cursor > > at the same position. How is it that bounds-of-thing-at-point does not take > > paragraph as argument? > > That is very nice. > > I like ivy-mode from GNU ELPA, it is package for automatic completion > of many functions. There are many various completion packages. > > It may help you faster explore which functions are available. > > I was looking if such function already exists by doing {C-h f} and > then I get list of functions, I have tried typing "trans" and "para" > and I can find function `transpose-paragraphs' > > You may spare your efforts by finding some probably already existing > functions. > > If you wish to make your own function out of `transpose-paragraphs' > you may come with cursor on the function name, above here ^ and type > {C-h f} then you press TAB and enter into file `paragraphs.el' where > you can find how function is written. > > Then you may copy the same function and name it > `my-transpose-paragraphs' and try modifying it as you wish. You could > as well modify original function to do what you wish and save it in > your configuration. > > See below: > > > (defun Skip-Over-Paragraphs (arg) > > I understand that some programming languages have mixture of upper > case and lower case function names, in Lisp that is not so common. I > believe it is common in some versions of Lisp, not in Emacs > lisp. > > As: > > (setq A 1) > (setq a 2) > > are not same so, so it is better writing all lower case letters. > > > (let ((Prg-Bounds (bounds-of-thing-at-point 'paragraph))) > > > > ;; ---------------------------------------------------------------- > > (when Wrd-Bounds > > (let* > > ( (Beg (point)) > > (End (cdr Prg-Bounds)) > > (Shift (- Beg End)) > > I understand you may need now for visibility or orientation some space > at ( (Beg)) yet by convention there is no such space. You better not > make new lines after let* to make it easier readable for people who > are familiar to different style. Lisp is great, you may write it > anyhow, but for readability there are some conventions. > > You may mark the function and simply press TAB and it will indent it > for you. > > Please see the Emacs Lisp manual as it is built into Emacs. There is > section "Tips" where you can read various conventions. > > > ;; -------------------------------------------------------- > > (Cursor-Psn > > (save-excursion > > (goto-char End) ; [#A] > > (if (condition-case err > > (progn ; bodyform > > (transpose-paragraphs arg) ; [#B] > > t > > ) > > Normally ending parenthesis you put straight after t. > > I suggest you use Options -> Highlight matching parenthesis to help > you see where you are. > > -- > There are 50 messages yet in my incoming mailbox. > ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: bounds-of-thing-at-point for paragraphs 2020-11-01 18:34 ` Christopher Dimech @ 2020-11-01 18:45 ` Drew Adams 2020-11-01 18:52 ` Jean Louis 2020-11-01 18:45 ` Jean Louis 1 sibling, 1 reply; 838+ messages in thread From: Drew Adams @ 2020-11-01 18:45 UTC (permalink / raw) To: Christopher Dimech, Jean Louis; +Cc: Help Gnu Emacs > I was asking how bounds-of-thing-at-point does not take paragraph as argument > as well, since it does for word, sentence, line. Can paragraph be included as > well? But it does. (bound-of-thing-at-point 'paragraph) works fine. (thing-at-point 'paragraph) also works fine. See (emacs) `Paragraphs' for info about how paragraphs are defined for Emacs use. https://www.gnu.org/software/emacs/manual/html_node/emacs/Paragraphs.html ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-01 18:45 ` Drew Adams @ 2020-11-01 18:52 ` Jean Louis 2020-11-01 19:00 ` Drew Adams 2020-11-01 19:27 ` Eli Zaretskii 0 siblings, 2 replies; 838+ messages in thread From: Jean Louis @ 2020-11-01 18:52 UTC (permalink / raw) To: Drew Adams; +Cc: Christopher Dimech, Help Gnu Emacs * Drew Adams <drew.adams@oracle.com> [2020-11-01 21:45]: > > I was asking how bounds-of-thing-at-point does not take paragraph as argument > > as well, since it does for word, sentence, line. Can paragraph be included as > > well? > > But it does. > > (bounds-of-thing-at-point 'paragraph) works fine. It works fine, but documentation does not describe it: bounds-of-thing-at-point is an autoloaded compiled Lisp function in ‘thingatpt.el’. (bounds-of-thing-at-point THING) Determine the start and end buffer locations for the THING at point. THING should be a symbol specifying a type of syntactic entity. Possibilities include ‘symbol’, ‘list’, ‘sexp’, ‘defun’, ‘filename’, ‘url’, ‘email’, ‘uuid’, ‘word’, ‘sentence’, ‘whitespace’, ‘line’, and ‘page’. See the file ‘thingatpt.el’ for documentation on how to define a valid THING. Return a cons cell (START . END) giving the start and end positions of the thing found. > (thing-at-point 'paragraph) also works fine. Also there documentation is not describing it: thing-at-point is an autoloaded compiled Lisp function in ‘thingatpt.el’. (thing-at-point THING &optional NO-PROPERTIES) Probably introduced at or before Emacs version 20. Return the THING at point. THING should be a symbol specifying a type of syntactic entity. Possibilities include ‘symbol’, ‘list’, ‘sexp’, ‘defun’, ‘filename’, ‘url’, ‘email’, ‘uuid’, ‘word’, ‘sentence’, ‘whitespace’, ‘line’, ‘number’, and ‘page’. Could somebody update documentation for those functions? ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: bounds-of-thing-at-point for paragraphs 2020-11-01 18:52 ` Jean Louis @ 2020-11-01 19:00 ` Drew Adams 2020-11-01 20:07 ` Christopher Dimech 2020-11-01 20:36 ` Jean Louis 2020-11-01 19:27 ` Eli Zaretskii 1 sibling, 2 replies; 838+ messages in thread From: Drew Adams @ 2020-11-01 19:00 UTC (permalink / raw) To: Jean Louis; +Cc: Christopher Dimech, Help Gnu Emacs > > (bounds-of-thing-at-point 'paragraph) works fine. > > It works fine, but documentation does not describe it: > > bounds-of-thing-at-point is an autoloaded compiled Lisp function in > ‘thingatpt.el’. > > (bounds-of-thing-at-point THING) > > Determine the start and end buffer locations for the THING at point. > THING should be a symbol specifying a type of syntactic entity. > Possibilities include ‘symbol’, ‘list’, ‘sexp’, ‘defun’, > ‘filename’, ‘url’, ‘email’, ‘uuid’, ‘word’, ‘sentence’, ‘whitespace’, > ‘line’, and ‘page’. > > See the file ‘thingatpt.el’ for documentation on how to define a > valid THING. > > Return a cons cell (START . END) giving the start and end > positions of the thing found. Just read it more carefully. 1. "Possibilities include" ^^^^^^^ It doesn't say that those are the only possibilities. 2. It points you to "`thingatpt.el' for documentation on how to define a valid THING." IOW, for documentation what makes a THING defined for use by `thing-at-point'. > > (thing-at-point 'paragraph) also works fine. > > Also there documentation is not describing it: > > thing-at-point is an autoloaded compiled Lisp function in > ‘thingatpt.el’. > > (thing-at-point THING &optional NO-PROPERTIES) > > Probably introduced at or before Emacs version 20. > > Return the THING at point. > THING should be a symbol specifying a type of syntactic entity. > Possibilities include ‘symbol’, ‘list’, ‘sexp’, ‘defun’, > ‘filename’, ‘url’, ‘email’, ‘uuid’, ‘word’, ‘sentence’, ‘whitespace’, > ‘line’, ‘number’, and ‘page’. See above. The word "include" doesn't mean the same thing as "include only" or "comprise". The list of THINGS mentioned isn't exhaustive. The English language includes the words "thing" and "point" (but it also includes a lot more words). ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: RE: bounds-of-thing-at-point for paragraphs 2020-11-01 19:00 ` Drew Adams @ 2020-11-01 20:07 ` Christopher Dimech 2020-11-01 22:06 ` Drew Adams 2020-11-01 20:36 ` Jean Louis 1 sibling, 1 reply; 838+ messages in thread From: Christopher Dimech @ 2020-11-01 20:07 UTC (permalink / raw) To: Drew Adams; +Cc: Help Gnu Emacs, Jean Louis Looking at thingatpt.el is not helpful. If you know important things that are useful to know about it, place it at the top of the file. I customarily define a documentation function for the file so that it would be available interactively, even if mostly of interest to Elisp Designers. > Sent: Sunday, November 01, 2020 at 8:00 PM > From: "Drew Adams" <drew.adams@oracle.com> > To: "Jean Louis" <bugs@gnu.support> > Cc: "Christopher Dimech" <dimech@gmx.com>, "Help Gnu Emacs" <help-gnu-emacs@gnu.org> > Subject: RE: bounds-of-thing-at-point for paragraphs > > > > (bounds-of-thing-at-point 'paragraph) works fine. > > > > It works fine, but documentation does not describe it: > > > > bounds-of-thing-at-point is an autoloaded compiled Lisp function in > > ‘thingatpt.el’. > > > > (bounds-of-thing-at-point THING) > > > > Determine the start and end buffer locations for the THING at point. > > THING should be a symbol specifying a type of syntactic entity. > > Possibilities include ‘symbol’, ‘list’, ‘sexp’, ‘defun’, > > ‘filename’, ‘url’, ‘email’, ‘uuid’, ‘word’, ‘sentence’, ‘whitespace’, > > ‘line’, and ‘page’. > > > > See the file ‘thingatpt.el’ for documentation on how to define a > > valid THING. > > > > Return a cons cell (START . END) giving the start and end > > positions of the thing found. > > Just read it more carefully. > > 1. "Possibilities include" > ^^^^^^^ > > It doesn't say that those are the only possibilities. > > 2. It points you to "`thingatpt.el' for documentation on > how to define a valid THING." IOW, for documentation > what makes a THING defined for use by `thing-at-point'. > > > > (thing-at-point 'paragraph) also works fine. > > > > Also there documentation is not describing it: > > > > thing-at-point is an autoloaded compiled Lisp function in > > ‘thingatpt.el’. > > > > (thing-at-point THING &optional NO-PROPERTIES) > > > > Probably introduced at or before Emacs version 20. > > > > Return the THING at point. > > THING should be a symbol specifying a type of syntactic entity. > > Possibilities include ‘symbol’, ‘list’, ‘sexp’, ‘defun’, > > ‘filename’, ‘url’, ‘email’, ‘uuid’, ‘word’, ‘sentence’, ‘whitespace’, > > ‘line’, ‘number’, and ‘page’. > > See above. The word "include" doesn't mean the > same thing as "include only" or "comprise". The > list of THINGS mentioned isn't exhaustive. > > The English language includes the words "thing" > and "point" (but it also includes a lot more words). > ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: RE: bounds-of-thing-at-point for paragraphs 2020-11-01 20:07 ` Christopher Dimech @ 2020-11-01 22:06 ` Drew Adams 2020-11-01 22:36 ` Christopher Dimech 0 siblings, 1 reply; 838+ messages in thread From: Drew Adams @ 2020-11-01 22:06 UTC (permalink / raw) To: Christopher Dimech; +Cc: Help Gnu Emacs, Jean Louis > Looking at thingatpt.el is not helpful. It's very helpful. It directly answers your question. Or perhaps you meant that needing to look at that file is a burden. That's different from saying that if you do look in the file you find no help. > If you know important things that are useful to know > about it, place it at the top of the file. Define "top" of the file. Elisp files have certain things, conventionally, at the very top. One of the things they can have near the top, i.e., in the file header, is a Commentary section, which is documentation. And lo and behold, what do we find there, in lines 4-7 of the Commentary? The function bounds-of-thing-at-point finds the beginning and end positions by moving first forward to the end of the "thing", and then backwards to the beginning. By default, it uses the corresponding forward-"thing" operator (eg. forward-word, forward-line). That directly answers your question, no? What happens when you do `C-h f forward- TAB'? Do you see `forward-paragraph' listed? QED. > I customarily define a documentation function for the file so that it > would be available interactively, even if mostly of interest to Elisp > Designers. You want interactive access to just the Commentary? Your wish is granted: M-x finder-commentary thingatpt That's how I got the text to include in my answer to you, without having to remove comment chars (`;'). (And yes, you can use `TAB' with `finder-commentary' to see all of the currently available libraries as candidates.) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: RE: RE: bounds-of-thing-at-point for paragraphs 2020-11-01 22:06 ` Drew Adams @ 2020-11-01 22:36 ` Christopher Dimech 2020-11-01 22:47 ` Jean Louis ` (2 more replies) 0 siblings, 3 replies; 838+ messages in thread From: Christopher Dimech @ 2020-11-01 22:36 UTC (permalink / raw) To: Drew Adams; +Cc: Help Gnu Emacs, Jean Louis When I tried I got "Can't find library thingatapt" M-x finder-commentary thingatpt > Sent: Sunday, November 01, 2020 at 11:06 PM > From: "Drew Adams" <drew.adams@oracle.com> > To: "Christopher Dimech" <dimech@gmx.com> > Cc: "Help Gnu Emacs" <help-gnu-emacs@gnu.org>, "Jean Louis" <bugs@gnu.support> > Subject: RE: RE: bounds-of-thing-at-point for paragraphs > > > Looking at thingatpt.el is not helpful. > > It's very helpful. It directly answers your question. > > Or perhaps you meant that needing to look at that file > is a burden. That's different from saying that if you > do look in the file you find no help. > > > If you know important things that are useful to know > > about it, place it at the top of the file. > > Define "top" of the file. Elisp files have certain > things, conventionally, at the very top. > > One of the things they can have near the top, i.e., > in the file header, is a Commentary section, which is > documentation. > > And lo and behold, what do we find there, in lines > 4-7 of the Commentary? > > The function bounds-of-thing-at-point finds the beginning and end > positions by moving first forward to the end of the "thing", and then > backwards to the beginning. By default, it uses the corresponding > forward-"thing" operator (eg. forward-word, forward-line). > > That directly answers your question, no? > > What happens when you do `C-h f forward- TAB'? Do you > see `forward-paragraph' listed? QED. > > > I customarily define a documentation function for the file so that it > > would be available interactively, even if mostly of interest to Elisp > > Designers. > > You want interactive access to just the Commentary? > Your wish is granted: > > M-x finder-commentary thingatpt > > That's how I got the text to include in my answer to > you, without having to remove comment chars (`;'). > > (And yes, you can use `TAB' with `finder-commentary' > to see all of the currently available libraries as > candidates.) > > ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: RE: RE: bounds-of-thing-at-point for paragraphs 2020-11-01 22:36 ` Christopher Dimech @ 2020-11-01 22:47 ` Jean Louis 2020-11-01 22:52 ` Drew Adams 2020-11-01 22:49 ` RE: RE: bounds-of-thing-at-point for paragraphs Jean Louis 2020-11-01 22:51 ` Drew Adams 2 siblings, 1 reply; 838+ messages in thread From: Jean Louis @ 2020-11-01 22:47 UTC (permalink / raw) To: Christopher Dimech; +Cc: GNU Emacs Help * Christopher Dimech <dimech@gmx.com> [2020-11-02 01:36]: > When I tried I got "Can't find library thingatapt" > > M-x finder-commentary thingatpt M-x find-library ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: RE: RE: bounds-of-thing-at-point for paragraphs 2020-11-01 22:47 ` Jean Louis @ 2020-11-01 22:52 ` Drew Adams 2020-11-01 23:14 ` Christopher Dimech 2020-11-02 6:07 ` finder-commentary Jean Louis 0 siblings, 2 replies; 838+ messages in thread From: Drew Adams @ 2020-11-01 22:52 UTC (permalink / raw) To: Jean Louis, Christopher Dimech; +Cc: GNU Emacs Help > > M-x finder-commentary thingatpt > > M-x find-library Nope, not what I meant. Sure, you can bring up the whole file. But `finder-commentary' is a help command designed just for this purpose. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: RE: RE: RE: bounds-of-thing-at-point for paragraphs 2020-11-01 22:52 ` Drew Adams @ 2020-11-01 23:14 ` Christopher Dimech 2020-11-02 1:07 ` Drew Adams 2020-11-02 6:07 ` finder-commentary Jean Louis 1 sibling, 1 reply; 838+ messages in thread From: Christopher Dimech @ 2020-11-01 23:14 UTC (permalink / raw) To: Drew Adams; +Cc: GNU Emacs Help, Jean Louis Of course I brought up the whole file. Yet I could not figure out about the paragraph thing. Which region are you referring that is useful to you? > Sent: Sunday, November 01, 2020 at 11:52 PM > From: "Drew Adams" <drew.adams@oracle.com> > To: "Jean Louis" <bugs@gnu.support>, "Christopher Dimech" <dimech@gmx.com> > Cc: "GNU Emacs Help" <help-gnu-emacs@gnu.org> > Subject: RE: RE: RE: bounds-of-thing-at-point for paragraphs > > > > M-x finder-commentary thingatpt > > > > M-x find-library > > Nope, not what I meant. Sure, you can bring up > the whole file. But `finder-commentary' is a > help command designed just for this purpose. > ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: RE: RE: RE: bounds-of-thing-at-point for paragraphs 2020-11-01 23:14 ` Christopher Dimech @ 2020-11-02 1:07 ` Drew Adams 2020-11-02 4:09 ` Robert Thorpe 0 siblings, 1 reply; 838+ messages in thread From: Drew Adams @ 2020-11-02 1:07 UTC (permalink / raw) To: Christopher Dimech; +Cc: GNU Emacs Help, Jean Louis > Of course I brought up the whole file. Which file? Were you able to find file thingatpt.el? > Yet I could not figure out about the paragraph thing. > Which region are you referring that is useful to you? Search for "Commentary" in file thingatpt.el. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-02 1:07 ` Drew Adams @ 2020-11-02 4:09 ` Robert Thorpe 2020-11-02 15:41 ` Drew Adams 0 siblings, 1 reply; 838+ messages in thread From: Robert Thorpe @ 2020-11-02 4:09 UTC (permalink / raw) To: Drew Adams; +Cc: help-gnu-emacs Drew Adams <drew.adams@oracle.com> writes: >> Of course I brought up the whole file. > > Which file? Were you able to find file thingatpt.el? > >> Yet I could not figure out about the paragraph thing. >> Which region are you referring that is useful to you? > > Search for "Commentary" in file thingatpt.el. As a sidenote, I found another bug here. In the buffer created by M-x finder-commentary it should be possible to quit using "q", but that keybinding doesn't work. I'll make a bug report. BR, Robert Thorpe ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: bounds-of-thing-at-point for paragraphs 2020-11-02 4:09 ` Robert Thorpe @ 2020-11-02 15:41 ` Drew Adams 2020-11-03 6:00 ` Corwin Brust 0 siblings, 1 reply; 838+ messages in thread From: Drew Adams @ 2020-11-02 15:41 UTC (permalink / raw) To: Robert Thorpe; +Cc: help-gnu-emacs > In the buffer created by M-x finder-commentary it should be possible to > quit using "q", but that keybinding doesn't work. I'll make a bug > report. I don't see that. I'm using Emacs 26.3. `finder-mode-map' has `q' defined as `finder-exit', which works fine, for me. Its doc says: Exit finder mode. Delete the window and kill all Finder-related buffers. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-02 15:41 ` Drew Adams @ 2020-11-03 6:00 ` Corwin Brust 2020-11-03 6:40 ` Stefan Kangas 0 siblings, 1 reply; 838+ messages in thread From: Corwin Brust @ 2020-11-03 6:00 UTC (permalink / raw) To: Drew Adams; +Cc: Help Gnu Emacs mailing list, Robert Thorpe Hi all, On Mon, Nov 2, 2020 at 9:41 AM Drew Adams <drew.adams@oracle.com> wrote: > > > In the buffer created by M-x finder-commentary it should be possible to > > quit using "q", but that keybinding doesn't work. I'll make a bug > > report. > > I don't see that. I'm using Emacs 26.3. > > `finder-mode-map' has `q' defined as `finder-exit', > which works fine, for me. Its doc says: > > Exit finder mode. > Delete the window and kill all Finder-related buffers. > I can reproduce this. In fact, I had been about to submit the same bug when I saw Robert's note (thanks Robert!) So, likely regression in 27? I'm not able to check master sadly. Regards, Corwin ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-03 6:00 ` Corwin Brust @ 2020-11-03 6:40 ` Stefan Kangas 2020-11-03 7:41 ` Corwin Brust 0 siblings, 1 reply; 838+ messages in thread From: Stefan Kangas @ 2020-11-03 6:40 UTC (permalink / raw) To: Corwin Brust, Drew Adams; +Cc: Help Gnu Emacs mailing list, Robert Thorpe Corwin Brust <corwin@bru.st> writes: >> Exit finder mode. >> Delete the window and kill all Finder-related buffers. > > I can reproduce this. In fact, I had been about to submit the same > bug when I saw Robert's note (thanks Robert!) > > So, likely regression in 27? I'm not able to check master sadly. See Bug#44384, fixed on master. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-03 6:40 ` Stefan Kangas @ 2020-11-03 7:41 ` Corwin Brust 2020-11-03 16:07 ` Drew Adams 0 siblings, 1 reply; 838+ messages in thread From: Corwin Brust @ 2020-11-03 7:41 UTC (permalink / raw) To: Stefan Kangas; +Cc: Help Gnu Emacs mailing list, Robert Thorpe Thank you Stefan! On Tue, Nov 3, 2020 at 12:40 AM Stefan Kangas <stefankangas@gmail.com> wrote: > > Corwin Brust <corwin@bru.st> writes: [...] > > So, likely regression in 27? I'm not able to check master sadly. > > See Bug#44384, fixed on master. FWIW, I can also repro this on 26.3 under -Q so I no longer think this is a regression for 27. Regards, Corwin ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: bounds-of-thing-at-point for paragraphs 2020-11-03 7:41 ` Corwin Brust @ 2020-11-03 16:07 ` Drew Adams 2020-11-06 23:45 ` Corwin Brust 0 siblings, 1 reply; 838+ messages in thread From: Drew Adams @ 2020-11-03 16:07 UTC (permalink / raw) To: Corwin Brust, Stefan Kangas; +Cc: Help Gnu Emacs mailing list, Robert Thorpe > FWIW, I can also repro this on 26.3 under -Q so I no longer think this > is a regression for 27. What is it that you can repro on 26.3? What's the recipe? If I use `emacs -Q' then `q' exits with `finder-exit', which deletes the window (unless it's alone in its frame). I think that's what `q' has always done in such a Finder window (until the regression introduced in Emacs 27). ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-03 16:07 ` Drew Adams @ 2020-11-06 23:45 ` Corwin Brust 2020-11-07 1:26 ` Stefan Kangas 0 siblings, 1 reply; 838+ messages in thread From: Corwin Brust @ 2020-11-06 23:45 UTC (permalink / raw) To: Drew Adams; +Cc: Help Gnu Emacs mailing list, Robert Thorpe, Stefan Kangas Thanks for replying back in Drew, I missed had missed this and just saw now. On Tue, Nov 3, 2020 at 10:07 AM Drew Adams <drew.adams@oracle.com> wrote: > > > FWIW, I can also repro this on 26.3 under -Q so I no longer think this > > is a regression for 27. > > What is it that you can repro on 26.3? What's the recipe? > > If I use `emacs -Q' then `q' exits with `finder-exit', > which deletes the window (unless it's alone in its frame). > > I think that's what `q' has always done in such a Finder > window (until the regression introduced in Emacs 27). I retested and now agree this is a regression for Emacs 27. I was intially confused about the different behaviour when the *Finder-package* is the only window in the frame. Retesting under -Q in 26.3 and 27.1 clearly gives different behavior when the commentary buffer's window isn't made to occupy the whole frame. Stephan, I think this should be pushed to the Emacs 27 branch. Are you convinced? Regards, Corwin 612-217-1742 612-695-4276 (signal) corwin@bru.st ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-06 23:45 ` Corwin Brust @ 2020-11-07 1:26 ` Stefan Kangas 0 siblings, 0 replies; 838+ messages in thread From: Stefan Kangas @ 2020-11-07 1:26 UTC (permalink / raw) To: Corwin Brust, Drew Adams; +Cc: Help Gnu Emacs mailing list, Robert Thorpe Corwin Brust <corwin@bru.st> writes: > I think this should be pushed to the Emacs 27 branch. Are you convinced? OK; done. ^ permalink raw reply [flat|nested] 838+ messages in thread
* finder-commentary 2020-11-01 22:52 ` Drew Adams 2020-11-01 23:14 ` Christopher Dimech @ 2020-11-02 6:07 ` Jean Louis 2020-11-02 15:48 ` finder-commentary Drew Adams 1 sibling, 1 reply; 838+ messages in thread From: Jean Louis @ 2020-11-02 6:07 UTC (permalink / raw) To: Drew Adams; +Cc: GNU Emacs Help * Drew Adams <drew.adams@oracle.com> [2020-11-02 01:53]: > > > M-x finder-commentary thingatpt > > > > M-x find-library > > Nope, not what I meant. Sure, you can bring up > the whole file. But `finder-commentary' is a > help command designed just for this purpose. Thank you, nice feature. ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: finder-commentary 2020-11-02 6:07 ` finder-commentary Jean Louis @ 2020-11-02 15:48 ` Drew Adams 2020-11-02 16:02 ` finder-commentary Drew Adams 0 siblings, 1 reply; 838+ messages in thread From: Drew Adams @ 2020-11-02 15:48 UTC (permalink / raw) To: Jean Louis; +Cc: GNU Emacs Help > >`finder-commentary' is a help command designed > > just for this purpose. > > Thank you, nice feature. Maybe it should be on the `Help' menu somewhere. ___ [My library `menu-bar+.el' puts `finder-by-keyword' on menu `Help' > `Learn More' > `Emacs Lisp' > `Locate Libraries By Keyword'. But I haven't added a menu item anywhere for `finder-commentary'.] ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: finder-commentary 2020-11-02 15:48 ` finder-commentary Drew Adams @ 2020-11-02 16:02 ` Drew Adams 2020-11-02 16:58 ` finder-commentary Jean Louis 0 siblings, 1 reply; 838+ messages in thread From: Drew Adams @ 2020-11-02 16:02 UTC (permalink / raw) To: Jean Louis; +Cc: GNU Emacs Help BTW/FWIW - My library `finder+.el' enhances Finder mode in minor ways. In particular, it changes `finder-commentary' so it names the buffer `*Commentary, <FILE>*, not just `*Finder*', so you can have any number of such buffers and recognize which libraries they are for. https://www.emacswiki.org/emacs/download/finder%2b.el ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: finder-commentary 2020-11-02 16:02 ` finder-commentary Drew Adams @ 2020-11-02 16:58 ` Jean Louis 2020-11-02 17:27 ` finder-commentary Drew Adams 0 siblings, 1 reply; 838+ messages in thread From: Jean Louis @ 2020-11-02 16:58 UTC (permalink / raw) To: Drew Adams; +Cc: GNU Emacs Help * Drew Adams <drew.adams@oracle.com> [2020-11-02 19:02]: > BTW/FWIW - > > My library `finder+.el' enhances Finder mode in minor ways. > > In particular, it changes `finder-commentary' so it names > the buffer `*Commentary, <FILE>*, not just `*Finder*', so > you can have any number of such buffers and recognize which > libraries they are for. > > https://www.emacswiki.org/emacs/download/finder%2b.el Is it automatically working with el-get? I can find it, and do el-get-install but do not see how to activate. -- There are 36 messages yet in my incoming mailbox. ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: finder-commentary 2020-11-02 16:58 ` finder-commentary Jean Louis @ 2020-11-02 17:27 ` Drew Adams 0 siblings, 0 replies; 838+ messages in thread From: Drew Adams @ 2020-11-02 17:27 UTC (permalink / raw) To: Jean Louis; +Cc: GNU Emacs Help > Is it automatically working with el-get? I can find it, and do > el-get-install but do not see how to activate. There's nothing to activate. Just load `finder+.el' (or a byte-compiled version of it, `finder.elc'): . Put it in your `load-path', then (require 'finder+). . Or interactively: `M-x load-library finder+'. . Or interactively, if not in your `load-path': `M-x load-file <.../finder+.el[c]> This is true of any Elisp library. That is, assuming the library has a `provide' you can `require' it, to load it, assuming it's in your `load-path'. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: RE: RE: bounds-of-thing-at-point for paragraphs 2020-11-01 22:36 ` Christopher Dimech 2020-11-01 22:47 ` Jean Louis @ 2020-11-01 22:49 ` Jean Louis 2020-11-01 22:51 ` Drew Adams 2 siblings, 0 replies; 838+ messages in thread From: Jean Louis @ 2020-11-01 22:49 UTC (permalink / raw) To: Christopher Dimech; +Cc: GNU Emacs Help * Christopher Dimech <dimech@gmx.com> [2020-11-02 01:36]: > When I tried I got "Can't find library thingatapt" > > M-x finder-commentary thingatpt Sorry I did not see you wish to find commentary only. On my side that function works. Do you complete with TAB when typing in minibuffer? ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: RE: RE: bounds-of-thing-at-point for paragraphs 2020-11-01 22:36 ` Christopher Dimech 2020-11-01 22:47 ` Jean Louis 2020-11-01 22:49 ` RE: RE: bounds-of-thing-at-point for paragraphs Jean Louis @ 2020-11-01 22:51 ` Drew Adams 2020-11-01 23:10 ` Christopher Dimech 2 siblings, 1 reply; 838+ messages in thread From: Drew Adams @ 2020-11-01 22:51 UTC (permalink / raw) To: Christopher Dimech; +Cc: Help Gnu Emacs, Jean Louis > When I tried I got "Can't find library thingatapt" > >> M-x finder-commentary thingatpt thingatpt, not thingatapt ^ emacs -Q M-x finder-commentary RET thi TAB RET ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: RE: RE: RE: bounds-of-thing-at-point for paragraphs 2020-11-01 22:51 ` Drew Adams @ 2020-11-01 23:10 ` Christopher Dimech 2020-11-02 1:05 ` Drew Adams 0 siblings, 1 reply; 838+ messages in thread From: Christopher Dimech @ 2020-11-01 23:10 UTC (permalink / raw) To: Drew Adams; +Cc: Help Gnu Emacs, Jean Louis I did 'M-x finder-commentary Ret thing Tab' which got me Library name: thingatpt.elc Result: "Can't find library thingatpt" > Sent: Sunday, November 01, 2020 at 11:51 PM > From: "Drew Adams" <drew.adams@oracle.com> > To: "Christopher Dimech" <dimech@gmx.com> > Cc: "Help Gnu Emacs" <help-gnu-emacs@gnu.org>, "Jean Louis" <bugs@gnu.support> > Subject: RE: RE: RE: bounds-of-thing-at-point for paragraphs > > > When I tried I got "Can't find library thingatapt" > > > >> M-x finder-commentary thingatpt > > thingatpt, not thingatapt > ^ > > > emacs -Q > > M-x finder-commentary RET thi TAB RET > ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: RE: RE: RE: bounds-of-thing-at-point for paragraphs 2020-11-01 23:10 ` Christopher Dimech @ 2020-11-02 1:05 ` Drew Adams 0 siblings, 0 replies; 838+ messages in thread From: Drew Adams @ 2020-11-02 1:05 UTC (permalink / raw) To: Christopher Dimech; +Cc: Help Gnu Emacs, Jean Louis > I did 'M-x finder-commentary Ret thing Tab' > which got me Library name: thingatpt.elc > Result: "Can't find library thingatpt" What happens if you type the whole file name? M-x finder-commentary RET thingatpt.el RET It should find that source file, if you have it. Similarly, `M-x find-library thingatpt.el' should find it. Do you have source file thingatpt.el? You should have it, as part of the GNU Emacs distribution. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-01 19:00 ` Drew Adams 2020-11-01 20:07 ` Christopher Dimech @ 2020-11-01 20:36 ` Jean Louis 2020-11-01 21:32 ` Michael Heerdegen 1 sibling, 1 reply; 838+ messages in thread From: Jean Louis @ 2020-11-01 20:36 UTC (permalink / raw) To: Drew Adams; +Cc: Christopher Dimech, Help Gnu Emacs * Drew Adams <drew.adams@oracle.com> [2020-11-01 22:01]: > > > (bounds-of-thing-at-point 'paragraph) works fine. > > > > It works fine, but documentation does not describe it: > > > > bounds-of-thing-at-point is an autoloaded compiled Lisp function in > > ‘thingatpt.el’. > > > > (bounds-of-thing-at-point THING) > > > > Determine the start and end buffer locations for the THING at point. > > THING should be a symbol specifying a type of syntactic entity. > > Possibilities include ‘symbol’, ‘list’, ‘sexp’, ‘defun’, > > ‘filename’, ‘url’, ‘email’, ‘uuid’, ‘word’, ‘sentence’, ‘whitespace’, > > ‘line’, and ‘page’. > > > > See the file ‘thingatpt.el’ for documentation on how to define a > > valid THING. > > > > Return a cons cell (START . END) giving the start and end > > positions of the thing found. > > Just read it more carefully. > > 1. "Possibilities include" > ^^^^^^^ > > It doesn't say that those are the only possibilities. Maybe if I say Sesame open the door... :-) I went into thingatpt.el and I tried searching for "paragraph" and I cannot find it. This opens plethora of possibilities to jump into maybe other files and find "paragraph" defined. > > Return the THING at point. > > THING should be a symbol specifying a type of syntactic entity. > > Possibilities include ‘symbol’, ‘list’, ‘sexp’, ‘defun’, > > ‘filename’, ‘url’, ‘email’, ‘uuid’, ‘word’, ‘sentence’, ‘whitespace’, > > ‘line’, ‘number’, and ‘page’. > > See above. The word "include" doesn't mean the > same thing as "include only" or "comprise". The > list of THINGS mentioned isn't exhaustive. > > The English language includes the words "thing" > and "point" (but it also includes a lot more words). Alright, sure. But that does not make it friendly to user to understand that paragraph is included. Do you have a word "paragraph" in your thingatpt.el? -- There are 57 messages yet in my incoming mailbox. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-01 20:36 ` Jean Louis @ 2020-11-01 21:32 ` Michael Heerdegen 2020-11-01 21:43 ` Jean Louis 2020-11-01 21:43 ` Jean Louis 0 siblings, 2 replies; 838+ messages in thread From: Michael Heerdegen @ 2020-11-01 21:32 UTC (permalink / raw) To: help-gnu-emacs Jean Louis <bugs@gnu.support> writes: > I went into thingatpt.el and I tried searching for "paragraph" and I > cannot find it. This opens plethora of possibilities to jump into > maybe other files and find "paragraph" defined. AFAIU a thing "foo" gets defined as side effect when a function `forward-foo' is defined. Seems actually most "things" are defined that way. Michael. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-01 21:32 ` Michael Heerdegen @ 2020-11-01 21:43 ` Jean Louis 2020-11-01 21:43 ` Jean Louis 1 sibling, 0 replies; 838+ messages in thread From: Jean Louis @ 2020-11-01 21:43 UTC (permalink / raw) To: Michael Heerdegen; +Cc: help-gnu-emacs * Michael Heerdegen <michael_heerdegen@web.de> [2020-11-02 00:33]: > Jean Louis <bugs@gnu.support> writes: > > > I went into thingatpt.el and I tried searching for "paragraph" and I > > cannot find it. This opens plethora of possibilities to jump into > > maybe other files and find "paragraph" defined. > > AFAIU a thing "foo" gets defined as side effect when a function > `forward-foo' is defined. Seems actually most "things" are defined that > way. That's magic ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-01 21:32 ` Michael Heerdegen 2020-11-01 21:43 ` Jean Louis @ 2020-11-01 21:43 ` Jean Louis 1 sibling, 0 replies; 838+ messages in thread From: Jean Louis @ 2020-11-01 21:43 UTC (permalink / raw) To: Michael Heerdegen; +Cc: help-gnu-emacs * Michael Heerdegen <michael_heerdegen@web.de> [2020-11-02 00:33]: > Jean Louis <bugs@gnu.support> writes: > > > I went into thingatpt.el and I tried searching for "paragraph" and I > > cannot find it. This opens plethora of possibilities to jump into > > maybe other files and find "paragraph" defined. > > AFAIU a thing "foo" gets defined as side effect when a function > `forward-foo' is defined. Seems actually most "things" are defined that > way. > > Michael. Then it could magically update the docstring as well. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-01 18:52 ` Jean Louis 2020-11-01 19:00 ` Drew Adams @ 2020-11-01 19:27 ` Eli Zaretskii 2020-11-01 19:51 ` Christopher Dimech 2020-11-01 20:23 ` Michael Heerdegen 1 sibling, 2 replies; 838+ messages in thread From: Eli Zaretskii @ 2020-11-01 19:27 UTC (permalink / raw) To: help-gnu-emacs > Date: Sun, 1 Nov 2020 21:52:32 +0300 > From: Jean Louis <bugs@gnu.support> > Cc: Christopher Dimech <dimech@gmx.com>, > Help Gnu Emacs <help-gnu-emacs@gnu.org> > > Return the THING at point. > THING should be a symbol specifying a type of syntactic entity. > Possibilities include ‘symbol’, ‘list’, ‘sexp’, ‘defun’, > ‘filename’, ‘url’, ‘email’, ‘uuid’, ‘word’, ‘sentence’, ‘whitespace’, > ‘line’, ‘number’, and ‘page’. > > > Could somebody update documentation for those functions? The number of "things" it can support is unbounded. How would you suggest to update the doc string to describe an infinite number of possible objects? ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-01 19:27 ` Eli Zaretskii @ 2020-11-01 19:51 ` Christopher Dimech 2020-11-01 20:00 ` Eli Zaretskii 2020-11-01 21:46 ` Drew Adams 2020-11-01 20:23 ` Michael Heerdegen 1 sibling, 2 replies; 838+ messages in thread From: Christopher Dimech @ 2020-11-01 19:51 UTC (permalink / raw) To: Eli Zaretskii; +Cc: help-gnu-emacs We should include ones that come to our minds would be useful, particularly those customarily dealt by users. Linguistic structures are an example since many Emacs users deal with words, sentences, and paragraphs on a daily basis. More documentation is more useful than less documentation. We can keep the more exotic things off the list. Especially THINGS coming from outer space. > Sent: Sunday, November 01, 2020 at 8:27 PM > From: "Eli Zaretskii" <eliz@gnu.org> > To: help-gnu-emacs@gnu.org > Subject: Re: bounds-of-thing-at-point for paragraphs > > > Date: Sun, 1 Nov 2020 21:52:32 +0300 > > From: Jean Louis <bugs@gnu.support> > > Cc: Christopher Dimech <dimech@gmx.com>, > > Help Gnu Emacs <help-gnu-emacs@gnu.org> > > > > Return the THING at point. > > THING should be a symbol specifying a type of syntactic entity. > > Possibilities include ‘symbol’, ‘list’, ‘sexp’, ‘defun’, > > ‘filename’, ‘url’, ‘email’, ‘uuid’, ‘word’, ‘sentence’, ‘whitespace’, > > ‘line’, ‘number’, and ‘page’. > > > > > > Could somebody update documentation for those functions? > > The number of "things" it can support is unbounded. How would you > suggest to update the doc string to describe an infinite number of > possible objects? > > ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-01 19:51 ` Christopher Dimech @ 2020-11-01 20:00 ` Eli Zaretskii 2020-11-01 20:09 ` Christopher Dimech 2020-11-01 21:46 ` Drew Adams 1 sibling, 1 reply; 838+ messages in thread From: Eli Zaretskii @ 2020-11-01 20:00 UTC (permalink / raw) To: help-gnu-emacs > From: Christopher Dimech <dimech@gmx.com> > Cc: help-gnu-emacs@gnu.org > Date: Sun, 1 Nov 2020 20:51:29 +0100 > > We should include ones that come to our minds would be useful That we did already. In fact, I think the list is too long as it is. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-01 20:00 ` Eli Zaretskii @ 2020-11-01 20:09 ` Christopher Dimech 2020-11-01 20:13 ` Eli Zaretskii 2020-11-01 20:27 ` Emanuel Berg via Users list for the GNU Emacs text editor 0 siblings, 2 replies; 838+ messages in thread From: Christopher Dimech @ 2020-11-01 20:09 UTC (permalink / raw) To: Eli Zaretskii; +Cc: help-gnu-emacs May I have my paragraph if you please? > Sent: Sunday, November 01, 2020 at 9:00 PM > From: "Eli Zaretskii" <eliz@gnu.org> > To: help-gnu-emacs@gnu.org > Subject: Re: bounds-of-thing-at-point for paragraphs > > > From: Christopher Dimech <dimech@gmx.com> > > Cc: help-gnu-emacs@gnu.org > > Date: Sun, 1 Nov 2020 20:51:29 +0100 > > > > We should include ones that come to our minds would be useful > > That we did already. In fact, I think the list is too long as it is. > > > ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-01 20:09 ` Christopher Dimech @ 2020-11-01 20:13 ` Eli Zaretskii 2020-11-01 20:27 ` Emanuel Berg via Users list for the GNU Emacs text editor 1 sibling, 0 replies; 838+ messages in thread From: Eli Zaretskii @ 2020-11-01 20:13 UTC (permalink / raw) To: help-gnu-emacs > From: Christopher Dimech <dimech@gmx.com> > Cc: help-gnu-emacs@gnu.org > Date: Sun, 1 Nov 2020 21:09:08 +0100 > > May I have my paragraph if you please? Paragraphs aren't handled by thingatpt.el. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-01 20:09 ` Christopher Dimech 2020-11-01 20:13 ` Eli Zaretskii @ 2020-11-01 20:27 ` Emanuel Berg via Users list for the GNU Emacs text editor 2020-11-01 20:31 ` Christopher Dimech 1 sibling, 1 reply; 838+ messages in thread From: Emanuel Berg via Users list for the GNU Emacs text editor @ 2020-11-01 20:27 UTC (permalink / raw) To: help-gnu-emacs Christopher Dimech wrote: > May I have my paragraph if you please? Do it yourself: 1. mark-paragraph 2. kill-region 3. re-search-backward for a blank line 4. yank -- underground experts united http://user.it.uu.se/~embe8573 https://dataswamp.org/~incal ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-01 20:27 ` Emanuel Berg via Users list for the GNU Emacs text editor @ 2020-11-01 20:31 ` Christopher Dimech 2020-11-01 22:10 ` Emanuel Berg via Users list for the GNU Emacs text editor 0 siblings, 1 reply; 838+ messages in thread From: Christopher Dimech @ 2020-11-01 20:31 UTC (permalink / raw) To: moasenwood; +Cc: help-gnu-emacs > Sent: Sunday, November 01, 2020 at 9:27 PM > From: "Emanuel Berg via Users list for the GNU Emacs text editor" <help-gnu-emacs@gnu.org> > To: help-gnu-emacs@gnu.org > Subject: Re: bounds-of-thing-at-point for paragraphs > > Christopher Dimech wrote: > > > May I have my paragraph if you please? > > Do it yourself: > > 1. mark-paragraph > > 2. kill-region > > 3. re-search-backward for a blank line > > 4. yank I meant mentioning paragraph in documentation for bounds-of-thing-at-point > > -- > underground experts united > http://user.it.uu.se/~embe8573 > https://dataswamp.org/~incal > > > ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-01 20:31 ` Christopher Dimech @ 2020-11-01 22:10 ` Emanuel Berg via Users list for the GNU Emacs text editor 0 siblings, 0 replies; 838+ messages in thread From: Emanuel Berg via Users list for the GNU Emacs text editor @ 2020-11-01 22:10 UTC (permalink / raw) To: help-gnu-emacs Christopher Dimech wrote: > I meant mentioning paragraph in documentation for > bounds-of-thing-at-point Wha...? :O Heh, I thought you wanted to transpose paragraphs :) -- underground experts united http://user.it.uu.se/~embe8573 https://dataswamp.org/~incal ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: bounds-of-thing-at-point for paragraphs 2020-11-01 19:51 ` Christopher Dimech 2020-11-01 20:00 ` Eli Zaretskii @ 2020-11-01 21:46 ` Drew Adams 1 sibling, 0 replies; 838+ messages in thread From: Drew Adams @ 2020-11-01 21:46 UTC (permalink / raw) To: Christopher Dimech, Eli Zaretskii; +Cc: help-gnu-emacs > We can keep the more exotic things off the list. > Especially THINGS coming from outer space. Paragraphs come from outer space, like all other things. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-01 19:27 ` Eli Zaretskii 2020-11-01 19:51 ` Christopher Dimech @ 2020-11-01 20:23 ` Michael Heerdegen 2020-11-01 20:29 ` Christopher Dimech 2020-11-01 21:01 ` Stefan Monnier 1 sibling, 2 replies; 838+ messages in thread From: Michael Heerdegen @ 2020-11-01 20:23 UTC (permalink / raw) To: help-gnu-emacs Eli Zaretskii <eliz@gnu.org> writes: > > Could somebody update documentation for those functions? > > The number of "things" it can support is unbounded. How would you > suggest to update the doc string to describe an infinite number of > possible objects? I think for discoverability for non-Elisp-programmer Emacs users it would be nice at least if there was something that would dynamically generate a list for you. Michael. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-01 20:23 ` Michael Heerdegen @ 2020-11-01 20:29 ` Christopher Dimech 2020-11-01 22:10 ` Drew Adams 2020-11-01 21:01 ` Stefan Monnier 1 sibling, 1 reply; 838+ messages in thread From: Christopher Dimech @ 2020-11-01 20:29 UTC (permalink / raw) To: Michael Heerdegen; +Cc: help-gnu-emacs > I think for discoverability for non-Elisp-programmer Emacs users it > would be nice at least if there was something that would dynamically > generate a list for you. Fully agree. A list is a beautiful thing. --------------------- Christopher Dimech General Administrator - Naiad Informatics - GNU Project (Geocomputation) - Geophysical Simulation - Geological Subsurface Mapping - Disaster Preparedness and Mitigation - Natural Resource Exploration and Production - Free Software Advocacy > Sent: Sunday, November 01, 2020 at 9:23 PM > From: "Michael Heerdegen" <michael_heerdegen@web.de> > To: help-gnu-emacs@gnu.org > Subject: Re: bounds-of-thing-at-point for paragraphs > > Eli Zaretskii <eliz@gnu.org> writes: > > > > Could somebody update documentation for those functions? > > > > The number of "things" it can support is unbounded. How would you > > suggest to update the doc string to describe an infinite number of > > possible objects? > > I think for discoverability for non-Elisp-programmer Emacs users it > would be nice at least if there was something that would dynamically > generate a list for you. > > Michael. > > > ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: bounds-of-thing-at-point for paragraphs 2020-11-01 20:29 ` Christopher Dimech @ 2020-11-01 22:10 ` Drew Adams 0 siblings, 0 replies; 838+ messages in thread From: Drew Adams @ 2020-11-01 22:10 UTC (permalink / raw) To: Christopher Dimech, Michael Heerdegen; +Cc: help-gnu-emacs > > I think for discoverability for non-Elisp-programmer Emacs users it > > would be nice at least if there was something that would dynamically > > generate a list for you. > > Fully agree. A list is a beautiful thing. I use this, which is a straightforward definition from the thingatpt.el Commentary. (defun icicle-defined-thing-p (thing) "Return non-nil if THING is defined as a thing-at-point type. THING is normally a symbol, but it can also be a string that names a symbol or a cons whose car is such a string. This is so that the function can be used to filter completion candidates." (when (consp thing) (setq thing (car thing))) (when (stringp thing) (setq thing (intern thing))) (let ((forward-op (or (get thing 'forward-op) (intern-soft (format "forward-%s" thing)))) (beginning-op (get thing 'beginning-op)) (end-op (get thing 'end-op)) (bounds-fn (get thing 'bounds-of-thing-at-point)) (thing-fn (get thing 'thing-at-point))) (or (functionp forward-op) (and (functionp beginning-op) (functionp end-op)) (functionp bounds-fn) (functionp thing-fn)))) (defun icicle-things-alist () "Alist of most thing types currently defined. Each is a cons (STRING), where STRING names a type of text entity for which there is a either a corresponding `forward-'thing operation, or corresponding `beginning-of-'thing and `end-of-'thing operations. The list includes the names of the symbols that satisfy `icicle-defined-thing-p', but with these excluded: `thing', `buffer', `point'." (let ((types ())) (mapatoms (lambda (tt) (when (icicle-defined-thing-p tt) (push (symbol-name tt) types)))) ;; Remove types that don't make sense. (dolist (typ '("thing" "buffer" "point")) (setq types (delete typ types))) (setq types (sort types #'string-lessp)) (mapcar #'list types))) Remove the mapcar sexp in the latter definition, if you want just a list, not an alist, of names. Map `intern' over the list if you want symbols instead of strings. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-01 20:23 ` Michael Heerdegen 2020-11-01 20:29 ` Christopher Dimech @ 2020-11-01 21:01 ` Stefan Monnier 1 sibling, 0 replies; 838+ messages in thread From: Stefan Monnier @ 2020-11-01 21:01 UTC (permalink / raw) To: help-gnu-emacs > I think for discoverability for non-Elisp-programmer Emacs users it > would be nice at least if there was something that would dynamically > generate a list for you. `C-h o` can display a dynamically-generated list. E.g. we do that for `pcase` (to list available patterns) and for generic functions (to list existing methods). Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: bounds-of-thing-at-point for paragraphs 2020-11-01 18:34 ` Christopher Dimech 2020-11-01 18:45 ` Drew Adams @ 2020-11-01 18:45 ` Jean Louis 2020-11-01 18:51 ` Drew Adams 1 sibling, 1 reply; 838+ messages in thread From: Jean Louis @ 2020-11-01 18:45 UTC (permalink / raw) To: Christopher Dimech; +Cc: Help Gnu Emacs * Christopher Dimech <dimech@gmx.com> [2020-11-01 21:35]: > Yes, but transpose-paragraph does not keep at the same point > position. You can remember the point and restore it. Make new function with: 1. Remember (point) 2. transpose-paragraph 3. (posn-set-point POSITION) > I was asking how bounds-of-thing-at-point does not take paragraph as > argument as well, since it does for word, sentence, line. Can > paragraph be included as well? You could try to define it. There is function org--paragraph-at-point that gives information about paragraph at point. Try it out. -- There are 50 messages yet in my incoming mailbox. ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: bounds-of-thing-at-point for paragraphs 2020-11-01 18:45 ` Jean Louis @ 2020-11-01 18:51 ` Drew Adams 0 siblings, 0 replies; 838+ messages in thread From: Drew Adams @ 2020-11-01 18:51 UTC (permalink / raw) To: Jean Louis, Christopher Dimech; +Cc: Help Gnu Emacs > > I was asking how bounds-of-thing-at-point does not take paragraph as > > argument as well, since it does for word, sentence, line. Can > > paragraph be included as well? > > You could try to define it. There is function org--paragraph-at-point > that gives information about paragraph at point. Try it out. No need. From the Commentary of file `thingatpt.el': ;; The function bounds-of-thing-at-point finds the beginning and end ;; positions by moving first forward to the end of the "thing", and then ;; backwards to the beginning. By default, it uses the corresponding ;; forward-"thing" operator (eg. forward-word, forward-line). ;; ;; Special cases are allowed for using properties associated with the named ;; "thing": ;; ;; forward-op Function to call to skip forward over a "thing" (or ;; with a negative argument, backward). ;; ;; beginning-op Function to call to skip to the beginning of a "thing". ;; end-op Function to call to skip to the end of a "thing". ;; ;; Reliance on existing operators means that many `things' can be accessed ;; without further code: eg. ;; (thing-at-point 'line) ;; (thing-at-point 'page) It's enough that there's a function `forward-paragraph' that moves forward over a paragraph. `thing-at-point' is designed to be usable out of the box with LOTS of things. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Proposal for an Emacs User Survey
@ 2020-10-08 15:30 Adrien Brochard
2020-10-08 17:27 ` Philip K.
` (3 more replies)
0 siblings, 4 replies; 838+ messages in thread
From: Adrien Brochard @ 2020-10-08 15:30 UTC (permalink / raw)
To: emacs-devel
Hi everyone,
I posted on reddit.com/r/emacs yesterday a proposal to craft and
distribute a survey for Emacs users to better grasp the diversity and
various usages out there. I got some very good feedback but there could
always be more.
The main points that need to be worked out are:
1. the actual questions to be asked
2. the platform to collect responses
Regarding the questions, I have a decent skeleton and a lot of suggestions.
But the for the platform to collect responses, this is where it gets
difficult. Something like a Google survey might the easiest/cheapest to
make and distribute and will work on most devices, but it obviously has
privacy concerns. On the other hand, doing something like self-hosting a
no-JS form is very time consuming. I was also thinking of allowing
responses via email for people who do not want to bother with a survey
link and then manually reconcile responses.
Links to the posts with the tentative questions:
-
https://www.reddit.com/r/emacs/comments/j6x7ad/proposal_for_an_emacs_user_survey/
-
https://www.reddit.com/r/emacs/comments/b2fh4y/help_reviewprovide_feedback_on_state_of_emacs/
Thank you for reading!
Best,
Adrien
^ permalink raw reply [flat|nested] 838+ messages in thread* Re: Proposal for an Emacs User Survey 2020-10-08 15:30 Proposal for an Emacs User Survey Adrien Brochard @ 2020-10-08 17:27 ` Philip K. 2020-10-08 17:45 ` Adrien Brochard 2020-10-09 0:41 ` Karl Fogel ` (2 subsequent siblings) 3 siblings, 1 reply; 838+ messages in thread From: Philip K. @ 2020-10-08 17:27 UTC (permalink / raw) To: Adrien Brochard; +Cc: emacs-devel Adrien Brochard <abrochard@gmx.com> writes: > Hi everyone, > > I posted on reddit.com/r/emacs yesterday a proposal to craft and > distribute a survey for Emacs users to better grasp the diversity and > various usages out there. I got some very good feedback but there could > always be more. > > The main points that need to be worked out are: > 1. the actual questions to be asked > 2. the platform to collect responses I think a major problem is how to get as many emacs users -- and not only reddit -- to participate. There are plenty of Emacs users who neither follow the mailing lists, nor use sites like Reddit. Many of them have had similar setups for years, and don't need to think about it. Of course I can inform those I am antiquated with, but that approach has it's limits. There is a disconnect between these two groups. Of course, neither is "right". I've seen "traditional users" who didn't know that M-x could be invoked using the alt key (instead pressing escape and then "x"), and newer users who use try to get as much of emacs out of the way, to use things like org or magit. My fear is that those in the latter group are more likely to hear about a poll like this, and be overrepresented at the expense of the former. And without a way to prove anything, either way, no real progress could be achieved -- one group will keep on saying that "it's time to become vs code" and the others will invoke a virtual "silent minority". > Regarding the questions, I have a decent skeleton and a lot of suggestions. > > But the for the platform to collect responses, this is where it gets > difficult. Something like a Google survey might the easiest/cheapest to > make and distribute and will work on most devices, but it obviously has > privacy concerns. On the other hand, doing something like self-hosting a > no-JS form is very time consuming. I was also thinking of allowing > responses via email for people who do not want to bother with a survey > link and then manually reconcile responses. Why not just create a simple HTML form with a captcha (not Google's thing, but a simple library that generates an image)? > Links to the posts with the tentative questions: > - > https://www.reddit.com/r/emacs/comments/j6x7ad/proposal_for_an_emacs_user_survey/ > - > https://www.reddit.com/r/emacs/comments/b2fh4y/help_reviewprovide_feedback_on_state_of_emacs/ > > Thank you for reading! > Best, > Adrien > > -- Philip K. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-08 17:27 ` Philip K. @ 2020-10-08 17:45 ` Adrien Brochard 2020-10-09 11:30 ` Philip K. 2020-10-09 17:59 ` Jean Louis 0 siblings, 2 replies; 838+ messages in thread From: Adrien Brochard @ 2020-10-08 17:45 UTC (permalink / raw) To: Philip K.; +Cc: emacs-devel Thank you for your response! > > I think a major problem is how to get as many emacs users -- and not > only reddit -- to participate. There are plenty of Emacs users who > neither follow the mailing lists, nor use sites like Reddit. Many of > them have had similar setups for years, and don't need to think about > it. Of course I can inform those I am antiquated with, but that approach > has it's limits. There is a real risk indeed of selection bias because it is hard to reach out to people who are not on the mailing list or on popular channels. I identified this issue on the reddit post, but aside from sharing the survey on the mailing list/reddit/irc/telegram/blogs and keeping the survey open for 1 month, I am not sure how to mitigate more. It is in a way the fundamental problem of surveys though. And I should specify that there's value in just getting any response, and that we should be mindful of this selection bias risk and not make carefree decisions based on the survey results. > Why not just create a simple HTML form with a captcha (not Google's > thing, but a simple library that generates an image)? I know it sounds easy, but it can rapidly become a considerable amount of work. The captcha is not trivial and then there's the question of the backend and where the data goes. To limit barrier of entry, the survey must be as easy to fill out as possible. That means that we can't have downtime, lag, and work on mobile too. I am more inclined to trust that work to professionals and have to pay a little for it. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-08 17:45 ` Adrien Brochard @ 2020-10-09 11:30 ` Philip K. 2020-10-09 14:37 ` tomas 2020-10-09 17:23 ` Adrien Brochard 2020-10-09 17:59 ` Jean Louis 1 sibling, 2 replies; 838+ messages in thread From: Philip K. @ 2020-10-09 11:30 UTC (permalink / raw) To: Adrien Brochard; +Cc: emacs-devel Adrien Brochard <abrochard@gmx.com> writes: >> Why not just create a simple HTML form with a captcha (not Google's >> thing, but a simple library that generates an image)? > > I know it sounds easy, but it can rapidly become a considerable amount > of work. The captcha is not trivial and then there's the question of the > backend and where the data goes. To limit barrier of entry, the survey > must be as easy to fill out as possible. That means that we can't have > downtime, lag, and work on mobile too. I am more inclined to trust that > work to professionals and have to pay a little for it. For the fun of it, I wrote a simple survey application[0] that includes a self-hosted captcha (without tracking anyone), requires no Javascript, is mobile friendly and should be fairly fast. Of course it can be improved. I wrote it as a quick and dirty evening project, but I think it demonstrates that this kind of an approach is practicable. [0] https://git.sr.ht/~zge/survey -- Philip K. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-09 11:30 ` Philip K. @ 2020-10-09 14:37 ` tomas 2020-10-09 17:23 ` Adrien Brochard 1 sibling, 0 replies; 838+ messages in thread From: tomas @ 2020-10-09 14:37 UTC (permalink / raw) To: Philip K.; +Cc: Adrien Brochard, emacs-devel [-- Attachment #1: Type: text/plain, Size: 320 bytes --] On Fri, Oct 09, 2020 at 01:30:48PM +0200, Philip K. wrote: [...] > For the fun of it, I wrote a simple survey application[0] [...] Thanks! I'll look into it. Perhaps I'll even steal something from it -- I'll let you know. Who knows. We might need something akin to suckless, for the web :) Cheers - t [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-09 11:30 ` Philip K. 2020-10-09 14:37 ` tomas @ 2020-10-09 17:23 ` Adrien Brochard 2020-10-09 18:17 ` Philip K. 1 sibling, 1 reply; 838+ messages in thread From: Adrien Brochard @ 2020-10-09 17:23 UTC (permalink / raw) To: Philip K.; +Cc: emacs-devel > For the fun of it, I wrote a simple survey application[0] that includes > a self-hosted captcha (without tracking anyone), requires no Javascript, > is mobile friendly and should be fairly fast. Of course it can be > improved. I wrote it as a quick and dirty evening project, but I > think it demonstrates that this kind of an approach is practicable. > > [0] https://git.sr.ht/~zge/survey Thank you! I really like reading go code (no sarcasm). It it clear that this approach will work but the remaining 20% are the hardest. I'm concerned with: - cleaner UI, not just HTML embedded in the code - mysql instead of sqlite, which also implies a mysql instance running - DOS protection, maybe some rate-limiting and IP blocking - HTTPS, thankfully it's easier now - monitoring, how do we know the service is running as expected - logging, and how to store logs for debug My greatest fear is people clicking on the link, filling out the form, trying to submit, seeing an error page, and never coming back to it. Best, Adrien ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-09 17:23 ` Adrien Brochard @ 2020-10-09 18:17 ` Philip K. 2020-10-09 19:52 ` Adrien Brochard 0 siblings, 1 reply; 838+ messages in thread From: Philip K. @ 2020-10-09 18:17 UTC (permalink / raw) To: Adrien Brochard; +Cc: emacs-devel Adrien Brochard <abrochard@gmx.com> writes: >> For the fun of it, I wrote a simple survey application[0] that includes >> a self-hosted captcha (without tracking anyone), requires no Javascript, >> is mobile friendly and should be fairly fast. Of course it can be >> improved. I wrote it as a quick and dirty evening project, but I >> think it demonstrates that this kind of an approach is practicable. >> >> [0] https://git.sr.ht/~zge/survey > > Thank you! I really like reading go code (no sarcasm). > It it clear that this approach will work but the remaining 20% are the > hardest. I'm concerned with: > - cleaner UI, not just HTML embedded in the code What would you have in mind? I know that my example is simple, but I prefer that to sites that take forever to load and reload everything all the time, for no apparent reason. > - mysql instead of sqlite, which also implies a mysql instance running SQLite is actually surprisingly resilient, according to [0]: > SQLite works great as the database engine for most low to medium traffic > websites (which is to say, most websites). The amount of web traffic > that SQLite can handle depends on how heavily the website uses its > database. Generally speaking, any site that gets fewer than 100K > hits/day should work fine with SQLite. The 100K hits/day figure is a > conservative estimate, not a hard upper bound. SQLite has been > demonstrated to work with 10 times that amount of traffic. But either way, I used sqlite to avoid setting up a RDBMS. [0] https://www.sqlite.org/whentouse.html > - DOS protection, maybe some rate-limiting and IP blocking > - HTTPS, thankfully it's easier now AFAIK these things can usually be handled by a frond-end such as NGINX. > - monitoring, how do we know the service is running as expected > - logging, and how to store logs for debug If there is any interest, extending the example to support this would be feasible. The "20%" you mention aren't easy, but from what I see it shouldn't be too hard either. > My greatest fear is people clicking on the link, filling out the form, > trying to submit, seeing an error page, and never coming back to it. The reason I suggested using a simple HTML form and implemented the demo was because I think simplicity helps avoid a lot of issues. With fewer dependencies, secondary services, modules, etc. the chance of one of these failing decreases. And having a smaller footprint should also reduce the network load. > Best, > Adrien -- Philip K. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-09 18:17 ` Philip K. @ 2020-10-09 19:52 ` Adrien Brochard 2020-10-10 3:56 ` Richard Stallman 2020-10-10 10:35 ` Philip K. 0 siblings, 2 replies; 838+ messages in thread From: Adrien Brochard @ 2020-10-09 19:52 UTC (permalink / raw) To: Philip K.; +Cc: emacs-devel >> - cleaner UI, not just HTML embedded in the code > > What would you have in mind? I know that my example is simple, but I > prefer that to sites that take forever to load and reload everything all > the time, for no apparent reason. The most obvious reason to me is that user error handling is pretty poor. Because there is no JS, we cannot offer front-end validation, that means that the backend server is responsible for validating fields submitted. If validation does not pass, the page must "reload" for the user and it needs to show exactly what went wrong and preserve the user input. That's my definition of a site that reloads all the time. >> - mysql instead of sqlite, which also implies a mysql instance running > > SQLite is actually surprisingly resilient, according to [0]: > >> SQLite works great as the database engine for most low to medium traffic >> websites (which is to say, most websites). The amount of web traffic >> that SQLite can handle depends on how heavily the website uses its >> database. Generally speaking, any site that gets fewer than 100K >> hits/day should work fine with SQLite. The 100K hits/day figure is a >> conservative estimate, not a hard upper bound. SQLite has been >> demonstrated to work with 10 times that amount of traffic. > > But either way, I used sqlite to avoid setting up a RDBMS. > > [0] https://www.sqlite.org/whentouse.html SQLite is resilient but it's dangerous to use it with multiple threads like how your go server does. You could use a single channel model to write records one at a time but now you have a risk to lose data from memory if your service restarts. > >> - DOS protection, maybe some rate-limiting and IP blocking >> - HTTPS, thankfully it's easier now > > AFAIK these things can usually be handled by a frond-end such as NGINX. That's true it can, but that means you need to deploy and configure one. https://www.nginx.com/blog/rate-limiting-nginx/ https://nginx.org/en/docs/http/configuring_https_servers.html >> - monitoring, how do we know the service is running as expected >> - logging, and how to store logs for debug > > If there is any interest, extending the example to support this would be > feasible. The "20%" you mention aren't easy, but from what I see it > shouldn't be too hard either. You're absolutely right. None of it is "too hard". But the problem is just how much time and effort are we willing to put into it. If the goal is to make an open source polling platform that we can re-use in the future, then absolutely all of this can be done. But if we treat this as a one-off and see how it turns out, the scope seems exaggerated. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-09 19:52 ` Adrien Brochard @ 2020-10-10 3:56 ` Richard Stallman 2020-10-10 9:36 ` Philip K. 2020-10-11 1:00 ` Drew Adams 2020-10-10 10:35 ` Philip K. 1 sibling, 2 replies; 838+ messages in thread From: Richard Stallman @ 2020-10-10 3:56 UTC (permalink / raw) To: Adrien Brochard; +Cc: philipk, emacs-devel [[[ 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. ]]] > The most obvious reason to me is that user error handling is pretty > poor. Because there is no JS, we cannot offer front-end validation, that > means that the backend server is responsible for validating fields > submitted. If we want to learn what users think, we should not limit their responses to a small set of 'valid" possible answers. The plan I designed for inquiries asks users to answer in their own words. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-10 3:56 ` Richard Stallman @ 2020-10-10 9:36 ` Philip K. 2020-10-10 16:33 ` Drew Adams 2020-10-11 10:46 ` Jean Louis 2020-10-11 1:00 ` Drew Adams 1 sibling, 2 replies; 838+ messages in thread From: Philip K. @ 2020-10-10 9:36 UTC (permalink / raw) To: rms; +Cc: abrochard, emacs-devel 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. ]]] > > > The most obvious reason to me is that user error handling is pretty > > poor. Because there is no JS, we cannot offer front-end validation, that > > means that the backend server is responsible for validating fields > > submitted. > > If we want to learn what users think, we should not limit their > responses to a small set of 'valid" possible answers. The plan > I designed for inquiries asks users to answer in their own words. But wouldn't that make it needlessly hard to analyse the results, especially if the question should be numerically quantified? I get the value of plain text responses, but recognizing that the answer to the question "how long have you been using emacs", could result in: - "Since 1996" - "24 Years" - "January 1996" - "Around the second time Clinton got sworn into office" - "1896" (but actually a typo) All of these basically mean the same, but the effort to recognize this automatically (which would be necessary, if you want to see how factors correlate) would not be worth it. -- Philip K. ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Proposal for an Emacs User Survey 2020-10-10 9:36 ` Philip K. @ 2020-10-10 16:33 ` Drew Adams 2020-10-10 18:02 ` Dmitry Gutov 2020-10-11 10:46 ` Jean Louis 1 sibling, 1 reply; 838+ messages in thread From: Drew Adams @ 2020-10-10 16:33 UTC (permalink / raw) To: Philip K., rms; +Cc: abrochard, emacs-devel > > If we want to learn what users think, we should not limit their > > responses to a small set of 'valid" possible answers. The plan > > I designed for inquiries asks users to answer in their own words. > > But wouldn't that make it needlessly hard to analyse the results, Ease in handling the results shouldn't be a major consideration. Quality of the feedback and quality of its analysis is more important that speed or ease. > especially if the question should be numerically quantified? Quantification of bad-quality information doesn't help. Better to get a high-quality understanding, and if some quantification _then_ helps then do it. > I get the value of plain text responses, but recognizing that the answer to the > question "how long have you been using emacs", could result in: > > - "Since 1996" > - "24 Years" > - "January 1996" > - "Around the second time Clinton got sworn into office" > - "1896" (but actually a typo) A very specific question like that can be asked in specific terms: how many years. But even that is likely to be misleading, if kept apart from considerations of kind and degree of use. Getting a good picture of Emacs users and uses is not easy, nor should it be. And again, users _reasons_ for actions, preferences, etc. are important. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-10 16:33 ` Drew Adams @ 2020-10-10 18:02 ` Dmitry Gutov 0 siblings, 0 replies; 838+ messages in thread From: Dmitry Gutov @ 2020-10-10 18:02 UTC (permalink / raw) To: Drew Adams, Philip K., rms; +Cc: abrochard, emacs-devel On 10.10.2020 19:33, Drew Adams wrote: > Ease in handling the results shouldn't be a major > consideration. Quality of the feedback and quality > of its analysis is more important that speed or ease. Difficulty in analysis is likely to result in a lack of transparency of such analysis's results. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-10 9:36 ` Philip K. 2020-10-10 16:33 ` Drew Adams @ 2020-10-11 10:46 ` Jean Louis 2020-10-11 18:42 ` Philip K. 1 sibling, 1 reply; 838+ messages in thread From: Jean Louis @ 2020-10-11 10:46 UTC (permalink / raw) To: Philip K.; +Cc: abrochard, rms, emacs-devel * Philip K. <philipk@posteo.net> [2020-10-10 12:37]: > 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. ]]] > > > > > The most obvious reason to me is that user error handling is pretty > > > poor. Because there is no JS, we cannot offer front-end validation, that > > > means that the backend server is responsible for validating fields > > > submitted. > > > > If we want to learn what users think, we should not limit their > > responses to a small set of 'valid" possible answers. The plan > > I designed for inquiries asks users to answer in their own words. > > But wouldn't that make it needlessly hard to analyse the results, > especially if the question should be numerically quantified? As I have done larger surveys for public relations and I know methods, I know how tedious it is to evaluate such survey, we have been employing many people, like 20 people, to just analyze what exactly did people check or did not check, what did they write, to read their handwriting, and then to properly analyze it. However, Emacs feature requests or survey about using Emacs need live user, not user as a number. > I get the value of plain text responses, but recognizing that the > answer to the question "how long have you been using emacs", could > result in: > > - "Since 1996" > - "24 Years" > - "January 1996" > - "Around the second time Clinton got sworn into office" > - "1896" (but actually a typo) > > All of these basically mean the same, but the effort to recognize this > automatically (which would be necessary, if you want to see how factors > correlate) would not be worth it. It is better not to do it automatically. Emacs is developed through number of developers, they are not doing development automatically, they are well coordinating and collaborating with each other. Any user who is sending a request is also collaborating in such development by proposing features or telling about dislikes, telling their opinion. Those users are valuable, their answers should not remain as numbers on the paper, or communication that comes only one time. Kind answer on their email or requests, likes or dislikes, will involve users into collaboration and coordination and better understanding of what such users were thinking. We already have mailing lists for Emacs, but we do not have it well integrated into Emacs, that users can find out about it. So I am proposing to follow the friendly GNU Hyperbole https://www.gnu.org/s/hyperbole example, where Bob Weiner have implemented Hyperbole menu, from which every user is enabled to subscribe to Hyperbole mailing list or to send email to Hyperbole mailing list. Thus menu item like "Tell us how to improve Emacs?" in Help menu could be the initiation to such collaboration. And I think that many Emacs users do not use Emacs to send email, so there shall be option by using eww, to send a form, and form can be already packaged with Emacs. Thus user could decide to: - subscribe to improvement mailing list - send email with or without subscription, just as almost any GNU list, - unsubscribe - or send a WWW form, by using eww function The form would be in HTML format, accessible to eww easily. Over time, the form could be improved or changed in new versions. It could include free field to write what one wants, or it could include set of question as well. Now this opens the question that the other mailing list, help-gnu-emacs should also be integrated in the menu, just as the user survey. I recommend everybody to install hyperbole package and to see how it was implemented, it gives incentive to user to collaborate and coordinate, and if it would not be implemented in the menu, user would hardly find the mailing list. Jean ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-11 10:46 ` Jean Louis @ 2020-10-11 18:42 ` Philip K. 2020-10-11 19:46 ` Jean Louis 0 siblings, 1 reply; 838+ messages in thread From: Philip K. @ 2020-10-11 18:42 UTC (permalink / raw) To: Jean Louis; +Cc: abrochard, rms, emacs-devel Jean Louis <bugs@gnu.support> writes: > * Philip K. <philipk@posteo.net> [2020-10-10 12:37]: >> 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. ]]] >> > >> > > The most obvious reason to me is that user error handling is pretty >> > > poor. Because there is no JS, we cannot offer front-end validation, that >> > > means that the backend server is responsible for validating fields >> > > submitted. >> > >> > If we want to learn what users think, we should not limit their >> > responses to a small set of 'valid" possible answers. The plan >> > I designed for inquiries asks users to answer in their own words. >> >> But wouldn't that make it needlessly hard to analyse the results, >> especially if the question should be numerically quantified? > > As I have done larger surveys for public relations and I know methods, > I know how tedious it is to evaluate such survey, we have been > employing many people, like 20 people, to just analyze what exactly > did people check or did not check, what did they write, to read their > handwriting, and then to properly analyze it. > > However, Emacs feature requests or survey about using Emacs need live > user, not user as a number. Of course, but there are still numbers that describe aggregate phenomenons that individual users don't actively notice. A question I would be interested in is what the correlation is between people who use specific configuration-templates (Doom, Spacemacs, etc.) and how long they have been using Emacs/Age. Depending on what the results are, we would have a batter guess as to whether the popularity of these templates is just because newer users aren't secure in configuring their own Emacs, or if people just like these templates in general (what they like is individual, that's where plain text responses are interesting). Other than that, I don't see why both approaches should be possible. Mixed, or separated, you can ask multiple/single choice questions for "hard data", and plain text for individual opinions. -- Philip K. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-11 18:42 ` Philip K. @ 2020-10-11 19:46 ` Jean Louis 0 siblings, 0 replies; 838+ messages in thread From: Jean Louis @ 2020-10-11 19:46 UTC (permalink / raw) To: Philip K.; +Cc: abrochard, rms, emacs-devel * Philip K. <philipk@posteo.net> [2020-10-11 21:42]: > Jean Louis <bugs@gnu.support> writes: > > > * Philip K. <philipk@posteo.net> [2020-10-10 12:37]: > >> 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. ]]] > >> > > >> > > The most obvious reason to me is that user error handling is pretty > >> > > poor. Because there is no JS, we cannot offer front-end validation, that > >> > > means that the backend server is responsible for validating fields > >> > > submitted. > >> > > >> > If we want to learn what users think, we should not limit their > >> > responses to a small set of 'valid" possible answers. The plan > >> > I designed for inquiries asks users to answer in their own words. > >> > >> But wouldn't that make it needlessly hard to analyse the results, > >> especially if the question should be numerically quantified? > > > > As I have done larger surveys for public relations and I know methods, > > I know how tedious it is to evaluate such survey, we have been > > employing many people, like 20 people, to just analyze what exactly > > did people check or did not check, what did they write, to read their > > handwriting, and then to properly analyze it. > > > > However, Emacs feature requests or survey about using Emacs need live > > user, not user as a number. > > Of course, but there are still numbers that describe aggregate > phenomenons that individual users don't actively notice. A question I > would be interested in is what the correlation is between people who use > specific configuration-templates (Doom, Spacemacs, etc.) and how long > they have been using Emacs/Age. Depending on what the results are, we > would have a batter guess as to whether the popularity of these > templates is just because newer users aren't secure in configuring their > own Emacs, or if people just like these templates in general (what they > like is individual, that's where plain text responses are > interesting). I have the book of I guess Robert Kyosaki here, I cannot find at moment exact reference, the idea I got from the book (or maybe not), is that surveys can be done easily, one can start asking even less number of users and with simple questions, and one will very soon find a pattern that becomes very probable final survey result. As those configuration templates are located on Microsoft Github, one way to make the survey or find out that information is to submit the issue there in each configuration, and simply ask them, you will find out. Another fact is that developers of those configurations obviously already did their own analysis on what is needed and wanted and produced that what became popular configuration. Their survey is already done. Thus if Spacemacs configuration is most popular, then core Emacs developers could use those results of established famous features and see if anything could be implemented easier from upstream. My personal view point on Spacesmacs, Doom, etc. is that those group of people like shiny, like showing off their theming, they have time for their hobby, but I have not researched enough, did not install any of those, I don't even install external themes, I use only those built ins. ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Proposal for an Emacs User Survey 2020-10-10 3:56 ` Richard Stallman 2020-10-10 9:36 ` Philip K. @ 2020-10-11 1:00 ` Drew Adams 1 sibling, 0 replies; 838+ messages in thread From: Drew Adams @ 2020-10-11 1:00 UTC (permalink / raw) To: rms, Adrien Brochard; +Cc: philipk, emacs-devel > If we want to learn what users think, we should not limit their > responses to a small set of 'valid" possible answers. The plan > I designed for inquiries asks users to answer in their own words. That's my suggestion as well. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-09 19:52 ` Adrien Brochard 2020-10-10 3:56 ` Richard Stallman @ 2020-10-10 10:35 ` Philip K. 2020-10-11 5:24 ` Richard Stallman 2020-10-11 7:31 ` Tomas Hlavaty 1 sibling, 2 replies; 838+ messages in thread From: Philip K. @ 2020-10-10 10:35 UTC (permalink / raw) To: Adrien Brochard; +Cc: emacs-devel Adrien Brochard <abrochard@gmx.com> writes: >>> - cleaner UI, not just HTML embedded in the code >> >> What would you have in mind? I know that my example is simple, but I >> prefer that to sites that take forever to load and reload everything all >> the time, for no apparent reason. > > The most obvious reason to me is that user error handling is pretty > poor. Because there is no JS, we cannot offer front-end validation, that > means that the backend server is responsible for validating fields > submitted. If validation does not pass, the page must "reload" for the > user and it needs to show exactly what went wrong and preserve the user > input. That's my definition of a site that reloads all the time. That could be mitigated with a "graceful degradation" approach, since most people do have javascript activated by default. HTML5 also has a few attributes that could help, such as pattern or required, depending on what questions are being asked. >>> - mysql instead of sqlite, which also implies a mysql instance running >> >> SQLite is actually surprisingly resilient, according to [0]: >> >>> SQLite works great as the database engine for most low to medium traffic >>> websites (which is to say, most websites). The amount of web traffic >>> that SQLite can handle depends on how heavily the website uses its >>> database. Generally speaking, any site that gets fewer than 100K >>> hits/day should work fine with SQLite. The 100K hits/day figure is a >>> conservative estimate, not a hard upper bound. SQLite has been >>> demonstrated to work with 10 times that amount of traffic. >> >> But either way, I used sqlite to avoid setting up a RDBMS. >> >> [0] https://www.sqlite.org/whentouse.html > > SQLite is resilient but it's dangerous to use it with multiple threads > like how your go server does. You could use a single channel model to > write records one at a time but now you have a risk to lose data from > memory if your service restarts. I'm familiar with the danger, but it shouldn't be a problem. As pointed out in [0], one can activate the SQLite mutex per flag. But at the same time, even sites as popular as Hacker News are alleged to use SQLite as their backend. [0] https://github.com/mattn/go-sqlite3/issues/249 >> >>> - DOS protection, maybe some rate-limiting and IP blocking >>> - HTTPS, thankfully it's easier now >> >> AFAIK these things can usually be handled by a frond-end such as NGINX. > > That's true it can, but that means you need to deploy and configure one. > https://www.nginx.com/blog/rate-limiting-nginx/ > https://nginx.org/en/docs/http/configuring_https_servers.html Perhaps using Guix could make that easier: https://guix.gnu.org/manual/devel/en/html_node/Web-Services.html#NGINX? >>> - monitoring, how do we know the service is running as expected >>> - logging, and how to store logs for debug >> >> If there is any interest, extending the example to support this would be >> feasible. The "20%" you mention aren't easy, but from what I see it >> shouldn't be too hard either. > > You're absolutely right. None of it is "too hard". But the problem is > just how much time and effort are we willing to put into it. If the goal > is to make an open source polling platform that we can re-use in the > future, then absolutely all of this can be done. But if we treat this as > a one-off and see how it turns out, the scope seems exaggerated. Depending on how many people participate, it would be interesting the repeat the survey year-by-year, so that trends and changes in the user-base can be recognized. -- Philip K. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-10 10:35 ` Philip K. @ 2020-10-11 5:24 ` Richard Stallman 2020-10-11 17:59 ` Philip K. 2020-10-11 7:31 ` Tomas Hlavaty 1 sibling, 1 reply; 838+ messages in thread From: Richard Stallman @ 2020-10-11 5:24 UTC (permalink / raw) To: Philip K.; +Cc: abrochard, emacs-devel [[[ 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. ]]] > > The most obvious reason to me is that user error handling is pretty > > poor. Because there is no JS, we cannot offer front-end validation, that > > means that the backend server is responsible for validating fields > > submitted. If validation does not pass, the page must "reload" for the > > user and it needs to show exactly what went wrong and preserve the user > > input. That's my definition of a site that reloads all the time. > That could be mitigated with a "graceful degradation" approach, since > most people do have javascript activated by default. HTML5 also has a > few attributes that could help, such as pattern or required, depending > on what questions are being asked. It is ok to send some JS code, which is labeled as free such that LibreJS recognizes it, which does nothing except validate the inputs. So that a person who enters valid inputs would see no difference between running the JS code and not running it. > >>> - mysql instead of sqlite, which also implies a mysql instance running > >> > >> SQLite is actually surprisingly resilient, according to [0]: It would be a mistake to put the input into any sort of database program. That would only make things difficult and increase the special knowledge people would need in order to work on this. Here's the simple and clean way to do it. Each time a user responds, convert all the answers into a formulaic piece text which states the questions and answers. Email that to a certain address, which will accumulate these messages in one inbox file. Then it will be simple to do all sorts of counting or analysis on that file. Database programs are useful when there are hundreds of thousands of records and you need to search for any one of them. Or when the data are being altered. We will not have so many answers, and each one will never change once sent. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-11 5:24 ` Richard Stallman @ 2020-10-11 17:59 ` Philip K. 2020-10-12 2:03 ` Richard Stallman 0 siblings, 1 reply; 838+ messages in thread From: Philip K. @ 2020-10-11 17:59 UTC (permalink / raw) To: Richard Stallman; +Cc: abrochard, emacs-devel Richard Stallman <rms@gnu.org> writes: > > >>> - mysql instead of sqlite, which also implies a mysql instance running > > >> > > >> SQLite is actually surprisingly resilient, according to [0]: > > It would be a mistake to put the input into any sort of database > program. That would only make things difficult and increase the > special knowledge people would need in order to work on this. > > Here's the simple and clean way to do it. > > Each time a user responds, convert all the answers into a formulaic > piece text which states the questions and answers. Email that to a > certain address, which will accumulate these messages in one inbox > file. > > Then it will be simple to do all sorts of counting or analysis on that > file. The issue I see here is that if you expert plain-text responses, someone might just submit something that breaks the format, or even submit an email written in HTML. So the data couldn't just be stored in plain text, but would have to at least have some decoding to correctly parse the message, and some encoding the safely store the message. You wouldn't want someone who could submit 1000 fake or troll responses, just because they know what what's going on behind the scenes. > Database programs are useful when there are hundreds of thousands of > records and you need to search for any one of them. Or when the data > are being altered. We will not have so many answers, and each one > will never change once sent. Databases are useful whenever you've got data to work with. SQLite is useful at whatever sale one is working at, from browsers to cars. And besides, it's safer to use than directly writing to the file system (see https://danluu.com/file-consistency/ for more details). And generally speaking, file systems are also just databases, just that they are directory-oriented, not record-oriented and usually have better support in regards to OS primitives. All in all, I don't this that this should be an issue, SQLite is well documented, and can easily be extracted into whatever format someone might need or want, just easier than with a mailbox or other classical unix-like approaches. -- Philip K. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-11 17:59 ` Philip K. @ 2020-10-12 2:03 ` Richard Stallman 0 siblings, 0 replies; 838+ messages in thread From: Richard Stallman @ 2020-10-12 2:03 UTC (permalink / raw) To: Philip K.; +Cc: abrochard, emacs-devel [[[ 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. ]]] > The issue I see here is that if you expert plain-text responses, someone > might just submit something that breaks the format, or even submit an > email written in HTML. This is not a major problem. The only thing that breaks the format of an inbox file is "From " in column 0, and the worst thing that does is generate a junk message. The program that generates the message can easily prevent this from happening. > You > wouldn't want someone who could submit 1000 fake or troll responses, > just because they know what what's going on behind the scenes. It's not likely that people will do this, and if they do, it would not be hard to delete those fake messages from the file. > All in all, I don't this that this should be an issue, SQLite is well > documented, Even if it is very good documentation, reading it and learning will take work. I don't want to have to read it, or learn how to do something with SQLite. It would be an extra unnecessary layer to cause confusion or problems, and there is no need for that complexity. and can easily be extracted into whatever format someone > might need or want, just easier than with a mailbox or other classical > unix-like approaches. It is not as easy for people who don't know or use database systems as it is for you. If some people find it helpful to analyze the data through a database system, I have nothing against their doing so. It won't be hard to have a program parse the inbox file and enter the data. The script can detect when a message was split, and disregard it. Or people can fix the broken messages with Emacs, either by hand with a Lisp program. It is also possible to handle each user's input in two ways when it is entered: put it into a database _and_ email it. That way, everyone's preferences are satisfied. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-10 10:35 ` Philip K. 2020-10-11 5:24 ` Richard Stallman @ 2020-10-11 7:31 ` Tomas Hlavaty 2020-10-11 12:04 ` Jean Louis 2020-10-11 17:47 ` Philip K. 1 sibling, 2 replies; 838+ messages in thread From: Tomas Hlavaty @ 2020-10-11 7:31 UTC (permalink / raw) To: emacs-devel On Sat 10 Oct 2020 at 12:35, "Philip K." <philipk@posteo.net> wrote: > That could be mitigated with a "graceful degradation" approach, since > most people do have javascript activated by default. it should be possible to fill in the survey from emacs emacs does not support executing javascript code many people do have javascript disabled by default many people just close and ignore pages that require javascript would not it be nice to be able to reply to the survey from emacs? for example, could the survey work similar to report-emacs-bug where the template is taken from somewhere dynamically from existing infrastructure (instead of extra web server), e.g. using a reference to a message on emacs-survey@gnu.org? ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-11 7:31 ` Tomas Hlavaty @ 2020-10-11 12:04 ` Jean Louis 2020-10-11 17:47 ` Philip K. 1 sibling, 0 replies; 838+ messages in thread From: Jean Louis @ 2020-10-11 12:04 UTC (permalink / raw) To: Tomas Hlavaty; +Cc: emacs-devel * Tomas Hlavaty <tom@logand.com> [2020-10-11 10:33]: > On Sat 10 Oct 2020 at 12:35, "Philip K." <philipk@posteo.net> wrote: > > That could be mitigated with a "graceful degradation" approach, since > > most people do have javascript activated by default. > > it should be possible to fill in the survey from emacs > > emacs does not support executing javascript code If any website functions only with Javascript, people would launch external browser from Emacs, thus jumping to Javascript which could be non-free. > many people do have javascript disabled by default Many is vague, and I am sure it is true, but "many" does not represent majority, you have to think of default settings in major browsers, if they have Javascript turned on, majority have Javascript turned on, regardless how many have it disabled. > many people just close and ignore pages that require javascript I agree, though many is not equal to majority. > would not it be nice to be able to reply to the survey from emacs? Yes, please. > for example, could the survey work similar to report-emacs-bug where > the template is taken from somewhere dynamically from existing > infrastructure (instead of extra web server), e.g. using a reference > to a message on emacs-survey@gnu.org? Exactly good idea. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-11 7:31 ` Tomas Hlavaty 2020-10-11 12:04 ` Jean Louis @ 2020-10-11 17:47 ` Philip K. 1 sibling, 0 replies; 838+ messages in thread From: Philip K. @ 2020-10-11 17:47 UTC (permalink / raw) To: Tomas Hlavaty; +Cc: emacs-devel Tomas Hlavaty <tom@logand.com> writes: > On Sat 10 Oct 2020 at 12:35, "Philip K." <philipk@posteo.net> wrote: >> That could be mitigated with a "graceful degradation" approach, since >> most people do have javascript activated by default. > > it should be possible to fill in the survey from emacs Of course, that's what "graceful degradation" implies. If Javascript is available, it will be used to improve the user experience. If not, everything still continues working, just eg. without the interactivity that Javascript might provide. -- Philip K. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-08 17:45 ` Adrien Brochard 2020-10-09 11:30 ` Philip K. @ 2020-10-09 17:59 ` Jean Louis 1 sibling, 0 replies; 838+ messages in thread From: Jean Louis @ 2020-10-09 17:59 UTC (permalink / raw) To: Adrien Brochard; +Cc: Philip K., emacs-devel * Adrien Brochard <abrochard@gmx.com> [2020-10-08 20:51]: > > Why not just create a simple HTML form with a captcha (not Google's > > thing, but a simple library that generates an image)? I am not using any captcha, simple HTML and server-side spam blocking. For that, two activities are necessary: - administrator to watch for eventual spam, and it will take time until spam starts coming - adding list of keywords into the spam-definition In Common lisp I have something like this that accepts CGI forms: (defparameter *spam-sets* '(("gratitude" "website" "magnificent" "investigation") ("face" "mask" "coronavirus") ("face" "mask") ("blackhat.to") ("disposable" "mask") ("medical" "mask") ("mask" "protect") ("mask" "virus"))) Only if all keywords appear, the text is rejected. In my opinion, it is better that administrator does administration then having all users checked for "being human" and spending time with the form. Jean ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-08 15:30 Proposal for an Emacs User Survey Adrien Brochard 2020-10-08 17:27 ` Philip K. @ 2020-10-09 0:41 ` Karl Fogel 2020-10-09 1:26 ` Adrien Brochard 2020-10-10 3:52 ` Richard Stallman 2020-10-09 3:35 ` Richard Stallman 2020-10-19 16:20 ` Philip K. 3 siblings, 2 replies; 838+ messages in thread From: Karl Fogel @ 2020-10-09 0:41 UTC (permalink / raw) To: Adrien Brochard; +Cc: emacs-devel On 08 Oct 2020, Adrien Brochard wrote: >But the for the platform to collect responses, this is where it gets >difficult. Something like a Google survey might the easiest/cheapest to >make and distribute and will work on most devices, but it obviously has >privacy concerns. On the other hand, doing something like self-hosting a >no-JS form is very time consuming. I was also thinking of allowing >responses via email for people who do not want to bother with a survey >link and then manually reconcile responses. There is a free software web-based survey tool named LimeSurvey: - https://en.wikipedia.org/wiki/LimeSurvey - https://github.com/LimeSurvey/LimeSurvey - https://www.limesurvey.org LimeSurvey.org seems to actually be a company that provides commercial hosting. It's not clear to me whether the version they host is just the free software version or whether it has some proprietary bits added, but in any case one could just run the free software version oneself. (I know a project that did so many years ago, and they had a good experience with it, FWIW.) Best regards, -Karl ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-09 0:41 ` Karl Fogel @ 2020-10-09 1:26 ` Adrien Brochard 2020-10-10 3:52 ` Richard Stallman 1 sibling, 0 replies; 838+ messages in thread From: Adrien Brochard @ 2020-10-09 1:26 UTC (permalink / raw) To: Karl Fogel; +Cc: emacs-devel > There is a free software web-based survey tool named LimeSurvey: > > - https://en.wikipedia.org/wiki/LimeSurvey > > - https://github.com/LimeSurvey/LimeSurvey > > - https://www.limesurvey.org > > LimeSurvey.org seems to actually be a company that provides commercial hosting. It's not clear to me whether the version they host is just the free software version or whether it has some proprietary bits added, but in any case one could just run the free software version oneself. (I know a project that did so many years ago, and they had a good experience with it, FWIW.) > > Best regards, > -Karl Thank you for the tip! I did look into that after someone recommended it. I like it, the main problem is indeed that I would have to self-host, which is not something I am comfortable doing at this point, at least not with the first iteration. And on the other side, their hosted version is very expensive unfortunately. Best, Adrien ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-09 0:41 ` Karl Fogel 2020-10-09 1:26 ` Adrien Brochard @ 2020-10-10 3:52 ` Richard Stallman 2020-10-10 21:44 ` Dmitry Gutov 1 sibling, 1 reply; 838+ messages in thread From: Richard Stallman @ 2020-10-10 3:52 UTC (permalink / raw) To: Karl Fogel; +Cc: abrochard, emacs-devel [[[ 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. ]]] > There is a free software web-based survey tool named LimeSurvey: Perhaps it would be ethical to use a platform like that, when what we want is a formulaic survey. But I think it is the wrong sort of tool for this job. We had a long discussion on this list, in April and/or May I think, about how to do polling about a simple change in features. What we need is to invite people to explain their preferences or wishes. Sorry, I don't have a pointer to any of those messages so I can't say what to search for, except the words "polling" and "inquiry". -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-10 3:52 ` Richard Stallman @ 2020-10-10 21:44 ` Dmitry Gutov 2020-10-12 2:04 ` Richard Stallman 0 siblings, 1 reply; 838+ messages in thread From: Dmitry Gutov @ 2020-10-10 21:44 UTC (permalink / raw) To: rms, Karl Fogel; +Cc: abrochard, emacs-devel Hi Richard, On 10.10.2020 06:52, Richard Stallman wrote: > We had a long discussion on this list, in April and/or May I think, > about how to do polling about a simple change in features. What we > need is to invite people to explain their preferences or wishes. Are you going to do that survey, the one discussed several months ago? ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-10 21:44 ` Dmitry Gutov @ 2020-10-12 2:04 ` Richard Stallman 0 siblings, 0 replies; 838+ messages in thread From: Richard Stallman @ 2020-10-12 2:04 UTC (permalink / raw) To: Dmitry Gutov; +Cc: kfogel, abrochard, emacs-devel [[[ 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. ]]] > > We had a long discussion on this list, in April and/or May I think, > > about how to do polling about a simple change in features. What we > > need is to invite people to explain their preferences or wishes. > Are you going to do that survey, the one discussed several months ago? That was an inquiry about using tabs for indentation. I have been too busy but I will try to get it moving. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-08 15:30 Proposal for an Emacs User Survey Adrien Brochard 2020-10-08 17:27 ` Philip K. 2020-10-09 0:41 ` Karl Fogel @ 2020-10-09 3:35 ` Richard Stallman 2020-10-09 18:01 ` Jean Louis 2020-10-09 23:12 ` Adrien Brochard 2020-10-19 16:20 ` Philip K. 3 siblings, 2 replies; 838+ messages in thread From: Richard Stallman @ 2020-10-09 3:35 UTC (permalink / raw) To: Adrien Brochard; +Cc: emacs-devel [[[ 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. ]]] I think using Google to communicate the users is bad because Google does so many bad things. We should not endorse it with our actions. In addition, most Google services require users to run nonfree software (Javascript code). If answering our questions requires the user to run some nonfree JS code, that would put us in a moral contradiction. Our goal is much more than just developing a successful editor; GNU Emacs is a GNU package, and the purpose of the GNU operating system is to win freedom for the users. We have to set an example of respecting and defending freedom in the methods we use, not just the program we are working on. See https://gnu.org/philosophy/free-sw.html and https://gnu.org/philosophy/free-software-even-more-important.html. I think Reddit is the wrong place to discuss this plan, for a similar reason. As I understand it, Reddit requires nonfree software to post on Reddit nowadays. Is that not so? The place to discuss the questions is here. Would you please post here your proposal for the questions to ask? Meanwhile, Here's the method I propose for inquiries (we used to call them "polls") about users' views about possible changes in well-known behaviors. * Make a file for the replies to go into. * Make a mailing address which drops all mail into the file. * Write a inquiry statement which describes the proposed change in sufficient detail that people can judge it, what kind of information we seek, and where to email the response. Include a deadline for replies at least 6 weeks in the future. If possible, we should tell users how to select various behaviors, so that they can state their opinions based on comparing actual experiences. End the inquiry statement with the following text. We do not seek "votes", but rather understanding. If you are for the change, please explain why. Would it help you directly? If so, in what scenarios? How often, and how strongly, would it benefit you? What would the benefit be? Or is it that you think it will improve Emacs, or speed Emacs development, by helping other users? How so? Please distinguish between what you know and what you predict. Likewise, if you are against the change, please explain why. Would it inconvenience you directly? If so, in what scenarios? How often, and how strongly, would it inconvenience you? What would the inconvenience be? Or is it that you think it will harm Emacs or Emacs development by inconveniencing others? How so? We invite you also to propose alterations in the proposed change that you think would improve it -- saying in what scenario that would be an improvement, and how so, etc. Please post the URL of this page in forums where it is appropriate, and resend it to Emacs users and mailing lists where you know people will be glad to receive it. It is crucial to urge people repeatedly to explain their positions because there is a strong tendency for people not to bother. * Put the inquiry statement in a web page under gnu.org/software/emacs. * Mail the inquiry statement info-gnu-emacs, help-gnu-emacs and emacs-tangents, with the URL of the web page _and_ the full text of the inquiry statement. Also post a note referring to the web page on reddit.com/r/emacs, and any other suitable places. Mail the URL to Sacha Chua <sacha@sachachua.com>. * Wait until at least two weeks after the deadline, then study and record the responses. Note down all interesting comments, since they are the most important information in the responses. * Do count how many people support each position that people support, but it would be a mistake to make the actual decision based simply on counting. A given change can affect one user very often, and affect another user only rarely, but they could both state a "strong preference". * We are not compelled to choose between "make that change" and "no change". The best outcome of the inquiry is that the responses show us how to design a way to please almost all users, almost all the time, and not displease any user very much. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-09 3:35 ` Richard Stallman @ 2020-10-09 18:01 ` Jean Louis 2020-10-09 23:12 ` Adrien Brochard 1 sibling, 0 replies; 838+ messages in thread From: Jean Louis @ 2020-10-09 18:01 UTC (permalink / raw) To: Richard Stallman; +Cc: Adrien Brochard, emacs-devel * Richard Stallman <rms@gnu.org> [2020-10-09 06:37]: > * Make a file for the replies to go into. > > * Make a mailing address which drops all mail into the file. That was specific proposal, it sounds good, I wish to understand who will implement it? Jean ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-09 3:35 ` Richard Stallman 2020-10-09 18:01 ` Jean Louis @ 2020-10-09 23:12 ` Adrien Brochard 2020-10-09 23:31 ` Drew Adams ` (6 more replies) 1 sibling, 7 replies; 838+ messages in thread From: Adrien Brochard @ 2020-10-09 23:12 UTC (permalink / raw) To: rms; +Cc: emacs-devel Thank you for your response. Please find the list of questions I have gathered at the end of this email. > [[[ 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. ]]] > > I think using Google to communicate the users is bad because Google > does so many bad things. We should not endorse it with our actions. > > In addition, most Google services require users to run nonfree > software (Javascript code). If answering our questions requires the > user to run some nonfree JS code, that would put us in a moral > contradiction. > > Our goal is much more than just developing a successful editor; GNU > Emacs is a GNU package, and the purpose of the GNU operating system is > to win freedom for the users. We have to set an example of respecting > and defending freedom in the methods we use, not just the program we > are working on. See https://gnu.org/philosophy/free-sw.html and > https://gnu.org/philosophy/free-software-even-more-important.html. > > I think Reddit is the wrong place to discuss this plan, for a similar > reason. As I understand it, Reddit requires nonfree software to post > on Reddit nowadays. Is that not so? I understand the position. My primary concern though is that without some convenience, it is difficult to convince a lot of people to respond. Which is why I am proposing two channels: an a dedicated email address that will accept plain text responses (at the risk of data quality), and an online form. That plain text form to be email can be hosted on a static site that people can access from Emacs itself. > If possible, we should tell users how to select various behaviors, so > that they can state their opinions based on comparing actual > experiences. > > End the inquiry statement with the following text. > > We do not seek "votes", but rather understanding. If you are for > the change, please explain why. Would it help you directly? If > so, in what scenarios? How often, and how strongly, would it > benefit you? What would the benefit be? > > Or is it that you think it will improve Emacs, or speed Emacs > development, by helping other users? How so? > > Please distinguish between what you know and what you predict. > > Likewise, if you are against the change, please explain why. > Would it inconvenience you directly? If so, in what scenarios? > How often, and how strongly, would it inconvenience you? What > would the inconvenience be? > > Or is it that you think it will harm Emacs or Emacs development by > inconveniencing others? How so? > > We invite you also to propose alterations in the proposed change that > you think would improve it -- saying in what scenario that would be an > improvement, and how so, etc. > > Please post the URL of this page in forums where it is appropriate, > and resend it to Emacs users and mailing lists where you know people > will be glad to receive it. > > It is crucial to urge people repeatedly to explain their positions > because there is a strong tendency for people not to bother. I am all in favor of this. Thank you for putting it together. Let me know if you think the wording is still coherent given the questions. > * Put the inquiry statement in a web page under gnu.org/software/emacs. > > * Mail the inquiry statement info-gnu-emacs, help-gnu-emacs and > emacs-tangents, with the URL of the web page _and_ the full text > of the inquiry statement. > > Also post a note referring to the web page on reddit.com/r/emacs, and > any other suitable places. Mail the URL to Sacha Chua > <sacha@sachachua.com>. > > * Wait until at least two weeks after the deadline, then study and > record the responses. Note down all interesting comments, since they > are the most important information in the responses. Yes to all of that. > * Do count how many people support each position that people support, > but it would be a mistake to make the actual decision based simply on > counting. A given change can affect one user very often, and affect > another user only rarely, but they could both state a "strong > preference". > > * We are not compelled to choose between "make that change" and "no > change". The best outcome of the inquiry is that the responses show > us how to design a way to please almost all users, almost all the > time, and not displease any user very much. I also agree with this. I think no matter what we are going to get selection bias and we should not rush any decision based on the survey results. * Survey Questions (Please note that any "other" should allow for free text entry for the respondent to elaborate) ** How would you characterize your use of Emacs? - Use it for work - I use it for serious "hobby" projects - I'm just tinkering - I use it for my studies - Other ** What do you use Emacs for? - Software development - Research writing - Data science - Writing - Other ** How long have you been using Emacs? ** Which version of Emacs do you use? ** What OS do you primary use? - Linux - Windows - MacOS - BSD - Other ** How do you use Emacs? - GUI - Terminal (TUI) - Both ** How do you run Emacs? - Client/Server mode only - Standalone application only - Both ** Describe your configuration - I am using vanilla emacs (little to no configuration). - Custom configuration - Spacemacs - https://github.com/syl20bnr/spacemacs - Doom Emacs - https://github.com/hlissner/doom-emacs - Prelude - https://github.com/bbatsov/prelude - purcell emacs.d - https://github.com/purcell/emacs.d - magnars emacs.d - https://github.com/magnars/.emacs.d - Emacs Starter Kit - https://github.com/eschulte/emacs-starter-kit - oh-my-emacs - https://github.com/xiaohanyu/oh-my-emacs - Better Defaults - https://github.com/technomancy/better-defaults - Graphene - https://github.com/rdallasgray/graphene - ohai-emacs - https://github.com/bodil/ohai-emacs - ergoemacs-mode - https://github.com/ergoemacs/ergoemacs-mode - Rho Emacs - https://github.com/GChristensen/rho-emacs - Radian - https://github.com/raxod502/radian - Centaur Emacs - https://github.com/seagle0128/.emacs.d - Other ** What keybindings do you use? - Emacs defaults - Evil/Spacemacs/Doom-Emacs (all the vim-likes) - CUA-mode - God-mode - Boon - Xah-Fly-Keys - Custom modal (ryo-modal, etc) - Custom modifiers (Emacs from scratch) - Other ** Prior to using Emacs what was your primary editor? - VIM - VScode - Eclipse - Notepad++ - Sublime - Intelij - Other ** org-mode usage - I use emacs only for org-mode - dayly - from time to time - Not a org-mode user ** Which completion/selection framework do you use? - helm - ivy - ido - icomplete - other - i don't use a completion framework ** How do you manage third-party elisp? - built-in package.el - Spacemacs does it for me - straight.el - borg - leaf - el-get - Nix - git submodules without Borg - git subtrees - git clones - guix - quelpa - cask - No third-party deps - other ** How do you get emacs packages(if applicable)? - No repos - Gnu Elpa - Melpa/Melpa Stable - Directly from the source (e. g. using straight). ** Can you list some of your favorite package? ** What package do you use for error checking? - Flymake - Flycheck - None ** Do you use TRAMP? ** DO you use Magit? ** What package do you use for project management? - project.el - projectile - Other(mention) - None ** Do you use shell/terminal emulator in Emacs? - eshell - shell - term - ansi-term - do not use. ** Do you use mail client in Emacs? - Mu4e - Gnus - Mut - notmuch - do not use ** What is your Elisp proficiency? - Beginner/No knowledge - Basic elisp understanding - Intermediate - Advanced - Expert ** If you use Emacs for programming, which languages do you program in? ** do you use a language server with lsp-mode? With what languages? ** Do you use Emacs for debugging? What do you use? (Gdb, dap-mode etc) ** Which theme do you use? ** Have you ever contributed to GNU Emacs core/Elpa? - No - No, but I would do that if the process is changed(e. g. using github pull requests instead of the mailing list, no papers, etc**. - I do PRs from time to time - I provide PRs regularly - I am active contributor/maintainer ** Have you ever contributed to Melpa package? - No - I do PRs from time to time - I provide PRs regularly - I am a package maintainer ** What Emacs community forums have you visited in the past year? Answers would be things like - r/emacs - Emacs mailing list - irc - Emacs meetups - I follow twitter Emacs related accounts - Other ** What are some of the Emacs improvements you are the most interested in? ** what do you think are Emacs' greatest strengths? ** can you recall any difficulties you faced initially learning Emacs? ** What is the one thing you would like emacs to do differently? ** How did you hear about this survey? ** If there is another survey in 2021, would you be opposed to it containing optional & general demographics questions? It could include age backets, gender, country or language ** Do you have a preferred platform for filling out the survey in the future? ** General feedback about the survey process? ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Proposal for an Emacs User Survey 2020-10-09 23:12 ` Adrien Brochard @ 2020-10-09 23:31 ` Drew Adams 2020-10-09 23:36 ` Adrien Brochard 2020-10-10 8:09 ` Teemu Likonen ` (5 subsequent siblings) 6 siblings, 1 reply; 838+ messages in thread From: Drew Adams @ 2020-10-09 23:31 UTC (permalink / raw) To: Adrien Brochard, rms; +Cc: emacs-devel As a start, lose all of the multiple choices. Just have open questions, letting users say what they do/use/prefer, etc. The multiple choices, even with an "other", bias the results. Ask users to express themselves, then work with whatever info they provide for the questions. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-09 23:31 ` Drew Adams @ 2020-10-09 23:36 ` Adrien Brochard 2020-10-10 2:21 ` Drew Adams 0 siblings, 1 reply; 838+ messages in thread From: Adrien Brochard @ 2020-10-09 23:36 UTC (permalink / raw) To: Drew Adams, rms; +Cc: emacs-devel > As a start, lose all of the multiple choices. > Just have open questions, letting users say > what they do/use/prefer, etc. > > The multiple choices, even with an "other", > bias the results. How does it bias results exactly? There is always a series of trade-off to make when surveying: free text is more open ended and allows for discovery, but multiple choices have higher completion rate and give specific answers. The set of questions is organized such that we have: - multiple choices regarding factual and technical practices (which version of Emacs/OS/packages etc) - open ended question with broader topics and free text - meta questions about the survey itself > Ask users to express themselves, then work > with whatever info they provide for the > questions. That's the point of the more open ended questions with free text along with the general feedback section. ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Proposal for an Emacs User Survey 2020-10-09 23:36 ` Adrien Brochard @ 2020-10-10 2:21 ` Drew Adams 2020-10-10 2:40 ` Adrien Brochard 0 siblings, 1 reply; 838+ messages in thread From: Drew Adams @ 2020-10-10 2:21 UTC (permalink / raw) To: Adrien Brochard, rms; +Cc: emacs-devel > > As a start, lose all of the multiple choices. > > Just have open questions, letting users say > > what they do/use/prefer, etc. > > > > The multiple choices, even with an "other", > > bias the results. > > How does it bias results exactly? Suggestions of what is possible. My suggestion is to just leave the questions open, and let people express themselves however they think best, rather than being incited to choose among suggested alternatives. Just a suggestion. > multiple choices have higher completion rate and give specific answers. Higher completion rate and specific answers can mean little, compared to thoughtful responses. Emacs has always preferred the latter. And explicitly solicit reasons - everywhere. Reasons can be important for guiding decisions here. > The set of questions is organized such that we have: > - multiple choices regarding factual and technical practices (which > version of Emacs/OS/packages etc) I've said what I think. Asking about packages is a bit different from asking about Emacs version and OS. The former, at least, should be an open question, IMHO. > - open ended question with broader topics and free text > - meta questions about the survey itself > > > Ask users to express themselves, then work > > with whatever info they provide for the questions. > > That's the point of the more open ended questions with free text along > with the general feedback section. Yes. My suggestion is more of that and less of citing multiple things that a user might consider choosing. Choosing OS's and Emacs versions is less likely to be opinion-based than choosing packages etc., and it's unlikely that someone will come up with a new (unlisted) OS or Emacs version. It's a different terrain, IMO - more choices, more movement/evolution, more individual preference-based. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-10 2:21 ` Drew Adams @ 2020-10-10 2:40 ` Adrien Brochard 2020-10-10 3:53 ` Drew Adams 0 siblings, 1 reply; 838+ messages in thread From: Adrien Brochard @ 2020-10-10 2:40 UTC (permalink / raw) To: Drew Adams, rms; +Cc: emacs-devel >>> As a start, lose all of the multiple choices. >>> Just have open questions, letting users say >>> what they do/use/prefer, etc. >>> >>> The multiple choices, even with an "other", >>> bias the results. >> >> How does it bias results exactly? > > Suggestions of what is possible. > > My suggestion is to just leave the questions open, > and let people express themselves however they > think best, rather than being incited to choose > among suggested alternatives. > > Just a suggestion. I understand what you are suggesting, but I do not understand the "bias the results" you are referring to. > Higher completion rate and specific answers can > mean little, compared to thoughtful responses. > Emacs has always preferred the latter. > > And explicitly solicit reasons - everywhere. > Reasons can be important for guiding decisions here. How about having a "why" optional free-text section after each non-factual multiple choice question? Like "which package manager do you use? and why?" or "What are some of your favorite packages and why?" I also could argue that if you present a paragraph input to users, only those with the time and energy will make the effort to write a comprehensive answer, which might create a real bias. On the other hand, if more people can emit their preference for a particular option, you do not know why, but you know where to start looking for why. You do point out something very real: the survey questions are mixing facts with opinions. We are asking factual things, along with general opinions on the state of things. There's obviously a trade-off to make between the two. Factual gives us quick results but without reason. Open ended decreases the response rate and increases the analysis time, but opens for more meaningful answers. ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Proposal for an Emacs User Survey 2020-10-10 2:40 ` Adrien Brochard @ 2020-10-10 3:53 ` Drew Adams 0 siblings, 0 replies; 838+ messages in thread From: Drew Adams @ 2020-10-10 3:53 UTC (permalink / raw) To: Adrien Brochard, rms; +Cc: emacs-devel I'm not going to argue about it. I think I made my suggestion clear, and I think you understand it well enough. Just one opinion. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-09 23:12 ` Adrien Brochard 2020-10-09 23:31 ` Drew Adams @ 2020-10-10 8:09 ` Teemu Likonen 2020-10-10 10:45 ` Rasmus ` (2 more replies) 2020-10-10 10:54 ` Thibaut Verron ` (4 subsequent siblings) 6 siblings, 3 replies; 838+ messages in thread From: Teemu Likonen @ 2020-10-10 8:09 UTC (permalink / raw) To: Adrien Brochard, rms; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 1062 bytes --] * 2020-10-09 19:12:23-04, Adrien Brochard wrote: > Please find the list of questions I have gathered at the end of this > email. Great! I would like to see this survey conducted. It would be interesting to see what people use Emacs for and some distribution of answers. It's not easy to find good sample of users but if the survey is published in some main communication platforms or communities it will be good enough, I think. Some Emacs proposals cause only talking and nobody actually does anything. So perhaps your survey will be the best Emacs survey ever. Best options are those that get implemented. > ** What package do you use for error checking? > - Flymake > - Flycheck > - None Some rare people use wcheck-mode which is available from GNU Elpa. I'm the author and would like to see if it gets even 1 % of users against the other more popular options. https://github.com/tlikonen/wcheck-mode -- /// Teemu Likonen - .-.. http://www.iki.fi/tlikonen/ // OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 251 bytes --] ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-10 8:09 ` Teemu Likonen @ 2020-10-10 10:45 ` Rasmus 2020-10-11 10:32 ` Jean Louis 2020-10-12 14:32 ` Adrien Brochard 2 siblings, 0 replies; 838+ messages in thread From: Rasmus @ 2020-10-10 10:45 UTC (permalink / raw) To: emacs-devel Hi Teemu, Teemu Likonen <tlikonen@iki.fi> writes: > Some rare people use wcheck-mode which is available from GNU > Elpa. I'm the author and would like to see if it gets even 1 % > of users against the other more popular options. > > https://github.com/tlikonen/wcheck-mode Aside: I used to use wheck. I think I might even have reached out to you many years ago. Hunspell support (e.g. ‘ispell-hunspell-add-multi-dic’, thanks Eli!) and the general functionality and speed of ‘flyspell’ has grown so good that I don’t need anything but vanilla Emacs. Many thanks for creating wheck; it allowed me to get good spell-checking at a time when it was otherwise hard to set up! [I see that whceck does a lot more and I wonder if it could be used for languagetool (the grammar checker)] Rasmus -- Together we'll stand, divided we'll fall ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-10 8:09 ` Teemu Likonen 2020-10-10 10:45 ` Rasmus @ 2020-10-11 10:32 ` Jean Louis 2020-10-11 15:15 ` Drew Adams 2020-10-11 18:33 ` Philip K. 2020-10-12 14:32 ` Adrien Brochard 2 siblings, 2 replies; 838+ messages in thread From: Jean Louis @ 2020-10-11 10:32 UTC (permalink / raw) To: Teemu Likonen; +Cc: Adrien Brochard, rms, emacs-devel * Teemu Likonen <tlikonen@iki.fi> [2020-10-10 11:35]: > * 2020-10-09 19:12:23-04, Adrien Brochard wrote: > > > Please find the list of questions I have gathered at the end of this > > email. > > Great! I would like to see this survey conducted. It would be > interesting to see what people use Emacs for and some distribution of > answers. It's not easy to find good sample of users but if the survey is > published in some main communication platforms or communities it will be > good enough, I think. If survey is published, for example on Reddit, such survey is narrow and specific to Reddit users, and would represent only that communication channel. My proposal on how to publish a survey is to include that in the Help menu, and let people do it straight from Emacs. That is similar to bug reporting, but it is not a bug, it is feature request. Something like: Tell us how we can improve? in the Help menu, would lead to description as how RMS said, and from there on, users would submit the email with their descriptions, likes, hates, whatever they wish to say. It could go straight to specific mailing list. Jean ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Proposal for an Emacs User Survey 2020-10-11 10:32 ` Jean Louis @ 2020-10-11 15:15 ` Drew Adams 2020-10-11 18:25 ` Jean Louis 2020-10-11 20:19 ` Proposal for an Emacs User Survey Drew Adams 2020-10-11 18:33 ` Philip K. 1 sibling, 2 replies; 838+ messages in thread From: Drew Adams @ 2020-10-11 15:15 UTC (permalink / raw) To: Jean Louis, Teemu Likonen; +Cc: Adrien Brochard, rms, emacs-devel > If survey is published, for example on Reddit, such survey is narrow > and specific to Reddit users, and would represent only that > communication channel. > > My proposal on how to publish a survey is to include that in the Help > menu, and let people do it straight from Emacs. That is similar to bug > reporting, but it is not a bug, it is feature request. ^^^^^^^^^^^^^^^^^^^^^ > Something like: > Tell us how we can improve? > in the Help menu, would lead to description as how RMS said, and from > there on, users would submit the email with their descriptions, likes, > hates, whatever they wish to say. > > It could go straight to specific mailing list. I agree that the `Help' menu could/should have an item for something like this. Actually, we already have this functionality, which is submitting free-form feedback of any kind. We call it an enhancement request, and we tell users to use `M-x report-emacs-bug' for it. This is not as well known as it should be, IMO. It would be good for the `Help' menu to have an item that explicitly calls this `Suggest Improvements' or similar. It would be bound to `report-emacs-bug'. ___ I think that corresponds to what you are suggesting. However, providing individual feedback to the "bug" list, as helpful as it might be, inviting a thread of discussion by interested parties, including some Emacs core developers, does not also involve or encourage any broader discussion/communication. That might be OK, and in fact that aspect hasn't yet been raised in this current thread. So far, we've discussed only submitting a survey, getting results, and analyzing/discussing them here, on emacs-devel. So as far as that goes, I think this suggestion from Jean-Louis does fit the bill. Well, it doesn't constitute a "survey", but it does correspond to what RMS, I, and Jean-Louis have emphasized here: getting users to say, in their own words, what they want and what they do. I've said this before (dunno whether I've proposed a separate `Help' menu item). We should make `report-emacs-bug' better known as a recommended way to submit ANY feedback about Emacs. The command name can mislead wrt this role. A separate `Help' menu item would help (even though redundant with item `Send Bug Report'). Or change that item to `Send Feedback or Bug Report'. It might also make sense, for discoverability etc., to add a `send-feedback' alias for `send-bug-report'. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-11 15:15 ` Drew Adams @ 2020-10-11 18:25 ` Jean Louis 2020-10-11 19:47 ` Drew Adams 2020-10-13 3:48 ` How to request changes in Emacs Richard Stallman 2020-10-11 20:19 ` Proposal for an Emacs User Survey Drew Adams 1 sibling, 2 replies; 838+ messages in thread From: Jean Louis @ 2020-10-11 18:25 UTC (permalink / raw) To: Drew Adams; +Cc: Adrien Brochard, rms, emacs-devel * Drew Adams <drew.adams@oracle.com> [2020-10-11 18:15]: > Actually, we already have this functionality, which is > submitting free-form feedback of any kind. We call it > an enhancement request, and we tell users to use > `M-x report-emacs-bug' for it. This is not as well > known as it should be, IMO. Only that "report Emacs bug" does not sound as free form feedback of any kind. I know it is, but it does not sound as enhancement request. It takes time for person to realize that. > It would be good for the `Help' menu to have an item > that explicitly calls this `Suggest Improvements' or > similar. It would be bound to `report-emacs-bug'. Such menu in Help could lead users to subscribe, unsubscribe, review or send email to help-gnu-emacs mailing list, send improvement or enhancement suggestions or anything, similar like GNU Hyperbole is doing it since decades. Survey in the context of the opinion poll: https://en.wikipedia.org/wiki/Survey_(human_research)#Opinion_poll The Help menu that would easier enable communication channel with users is necessary. Survey itself is not as much important as the ability or capacity in Emacs development to analyse the data that is already there in public, as I mentioned, bug report database is there, and there are numbers of stars or likes on various public projects, then there are search engines, and various comments of users on other public channels. Subject of stars/likes and considering that users really like something because of number of stars/likes is doubtful. Those who have spent few thousand dollars on advertising of their services or products, they will know why is number of stars/likes doubtful. Example is Spacemacs configuration, I do not know if it is "configuration" or "text editor built on top of Emacs" as it says on Archlinux website: https://wiki.archlinux.org/index.php/Spacemacs What I may say about that, even if Spacemacs developers did not advertise, they could as well advertise for it and obtain those stars/likes and apparent online popularity. But number of stars does not necessarily mean number of users. Number of users publishing online that they use Spacemacs, does not necessarily mean that is less then number of users who do not use Spacemacs, maybe those groups are not willing to publish their statements, or find it silly, like I do. I find it silly to argue about theming, fonts, but maybe is that exactly what is attracting users, some nice theme, flashy, shiny stuff. That is up to Emacs analysis department (emacs-devel) to accept as challenge. > I've said this before (dunno whether I've proposed a separate `Help' > menu item). We should make `report-emacs-bug' better known as a > recommended way to submit ANY feedback about Emacs. Definitely. > The command name can mislead wrt this role. A > separate `Help' menu item would help (even though > redundant with item `Send Bug Report'). Or change > that item to `Send Feedback or Bug Report'. > > It might also make sense, for discoverability etc., > to add a `send-feedback' alias for `send-bug-report'. That is right. > Well, it doesn't constitute a "survey", but it does correspond to > what RMS, I, and Jean-Louis have emphasized here: getting users to > say, in their own words, what they want and what they do. Let me emphasize again, there is number of users who will never speak in public or publish their opinion, why should they? (as thinking from their view point). In my opinion that is greater number of Emacs users. It has to be taken in consideration if then developers are working only for those who are online louder and more exposed to talk, or if they should be maybe working on some set of principles for general users. Let me give you few practical examples from: https://www.debian.org/users/ There are listed among others, following organizations: * Electronics Research Group, University of Aberdeen, Aberdeen, Scotland * Department of Informatics, University of Zurich, Zurich, Switzerland * General Students' Committee (AStA), Saarland University, Saarbrücken, Germany * Athénée Royal de Gembloux, Gembloux, Belgium * Computer Science, Brown University, Providence, RI, USA * Sidney Sussex College, University of Cambridge, UK * Centro de Comunicación Científica, Universidad de Buenos Aires, Argentina * CEIC, Scuola Normale Superiore di Pisa, Italy * Mexican Space Weather Service (SCiESMEX), Geophysics Institute campus Morelia (IGUM), National University of Mexico (UNAM), Mexico * COC Araraquara, Brazil * Department of Computer Science, Savitribai Phule Pune University, India * Departamento de Arquitectura y Tecnología de Sistemas Informáticos (Facultad de Informática), Universidad Politécnica de Madrid, Madrid, Spain * Department of Control Engineering, Faculty of Electrical Engineering, Czech Technical University, Czech Republic * Swiss Federal Institute of Technology Zurich, Department of Physics, ETH Zurich, Switzerland * Formation Canadienne, Université Libre de Guinée (UG), Conakry, Republic of Guinea * Genomics Research Group, CRIBI - Università di Padova, Italy * Department of Geological Sciences and Geotechnology, University of Milano-Bicocca, Italy * Dipartimento di Geoscienze, Università degli Studi di Padova, Italy * Nucleo Lab, Universidad Mayor de San Andrés, Bolivia * Department of Physics, Harvard University, USA I am to assume that among those organizations there are many people using Emacs, people of different characteristics, not of those groups who like theming and online popularities, so those people in those organizations, who use Emacs, in my opinion, would be less loud online to promote Emacs in the manner how Doom/Spacemacs or others are doing it. Such people would be impossible to reach by publishing some online survey anywhere, but they could be reached through Help menu. There are various groups of people, now we have groups of people who think that Spacemacs is editor built on top of Emacs, maybe it is true, so it is written, but that group of people is now mentioning "Spacemacs" and not Emacs, so they will even ask classic Emacs questions under Spacemacs subjects online. To introduce those users to Emacs development and helpful mailing lists, such menu Help --> Contact us or Tell us your opinion, would be helpful. But nevertheless Spacemacs as example of online apparent popularity, not the real popularity. What if Spacemacs have employed advertising to reach stars and likes? That is not hard to do. I do not think that Emacs ever advertised as commercial companies are doing it, it is self-advertised and promoted through OS distributions. Real popularity could be somehow obtained if GNU/Linux distributions and BSD and other operating system distributions and Emacs main website would publish their statistics. Real data useful for surveys cannot be accurately obtained by publishing such survey online anywhere else but in Emacs itself, including with email and with the anonymous form submission where no personal user information will be entered. I would even state explicitly that no IP logs will be kept, all would go to /dev/null and systems like captcha would not be necessary, as Emacs could formulate the buffer with the HTML rendered and viewed with eww that already contains inside tokens that will recognize that such form is coming from within Emacs and from nowhere else. Separate form could be made for online public. Summary: - there are different groups of users, in my opinion, development is rather looking onto feedback of those who are more loud online, as those who don't communicate they cannot be reached anyway - those groups of users who are publicly telling about their ideas related to Emacs, may not be, or may be, representative or majority group of users, but myself I doubt they are. Relying that those groups are representative for majority of Emacs users is doubtful as well. - it is better to develop for majority, just as by principle was done for years for and within Emacs, and I would say to skip all the surveys, and to increase the analysis and enhancement capacities. Data is already there as mentioned. - if any survey is done, such survey should target to find out what the majority really wants, in order to bring about more Emacs popularity. But looking into present popular projects, one can easily draw conclusions without vias. - add the button in the Help menu to contact help-gnu-emacs mailing list, subscribe, unsubscribe, send email anyway, or send feedback or send bug report. The "Send bug report" menu could be converted to multi menu doing that feature. ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Proposal for an Emacs User Survey 2020-10-11 18:25 ` Jean Louis @ 2020-10-11 19:47 ` Drew Adams 2020-10-11 20:36 ` Jean Louis 2020-10-13 3:48 ` How to request changes in Emacs Richard Stallman 1 sibling, 1 reply; 838+ messages in thread From: Drew Adams @ 2020-10-11 19:47 UTC (permalink / raw) To: Jean Louis; +Cc: Adrien Brochard, rms, emacs-devel > > Actually, we already have this functionality, which is > > submitting free-form feedback of any kind. We call it > > an enhancement request, and we tell users to use > > `M-x report-emacs-bug' for it. This is not as well > > known as it should be, IMO. > > Only that "report Emacs bug" does not sound as free form feedback of > any kind. I know it is, but it does not sound as enhancement > request. It takes time for person to realize that. Agreed. Along with the suggestion to (also) pitch the command as a way to provide feedback of any kind, we should work on the command's description and even some of its behavior. The fact that it is also for suggestions should be as front-and-center as is the fact that it is the preferred way to submit a bug report. > > It would be good for the `Help' menu to have an item > > that explicitly calls this `Suggest Improvements' or > > similar. It would be bound to `report-emacs-bug'. > > Such menu in Help could lead users to subscribe, unsubscribe, review > or send email to help-gnu-emacs mailing list, send improvement or > enhancement suggestions or anything, similar like GNU Hyperbole is > doing it since decades. Those kinds of things are indeed also possible. We could add a submenu of `Help' for things related to the existing mailing lists (reading, subscribing, submitting). > The Help menu that would easier enable communication channel with > users is necessary. > > Survey itself is not as much important as the ability or capacity in > Emacs development to analyse the data that is already there in public, > as I mentioned, bug report database is there, and there are numbers of > stars or likes on various public projects, then there are search > engines, and various comments of users on other public channels. > > Subject of stars/likes and considering that users really like > something because of number of stars/likes is doubtful. Those who have > spent few thousand dollars on advertising of their services or > products, they will know why is number of stars/likes doubtful. I tend to agree. Almost anything can be of some value, but extracting real, useful value from some things can be unobvious, difficult, or otherwise not worth the trial. > > I've said this before (dunno whether I've proposed a separate `Help' > > menu item). We should make `report-emacs-bug' better known as a > > recommended way to submit ANY feedback about Emacs. > > Definitely. > > > The command name can mislead wrt this role. A > > separate `Help' menu item would help (even though > > redundant with item `Send Bug Report'). Or change > > that item to `Send Feedback or Bug Report'. > > > > It might also make sense, for discoverability etc., > > to add a `send-feedback' alias for `send-bug-report'. > > That is right. > > > Well, it doesn't constitute a "survey", but it does correspond to > > what RMS, I, and Jean-Louis have emphasized here: getting users to > > say, in their own words, what they want and what they do. > > Let me emphasize again, there is number of users who will never speak > in public or publish their opinion, why should they? (as thinking from > their view point). In my opinion that is greater number of Emacs > users. It has to be taken in consideration if then developers are > working only for those who are online louder and more exposed to talk, > or if they should be maybe working on some set of principles for > general users. Of course. For active input we're pretty much limited to voluntary contribution. That can be encouraged, but we can be sure, at most, only that it represents the views of the volunteers. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-11 19:47 ` Drew Adams @ 2020-10-11 20:36 ` Jean Louis 0 siblings, 0 replies; 838+ messages in thread From: Jean Louis @ 2020-10-11 20:36 UTC (permalink / raw) To: Drew Adams; +Cc: Adrien Brochard, rms, emacs-devel * Drew Adams <drew.adams@oracle.com> [2020-10-11 22:48]: > Those kinds of things are indeed also possible. We could add a > submenu of `Help' for things related to the existing mailing lists > (reading, subscribing, submitting). Please install Hyperbole and see how they done that. > > > Well, it doesn't constitute a "survey", but it does correspond to > > > what RMS, I, and Jean-Louis have emphasized here: getting users to > > > say, in their own words, what they want and what they do. > > > > Let me emphasize again, there is number of users who will never speak > > in public or publish their opinion, why should they? (as thinking from > > their view point). In my opinion that is greater number of Emacs > > users. It has to be taken in consideration if then developers are > > working only for those who are online louder and more exposed to talk, > > or if they should be maybe working on some set of principles for > > general users. > > Of course. For active input we're pretty much limited to voluntary > contribution. That can be encouraged, but we can be sure, at most, > only that it represents the views of the volunteers. Those who don't want to tell anything, should speak out louder... ^ permalink raw reply [flat|nested] 838+ messages in thread
* How to request changes in Emacs 2020-10-11 18:25 ` Jean Louis 2020-10-11 19:47 ` Drew Adams @ 2020-10-13 3:48 ` Richard Stallman 2020-10-13 4:59 ` Jean Louis 2020-10-13 15:56 ` Drew Adams 1 sibling, 2 replies; 838+ messages in thread From: Richard Stallman @ 2020-10-13 3:48 UTC (permalink / raw) To: Jean Louis; +Cc: abrochard, drew.adams, emacs-devel [[[ 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. ]]] > Only that "report Emacs bug" does not sound as free form feedback of > any kind. I know it is, but it does not sound as enhancement > request. It takes time for person to realize that. That is a good point. Do people have concrete suggestions for how to make it clearer how to request changes etc? -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: How to request changes in Emacs 2020-10-13 3:48 ` How to request changes in Emacs Richard Stallman @ 2020-10-13 4:59 ` Jean Louis 2020-10-16 4:00 ` Richard Stallman 2020-10-13 15:56 ` Drew Adams 1 sibling, 1 reply; 838+ messages in thread From: Jean Louis @ 2020-10-13 4:59 UTC (permalink / raw) To: Richard Stallman; +Cc: abrochard, drew.adams, emacs-devel * Richard Stallman <rms@gnu.org> [2020-10-13 06:50]: > [[[ 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. ]]] > > > Only that "report Emacs bug" does not sound as free form feedback of > > any kind. I know it is, but it does not sound as enhancement > > request. It takes time for person to realize that. > > That is a good point. Do people have concrete suggestions for > how to make it clearer how to request changes etc? We discussed that in this same thread, concrete proposal would be to expand the menu item Help -> Send Bug Report The item "Send Bug Report" could be placeholder for something like "Tell us how to improve" which would expand in more submenu options, something like: - Send Bug Report - Suggest Emacs improvements - Send email to Help GNU Emacs - Join the Help GNU Emacs mailing list - Leave Help GNU Emacs mailing list The item "Suggest Emacs improvements" would be similar like report-emacs-bug, with different wordings, as user is not speaking about the bug, email could be sent to mailing list. It would be free form, and it could also include various information of the system similar as report-emacs-bug GNU Hyperbole has similar features built in. Drew Adams could give maybe better references to emails in this thread, you could review the thread by the subject How to make Emacs popular again. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: How to request changes in Emacs 2020-10-13 4:59 ` Jean Louis @ 2020-10-16 4:00 ` Richard Stallman 2020-10-16 4:47 ` Drew Adams 0 siblings, 1 reply; 838+ messages in thread From: Richard Stallman @ 2020-10-16 4:00 UTC (permalink / raw) To: Jean Louis; +Cc: abrochard, drew.adams, emacs-devel [[[ 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. ]]] > The item "Send Bug Report" could be placeholder for something like > "Tell us how to improve" which would expand in more submenu options, > something like: I guess so. Perhaps it should be renamed to "Give Feedback." I always find submenus inconvenient to select from; am I the only one? Is it because I rarely do that? > - Send Bug Report > - Suggest Emacs improvements > - Send email to Help GNU Emacs I suggest Mail a question to help-gnu-emacs. > - Join the Help GNU Emacs mailing list > - Leave Help GNU Emacs mailing list I think the last two are not needed. If a user finds out about help-gnu-emacs, perse can decide to join. Also, that command could display, in some way, guidance on how to subscribe or unsubscribe. Having fewer options could permit a more convenient interface for choosing an option. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: How to request changes in Emacs 2020-10-16 4:00 ` Richard Stallman @ 2020-10-16 4:47 ` Drew Adams 0 siblings, 0 replies; 838+ messages in thread From: Drew Adams @ 2020-10-16 4:47 UTC (permalink / raw) To: rms, Jean Louis; +Cc: abrochard, emacs-devel >> - Send Bug Report >> - Suggest Emacs improvements I suggested it's also possible to combine those two: A separate `Help' menu item would help (even though redundant with item `Send Bug Report'). Or change that item to `Send Feedback or Bug Report'. ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: How to request changes in Emacs 2020-10-13 3:48 ` How to request changes in Emacs Richard Stallman 2020-10-13 4:59 ` Jean Louis @ 2020-10-13 15:56 ` Drew Adams 2020-10-14 4:42 ` Richard Stallman 1 sibling, 1 reply; 838+ messages in thread From: Drew Adams @ 2020-10-13 15:56 UTC (permalink / raw) To: rms, Jean Louis; +Cc: abrochard, emacs-devel > > Only that "report Emacs bug" does not sound as free form feedback of > > any kind. I know it is, but it does not sound as enhancement > > request. It takes time for person to realize that. > > That is a good point. Do people have concrete suggestions for > how to make it clearer how to request changes etc? There have been concrete suggestions for this. For instance: https://lists.gnu.org/archive/html/emacs-devel/2020-10/msg00552.html The suggestions there include: 1. Alias `report-emacs-bug' to a name that suggests sending feedback in general, not just reporting a bug. 2. Change the description of that command, to reflect the fact that it is for _both_ sending general feedback and reporting bugs. And change the descriptions in manuals accordingly. 3. Changing the Help menu item for reporting a but, so it suggests either reporting a bug or sending general feedback. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: How to request changes in Emacs 2020-10-13 15:56 ` Drew Adams @ 2020-10-14 4:42 ` Richard Stallman 2020-10-14 5:12 ` Drew Adams 0 siblings, 1 reply; 838+ messages in thread From: Richard Stallman @ 2020-10-14 4:42 UTC (permalink / raw) To: Drew Adams; +Cc: abrochard, bugs, emacs-devel [[[ 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. ]]] emacs-feedback could be a good name, but perhaps it should not insert into the message some of the things that report-emacs-bug inserts. They are relevant if the subject is a bug that just occurred, but not in other circumstances. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: How to request changes in Emacs 2020-10-14 4:42 ` Richard Stallman @ 2020-10-14 5:12 ` Drew Adams 0 siblings, 0 replies; 838+ messages in thread From: Drew Adams @ 2020-10-14 5:12 UTC (permalink / raw) To: rms; +Cc: abrochard, bugs, emacs-devel > emacs-feedback could be a good name, but perhaps it should not insert > into the message some of the things that report-emacs-bug inserts. > They are relevant if the subject is a bug that just occurred, but not > in other circumstances. Agreed. They are not necessarily relevant, not all anyway. ___ [I suggested, in 2013 and 2016, that we modularize the possible info to automatically gather and send, and let users choose which such pieces they want to send. That modularization would also make it clearer & easier to handle a new command for sending feedback a bit differently from `report-emacs-bug', in terms of what to include. https://lists.gnu.org/archive/html/emacs-devel/2016-05/msg00238.html https://lists.gnu.org/archive/html/emacs-devel/2013-01/msg00431.html] ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Proposal for an Emacs User Survey 2020-10-11 15:15 ` Drew Adams 2020-10-11 18:25 ` Jean Louis @ 2020-10-11 20:19 ` Drew Adams 2020-10-11 20:42 ` Jean Louis 1 sibling, 1 reply; 838+ messages in thread From: Drew Adams @ 2020-10-11 20:19 UTC (permalink / raw) To: Jean Louis, Teemu Likonen; +Cc: Adrien Brochard, rms, emacs-devel > I've said this before.... We should make > `report-emacs-bug' better known as a recommended > way to submit ANY feedback about Emacs. ... > It might also make sense, for discoverability etc., > to add a `send-feedback' alias for `send-bug-report'. I'll mention also that I often suggest to users (e.g. on SE.emacs or Reddit) that they use `M-x report-emacs-bug' to send an enhancement request. And pretty much each time I feel obliged to add something like "(that's for enhancement reports, as well as bug reports)" so they aren't scared away by the command name, thinking that it's something too serious or that they might get criticized for not submitting a report of a proper bug. An alias that emphasizes general feedback to improve Emacs would be good, I think. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-11 20:19 ` Proposal for an Emacs User Survey Drew Adams @ 2020-10-11 20:42 ` Jean Louis 0 siblings, 0 replies; 838+ messages in thread From: Jean Louis @ 2020-10-11 20:42 UTC (permalink / raw) To: Drew Adams; +Cc: Adrien Brochard, rms, emacs-devel * Drew Adams <drew.adams@oracle.com> [2020-10-11 23:20]: > > I've said this before.... We should make > > `report-emacs-bug' better known as a recommended > > way to submit ANY feedback about Emacs. > ... > > It might also make sense, for discoverability etc., > > to add a `send-feedback' alias for `send-bug-report'. > > I'll mention also that I often suggest to users > (e.g. on SE.emacs or Reddit) that they use `M-x > report-emacs-bug' to send an enhancement request. > > And pretty much each time I feel obliged to add > something like "(that's for enhancement reports, > as well as bug reports)" so they aren't scared > away by the command name, thinking that it's > something too serious or that they might get > criticized for not submitting a report of a > proper bug. > > An alias that emphasizes general feedback to > improve Emacs would be good, I think. You are putting much energy into that. Then, did you review the bug database, how many enhancements really arrived? Now, speaking of Emacs improvements, those popular configurations are already showing what some users wish and want, they also do good work in attracting new users to Emacs. Speaking of MELPA, that is also something users want, so I hope we start somehow doing elpa.nongnu.org where such packages can be invited, so I understood, polished and distributed. So, all those popular configurations could be then forked into elpa.nongnu.org including thousands of other packages, after careful review. That is for me the summary of this talk, there is need for a shelf with new shiny shoes. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-11 10:32 ` Jean Louis 2020-10-11 15:15 ` Drew Adams @ 2020-10-11 18:33 ` Philip K. 2020-10-11 18:45 ` Jean Louis ` (2 more replies) 1 sibling, 3 replies; 838+ messages in thread From: Philip K. @ 2020-10-11 18:33 UTC (permalink / raw) To: Jean Louis; +Cc: Adrien Brochard, rms, emacs-devel Jean Louis <bugs@gnu.support> writes: > * Teemu Likonen <tlikonen@iki.fi> [2020-10-10 11:35]: >> * 2020-10-09 19:12:23-04, Adrien Brochard wrote: >> >> > Please find the list of questions I have gathered at the end of this >> > email. >> >> Great! I would like to see this survey conducted. It would be >> interesting to see what people use Emacs for and some distribution of >> answers. It's not easy to find good sample of users but if the survey is >> published in some main communication platforms or communities it will be >> good enough, I think. > > If survey is published, for example on Reddit, such survey is narrow > and specific to Reddit users, and would represent only that > communication channel. > > My proposal on how to publish a survey is to include that in the Help > menu, and let people do it straight from Emacs. That is similar to bug > reporting, but it is not a bug, it is feature request. But if you have to have mail configured, you're also only going to have a specific subset of all users. I think the idea of having a survey that could be filled out from Emacs is interesting (although we would only get to hear from current users, not previous users). But it would have to work regardless of what the user has configured or not. From what I see, that would either mean a web form that can be filled out using EWW or a package that could be downloaded from ELPA. -- Philip K. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-11 18:33 ` Philip K. @ 2020-10-11 18:45 ` Jean Louis 2020-10-13 3:48 ` Richard Stallman 2020-10-11 19:47 ` Drew Adams 2020-10-11 20:54 ` Jean Louis 2 siblings, 1 reply; 838+ messages in thread From: Jean Louis @ 2020-10-11 18:45 UTC (permalink / raw) To: Philip K.; +Cc: Adrien Brochard, rms, emacs-devel * Philip K. <philipk@posteo.net> [2020-10-11 21:33]: > I think the idea of having a survey that could be filled out from Emacs > is interesting (although we would only get to hear from current users, > not previous users). But it would have to work regardless of what the > user has configured or not. From what I see, that would either mean a > web form that can be filled out using EWW or a package that could be > downloaded from ELPA. To reach previous users, we may ask Vim and VSCode developers to include the Emacs survey option. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-11 18:45 ` Jean Louis @ 2020-10-13 3:48 ` Richard Stallman 0 siblings, 0 replies; 838+ messages in thread From: Richard Stallman @ 2020-10-13 3:48 UTC (permalink / raw) To: Jean Louis; +Cc: philipk, abrochard, emacs-devel [[[ 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. ]]] > To reach previous users, we may ask Vim and VSCode developers to > include the Emacs survey option. It could be useful to ask those users a different survey. However, the Microsoft management would surely not cooperate; I am not going to ask them. We could reach plenty of former Emacs users in other ways. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Proposal for an Emacs User Survey 2020-10-11 18:33 ` Philip K. 2020-10-11 18:45 ` Jean Louis @ 2020-10-11 19:47 ` Drew Adams 2020-10-11 20:33 ` Jean Louis 2020-10-11 20:54 ` Jean Louis 2 siblings, 1 reply; 838+ messages in thread From: Drew Adams @ 2020-10-11 19:47 UTC (permalink / raw) To: Philip K., Jean Louis; +Cc: Adrien Brochard, rms, emacs-devel > > My proposal on how to publish a survey is to include that in the Help > > menu, and let people do it straight from Emacs. That is similar to bug > > reporting, but it is not a bug, it is feature request. > > But if you have to have mail configured, you're also only going to have > a specific subset of all users. Nothing _limits_ input to email. That's all we handle today, and we should at least continue to handle such input. But if we want to entertain supporting other input methods (smoke signals... whatever), that's not impossible. > I think the idea of having a survey that could be filled out from Emacs > is interesting (although we would only get to hear from current users, > not previous users). But it would have to work regardless of what the > user has configured or not. From what I see, that would either mean a > web form that can be filled out using EWW or a package that could be > downloaded from ELPA. It's not only either/or. The point of the suggestion was to leverage the existing `report-emacs-bug' input of general, free-form feedback. Where "leverage" also means encourage. And that in turn means new names (command alias, menu items,... whatever) and some new description (e.g. rework the wording of the existing bug-reporting instructions). ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-11 19:47 ` Drew Adams @ 2020-10-11 20:33 ` Jean Louis 2020-10-11 23:24 ` Drew Adams 0 siblings, 1 reply; 838+ messages in thread From: Jean Louis @ 2020-10-11 20:33 UTC (permalink / raw) To: Drew Adams; +Cc: Philip K., Adrien Brochard, rms, emacs-devel * Drew Adams <drew.adams@oracle.com> [2020-10-11 22:48]: > > > My proposal on how to publish a survey is to include that in the Help > > > menu, and let people do it straight from Emacs. That is similar to bug > > > reporting, but it is not a bug, it is feature request. > > > > But if you have to have mail configured, you're also only going to have > > a specific subset of all users. > > Nothing _limits_ input to email. That's all we handle today, and we > should at least continue to handle such input. But if we want to > entertain supporting other input methods (smoke signals... > whatever), that's not impossible. Is hard for me to understand the above. Let me say that trends changed, there are now more people using Internet, and there are more people using Internet without email or not knowing what email does, or having email, but never using it and not knowing what it does, including people having email and using it exclusively on their mobile devices, not knowing they can use it from computers. Suspicious is also Windows and other systems but Unix-like systems, I did not try, I just don't know how would report-emacs-bug function on Windows, I doubt it is well integrated. I would just make it as a form, either as Emacs forms from forms.el library, plus some POST to URL, or as HTML form by using eww. In such form, user could enter email, but if user does not have email, need not enter such, neither the name. User could still communicate, it would be one way, but better some opinions then none, hey. > > I think the idea of having a survey that could be filled out from Emacs > > is interesting (although we would only get to hear from current users, > > not previous users). But it would have to work regardless of what the > > user has configured or not. From what I see, that would either mean a > > web form that can be filled out using EWW or a package that could be > > downloaded from ELPA. > > It's not only either/or. > > The point of the suggestion was to leverage the existing > `report-emacs-bug' input of general, free-form feedback. Where > "leverage" also means encourage. And that in turn means new names > (command alias, menu items,... whatever) and some new description > (e.g. rework the wording of the existing bug-reporting > instructions). Not sure, I would leave report-emacs-bug in place, and add feedback or suggestions with different wording, including access to friendly mailing lists and IRC channel. So far fastest way to get live help for Emacs is IRC. ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Proposal for an Emacs User Survey 2020-10-11 20:33 ` Jean Louis @ 2020-10-11 23:24 ` Drew Adams 2020-10-12 4:10 ` Jean Louis 0 siblings, 1 reply; 838+ messages in thread From: Drew Adams @ 2020-10-11 23:24 UTC (permalink / raw) To: Jean Louis; +Cc: Philip K., Adrien Brochard, rms, emacs-devel > > > But if you have to have mail configured, you're also only going to have > > > a specific subset of all users. > > > > Nothing _limits_ input to email. That's all we handle today, and we > > should at least continue to handle such input. But if we want to > > entertain supporting other input methods (smoke signals... > > whatever), that's not impossible. > > Is hard for me to understand the above. It's hard for me to understand what you write, below. My point there was only that nothing limits acceptance of user input only in the form of email. That's all. To be clear, I'm in favor of continuing to accept input by email. I'm strongly in favor of that. And in particular by `report-emacs-bug'. I was just saying that nothing prevents accepting feedback in other ways. Of course, some ways would no doubt require some support development. (Something like snail mail would not.) > Let me say that trends changed, there are now more people using > Internet, and there are more people using Internet without email or > not knowing what email does, or having email, but never using it and > not knowing what it does, including people having email and using it > exclusively on their mobile devices, not knowing they can use it from > computers. > > Suspicious is also Windows and other systems but Unix-like systems, > I did not try, I just don't know how would report-emacs-bug function > on Windows, I doubt it is well integrated. > > I would just make it as a form, either as Emacs forms from forms.el > library, plus some POST to URL, or as HTML form by using eww. > > In such form, user could enter email, but if user does not have email, > need not enter such, neither the name. User could still communicate, > it would be one way, but better some opinions then none, hey. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-11 23:24 ` Drew Adams @ 2020-10-12 4:10 ` Jean Louis 2020-10-12 17:35 ` Drew Adams 0 siblings, 1 reply; 838+ messages in thread From: Jean Louis @ 2020-10-12 4:10 UTC (permalink / raw) To: Drew Adams; +Cc: Philip K., Adrien Brochard, rms, emacs-devel * Drew Adams <drew.adams@oracle.com> [2020-10-12 02:25]: > > > > But if you have to have mail configured, you're also only going to have > > > > a specific subset of all users. > > > > > > Nothing _limits_ input to email. That's all we handle today, and we > > > should at least continue to handle such input. But if we want to > > > entertain supporting other input methods (smoke signals... > > > whatever), that's not impossible. > > > > Is hard for me to understand the above. > > It's hard for me to understand what you write, below. > > My point there was only that nothing limits acceptance > of user input only in the form of email. That's all. > > To be clear, I'm in favor of continuing to accept > input by email. I'm strongly in favor of that. > And in particular by `report-emacs-bug'. Yes, I have confirmed that. Additionally for users who did not set up email system, I said that form can be used to submit information, which in turn is again converted to email. A form submission can be anonymous, or with email address again, but email system need not be set. I am not using Windows, but there I think on Windows mostly. I doubt GNU/Linux systems all have set up email transport, but they would rather have WWW access. Is it now clearer? ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Proposal for an Emacs User Survey 2020-10-12 4:10 ` Jean Louis @ 2020-10-12 17:35 ` Drew Adams 2020-10-12 18:33 ` Jean Louis 0 siblings, 1 reply; 838+ messages in thread From: Drew Adams @ 2020-10-12 17:35 UTC (permalink / raw) To: Jean Louis; +Cc: Philip K., Adrien Brochard, rms, emacs-devel > Additionally for users who did not set up email system, Most users have an email client, and they can use that client for this. But it is a valid point that some users, who can use email, might nevertheless not want to, or might prefer another way of sending feedback. We can accept feedback in more than one way. > I said that > form can be used to submit information, which in turn is again > converted to email. A form submission can be anonymous, or with email > address again, but email system need not be set. Email system need not be set, to send email feedback. Depending on what you might mean by "email system" and "set". It's enough to have a mail client. > I am not using Windows, but there I think on Windows mostly. I doubt > GNU/Linux systems all have set up email transport, but they would > rather have WWW access. Is it now clearer? I take the point that not everyone will have email set up on the computer they use for Emacs. OK. And some users might prefer not to use email to provide Emacs feedback. Other ways to do that can be accepted/supported. I have nothing specific to say about any such other ways. ___ On another major question in this thread: I'm in favor of emphasizing solicitation and consideration of free-form feedback, over multiple-choice votes (check-boxes, radio buttons). And I'm in favor of asking that those submitting suggestions to give their reasons, for better understanding. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-12 17:35 ` Drew Adams @ 2020-10-12 18:33 ` Jean Louis 2020-10-12 18:41 ` Drew Adams 0 siblings, 1 reply; 838+ messages in thread From: Jean Louis @ 2020-10-12 18:33 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-devel * Drew Adams <drew.adams@oracle.com> [2020-10-12 20:37]: > > Additionally for users who did not set up email system, > > Most users have an email client, and they can use that client for > this. But it is a valid point that some users, who can use email, > might nevertheless not want to, or might prefer another way of > sending feedback. We can accept feedback in more than one way. Just thinking of those Windows users and GNU/Linux and BSD users who would not have the Emacs set for sending email, what if they just use smartphones to send emails? There are different groups of users today, is not same as before 20 years when email was so much popular. There are users using almost exclusively chat systems, disregarding email. I wonder if users on Windows or GNU/Linux who do use email on their system would be properly served with the option 'mail-client'. They would face 3 options, mail-client, transport, smtp, right? I have just tried it on my Hyperbola GNU/Linux-libre where I have set mutt as my mail client, so what happened is following: - I have chosen 'mail client' - epiphany browser opened, I do not know why exactly - thereafter xterm opened, with mutt - mutt asked me pre-defined emails as I specified it in the Emacs M-x mail, I guess it would be same as report-emacs-bug - I found my double signature inside of the new email, and when I wanted to send email, my from email was changed to other email address - instead of having Unix style line endings, I could see ^M when editing that new email from mutt, very ugly Overall, on GNU/Linux I am not satisfied with mail-client option, it can be my own bad configuration. And I wonder how well would that work on side of other people using various mail clients, and if at all it would work. I could see following in the new email that was invoked through mail client option, those annoying ^M --Text follows this line--^M ^M ^M -- ^M Thanks,^M Jean ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Proposal for an Emacs User Survey 2020-10-12 18:33 ` Jean Louis @ 2020-10-12 18:41 ` Drew Adams 0 siblings, 0 replies; 838+ messages in thread From: Drew Adams @ 2020-10-12 18:41 UTC (permalink / raw) To: Jean Louis; +Cc: emacs-devel > Just thinking of those Windows users and GNU/Linux and BSD users who > would not have the Emacs set for sending email, what if they just use > smartphones to send emails? There are different groups of users today, > is not same as before 20 years when email was so much popular. There > are users using almost exclusively chat systems, disregarding email. > > I wonder if users on Windows or GNU/Linux who do use email on their > system would be properly served with the option 'mail-client'. I can't speak to all that you say/ask. I can say this: I use Emacs on MS Windows, and I use MS Outlook as my mail client. And I have no problem using it with `report-emacs-bug'. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-11 18:33 ` Philip K. 2020-10-11 18:45 ` Jean Louis 2020-10-11 19:47 ` Drew Adams @ 2020-10-11 20:54 ` Jean Louis 2 siblings, 0 replies; 838+ messages in thread From: Jean Louis @ 2020-10-11 20:54 UTC (permalink / raw) To: Philip K.; +Cc: Adrien Brochard, rms, emacs-devel * Philip K. <philipk@posteo.net> [2020-10-11 21:34]: > Jean Louis <bugs@gnu.support> writes: > > > * Teemu Likonen <tlikonen@iki.fi> [2020-10-10 11:35]: > >> * 2020-10-09 19:12:23-04, Adrien Brochard wrote: > >> > >> > Please find the list of questions I have gathered at the end of this > >> > email. > >> > >> Great! I would like to see this survey conducted. It would be > >> interesting to see what people use Emacs for and some distribution of > >> answers. It's not easy to find good sample of users but if the survey is > >> published in some main communication platforms or communities it will be > >> good enough, I think. > > > > If survey is published, for example on Reddit, such survey is narrow > > and specific to Reddit users, and would represent only that > > communication channel. > > > > My proposal on how to publish a survey is to include that in the Help > > menu, and let people do it straight from Emacs. That is similar to bug > > reporting, but it is not a bug, it is feature request. > > But if you have to have mail configured, you're also only going to have > a specific subset of all users. > > I think the idea of having a survey that could be filled out from Emacs > is interesting (although we would only get to hear from current users, > not previous users). But it would have to work regardless of what the > user has configured or not. From what I see, that would either mean a > web form that can be filled out using EWW or a package that could be > downloaded from ELPA. If the eww's eww-submit function get dissected, maybe there will be simplest POST function, then library forms.el can be used to POST the information to GNU servers, which in turn arrives by email easily. Even the CGI script can be written in Emacs Lisp to accept the email and send into the queue for approval before publishing it to mailing list. That would not need to load full eww, it can display users few fields, if one wish to enter some personal information or not, it would be equal. Form would send it to server. Server side Emacs CGI would send email to queue mailman or some mailing list manager for approval or censorship :-) Emails would be sent from form-submission@gnu.org to mailing list with Reply-To: email address of user who submitted the form. But what if email address is not working?! Other users or developers could collaborate or answer questions. See: share/emacs/28.0.50/etc/forms ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-10 8:09 ` Teemu Likonen 2020-10-10 10:45 ` Rasmus 2020-10-11 10:32 ` Jean Louis @ 2020-10-12 14:32 ` Adrien Brochard 2 siblings, 0 replies; 838+ messages in thread From: Adrien Brochard @ 2020-10-12 14:32 UTC (permalink / raw) To: Teemu Likonen, rms; +Cc: emacs-devel Thank you! I added wcheck-mode to the list. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-09 23:12 ` Adrien Brochard 2020-10-09 23:31 ` Drew Adams 2020-10-10 8:09 ` Teemu Likonen @ 2020-10-10 10:54 ` Thibaut Verron 2020-10-10 13:50 ` Philip K. ` (2 more replies) 2020-10-10 13:17 ` Rasmus ` (3 subsequent siblings) 6 siblings, 3 replies; 838+ messages in thread From: Thibaut Verron @ 2020-10-10 10:54 UTC (permalink / raw) To: Adrien Brochard; +Cc: Richard Stallman, emacs-devel Hi, To me it looks like a pretty solid list of questions. I'd just suggest a few changes (assuming we go with multiple-choice): > ** How do you run Emacs? > - Client/Server mode only > - Standalone application only > - Both I would add a "I don't know" item here. > ** Describe your configuration > - I am using vanilla emacs (little to no configuration). > - Custom configuration > - Spacemacs - https://github.com/syl20bnr/spacemacs > - Doom Emacs - https://github.com/hlissner/doom-emacs > - Prelude - https://github.com/bbatsov/prelude > - purcell emacs.d - https://github.com/purcell/emacs.d > - magnars emacs.d - https://github.com/magnars/.emacs.d > - Emacs Starter Kit - https://github.com/eschulte/emacs-starter-kit > - oh-my-emacs - https://github.com/xiaohanyu/oh-my-emacs > - Better Defaults - https://github.com/technomancy/better-defaults > - Graphene - https://github.com/rdallasgray/graphene > - ohai-emacs - https://github.com/bodil/ohai-emacs > - ergoemacs-mode - https://github.com/ergoemacs/ergoemacs-mode > - Rho Emacs - https://github.com/GChristensen/rho-emacs > - Radian - https://github.com/raxod502/radian > - Centaur Emacs - https://github.com/seagle0128/.emacs.d > - Other This list is significantly longer than others in the questionnaire. Would it make sense to group the less common ones in "other"? I also don't know if I would include better-defaults, ergoemacs, etc, in that list: they are standard packages, they don't require replacing your .emacs.d. > ** What keybindings do you use? > - Emacs defaults > - Evil/Spacemacs/Doom-Emacs (all the vim-likes) > - CUA-mode > - God-mode > - Boon > - Xah-Fly-Keys > - Custom modal (ryo-modal, etc) > - Custom modifiers (Emacs from scratch) > - Other Same doubt regarding the less common options. Also, I'd add Viper (built-in) to the vim-likes. > > ** Prior to using Emacs what was your primary editor? > - VIM > - VScode > - Eclipse > - Notepad++ > - Sublime > - Intelij > - Other I'd add an entry "Text editor supplied by the OS (notepad, gedit, kate...)" and an entry "None". > ** Do you use shell/terminal emulator in Emacs? > - eshell > - shell > - term > - ansi-term > - do not use. I'd add "vterm" and "other". > > ** Do you use mail client in Emacs? > - Mu4e > - Gnus > - Mut > - notmuch > - do not use Here too, "other" should be an option. Nice work ! ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-10 10:54 ` Thibaut Verron @ 2020-10-10 13:50 ` Philip K. 2020-10-12 14:36 ` Adrien Brochard 2020-10-11 11:58 ` Jean Louis 2020-10-12 14:36 ` Adrien Brochard 2 siblings, 1 reply; 838+ messages in thread From: Philip K. @ 2020-10-10 13:50 UTC (permalink / raw) To: Thibaut Verron; +Cc: Adrien Brochard, Richard Stallman, emacs-devel Thibaut Verron <thibaut.verron@gmail.com> writes: >> ** Do you use mail client in Emacs? >> - Mu4e >> - Gnus >> - Mut >> - notmuch >> - do not use > > Here too, "other" should be an option. The list is incomplete, but are there really that many mail clients that they couldn't be listed. Emacswiki[0] lists: - Rmail - Gnus - MH-E - Wanderlust - Mew - VM - Notmuch - mu4e - mutt and a few more unmaintained ones. I guess if other could stand for those? [0] https://www.emacswiki.org/emacs/CategoryMail -- Philip K. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-10 13:50 ` Philip K. @ 2020-10-12 14:36 ` Adrien Brochard 0 siblings, 0 replies; 838+ messages in thread From: Adrien Brochard @ 2020-10-12 14:36 UTC (permalink / raw) To: Philip K., Thibaut Verron; +Cc: Richard Stallman, emacs-devel Thank you! Added! On 10/10/20 9:50 AM, Philip K. wrote: > Thibaut Verron <thibaut.verron@gmail.com> writes: > >>> ** Do you use mail client in Emacs? >>> - Mu4e >>> - Gnus >>> - Mut >>> - notmuch >>> - do not use >> >> Here too, "other" should be an option. > > The list is incomplete, but are there really that many mail clients that > they couldn't be listed. Emacswiki[0] lists: > > - Rmail > - Gnus > - MH-E > - Wanderlust > - Mew > - VM > - Notmuch > - mu4e > - mutt > > and a few more unmaintained ones. I guess if other could stand for those? > > [0] https://www.emacswiki.org/emacs/CategoryMail > ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-10 10:54 ` Thibaut Verron 2020-10-10 13:50 ` Philip K. @ 2020-10-11 11:58 ` Jean Louis 2020-10-12 14:36 ` Adrien Brochard 2 siblings, 0 replies; 838+ messages in thread From: Jean Louis @ 2020-10-11 11:58 UTC (permalink / raw) To: Thibaut Verron; +Cc: Adrien Brochard, Richard Stallman, emacs-devel * Thibaut Verron <thibaut.verron@gmail.com> [2020-10-10 13:56]: > I would add a "I don't know" item here. > > > ** Describe your configuration > > - I am using vanilla emacs (little to no configuration). > > - Custom configuration > > - Spacemacs - https://github.com/syl20bnr/spacemacs > > - Doom Emacs - https://github.com/hlissner/doom-emacs > > - Prelude - https://github.com/bbatsov/prelude > > - purcell emacs.d - https://github.com/purcell/emacs.d > > - magnars emacs.d - https://github.com/magnars/.emacs.d > > - Emacs Starter Kit - https://github.com/eschulte/emacs-starter-kit > > - oh-my-emacs - https://github.com/xiaohanyu/oh-my-emacs > > - Better Defaults - https://github.com/technomancy/better-defaults > > - Graphene - https://github.com/rdallasgray/graphene > > - ohai-emacs - https://github.com/bodil/ohai-emacs > > - ergoemacs-mode - https://github.com/ergoemacs/ergoemacs-mode > > - Rho Emacs - https://github.com/GChristensen/rho-emacs > > - Radian - https://github.com/raxod502/radian > > - Centaur Emacs - https://github.com/seagle0128/.emacs.d > > - Other The Emacs bug report system already include packages employed by various users, so the survey data of who uses which package, on which system, which Emacs version, is already there in the bug system. It needs only be evaluated, Emacs Lisp could crawl through the bug report and find out which packages are used mostly, which configurations, themes are used mostly by those who report bugs. Help menu -> Tell us how to improve Emacs, could automatically ask user to send whatever list of packages user is using, of course by asking user for permission, in similar way how that does the function {M-x report-emacs-bug} I am against advertising of the Microsoft® Github® on any official Emacs communication lines. I find the above Microsoft Github list biased for the reason that the list have been made in specific order by somebody and I do not see why should Centaur be last and Spacemacs first. Additionally, whoever made the list, already have got it by popularity, in fact, there is nothing to be asked, as Github is asking users to LIKE the project, there are "stars" given by users, so if you wish to know which Github project is more popular, use the following search: https://github.com/search?o=desc&q=emacs&s=stars&type=Repositories The evaluation is right there, as it is sorted by stars given by its users. Thus the above list is absolutely not necessary. Emacs, as free software, in general should not be pointing users to Github for reasons of non-free Javascript. Jean ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-10 10:54 ` Thibaut Verron 2020-10-10 13:50 ` Philip K. 2020-10-11 11:58 ` Jean Louis @ 2020-10-12 14:36 ` Adrien Brochard 2 siblings, 0 replies; 838+ messages in thread From: Adrien Brochard @ 2020-10-12 14:36 UTC (permalink / raw) To: thibaut.verron; +Cc: Richard Stallman, emacs-devel Thank you! I've added your suggestions to the survey. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-09 23:12 ` Adrien Brochard ` (2 preceding siblings ...) 2020-10-10 10:54 ` Thibaut Verron @ 2020-10-10 13:17 ` Rasmus 2020-10-12 14:41 ` Adrien Brochard 2020-10-11 5:23 ` Richard Stallman ` (2 subsequent siblings) 6 siblings, 1 reply; 838+ messages in thread From: Rasmus @ 2020-10-10 13:17 UTC (permalink / raw) To: emacs-devel Hi Adrien, Thank you for putting together the questions. I think they are some good questions there, although I am not quite sure what exactly the “research question” is. But I guess it’s just understanding users broadly... Adrien Brochard <abrochard@gmx.com> writes: > ** How would you characterize your use of Emacs? > - Use it for work - I use it for serious "hobby" projects - > I'm just tinkering - I use it for my studies - Other I would’t want to limit my choice to one here. I use Emacs for work (when I can) and for hobby projects. IOW: Multiple choices would be nice. > ** What do you use Emacs for? > - Software development - Research writing - Data science - > Writing - Other As above. > ** What OS do you primary use? > - Linux - Windows - MacOS - BSD - Other As above. > ** Describe your configuration > - I am using vanilla emacs (little to no configuration). - > Custom configuration - Spacemacs - > https://github.com/syl20bnr/spacemacs - Doom Emacs - > https://github.com/hlissner/doom-emacs - Prelude - > https://github.com/bbatsov/prelude - purcell emacs.d - > https://github.com/purcell/emacs.d - magnars emacs.d - > https://github.com/magnars/.emacs.d - Emacs Starter Kit - > https://github.com/eschulte/emacs-starter-kit - oh-my-emacs - > https://github.com/xiaohanyu/oh-my-emacs - Better Defaults - > https://github.com/technomancy/better-defaults - Graphene - > https://github.com/rdallasgray/graphene - ohai-emacs - > https://github.com/bodil/ohai-emacs - ergoemacs-mode - > https://github.com/ergoemacs/ergoemacs-mode - Rho Emacs - > https://github.com/GChristensen/rho-emacs - Radian - > https://github.com/raxod502/radian - Centaur Emacs - > https://github.com/seagle0128/.emacs.d - Other Well done finding all of those. I haven’t heard of most of those. > ** What keybindings do you use? > - Emacs defaults - Evil/Spacemacs/Doom-Emacs (all the > vim-likes) - CUA-mode - God-mode - Boon - Xah-Fly-Keys - > Custom modal (ryo-modal, etc) - Custom modifiers (Emacs from > scratch) - Other It may also be interesting to ask which keybinding you initially used. I would guess a lot of people started with CUA and moved to vanilla keybindings. > ** Prior to using Emacs what was your primary editor? > - VIM - VScode - Eclipse - Notepad++ - Sublime - Intelij - > Other None/don’t know? (I used TeXnicCenter but it is hardly an editor). > ** How do you manage third-party elisp? > - built-in package.el - Spacemacs does it for me - > straight.el - borg - leaf - el-get - Nix - git submodules > without Borg - git subtrees - git clones - guix - quelpa - > cask - No third-party deps - other Again, I’m impressed that you put together such a long list! > ** How do you get emacs packages(if applicable)? > - No repos - Gnu Elpa - Melpa/Melpa Stable - Directly from > the source (e. g. using straight). GNU ELPA is configured by default so is no repos necessary? > ** Can you list some of your favorite package? > > ** What package do you use for error checking? > - Flymake - Flycheck - None > > ** Do you use TRAMP? > > ** DO you use Magit? What is the purpose of this question? There are many VC programs and Magit can only be used for git. So if we care about “do you control VC from Emacs” then the question might not be precise enough. > ** Do you use shell/terminal emulator in Emacs? > - eshell - shell - term - ansi-term - do not use. “None” for consistency? > ** Do you use mail client in Emacs? > - Mu4e - Gnus - Mut - notmuch - do not use “mu4e” and “Mutt” I guess? And “None” for consistency. > ** What is your Elisp proficiency? > - Beginner/No knowledge - Basic elisp understanding - > Intermediate - Advanced - Expert I would find it very hard to decide here. Could something like this be split into more easily quantifiable choices? Like do you know how to use ‘defmacro’? > ** do you use a language server with lsp-mode? With what > languages? Maybe mention eglot as well? > ** Have you ever contributed to GNU Emacs core/Elpa? > - No - No, but I would do that if the process is > changed(e. g. using > github pull requests instead of the mailing list, no papers, > etc**. > - I do PRs from time to time - I provide PRs regularly - I > am active contributor/maintainer Nitpick: would “patches” be more well-understood than PR? > ** Have you ever contributed to Melpa package? > - No - I do PRs from time to time - I provide PRs regularly > - I am a package maintainer Nitpick: I guess you mean something more broad than “melpa” here? I guess I should understand it as “non-core packages” or “packages not shipped with Emacs” (that’s also not entirely correct as it may cover ELPA). > ** What Emacs community forums have you visited in the past > year? Answers would be things like > - r/emacs - Emacs mailing list - irc - Emacs meetups - I > follow twitter Emacs related accounts - Other Maybe include the Emacs stack exchange or does that not qualify as a forum? https://emacs.stackexchange.com/ It would also be good to have a banner there once the survey is “up”. > ** If there is another survey in 2021, would you be opposed to > it containing optional & general demographics questions? > It could include age backets, gender, country or language Can’t you just put those in and make them optional? Kind regards, Rasmus -- Human: An animal that complicates things more than strictly necessary ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-10 13:17 ` Rasmus @ 2020-10-12 14:41 ` Adrien Brochard 0 siblings, 0 replies; 838+ messages in thread From: Adrien Brochard @ 2020-10-12 14:41 UTC (permalink / raw) To: Rasmus, emacs-devel Thank you! I've added your suggestions in. For the lists, you can thank the Reddit community, they did all the hard work. >> ** What is your Elisp proficiency? - Beginner/No knowledge - Basic >> elisp understanding - Intermediate - Advanced - Expert > > I would find it very hard to decide here. Could something like this be > split into more easily quantifiable choices? Like do you know how to use > ‘defmacro’? ** What is your Elisp proficiency? - No knowledge - I copy paste some code here and there, mostly for my configuration - I can write my own simple functions - I can write my own packages What about these levels? >> ** If there is another survey in 2021, would you be opposed to it >> containing optional & general demographics questions? It could >> include age backets, gender, country or language > > Can’t you just put those in and make them optional? Some people were vocal about their preference for the survey not to include demographic questions, even optional, as it was inviting trouble. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-09 23:12 ` Adrien Brochard ` (3 preceding siblings ...) 2020-10-10 13:17 ` Rasmus @ 2020-10-11 5:23 ` Richard Stallman 2020-10-11 7:35 ` Vasilij Schneidermann 2020-10-12 15:16 ` Adrien Brochard 2020-10-11 20:54 ` Bonface M. K. 2020-10-16 13:30 ` Philip K. 6 siblings, 2 replies; 838+ messages in thread From: Richard Stallman @ 2020-10-11 5:23 UTC (permalink / raw) To: Adrien Brochard; +Cc: emacs-devel [[[ 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. ]]] Since this is a general survey rather than a focused inquiry, some of my plans don't apply. A multiple choice answer-taker would be usable in principel for these questions. But it needs to meet our ethical criteria -- not sending nonfree JS code to the browser. Also, each question should offer a way to answer "none of the above" or "I'm a strange case". Your questions seem pretty good overall for a survey. Here are a few specific critiques. > ** What OS do you primary use? > - Linux Linux is a kernel, not an operating system. So it should say, "GNU/Linux." See https://gnu.org/gnu/linux-and-gnu.html and https://gnu.org/gnu/gnu-linux-faq.html, plus the history in https://gnu.org/gnu/the-gnu-project.html. > ** How do you use Emacs? > - GUI > - Terminal (TUI) Some people will not know those terms, so let's use names that anyone will understand. > ** Which completion/selection framework do you use? Is it correct to assume a person uses only one? > ** Have you ever contributed to Melpa package? If it mentions Melpa, it must explain the ethical reason we cannot recommend anything about Melpa. I would rather not mention that name at all. > ** can you recall any difficulties you faced initially learning Emacs? Add, "Please be as specific and concrete as your memories permit." > ** If there is another survey in 2021, would you be opposed to it > containing optional & general demographics questions? > It could include age backets, gender, country or language Let's not ask that. We should not invite people to make difficulties for us. > ** Do you have a preferred platform for filling out the survey in the > future? That question would be useless -- people would recommend unjust platforms based on practical convenience. Let's add a short test: we could offer multiple choice answers for each of these. For some questions the user should be able to select multiple answers, and should select all that are valid. > What is GNU? > What is GNU/Linux? > How does GNU Emacs related to GNU? > What is free software (libre software)? > Which of these are free liceenses? > How does GNU relate to free software? -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-11 5:23 ` Richard Stallman @ 2020-10-11 7:35 ` Vasilij Schneidermann 2020-10-11 12:08 ` Jean Louis ` (2 more replies) 2020-10-12 15:16 ` Adrien Brochard 1 sibling, 3 replies; 838+ messages in thread From: Vasilij Schneidermann @ 2020-10-11 7:35 UTC (permalink / raw) To: Richard Stallman; +Cc: Adrien Brochard, emacs-devel [-- Attachment #1: Type: text/plain, Size: 1462 bytes --] > If it mentions Melpa, it must explain the ethical reason we cannot > recommend anything about Melpa. > > I would rather not mention that name at all. Not mentioning MELPA as an option because you feel uncomfortable about it will distort survey results, especially for the part where you ask what package archives people use. Worse, it leads to a self-reinforcing effect: If the true extent of people using MELPA is unknown, emacs-devel will continue making choices on the false premise that MELPA isn't a thing at all. In the worst case GNU ELPA will be eclipsed by MELPA and cease to be of any practical concern (and it sure seems to me that this is where things are heading currently). Remember, this is a survey to find out how Emacs users use their editor, not about how much they adhere to FSF ideology. > Let's add a short test: we could offer multiple choice answers for > each of these. For some questions the user should be able to select > multiple answers, and should select all that are valid. > > > What is GNU? > > > What is GNU/Linux? > > > How does GNU Emacs related to GNU? > > > What is free software (libre software)? > > > Which of these are free liceenses? > > > How does GNU relate to free software? See my last sentence above. What's the point of this quiz? Finding out what percentage of Emacs users fully believes in GNU's goals? What will that information be used for? [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-11 7:35 ` Vasilij Schneidermann @ 2020-10-11 12:08 ` Jean Louis 2020-10-11 12:50 ` Vasilij Schneidermann 2020-10-12 2:04 ` Richard Stallman 2020-10-12 2:04 ` Richard Stallman 2 siblings, 1 reply; 838+ messages in thread From: Jean Louis @ 2020-10-11 12:08 UTC (permalink / raw) To: Richard Stallman, Adrien Brochard, emacs-devel * Vasilij Schneidermann <mail@vasilij.de> [2020-10-11 10:38]: > > If it mentions Melpa, it must explain the ethical reason we cannot > > recommend anything about Melpa. > > > > I would rather not mention that name at all. > > Not mentioning MELPA as an option because you feel uncomfortable about > it will distort survey results, especially for the part where you ask > what package archives people use. Worse, it leads to a self-reinforcing > effect: If the true extent of people using MELPA is unknown, > emacs-devel will continue making choices on the false premise that MELPA > isn't a thing at all. In the worst case GNU ELPA will be eclipsed by > MELPA and cease to be of any practical concern (and it sure seems to me > that this is where things are heading currently). Remember, this is a > survey to find out how Emacs users use their editor, not about how much > they adhere to FSF ideology. Does MELPA contains non-free software? ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-11 12:08 ` Jean Louis @ 2020-10-11 12:50 ` Vasilij Schneidermann 2020-10-11 17:15 ` Jean Louis 2020-10-12 2:04 ` Richard Stallman 0 siblings, 2 replies; 838+ messages in thread From: Vasilij Schneidermann @ 2020-10-11 12:50 UTC (permalink / raw) To: Jean Louis; +Cc: Adrien Brochard, Richard Stallman, emacs-devel [-- Attachment #1: Type: text/plain, Size: 724 bytes --] > Does MELPA contains non-free software? No, it doesn't. Neither does the website contain non-free JS, it runs fine with LibreJS. The only concern here is that MELPA does not adhere to GNU's coding guidelines, such as never ever referring, linking or otherwise supporting non-free software (for example by hosting packages that wrap non-free executables or are tied into working with non-free operating systems). And why should they, they are not GNU, they are a community-provided package archive and a wildly successful one, too. Even if it contained non-free software, this is beside the point. What use is a survey if it doesn't strive to accurately capture the status quo and instead basks in ideological purity? [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-11 12:50 ` Vasilij Schneidermann @ 2020-10-11 17:15 ` Jean Louis 2020-10-11 17:36 ` Thibaut Verron 2020-10-12 2:04 ` Richard Stallman 1 sibling, 1 reply; 838+ messages in thread From: Jean Louis @ 2020-10-11 17:15 UTC (permalink / raw) To: emacs-devel; +Cc: Adrien Brochard, Richard Stallman * Vasilij Schneidermann <mail@vasilij.de> [2020-10-11 15:51]: > > Does MELPA contains non-free software? > > No, it doesn't. Neither does the website contain non-free JS, it runs > fine with LibreJS. The only concern here is that MELPA does not adhere > to GNU's coding guidelines, such as never ever referring, linking or > otherwise supporting non-free software (for example by hosting packages > that wrap non-free executables or are tied into working with non-free > operating systems). In other words packages on MELPA would or could refer, link and support non-free software including wrapping it. Hypothetical example could be the emacs package that supports proprietary speech system, such package could be interesting for developers, but without proprietary speech system it could not run, thus disabling freedom of users. Emacs is free software project, forerunner, so I guess that developers by GNU principles would not support, improve, develop, those software packages that are beyond free software principles. What each developer does in their private life is their own decision, each is free to use proprietary software how they wish, yet in the written or not written agreement for Emacs development, you all do not develop or support proprietary software. Thus a survey that brings up the issue that somebody would like to see Emacs Lisp package that supports proprietary speech software on Windows, would simply not work, as that would be waste of time. Nevertheless such inputs may come anyway, if good communication channel is offered, but there is no need to support inputs from users who would use or do not mind using proprietary wrapped software, as project is GNU, and Emacs is inseparable of principles of free software and GNU. > And why should they, they are not GNU, they are a community-provided > package archive and a wildly successful one, too. > > Even if it contained non-free software, this is beside the point. > What use is a survey if it doesn't strive to accurately capture the > status quo and instead basks in ideological purity? In my opinion, if GNU project is asking for input by well established communication line, and I suggest that such is implemented in Help menu, then it is inseparable from the movement to push free software philosophy onto users, as that is good thing to do. Ideological purity is impossible attainment. Every person is free to make surveys, any company or any individual, a user could use even proprietary software to make survey for Emacs, Microsoft would be free to begin its Windows by asking if their editor is better or Emacs. Any private person can turn on advertising on Internet and capture Emacs users and ask them any questions. This freedom of making surveys exist. I am saying this as "Emacs Survey" can be done independently on global level, but that is not for GNU to do it in that manner. MELPA probably collects information of IP addresses, locations, and number of downloads, thus they have enough data and possibilities for their own survey. By the way, it disallows me to browse the MELPA.ORG website without Javascript, I do not know if it is free or not. Let us imagine Microsoft providing Emacs script repository, that is quite possible, they do it now indirectly through Github, but we can imagine that such abusive company could lead users to many non-free software, and that was never the purpose of Emacs. Would then GNU ask Microsoft to ask users about that?! I don't think so, so GNU and GNU Emacs are inseparable from free software enlightenment and should not lead users to repositories where users may download or otherwise get abused by proprietary software. I like looking into extreme hypothetical situations to recognize if the direction of any action is supportive or not supportive for the group of people I personally belong, in this case free software movement. And that does not mean bashing onto anybody who bundles proprietary software, it just means promoting more of those free software principles to guide people gently into abuse free future. Jean ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-11 17:15 ` Jean Louis @ 2020-10-11 17:36 ` Thibaut Verron 2020-10-11 18:13 ` Brett Gilio 2020-10-11 18:34 ` Jean Louis 0 siblings, 2 replies; 838+ messages in thread From: Thibaut Verron @ 2020-10-11 17:36 UTC (permalink / raw) To: Jean Louis; +Cc: Adrien Brochard, Richard Stallman, emacs-devel > MELPA probably collects information of IP addresses, locations, and > number of downloads, thus they have enough data and possibilities for > their own survey. By the way, it disallows me to browse the MELPA.ORG > website without Javascript, I do not know if it is free or not. LibreJS only blocks two scripts on melpa.org: a twitter widget, and a google analytics snippet. Neither of those are necessary for using the site. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-11 17:36 ` Thibaut Verron @ 2020-10-11 18:13 ` Brett Gilio 2020-10-11 18:27 ` Thibaut Verron 2020-10-11 18:34 ` Jean Louis 1 sibling, 1 reply; 838+ messages in thread From: Brett Gilio @ 2020-10-11 18:13 UTC (permalink / raw) To: Thibaut Verron; +Cc: Adrien Brochard, Richard Stallman, Jean Louis, emacs-devel Thibaut Verron <thibaut.verron@gmail.com> writes: > > LibreJS only blocks two scripts on melpa.org: a twitter widget, and a > google analytics snippet. > > Neither of those are necessary for using the site. > It would be great if melpa.org didn't require Javascript for functionality, at all. But that is just my opinion. It is not possible to browse packages on M-x eww, for example. Perhaps a fallback would be nice. -- Brett M. Gilio <brettg@gnu.org> https://brettgilio.com ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-11 18:13 ` Brett Gilio @ 2020-10-11 18:27 ` Thibaut Verron 2020-10-11 18:44 ` Jean Louis 0 siblings, 1 reply; 838+ messages in thread From: Thibaut Verron @ 2020-10-11 18:27 UTC (permalink / raw) To: Brett Gilio; +Cc: Adrien Brochard, Richard Stallman, Jean Louis, emacs-devel > It would be great if melpa.org didn't require Javascript for > functionality, at all. But that is just my opinion. > > It is not possible to browse packages on M-x eww, for example. Perhaps a > fallback would be nice. M-x list-packages ? ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-11 18:27 ` Thibaut Verron @ 2020-10-11 18:44 ` Jean Louis 2020-10-11 18:58 ` Thibaut Verron 0 siblings, 1 reply; 838+ messages in thread From: Jean Louis @ 2020-10-11 18:44 UTC (permalink / raw) To: Thibaut Verron Cc: Adrien Brochard, Richard Stallman, Brett Gilio, emacs-devel * Thibaut Verron <thibaut.verron@gmail.com> [2020-10-11 21:28]: > > It would be great if melpa.org didn't require Javascript for > > functionality, at all. But that is just my opinion. > > > > It is not possible to browse packages on M-x eww, for example. Perhaps a > > fallback would be nice. > > M-x list-packages ? It is possible that MELPA webmaster have setup that website with intention not to let Emacs users browse packages through Emacs, but to force them to install MELPA into Emacs As the link to packages list is impossible to reach, but the link on how to add MELPA to Emacs is quite reachable through Emacs. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-11 18:44 ` Jean Louis @ 2020-10-11 18:58 ` Thibaut Verron 2020-10-11 20:12 ` Jean Louis 0 siblings, 1 reply; 838+ messages in thread From: Thibaut Verron @ 2020-10-11 18:58 UTC (permalink / raw) To: Jean Louis; +Cc: Adrien Brochard, Richard Stallman, Brett Gilio, emacs-devel Le dim. 11 oct. 2020 à 20:47, Jean Louis <bugs@gnu.support> a écrit : > > * Thibaut Verron <thibaut.verron@gmail.com> [2020-10-11 21:28]: > > > It would be great if melpa.org didn't require Javascript for > > > functionality, at all. But that is just my opinion. > > > > > > It is not possible to browse packages on M-x eww, for example. Perhaps a > > > fallback would be nice. > > > > M-x list-packages ? > > It is possible that MELPA webmaster have setup that website with > intention not to let Emacs users browse packages through Emacs, but to > force them to install MELPA into Emacs > > As the link to packages list is impossible to reach, but the link on > how to add MELPA to Emacs is quite reachable through Emacs. I think you're making an unfair "trial of motives" here. You can add Melpa to the list of repositories in an emacs instance and then browse it with list-packages. That will not "install Melpa" if you don't add the repository line in your init.el. For the record, here is the (short) discussion on the topic: https://github.com/melpa/melpa/issues/3483 ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-11 18:58 ` Thibaut Verron @ 2020-10-11 20:12 ` Jean Louis 0 siblings, 0 replies; 838+ messages in thread From: Jean Louis @ 2020-10-11 20:12 UTC (permalink / raw) To: Thibaut Verron Cc: Adrien Brochard, Richard Stallman, Brett Gilio, emacs-devel * Thibaut Verron <thibaut.verron@gmail.com> [2020-10-11 21:58]: > Le dim. 11 oct. 2020 à 20:47, Jean Louis <bugs@gnu.support> a écrit : > > > > * Thibaut Verron <thibaut.verron@gmail.com> [2020-10-11 21:28]: > > > > It would be great if melpa.org didn't require Javascript for > > > > functionality, at all. But that is just my opinion. > > > > > > > > It is not possible to browse packages on M-x eww, for example. Perhaps a > > > > fallback would be nice. > > > > > > M-x list-packages ? > > > > It is possible that MELPA webmaster have setup that website with > > intention not to let Emacs users browse packages through Emacs, but to > > force them to install MELPA into Emacs > > > > As the link to packages list is impossible to reach, but the link on > > how to add MELPA to Emacs is quite reachable through Emacs. > > I think you're making an unfair "trial of motives" here. Slight act of distracting and magic is done, instead of letting users understand what MELPA is, like does it at all offer free software (it is not described on the page or mentioned), it just says: do this and install this in Emacs, then proceed with installation of packages. It does not link back to Emacs software page, which I would as responsible webmaster always do. As I am not a judge, I make no trials, my impression though remains the same that it was intentional. Now you say the bug report from 2016 to make MELPA browsable by Emacs still remains same. > For the record, here is the (short) discussion on the topic: > https://github.com/melpa/melpa/issues/3483 I see some pretty trivial nonsense there: > "There is therefore no easy way to fix this, and I don't believe it > is worth a bigger effort," How it was done by using Javascript, it can be done by using Emacs Lisp or any other programming language, and generate static pages, quite automatically. > You can add Melpa to the list of repositories in an emacs instance and > then browse it with list-packages. That will not "install Melpa" if > you don't add the repository line in your init.el. I am speaking of accessibility subject. It will be remedied with elpa.nongnu.org ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-11 17:36 ` Thibaut Verron 2020-10-11 18:13 ` Brett Gilio @ 2020-10-11 18:34 ` Jean Louis 2020-10-11 19:15 ` Thibaut Verron 1 sibling, 1 reply; 838+ messages in thread From: Jean Louis @ 2020-10-11 18:34 UTC (permalink / raw) To: Thibaut Verron; +Cc: Adrien Brochard, Richard Stallman, emacs-devel * Thibaut Verron <thibaut.verron@gmail.com> [2020-10-11 20:37]: > > MELPA probably collects information of IP addresses, locations, and > > number of downloads, thus they have enough data and possibilities for > > their own survey. By the way, it disallows me to browse the MELPA.ORG > > website without Javascript, I do not know if it is free or not. > > LibreJS only blocks two scripts on melpa.org: a twitter widget, and a > google analytics snippet. > > Neither of those are necessary for using the site. I expect that any site promoting Emacs based software is accessible through Emacs and that such site should not expose me to Google Intelligence and Twitter, I don't like being tracked across other websites. I can perfectly use http://elpa.gnu.org through Emacs I cannot at all use https://melpa.org through Emacs, it is impossible. It is common sense not to design sites in such stunned way (sorry I was looking for synonyms of "stupid" not to be too bold). Website of MELPA is ridiculous. If it promotes Emacs, it should be accessible through Emacs. And now we discuss what Emacs users want, example me, I don't want to be pushed around. MELPA * Packages <--- I can click, but nothing happens * Getting started <--- I can click, but nothing happens * GitHub <--- brings me to Microsoft Github (THE LINK WORKS!!! YEAH!!!) MELPA (Milkypostman’s Emacs Lisp Package Archive) * Up-to-date packages built on our servers from upstream source * Installable in any Emacs with 'package.el' - no local version-control tools needed * Curated - no obsolete, renamed, forked or randomly hacked packages * Comprehensive - more packages than any other archive * Automatic updates - new commits result in new packages * Extensible - contribute recipes via github, and we'll build the packages This site requires JavaScript to function. You can browse and install packages directly from Emacs (see MELPA's README.md on GitHub). Source code for this page → JavaScript license information -------- end of inaccessible MELPA website -------- I cannot wait for non-GNU ELPA to begin. Jean ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-11 18:34 ` Jean Louis @ 2020-10-11 19:15 ` Thibaut Verron 2020-10-11 19:22 ` Qiantan Hong 2020-10-11 20:26 ` Jean Louis 0 siblings, 2 replies; 838+ messages in thread From: Thibaut Verron @ 2020-10-11 19:15 UTC (permalink / raw) To: Jean Louis; +Cc: Adrien Brochard, Richard Stallman, emacs-devel > I can perfectly use http://elpa.gnu.org through Emacs > > I cannot at all use https://melpa.org through Emacs, it is > impossible. It is common sense not to design sites in such stunned way > (sorry I was looking for synonyms of "stupid" not to be too bold). It seems reasonable to me that a list that changes every now and then (Elpa) is easier to serve statically than a list which is updated several times a day (Melpa). But if the list of GNU Elpa is generated automatically, maybe the code to do that can be useful to Melpa. > Website of MELPA is ridiculous. If it promotes Emacs, it should be > accessible through Emacs. And now we discuss what Emacs users want, > example me, I don't want to be pushed around. Or maybe Emacs should have a web browser which can run (free) javascript. I don't think so, for obvious security reasons, but then again I don't expect to be able to access all emacs-related websites from within Emacs. And, again, Melpa is accessible through Emacs: the entire content of the website is served on an API which is fully supported by Emacs (list-packages). > This site requires JavaScript to function. At least that's pretty explicit. > JavaScript license information And they went through the trouble of using only free javascript for the website (except for the, admittedly, unnecessary twitter feed and analytics, which a lot of users will block with their adblocker or LibreJS). ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-11 19:15 ` Thibaut Verron @ 2020-10-11 19:22 ` Qiantan Hong 2020-10-13 3:47 ` Richard Stallman 2020-10-11 20:26 ` Jean Louis 1 sibling, 1 reply; 838+ messages in thread From: Qiantan Hong @ 2020-10-11 19:22 UTC (permalink / raw) To: thibaut.verron@gmail.com Cc: Adrien Brochard, rms@gnu.org, Jean Louis, emacs-devel [-- Attachment #1: Type: text/plain, Size: 393 bytes --] > > Or maybe Emacs should have a web browser which can run (free) javascript. > Emacs with —with-xwidget build already does. And I was working on some patches to port librejs and potentially other WebExtensions plugins to it. The copyright office of my school is a bit slow so it’s been stopped for a while, but should not take much time once the copyright assignment is complete. [-- Attachment #2: smime.p7s --] [-- Type: application/pkcs7-signature, Size: 1858 bytes --] ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-11 19:22 ` Qiantan Hong @ 2020-10-13 3:47 ` Richard Stallman 0 siblings, 0 replies; 838+ messages in thread From: Richard Stallman @ 2020-10-13 3:47 UTC (permalink / raw) To: Qiantan Hong; +Cc: abrochard, bugs, thibaut.verron, emacs-devel [[[ 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. ]]] > > Or maybe Emacs should have a web browser which can run (free) javascript. > > > Emacs with —with-xwidget build already does. Please do not do anything along those lines. What we already did may have been a grave ethical mistake. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-11 19:15 ` Thibaut Verron 2020-10-11 19:22 ` Qiantan Hong @ 2020-10-11 20:26 ` Jean Louis 1 sibling, 0 replies; 838+ messages in thread From: Jean Louis @ 2020-10-11 20:26 UTC (permalink / raw) To: Thibaut Verron; +Cc: Adrien Brochard, Richard Stallman, emacs-devel * Thibaut Verron <thibaut.verron@gmail.com> [2020-10-11 22:16]: > > I can perfectly use http://elpa.gnu.org through Emacs > > > > I cannot at all use https://melpa.org through Emacs, it is > > impossible. It is common sense not to design sites in such stunned way > > (sorry I was looking for synonyms of "stupid" not to be too bold). > > It seems reasonable to me that a list that changes every now and then > (Elpa) is easier to serve statically than a list which is updated > several times a day (Melpa). What can be generated online, it can be generated statically, it is matter of seconds. Thus I am not underestimating the webmaster of MELPA. He did not want it in 2016, he does not want it now. There is no "discussion" on the bug report, he closed the bug, finished. It does not seem to be user friendly. There is nothing interactive on MELPA to be served dynamically, there is no user input other than clicking, there are no interactions. I do not underestimate programmers and their intelligence. If MELPA would be easily browsable, it would be easily duplicated as a website. > But if the list of GNU Elpa is generated automatically, maybe the > code to do that can be useful to Melpa. Of course it can. For now it seem trivial, and can be done through Emacs Lisp. > > Website of MELPA is ridiculous. If it promotes Emacs, it should be > > accessible through Emacs. And now we discuss what Emacs users want, > > example me, I don't want to be pushed around. > > Or maybe Emacs should have a web browser which can run (free) > javascript. But why only javascript, maybe Emacs should have Emacs Lisp instead of Javascript, that way we could run programs on Emacs by installing them straight from websites without knowing what is going to happen, within some safe environment so that it does not affect the system. So far I know, any script could be included in web pages, it all depends of plugins to browsers, I remember Perl could be included in the web pages, and other programming languages, why not Emacs Lisp then. > I don't think so, for obvious security reasons, but then again I > don't expect to be able to access all emacs-related websites from > within Emacs. That's what I am talking about, it should be accessible through Emacs. > And, again, Melpa is accessible through Emacs: the entire content of > the website is served on an API which is fully supported by Emacs > (list-packages). > > > This site requires JavaScript to function. > > At least that's pretty explicit. And how that can be good, we speak of Emacs, not of whatever else. People do use Internet through Emacs. > > JavaScript license information > > And they went through the trouble of using only free javascript for > the website (except for the, admittedly, unnecessary twitter feed and > analytics, which a lot of users will block with their adblocker or > LibreJS). Which makes the MELPA website non-free website, not recommended for freedom lovers. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-11 12:50 ` Vasilij Schneidermann 2020-10-11 17:15 ` Jean Louis @ 2020-10-12 2:04 ` Richard Stallman 2020-10-12 3:32 ` Thibaut Verron 1 sibling, 1 reply; 838+ messages in thread From: Richard Stallman @ 2020-10-12 2:04 UTC (permalink / raw) To: Vasilij Schneidermann; +Cc: abrochard, bugs, emacs-devel [[[ 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. ]]] > Even if it contained non-free software, this is beside the point. What > use is a survey if it doesn't strive to accurately capture the status > quo and instead basks in ideological purity? That's not a fair description of what we are doing, so it is a misled criticism. You can't convince me that what I am doing is mistaken by describing it wrong. And please don't be so harsh in tone. Please review the Kind Communications Guidelines, https://gnu.org/philosophy/kind-communication.html, and try to express your point in a way that is less harsh. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-12 2:04 ` Richard Stallman @ 2020-10-12 3:32 ` Thibaut Verron 2020-10-12 5:04 ` Jean Louis 2020-10-12 5:36 ` Jean Louis 0 siblings, 2 replies; 838+ messages in thread From: Thibaut Verron @ 2020-10-12 3:32 UTC (permalink / raw) To: Richard Stallman Cc: emacs-devel, Adrien Brochard, bugs, Vasilij Schneidermann [-- Attachment #1: Type: text/plain, Size: 991 bytes --] > > > Even if it contained non-free software, this is beside the point. What > > use is a survey if it doesn't strive to accurately capture the status > > quo and instead basks in ideological purity? > > That's not a fair description of what we are doing, so it is a misled > criticism. Just as a reminder, here is what the email starter suggested: > a survey for Emacs users to better grasp the diversity and various usages out there There is nothing about taking practical decisions or encouraging free software (or anything) there. And I would be worried about selection bias in a survey which voluntarily omits the most popular options from the lists of choices: how many people would choose not to complete the survey of they feel that the questions are biased? Would it be acceptable to put all major package repos in the list, with a warning saying that melpa is not a free software repository? The same warning could be used when mentioning windows, non-free IDEs, etc. [-- Attachment #2: Type: text/html, Size: 1501 bytes --] ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-12 3:32 ` Thibaut Verron @ 2020-10-12 5:04 ` Jean Louis 2020-10-12 5:33 ` Thibaut Verron 2020-10-12 5:36 ` Jean Louis 1 sibling, 1 reply; 838+ messages in thread From: Jean Louis @ 2020-10-12 5:04 UTC (permalink / raw) To: Thibaut Verron; +Cc: Richard Stallman, emacs-devel * Thibaut Verron <thibaut.verron@gmail.com> [2020-10-12 06:33]: > > > > > Even if it contained non-free software, this is beside the point. What > > > use is a survey if it doesn't strive to accurately capture the status > > > quo and instead basks in ideological purity? > > > > That's not a fair description of what we are doing, so it is a misled > > criticism. > > > Just as a reminder, here is what the email starter suggested: > > > a survey for Emacs users to better grasp the diversity and various usages > out there > > There is nothing about taking practical decisions or encouraging free > software (or anything) there. Every opinion poll survey has a purpose, normally the purpose is to find out what majority wish and want to improve the product or service and thus reach or gain more customers, strike it, users. - Encouraging free software is within the context of GNU Emacs subject. - Encouraging or supporting usage of non-free software is not within the context. Thus the survey or opinion polls cannot be evaluated in the manner to encourage usage of proprietary software, it is vice versa. Those opinions vouching for proprietary software would or should be enlightened of the benefits and safety of free software. A survey from the context of GNU Emacs development naturally should involve questions related to free software as the purpose of Emacs was historically to distribute free software, https://www.gnu.org/gnu/thegnuproject.html > Would it be acceptable to put all major package repos in the list, > with a warning saying that melpa is not a free software repository? Are there many package repositories? I know of three, there will be fourth soon elpa.nongnu.org or similar. They do provide free software naturally as packages should be GPL so far I understand (not sure), but if they wrap non free software or have pointers to non free software, such recommendation would be contrary to principles why GNU Emacs have been made as free software. > The same warning could be used when mentioning windows, non-free > IDEs, etc. Warning you mention is used on Emacs download page, see https://www.gnu.org/software/emacs/download.html ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-12 5:04 ` Jean Louis @ 2020-10-12 5:33 ` Thibaut Verron 2020-10-12 6:29 ` Jean Louis ` (3 more replies) 0 siblings, 4 replies; 838+ messages in thread From: Thibaut Verron @ 2020-10-12 5:33 UTC (permalink / raw) To: Jean Louis; +Cc: Richard Stallman, emacs-devel > > Just as a reminder, here is what the email starter suggested: > > > > > a survey for Emacs users to better grasp the diversity and various usages > > out there > > > > There is nothing about taking practical decisions or encouraging free > > software (or anything) there. > > Every opinion poll survey has a purpose, normally the purpose is to > find out what majority wish and want to improve the product or service > and thus reach or gain more customers, strike it, users. Yes it has a purpose, I quoted it above. To understand "the diversity and various usages out there". Specifically excluding some popular usages defeats that purpose. If anything, wouldn't we want to get an idea how many Emacs users currently use a non-free package repository? On the other hand, there are no questions in the suggested list about what people want. > > Would it be acceptable to put all major package repos in the list, > > with a warning saying that melpa is not a free software repository? > > Are there many package repositories? I know of three, there will be > fourth soon elpa.nongnu.org or similar. Yes, that sounds about right. > They do provide free software naturally as packages should be GPL so > far I understand (not sure), but if they wrap non free software or > have pointers to non free software, such recommendation would be > contrary to principles why GNU Emacs have been made as free software. I don't understand why a question in a survey would be seen as a recommendation. That's similar, in a sense, to those social surveys asking people if they have done drugs. I don't think those want to encourage people to take drugs. > > The same warning could be used when mentioning windows, non-free > > IDEs, etc. > > Warning you mention is used on Emacs download page, see > https://www.gnu.org/software/emacs/download.html Great, so there is precedent ! Why is it acceptable and sufficient on the main download page but not acceptable in a survey? Those words are a bit too harsh when applied to Melpa, I hope that we agree on that. And nobody likes to read propaganda (no matter how justified) in a survey, so having such a long tirade could again lead to selection bias. But, for example, wouldn't something like below be both short and explicit enough? "- Melpa (Note: Emacs and the GNU project DO NOT ENDORSE package repositories which encourage non-free software, see https://www.gnu.org/philosophy/)" ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-12 5:33 ` Thibaut Verron @ 2020-10-12 6:29 ` Jean Louis 2020-10-12 6:58 ` Thibaut Verron 2020-10-12 7:54 ` Ihor Radchenko 2020-10-13 3:53 ` Richard Stallman ` (2 subsequent siblings) 3 siblings, 2 replies; 838+ messages in thread From: Jean Louis @ 2020-10-12 6:29 UTC (permalink / raw) To: Thibaut Verron; +Cc: Richard Stallman, emacs-devel * Thibaut Verron <thibaut.verron@gmail.com> [2020-10-12 08:34]: > > > Just as a reminder, here is what the email starter suggested: > > > > > > > a survey for Emacs users to better grasp the diversity and various usages > > > out there > > > > > > There is nothing about taking practical decisions or encouraging free > > > software (or anything) there. > > > > Every opinion poll survey has a purpose, normally the purpose is to > > find out what majority wish and want to improve the product or service > > and thus reach or gain more customers, strike it, users. > > Yes it has a purpose, I quoted it above. To understand "the diversity > and various usages out there". Specifically excluding some popular > usages defeats that purpose. Tell me examples of popular usage that you refer to? Free form gives enough possibility for any user to explain anything they wish. > If anything, wouldn't we want to get an idea how many Emacs users > currently use a non-free package repository? I am not sure if there is any non-free package repository for Emacs. MELPA is fetching most packages from the Microsoft Github, and Github dictates free licenses for any public repository, most of them are free software. For me is hard to find particular example that uses non free software. That will be work to do, to move some public packages to non-GNU ELPA. MELPA recipes can be cloned, copy of software can be placed on nongnu.org automatically, later revised from TODO to be TO PUBLISH, and distributed ethically. > > They do provide free software naturally as packages should be GPL so > > far I understand (not sure), but if they wrap non free software or > > have pointers to non free software, such recommendation would be > > contrary to principles why GNU Emacs have been made as free software. > > I don't understand why a question in a survey would be seen as a > recommendation. Above paragraph refers to MELPA, that could wrap non free software in the free software packages. I can then imagine links in packages pointing to non free software, that is what was meant with recommendation. It does not refer to questions in the opinion poll. > That's similar, in a sense, to those social surveys asking people if > they have done drugs. I don't think those want to encourage people to > take drugs. > > > > The same warning could be used when mentioning windows, non-free > > > IDEs, etc. > > > > Warning you mention is used on Emacs download page, see > > https://www.gnu.org/software/emacs/download.html > > Great, so there is precedent ! Why is it acceptable and sufficient on > the main download page but not acceptable in a survey? It is not a new precedent, it was from the creation of Emacs to talk about free software, and advise people. In my opinion GNU project should increase the marketing of free software philosophy by power of 10, it is not enough. > Those words are a bit too harsh when applied to Melpa, I hope that > we agree on that. And nobody likes to read propaganda (no matter how > justified) in a survey, so having such a long tirade could again > lead to selection bias. GNU project with promotion of free software is not biased as that would mean that it is influenced in an unfair way. GNU project is influenced in a fair way and thus should be promoting and supporting free software and helping users of proprietary software to understand what is free software and freedom in computing. The word propaganda you maybe used in a negative connotation, but the word itself means promoting information to spread some cause. Who is not interested, would not read it. The point of propaganda that some will get interested, so propaganda gives results for those who are. > But, for example, wouldn't something like below be both short and > explicit enough? > > "- Melpa (Note: Emacs and the GNU project DO NOT ENDORSE package > repositories which encourage non-free software, see > https://www.gnu.org/philosophy/)" I do not think that it is necessary for survey from GNU Emacs to ask if people are using Melpa or whatever other software repository. Reason for that is that it is obvious that people do, people ARE using MELPA and Marmalade software repositories; AND more important reason not to ask is that information about usage of those repositories, likes, number of contributors, it is already available on the Microsoft Github "Insights" link on the MELPA page. There is no point in asking users what is already obvious. There are stars or likes on Github. If there is certain disagreement between GNU and MELPA, that is valid reason as well. In my opinion, the team of MELPA is preparing the list of packages well, then GNU team working on ELPA on nongnu.org can fork all the software and curate and remove whatever is unsafe or not ethical and make a new repository. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-12 6:29 ` Jean Louis @ 2020-10-12 6:58 ` Thibaut Verron 2020-10-12 8:16 ` Jean Louis 2020-10-12 7:54 ` Ihor Radchenko 1 sibling, 1 reply; 838+ messages in thread From: Thibaut Verron @ 2020-10-12 6:58 UTC (permalink / raw) To: Jean Louis; +Cc: Richard Stallman, emacs-devel > Tell me examples of popular usage that you refer to? Downloading packages from Melpa every day. Or even using Doom or Spacemacs (both activate the Melpa repository afaict, through Straight in the case of Doom). > Free form gives enough possibility for any user to explain anything > they wish. But do they wish to? Imagine a poll for a presidential election, where John Doe and Richard Miles are the frontrunners. Now let's say that a pollster frames its question like this: "Who do you intend to vote for? - John Doe - Other (please specify)" What would you think of the data resulting from such a poll? > > > If anything, wouldn't we want to get an idea how many Emacs users > > currently use a non-free package repository? > > I am not sure if there is any non-free package repository for > Emacs. > > MELPA is fetching most packages from the Microsoft Github, and Github > dictates free licenses for any public repository, most of them are > free software. For me is hard to find particular example that uses non > free software. Okay... > Above paragraph refers to MELPA, that could wrap non free software in > the free software packages. I can then imagine links in packages pointing > to non free software, that is what was meant with recommendation. It > does not refer to questions in the opinion poll. Okay. > GNU project with promotion of free software is not biased as that > would mean that it is influenced in an unfair way. The GNU project is not biased. But the proposed amended survey would be, similar to the hypothetical presidential poll above. > > GNU project is influenced in a fair way and thus should be promoting > and supporting free software and helping users of proprietary software > to understand what is free software and freedom in computing. > > The word propaganda you maybe used in a negative connotation, but the > word itself means promoting information to spread some cause. Who is > not interested, would not read it. The point of propaganda that some > will get interested, so propaganda gives results for those who are. Who is not interested might also leave the survey and skew the data. Advertisement campaigns disguised as surveys are legion. > > But, for example, wouldn't something like below be both short and > > explicit enough? > > > > "- Melpa (Note: Emacs and the GNU project DO NOT ENDORSE package > > repositories which encourage non-free software, see > > https://www.gnu.org/philosophy/)" > > I do not think that it is necessary for survey from GNU Emacs to ask > if people are using Melpa or whatever other software > repository. > > Reason for that is that it is obvious that people do, people ARE using > MELPA and Marmalade software repositories; Okay, that is a valid point (although I would be interested to know if people still use Marmalade). But then we might as well drop the repository question altogether. > AND more important reason > not to ask is that information about usage of those repositories, > likes, number of contributors, it is already available on the > Microsoft Github "Insights" link on the MELPA page. There is no point > in asking users what is already obvious. There are stars or likes on > Github. This data might have its own selection bias. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-12 6:58 ` Thibaut Verron @ 2020-10-12 8:16 ` Jean Louis 2020-10-12 8:37 ` Thibaut Verron 0 siblings, 1 reply; 838+ messages in thread From: Jean Louis @ 2020-10-12 8:16 UTC (permalink / raw) To: Thibaut Verron; +Cc: Richard Stallman, emacs-devel * Thibaut Verron <thibaut.verron@gmail.com> [2020-10-12 10:00]: > > Tell me examples of popular usage that you refer to? > > Downloading packages from Melpa every day. Or even using Doom or > Spacemacs (both activate the Melpa repository afaict, through Straight > in the case of Doom). Aha. As there is disagreement between GNU project and MELPA way of providing software packages, and as it is obvious that many users do use MELPA, there is no need to ask what is obvious, one has to implement wider software package repository from GNU project itself. Spacemacs is configuration, it is also considered software, so also for this is obvious that 20,000+ Microsoft Github users have given star/like on Github, as that is what I understand when I read 20.7k+ -- so it is obvious, that need not be asked, asking would be useless compared to obvious statistical results. (Note, when I use the word Microsoft in front of Github, it is used in the sense of warning.) Unless Github statistics are fake, GNU Emacs developers can already think why those 20,700+ users are using Spacemacs and think how to improve Emacs in general. In my opinion there is no need to ask what is obvious. There is need to act. > > Free form gives enough possibility for any user to explain anything > > they wish. > > But do they wish to? So far I read on this list, that was proposed by RMS and few others acknowledged it, I also think that it should be free form and I and Drew, we like it to be included permanently in the menu, something like: Help -> Tell us how to improve Then from Tell us how to improve: -> Report Emacs bug -> Suggest improvements -> Subscribe to Help GNU Emacs mailing list -> Send email to Help GNU Emacs list -> Unsubscribe from Help GNU Emacs mailing list The menu item "Suggest improvements" could be similar to report-emacs-bug just enlightening and inviting user to communicate about enhancements. There is no need in Emacs for those opinion poll surveys with set of questions, it is questionable and unclear who would be doing such survey, who would be paying for that, and who would be evaluating it. What is successful action is to listen to users who write to help-gnu-emacs, devel-emacs and developers also listen to users beyond official GNU communication lines, so that what is successful is working, and need not be changed. Cheapest long term solution is to embed it in Emacs, that is anyway inviting new users to collaborate. Then listening to users and improving by understanding their needs. > Imagine a poll for a presidential election, where John Doe and Richard > Miles are the frontrunners. > > Now let's say that a pollster frames its question like this: > > "Who do you intend to vote for? > - John Doe > - Other (please specify)" > > What would you think of the data resulting from such a poll? I know what you mean, especially for the reason that I have been doing surveys with people on the phone, in person face to face, on the street, and by visiting people at their homes, I have got paid for making surveys, and I know how to evaluate surveys, and how to write them properly. My answer to that proposal is same as Drew's, something like implementation of the above menus in the Help. > > GNU project with promotion of free software is not biased as that > > would mean that it is influenced in an unfair way. > > The GNU project is not biased. But the proposed amended survey would > be, similar to the hypothetical presidential poll above. So far I know, GNU project is not encompassing projects that are not ethical. For those questions that RMS proposed, I think they are also not necessary to be made for the reason that every survey gives its results or data that has to be evaluated, and it is obvious that many users, millions probably, do not know what is Linux as kernel and what is operating system. In that sense, Emacs already has in its splash screen (About GNU Emacs): Welcome to GNU Emacs, one component of the GNU/Linux operating system Where the words "GNU/Linux" are hyperlinked to appropriate GNU page. nd in my opinion, Emacs should contain more information and links to free software, that should be *contained* in the Emacs distribution and not just hyperlinked. For example I think that GNU Manifesto should go back to GNU Emacs where it was, it should be obtainable through Help system. Additionally, I would include in the Help system, the option to turn on "Free Software Menu". Then the Free Software menu option would appear with various submenues, delivering GNU free software philosophy straight from Emacs, without using Internet. My opinion is maybe in that sense more "pushy" then what RMS wants, I think that free software philosophy has to be pushy 10 times more than it is now, as the increase of proprietary software and troublesame abuses of people on this planet increased as well. > Okay, that is a valid point (although I would be interested to > know if people still use Marmalade). But then we might as well drop > the repository question altogether. I would drop all the questions, and just have it embedded in Emacs Help menu for people to complain, suggest improvements, etc. System already exists, but "Report Emacs bug" does not incite suggesting improvements. I read now that Marmalade has been discontinued. Proposal about making a survey is fine, why not? But where is the person responsible, money, funds, methods, tactical plan how to implement the survey, evaluator, and so on?! All that is time and resources consuming process, while in same time developers already know what is attracting people, what has to be done to be improved, they are finally improving it every day. > > AND more important reason not to ask is that information about > > usage of those repositories, likes, number of contributors, it is > > already available on the Microsoft Github "Insights" link on the > > MELPA page. There is no point in asking users what is already > > obvious. There are stars or likes on Github. > > This data might have its own selection bias. Of course. I would not trust the Microsoft Github data at all, and it does not show logically to be true, here is short analysis: - we assume here that Spacemacs has 20700 stars/likes on Microsoft Github, because it says so on the page. Does that mean those are "users" of Spacemacs? Hard to believe, see below why. - if I open the main Spacemacs Github page, I can see that last improvement on Spacemacs was 29th February 2020, there is not much going on. But Spacemacs is appearing as first on Github for the search word "emacs". - I can see number of contributors, number is 562 contributors, there are so many contributors but the last update was 29th February 2020, maybe I am mistaken. So many contributors are counted as such if they report a bug, they do not write software necessarily. I can see very unrelated or mixture of bugs reported: https://github.com/syl20bnr/spacemacs/issues?q=is%3Aissue+is%3Aclosed - in my opinion, there is maybe 1000 - max 2000 real users of Spacemacs, not more than that. I am assumin that maybe each among 4 will make "issue" and thus become contributor, about 562 x 4 people is my imaginative assumption of number of users who ever tried Spacemacs, and I am sure that bunch of them stopped using it as well. It is untrue that 20700 stars mean there are so many users, people click how they want and wish. Spacemacs is definitely not for beginners, it is distributed from Git, so user must have and know how to git pull or clone it. It could be as well possible that author have advertised Spacemacs back in time. In general, it is doing good job to advertise Emacs. Jean ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-12 8:16 ` Jean Louis @ 2020-10-12 8:37 ` Thibaut Verron 2020-10-12 14:09 ` Jean Louis 0 siblings, 1 reply; 838+ messages in thread From: Thibaut Verron @ 2020-10-12 8:37 UTC (permalink / raw) To: Jean Louis; +Cc: Richard Stallman, emacs-devel > Spacemacs is configuration, it is also considered software, so also > for this is obvious that 20,000+ Microsoft Github users have given > star/like on Github, as that is what I understand when I read 20.7k+ > -- so it is obvious, that need not be asked, asking would be useless > compared to obvious statistical results. (Note, when I use the word > Microsoft in front of Github, it is used in the sense of warning.) I would think that those 20k are a gross underestimate, more on that below. (And I understood that.) > Unless Github statistics are fake, GNU Emacs developers can already > think why those 20,700+ users are using Spacemacs and think how to > improve Emacs in general. In my opinion there is no need to ask what > is obvious. There is need to act. The actual number is not obvious, beyond "at least 20k". > I know what you mean, especially for the reason that I have been doing > surveys with people on the phone, in person face to face, on the > street, and by visiting people at their homes, I have got paid for > making surveys, and I know how to evaluate surveys, and how to write > them properly. > > My answer to that proposal is same as Drew's, something like > implementation of the above menus in the Help. So only free form, no multiple choice, and permanently in Emacs? That's fine for me. The goal is then sensibly different from that of the suggested survey, and as you say, they are not mutually exclusive. > My opinion is maybe in that sense more "pushy" then what RMS wants, I > think that free software philosophy has to be pushy 10 times more than > it is now, as the increase of proprietary software and troublesame > abuses of people on this planet increased as well. > > > Okay, that is a valid point (although I would be interested to > > know if people still use Marmalade). But then we might as well drop > > the repository question altogether. > > I would drop all the questions, and just have it embedded in Emacs > Help menu for people to complain, suggest improvements, etc. System > already exists, but "Report Emacs bug" does not incite suggesting > improvements. Questions are useful to avoid writer paralysis though. There could be three systems: "answer survey" (with a few free-form questions to give inspiration), "send suggestion", "report bug". > > Of course. I would not trust the Microsoft Github data at all, and it > does not show logically to be true, here is short analysis: > > - we assume here that Spacemacs has 20700 stars/likes on Microsoft > Github, because it says so on the page. Does that mean those are > "users" of Spacemacs? Hard to believe, see below why. > > - if I open the main Spacemacs Github page, I can see that last > improvement on Spacemacs was 29th February 2020, there is not much > going on. But Spacemacs is appearing as first on Github for the > search word "emacs". Second is the emacs-mirror (and the first result for a google search "github emacs" for me). I don't know how github sorts its results, it is not just stars. > - I can see number of contributors, number is 562 contributors, there > are so many contributors but the last update was 29th February 2020, > maybe I am mistaken. So many contributors are counted as such if > they report a bug, they do not write software necessarily. I can see > very unrelated or mixture of bugs reported: > https://github.com/syl20bnr/spacemacs/issues?q=is%3Aissue+is%3Aclosed Some branches are more recent, see for example buffertabs, last updated 2 weeks ago and 4k commits ahead of master. Apparently Github defines contributor as "has published to master" (possibly via a fork and pull-request?). The list of contributors is not visible beyond the top 100, but those 100 all have at least one commit on master. > It is untrue that 20700 stars mean there are so many users, people > click how they want and wish. Spacemacs is definitely not for > beginners, it is distributed from Git, so user must have and know how > to git pull or clone it. Are you sure about that? The website spacemacs.org has a big "download" button which serves a zipped copy of master. Does running spacemacs require knowledge from git after that point? Regardless, it is possible to run spacemacs without ever visiting the github page of the project, and github stars cannot track those. So even though some of those 20k stars are probably not users, or are no longer users, I still believe that the actual number of users may be way more than 20k. A properly conducted survey seems like a good way to get a better estimate of the actual number. But I agree that it is not a trivial task. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-12 8:37 ` Thibaut Verron @ 2020-10-12 14:09 ` Jean Louis 0 siblings, 0 replies; 838+ messages in thread From: Jean Louis @ 2020-10-12 14:09 UTC (permalink / raw) To: Thibaut Verron; +Cc: Richard Stallman, emacs-devel * Thibaut Verron <thibaut.verron@gmail.com> [2020-10-12 11:38]: > So only free form, no multiple choice, and permanently in Emacs? > That's fine for me. > > The goal is then sensibly different from that of the suggested survey, > and as you say, they are not mutually exclusive. Yes, like that. Emacs has its website, various simple qeustion based opinion polls can easily published on the website, that was done since inception of websites. > > My opinion is maybe in that sense more "pushy" then what RMS wants, I > > think that free software philosophy has to be pushy 10 times more than > > it is now, as the increase of proprietary software and troublesame > > abuses of people on this planet increased as well. > > > > > Okay, that is a valid point (although I would be interested to > > > know if people still use Marmalade). But then we might as well drop > > > the repository question altogether. > > > > I would drop all the questions, and just have it embedded in Emacs > > Help menu for people to complain, suggest improvements, etc. System > > already exists, but "Report Emacs bug" does not incite suggesting > > improvements. > > Questions are useful to avoid writer paralysis though. > There could be three systems: "answer survey" (with a few free-form > questions to give inspiration), "send suggestion", "report bug". That is right, that is how users should be motivated to communicate. > > Of course. I would not trust the Microsoft Github data at all, and it > > does not show logically to be true, here is short analysis: > > > > - we assume here that Spacemacs has 20700 stars/likes on Microsoft > > Github, because it says so on the page. Does that mean those are > > "users" of Spacemacs? Hard to believe, see below why. > > > > - if I open the main Spacemacs Github page, I can see that last > > improvement on Spacemacs was 29th February 2020, there is not much > > going on. But Spacemacs is appearing as first on Github for the > > search word "emacs". > > Second is the emacs-mirror (and the first result for a google search > "github emacs" for me). Emacs mirror on Github is second, but obviously there is no movement there, it shows that statistics are doubtful. > I don't know how github sorts its results, it is not just stars. Because nobody knows, and especially because it is from Microsoft, I would not touch it or believe it. But that is up to imaginary, as for now, survey evaluators. > > It is untrue that 20700 stars mean there are so many users, people > > click how they want and wish. Spacemacs is definitely not for > > beginners, it is distributed from Git, so user must have and know how > > to git pull or clone it. > > Are you sure about that? The website spacemacs.org has a big > "download" button which serves a zipped copy of master. > Does running spacemacs require knowledge from git after that point? No info on that. But it is quite easy to ask Spacemacs for website statistics, as survey for that reason is obviously not necessary. Then how to know if statistics are real? By asking various configuration packages for statistics, one can find out some ratios, but why? One has to ask WHY each time. One WHY could be to replicate or include or invite the configuration to GNU project. If that is reason why, then why not ask. If there is nothing special, it is just good to let people do what they wish. Example of discussed Spacemacs is clear to me, the data is already there, so the result of pathetic evaluation is that there are many Vim users who like now to use Emacs because of Spacemacs, there are many new keybindings, so if anybody wish to improve Emacs, one could see which are major features of Spacemacs and could ask developers to include their settings into main stream Emacs. Why not? Just go ahead and ask. GNU project already invited everybody to contribute with their projects to be included in GNU. You may ask RMS and Spacemacs developers, if they wish to include Spacemacs as official part of GNU Emacs, that way GNU Emacs would possibly gain popularity. Spacemacs configuration could be optional for user to set, similar like a theme. Why not. I know there are ways. > Regardless, it is possible to run spacemacs without ever visiting the > github page of the project, and github stars cannot track those. > So even though some of those 20k stars are probably not users, or are > no longer users, I still believe that the actual number of users may > be way more than 20k. Yes, but how do you know that? Like where is information available? Finally, why is it important? It is clear that some people like Vim configuration in Emacs, yet it does not mean to change whole configuration to be like theirs. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-12 6:29 ` Jean Louis 2020-10-12 6:58 ` Thibaut Verron @ 2020-10-12 7:54 ` Ihor Radchenko 2020-10-12 8:34 ` Jean Louis 1 sibling, 1 reply; 838+ messages in thread From: Ihor Radchenko @ 2020-10-12 7:54 UTC (permalink / raw) To: Jean Louis, Thibaut Verron; +Cc: Richard Stallman, emacs-devel > Reason for that is that it is obvious that people do, people ARE using > MELPA and Marmalade software repositories; AND more important reason > not to ask is that information about usage of those repositories, > likes, number of contributors, it is already available on the > Microsoft Github "Insights" link on the MELPA page. There is no point > in asking users what is already obvious. There are stars or likes on > Github. I disagree that there is no point asking. Assuming that we are interested to know about MELPA/Marmalade usage, taking information about usage/stars/contributors/etc from third-party sources will represent different subset of Emacs users - it cannot be compared with other results of the presently discussed poll. All the MELPA/marmalade statistics is inherently biased. It only represents Emacs users using those repositories. On the other hand, asking about package repositories in this poll will provide us with a concrete estimate how popular are MELPA and Mermalade. In future, when nongnu ELPA is going to be up and running for a while, it may also be interesting to see how the popularity changes. Best, Ihor Jean Louis <bugs@gnu.support> writes: > * Thibaut Verron <thibaut.verron@gmail.com> [2020-10-12 08:34]: >> > > Just as a reminder, here is what the email starter suggested: >> > > >> > > > a survey for Emacs users to better grasp the diversity and various usages >> > > out there >> > > >> > > There is nothing about taking practical decisions or encouraging free >> > > software (or anything) there. >> > >> > Every opinion poll survey has a purpose, normally the purpose is to >> > find out what majority wish and want to improve the product or service >> > and thus reach or gain more customers, strike it, users. >> >> Yes it has a purpose, I quoted it above. To understand "the diversity >> and various usages out there". Specifically excluding some popular >> usages defeats that purpose. > > Tell me examples of popular usage that you refer to? > > Free form gives enough possibility for any user to explain anything > they wish. > >> If anything, wouldn't we want to get an idea how many Emacs users >> currently use a non-free package repository? > > I am not sure if there is any non-free package repository for > Emacs. > > MELPA is fetching most packages from the Microsoft Github, and Github > dictates free licenses for any public repository, most of them are > free software. For me is hard to find particular example that uses non > free software. > > That will be work to do, to move some public packages to non-GNU ELPA. > > MELPA recipes can be cloned, copy of software can be placed on > nongnu.org automatically, later revised from TODO to be TO PUBLISH, > and distributed ethically. > >> > They do provide free software naturally as packages should be GPL so >> > far I understand (not sure), but if they wrap non free software or >> > have pointers to non free software, such recommendation would be >> > contrary to principles why GNU Emacs have been made as free software. >> >> I don't understand why a question in a survey would be seen as a >> recommendation. > > Above paragraph refers to MELPA, that could wrap non free software in > the free software packages. I can then imagine links in packages pointing > to non free software, that is what was meant with recommendation. It > does not refer to questions in the opinion poll. > >> That's similar, in a sense, to those social surveys asking people if >> they have done drugs. I don't think those want to encourage people to >> take drugs. >> >> > > The same warning could be used when mentioning windows, non-free >> > > IDEs, etc. >> > >> > Warning you mention is used on Emacs download page, see >> > https://www.gnu.org/software/emacs/download.html >> >> Great, so there is precedent ! Why is it acceptable and sufficient on >> the main download page but not acceptable in a survey? > > It is not a new precedent, it was from the creation of Emacs to talk > about free software, and advise people. In my opinion GNU project > should increase the marketing of free software philosophy by power of > 10, it is not enough. > >> Those words are a bit too harsh when applied to Melpa, I hope that >> we agree on that. And nobody likes to read propaganda (no matter how >> justified) in a survey, so having such a long tirade could again >> lead to selection bias. > > GNU project with promotion of free software is not biased as that > would mean that it is influenced in an unfair way. > > GNU project is influenced in a fair way and thus should be promoting > and supporting free software and helping users of proprietary software > to understand what is free software and freedom in computing. > > The word propaganda you maybe used in a negative connotation, but the > word itself means promoting information to spread some cause. Who is > not interested, would not read it. The point of propaganda that some > will get interested, so propaganda gives results for those who are. > >> But, for example, wouldn't something like below be both short and >> explicit enough? >> >> "- Melpa (Note: Emacs and the GNU project DO NOT ENDORSE package >> repositories which encourage non-free software, see >> https://www.gnu.org/philosophy/)" > > I do not think that it is necessary for survey from GNU Emacs to ask > if people are using Melpa or whatever other software > repository. > > Reason for that is that it is obvious that people do, people ARE using > MELPA and Marmalade software repositories; AND more important reason > not to ask is that information about usage of those repositories, > likes, number of contributors, it is already available on the > Microsoft Github "Insights" link on the MELPA page. There is no point > in asking users what is already obvious. There are stars or likes on > Github. > > If there is certain disagreement between GNU and MELPA, that is valid > reason as well. > > In my opinion, the team of MELPA is preparing the list of packages > well, then GNU team working on ELPA on nongnu.org can fork all the > software and curate and remove whatever is unsafe or not ethical and > make a new repository. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-12 7:54 ` Ihor Radchenko @ 2020-10-12 8:34 ` Jean Louis 2020-10-12 8:54 ` Ihor Radchenko 0 siblings, 1 reply; 838+ messages in thread From: Jean Louis @ 2020-10-12 8:34 UTC (permalink / raw) To: Ihor Radchenko; +Cc: Richard Stallman, Thibaut Verron, emacs-devel * Ihor Radchenko <yantar92@gmail.com> [2020-10-12 10:56]: > > Reason for that is that it is obvious that people do, people ARE using > > MELPA and Marmalade software repositories; AND more important reason > > not to ask is that information about usage of those repositories, > > likes, number of contributors, it is already available on the > > Microsoft Github "Insights" link on the MELPA page. There is no point > > in asking users what is already obvious. There are stars or likes on > > Github. > > I disagree that there is no point asking. Assuming that we are > interested to know about MELPA/Marmalade usage, taking information about > usage/stars/contributors/etc from third-party sources will represent > different subset of Emacs users - it cannot be compared with other > results of the presently discussed poll. > > All the MELPA/marmalade statistics is inherently biased. It only > represents Emacs users using those repositories. On the other hand, > asking about package repositories in this poll will provide us with a > concrete estimate how popular are MELPA and Mermalade. In future, when > nongnu ELPA is going to be up and running for a while, it may also be > interesting to see how the popularity changes. When doing an opinion poll, it involves investment of money, time, efforts, people, so the answers have to be evaluated with purpose to do something. Marmalade is anyway not working any more. Let us say you wish to ask if users are using MELPA or what else? There is nothing else to compare. ELPA is already built-in, there is no other package repository. Now you wish to find statistical information how many users use MELPA, but why not simply ask MELPA developers to provide such statistic? They probably have statistics of downloads or accesses to the website. There is no point to asking around the corner, when one can ask directly. Let us say one wish to evaluate which packages are more popular, you can take a list of package from MELPA, then run Emacs Lisp through the list, and then probably use Github API or web scraper, you can find which package has more stars/likes or number of forks. Similar results you can get from Github search. None of results, neither survey results nor Github API/search results are correct results, so it would be expensive making survey in that way. So, for number of MELPA downloads, anybody wishing to find out, one can ask there. Another question how they are evaluating the website statistics. But for which practical use?! For popularity of various packages, it is possible to use API (I just guess so) or web scraper, and obtain statistical information. But for which practical use?! Most practical is when user reports a bug, then it can be solved, or user reports enhancement to software, it could be implemented. This mailing list is a small survey itself, help-gnu-emacs mailing list as well, various answers on non-GNU websites also represent valuable data for improvements, at this moment there is so much data that demands improvements. Jean ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-12 8:34 ` Jean Louis @ 2020-10-12 8:54 ` Ihor Radchenko 2020-10-12 16:36 ` Jean Louis 0 siblings, 1 reply; 838+ messages in thread From: Ihor Radchenko @ 2020-10-12 8:54 UTC (permalink / raw) To: Jean Louis; +Cc: Richard Stallman, Thibaut Verron, emacs-devel > Let us say you wish to ask if users are using MELPA or what else? > There is nothing else to compare. At least we can get ratio between people using MELPA vs. not using MELPA. As I stated, it might be useful later, when we have nongnu ELPA. Or it might, for example, reveal that most of Emacs users are actually not using MELPA (though I don't believe that it is the case). Note that I am not arguing that we have to include this question in this specific poll (there will be many other valuable inputs regardless of this question). Just wanted to point out that MELPA statistics will not answer the question what fraction of users are _not_ using MELPA. If that fraction is significant (unlikely), taking only MELPA statistics might be not representative. Best, Ihor Jean Louis <bugs@gnu.support> writes: > * Ihor Radchenko <yantar92@gmail.com> [2020-10-12 10:56]: >> > Reason for that is that it is obvious that people do, people ARE using >> > MELPA and Marmalade software repositories; AND more important reason >> > not to ask is that information about usage of those repositories, >> > likes, number of contributors, it is already available on the >> > Microsoft Github "Insights" link on the MELPA page. There is no point >> > in asking users what is already obvious. There are stars or likes on >> > Github. >> >> I disagree that there is no point asking. Assuming that we are >> interested to know about MELPA/Marmalade usage, taking information about >> usage/stars/contributors/etc from third-party sources will represent >> different subset of Emacs users - it cannot be compared with other >> results of the presently discussed poll. >> >> All the MELPA/marmalade statistics is inherently biased. It only >> represents Emacs users using those repositories. On the other hand, >> asking about package repositories in this poll will provide us with a >> concrete estimate how popular are MELPA and Mermalade. In future, when >> nongnu ELPA is going to be up and running for a while, it may also be >> interesting to see how the popularity changes. > > When doing an opinion poll, it involves investment of money, time, > efforts, people, so the answers have to be evaluated with purpose to > do something. > > Marmalade is anyway not working any more. > > Let us say you wish to ask if users are using MELPA or what else? > There is nothing else to compare. > > ELPA is already built-in, there is no other package repository. Now > you wish to find statistical information how many users use MELPA, but > why not simply ask MELPA developers to provide such statistic? They > probably have statistics of downloads or accesses to the > website. There is no point to asking around the corner, when one can > ask directly. > > Let us say one wish to evaluate which packages are more popular, you > can take a list of package from MELPA, then run Emacs Lisp through the > list, and then probably use Github API or web scraper, you can find > which package has more stars/likes or number of forks. Similar results > you can get from Github search. None of results, neither survey > results nor Github API/search results are correct results, so it would > be expensive making survey in that way. > > So, for number of MELPA downloads, anybody wishing to find out, one > can ask there. Another question how they are evaluating the website > statistics. But for which practical use?! > > For popularity of various packages, it is possible to use API (I just > guess so) or web scraper, and obtain statistical information. But for > which practical use?! > > Most practical is when user reports a bug, then it can be solved, or > user reports enhancement to software, it could be implemented. > > This mailing list is a small survey itself, help-gnu-emacs mailing > list as well, various answers on non-GNU websites also represent > valuable data for improvements, at this moment there is so much data > that demands improvements. > > Jean ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-12 8:54 ` Ihor Radchenko @ 2020-10-12 16:36 ` Jean Louis 0 siblings, 0 replies; 838+ messages in thread From: Jean Louis @ 2020-10-12 16:36 UTC (permalink / raw) To: Ihor Radchenko; +Cc: Richard Stallman, Thibaut Verron, emacs-devel * Ihor Radchenko <yantar92@gmail.com> [2020-10-12 11:56]: > > Let us say you wish to ask if users are using MELPA or what else? > > There is nothing else to compare. > > At least we can get ratio between people using MELPA vs. not using > MELPA. As I stated, it might be useful later, when we have nongnu ELPA. > Or it might, for example, reveal that most of Emacs users are actually > not using MELPA (though I don't believe that it is the case). Take in consideration that there are many organizations using GNU/Linux distributions internally on many many computers, with many many users. From time to time those users may need to use some editors. But in general, they will not be excited for any talk we have here, for any usage of Internet beyond their work or study. That group of users consider would think it is immature to speak of configurations, etc. Debian is collecting some information of organizations using it: https://www.debian.org/users/ Example: https://www.debian.org/users/edu/ethz_phys > Swiss Federal Institute of Technology Zurich, Department of Physics, ETH Zurich, Switzerland > We have about 160 workstations which are automatically installed > with additional science/math/astronomical software. We also have > about 10 servers. All machines run stable. Now those 160 workstations with some nice software, maybe they are used by students, I do not know, but those people whoever use them are still users of a system, among them there will be those using GNU Emacs, but they may not be excited for the talk we have here. One would need to find out with them how many would be using Emacs, and I doubt anybody would be using MELPA. Hypothetically, university could have 160 workstations and 2000 users, maybe some use Emacs, some not, among those who use maybe nobody use MELPA, while for usage of ELPA, one could say "YES" because it is embedded, but practically, maybe nobody used neither ELPA or MELPA. And you would never find out about those 2000 users. In addition, those 2000 users are growing each year, as there is new number of students coming to university, those among them using Emacs would become users of Emacs and would later probably not be using Emacs, maybe after they finish university there are other things to do. Yet such case would be very significant case of users of Emacs. GNU/Linux systems are multi-user systems, one computer could have large number of users, many would never be involved with any development, or being proud of using Emacs, so what, it is just editor for them or just computing environment, but they would not need to communicate online about that. Basically, the point of that survey is useless, as it will not reach the true user base. It will reach us, people who like polishing their cheap "cars", ricers by definition, how they call computer users who polish their Window Manager themes, icons, colors, and now Emacs. Ricers. Jargon file has to be updated. Rice "Rice" is a word that is commonly used to refer to making visual improvements and customizations on one's desktop. It was inherited from the practice of customizing cheap Asian import cars to make them appear to be faster than they actually were - which was also known as "ricing". Here on /r/unixporn , the word is accepted by the majority of the community and is used sparingly to refer to a visually attractive desktop upgraded beyond the default. From: https://www.reddit.com/r/unixporn/wiki/themeing/dictionary#wiki_rice I hope you get my point. The survey would not be really directed to Emacs users, as the true user base is hard to reach. It would be directed to Emacs Ricers, people who like polishing their Emacs. > Note that I am not arguing that we have to include this question in this > specific poll (there will be many other valuable inputs regardless of > this question). Those polls are best to be placed on Emacs website. Or just make a package in Emacs that is similar to Debian's popularity contest package, see statistics here: https://popcon.debian.org/ and here is statistics for Emacs: https://qa.debian.org/popcon.php?package=emacs I see there about 50000 users, there could be hundreds of thousands of users, as not everybody is using the package "popularity-contest" to submit reports about their usage. Vim is leading before Emacs: https://qa.debian.org/popcon.php?package=vim Now those statistics are indication, but not the real information, as one has to know dynamics and definitions. Popularity contest does not mean it is popular by use, but by number of installation. To be popular by use is not same as to be popular by number of installations. One can see that on each statistics page that most popular package in Debian is dpkg, but I really doubt that it is "most popular software used by users" in Debian. libc6 is also most popular software, but who knows about that? Do you see that statistics can be doubtful? Which computer user is going around and telling how he is using libc6 on his computer, being proud, or liking to configure it for his pleasure?! Yet the package is "popular" as number one. Example how such popularity is blown up is that Debian package 'education-common' recommends 'vim' or other version of vim. Let us say somebody wish to install some educational package in Debian, such could pull 'education-common' which in turn could pull 'vim' as recommended package, but user would not be really using 'vim', one would be using what one wants (some other software). Such popularity contest would counte number of installations of packages, and so it does it automatically. > Just wanted to point out that MELPA statistics will not answer the > question what fraction of users are _not_ using MELPA. If that > fraction is significant (unlikely), taking only MELPA statistics > might be not representative. Nothing can answer that question, as real number of Emacs users cannot be obtained. But hey, we can reach those who are online. Emacs Ricers. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-12 5:33 ` Thibaut Verron 2020-10-12 6:29 ` Jean Louis @ 2020-10-13 3:53 ` Richard Stallman 2020-10-13 5:25 ` Jean Louis 2020-10-13 3:53 ` Richard Stallman 2020-10-15 3:52 ` Richard Stallman 3 siblings, 1 reply; 838+ messages in thread From: Richard Stallman @ 2020-10-13 3:53 UTC (permalink / raw) To: thibaut.verron; +Cc: bugs, emacs-devel [[[ 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. ]]] > I don't understand why a question in a survey would be seen as a > recommendation. Simply mentioning MELPA encourages people to think we consider it legitimate. We do not! And it defeats our goals if people think that we do. MELPA contains programs that depend on, that require installation of, various nonfree programs. Thus, it leads people to install those. This encourages injustice -- the injustice of those nonfree programs. Most Emacs users have probably never thought about this issue. They take for granted that nonfree programs are legitimate, they believe everyone considers them legitimate, and they assume we do too. It is important to educate these people that the GNU Project does not agree with "everyone" on this. Some Emacs users have though about this but were not convinced, and then they probably dropped the question from their thoughts. If we treat MELPA as if it were as legitimate as the free archives, they will be encouraged in considering it as legitimate as the free archives. Perhaps we should do something to show them what the issue is. Perhaps with text like this: ====================================================================== GNU Emacs is part of the GNU operating system. The GNU Project aims to escape, then replace, all nonfree software with freedom-respecting free software. We maintain an Emacs package archive that consists of free packages that can run in a free environment. There is another Emacs package archive called Melpa which distributes packages require the user to install some nonfree programs. That practice is harmful because it encourages the installation of those nonfree programs, and that works against our goal -- it prioritizes short-term convenience over freedom. Rather than prioritize short-term convenience over freedom, we normally avoid mentioning that Malpa exists. As a special exception, we mentioned it in a question in this survey, to get data about its use. That does not mean we have changed our minds about our criticism of Melpa. ====================================================================== How about that? -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-13 3:53 ` Richard Stallman @ 2020-10-13 5:25 ` Jean Louis 2020-10-15 3:59 ` Richard Stallman 0 siblings, 1 reply; 838+ messages in thread From: Jean Louis @ 2020-10-13 5:25 UTC (permalink / raw) To: Richard Stallman; +Cc: thibaut.verron, emacs-devel It is good to develop verified, safe, separate repository at elpa.nongnu.org that would be included in Emacs as default, so that people can get the safe, verified packages from repository that takes care of users and help them understand freedom issues. For MELPA warning it is good to be specific, as if there is some wrapped proprietary software on MELPA, then let us find out which software it is, and one can make a list, or even ask MELPA not to include such. Which one it is exactly? The list of packages that wrap proprietary software would be anyway required, if GNU wish to publish elpa.nongnu.org Above is based on below. * Richard Stallman <rms@gnu.org> [2020-10-13 06:53]: > Some Emacs users have though about this but were not convinced, and > then they probably dropped the question from their thoughts. If we > treat MELPA as if it were as legitimate as the free archives, they > will be encouraged in considering it as legitimate as the free > archives. > > Perhaps we should do something to show them what the issue is. > Perhaps with text like this: > > ====================================================================== > GNU Emacs is part of the GNU operating system. The GNU Project aims > to escape, then replace, all nonfree software with freedom-respecting > free software. > > We maintain an Emacs package archive that consists of free packages > that can run in a free environment. There is another Emacs package > archive called Melpa which distributes packages require the user to > install some nonfree programs. That practice is harmful because it > encourages the installation of those nonfree programs, and that works > against our goal -- it prioritizes short-term convenience over > freedom. > > Rather than prioritize short-term convenience over freedom, we > normally avoid mentioning that Malpa exists. > > As a special exception, we mentioned it in a question in this survey, > to get data about its use. That does not mean we have changed our > minds about our criticism of Melpa. > ====================================================================== ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-13 5:25 ` Jean Louis @ 2020-10-15 3:59 ` Richard Stallman 2020-10-15 5:19 ` Jean Louis 0 siblings, 1 reply; 838+ messages in thread From: Richard Stallman @ 2020-10-15 3:59 UTC (permalink / raw) To: Jean Louis; +Cc: thibaut.verron, emacs-devel [[[ 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. ]]] > For MELPA warning it is good to be specific, as if there is some > wrapped proprietary software on MELPA, then let us find out which > software it is, and one can make a list, or even ask MELPA not to > include such. > Which one it is exactly? I don't know, but probably someone here knows of some examples. I have a vague recollection, though, that some of us already asked the maintainers of Melpa to make this change, and they did not want to. Does anyone actually know? > The list of packages that wrap proprietary software would be anyway > required, if GNU wish to publish elpa.nongnu.org Yes and no. We would not try to import all packages from MELPA except those that were excluded for this reason. Rather, we would need to examine each package to decide whether to import it, and whether and how change it. In the process we would see if the package has any problems that might be reasons not to import it. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-15 3:59 ` Richard Stallman @ 2020-10-15 5:19 ` Jean Louis 0 siblings, 0 replies; 838+ messages in thread From: Jean Louis @ 2020-10-15 5:19 UTC (permalink / raw) To: Richard Stallman; +Cc: thibaut.verron, emacs-devel * Richard Stallman <rms@gnu.org> [2020-10-15 07:00]: > [[[ 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. ]]] > > > For MELPA warning it is good to be specific, as if there is some > > wrapped proprietary software on MELPA, then let us find out which > > software it is, and one can make a list, or even ask MELPA not to > > include such. > > > Which one it is exactly? > > I don't know, but probably someone here knows of some examples. > > I have a vague recollection, though, that some of us already asked the > maintainers of Melpa to make this change, and they did not want to. > > Does anyone actually know? Maybe these: - lastpass, LastPass proprietary software command wrapper, it probably interacts with proprietary software from Emacs, inciting users to try out or use or install LastPass - sharper, dotnet CLI wrapper, I am just blindly assuming that dotnet CLI is Microsoft proprietary programming language Jean ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-12 5:33 ` Thibaut Verron 2020-10-12 6:29 ` Jean Louis 2020-10-13 3:53 ` Richard Stallman @ 2020-10-13 3:53 ` Richard Stallman 2020-10-13 5:27 ` Jean Louis 2020-10-15 3:52 ` Richard Stallman 3 siblings, 1 reply; 838+ messages in thread From: Richard Stallman @ 2020-10-13 3:53 UTC (permalink / raw) To: thibaut.verron; +Cc: bugs, emacs-devel [[[ 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. ]]] > > Warning you mention is used on Emacs download page, see > > https://www.gnu.org/software/emacs/download.html > Great, so there is precedent ! Why is it acceptable and sufficient on > the main download page but not acceptable in a survey? I am not sure what those words mean. I will look at that page and see if I can figure it out. Would people like to explain what part or aspect of that page is at issue here? -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-13 3:53 ` Richard Stallman @ 2020-10-13 5:27 ` Jean Louis 2020-10-16 3:59 ` Richard Stallman 0 siblings, 1 reply; 838+ messages in thread From: Jean Louis @ 2020-10-13 5:27 UTC (permalink / raw) To: Richard Stallman; +Cc: thibaut.verron, emacs-devel * Richard Stallman <rms@gnu.org> [2020-10-13 06:53]: > [[[ 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. ]]] > > > > Warning you mention is used on Emacs download page, see > > > https://www.gnu.org/software/emacs/download.html > > > Great, so there is precedent ! Why is it acceptable and sufficient on > > the main download page but not acceptable in a survey? > > I am not sure what those words mean. I will look at that page > and see if I can figure it out. Would people like to explain what > part or aspect of that page is at issue here? You missed to follow the thread. Discussion was about warning users about non-free software in the survey itself. On that page, we are warning users with below wording. Nonfree systems The reason for GNU Emacs's existence is to provide a powerful editor for the GNU operating system. Versions of GNU, such as GNU/Linux, are the primary platforms for Emacs development. However, GNU Emacs includes support for some other systems that volunteers choose to support. The purpose of the GNU system is to give users the freedom that proprietary software takes away from its users. Proprietary operating systems (like other proprietary programs) are an injustice, and we aim for a world in which they do not exist. To improve the use of proprietary systems is a misguided goal. Our aim, rather, is to eliminate them. We include support for some proprietary systems in GNU Emacs in the hope that running Emacs on them will give users a taste of freedom and thus lead them to free themselves. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-13 5:27 ` Jean Louis @ 2020-10-16 3:59 ` Richard Stallman 2020-10-16 6:02 ` Marcel Ventosa 2020-10-16 7:05 ` Thibaut Verron 0 siblings, 2 replies; 838+ messages in thread From: Richard Stallman @ 2020-10-16 3:59 UTC (permalink / raw) To: Jean Louis; +Cc: thibaut.verron, emacs-devel [[[ 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. ]]] > On that page, we are warning users with below wording. Yes. I wrote those words. It is crucial to have them there, because we mention Windows and MacOS. Where we mention them, we should explain why they are unjust -- because otherwise people will assume we share the usual amoral attitude towards them. I think of it as a denunciation, not a warning. Why is it ok to mention Windows and MacOS there? Because everyone using a computer already knows about them. See node References in the GNU Coding Standards (https://www.gnu.org/prep/standards/). I hope that only a minority of Emacs users know about MELPA, and I'd rather not inform the rest about it. But if something is going to inform them anyway, it is better to do it with a denunciation. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 3:59 ` Richard Stallman @ 2020-10-16 6:02 ` Marcel Ventosa 2020-10-16 6:52 ` Thibaut Verron ` (2 more replies) 2020-10-16 7:05 ` Thibaut Verron 1 sibling, 3 replies; 838+ messages in thread From: Marcel Ventosa @ 2020-10-16 6:02 UTC (permalink / raw) To: Richard Stallman; +Cc: thibaut.verron, Jean Louis, emacs-devel On Thu, 15 Oct 2020 23:59:07 -0400 Richard Stallman <rms@gnu.org> wrote: > I hope that only a minority of Emacs users know about MELPA, and I'd > rather not inform the rest about it. But if something is going to > inform them anyway, it is better to do it with a denunciation. I've been using Emacs (and MELPA) for the best part of a decade and knew nothing about this! I'm concerned to use only free software and actively avoid proprietary software, so this is a bit of a shock. Is there anywhere I can read more about this issue? I think this illustrates well why any initiative related with GNU (even by association) should avoid mentioning proprietary software without a clear warning and should, in fact, do its utmost to educate users about free software. I've used Trisquel, Parabola and Replicant for many years, and in all of those cases, installing proprietary software is purposely made difficult (For example, using a `your-freedom' package in Parabola. It makes sense to force a user to actively remove `your-freedom' if he or she wants to install a proprietary program; difficult to do so by mistake. In fact, I would go the extra mile and say Emacs should expressly warn users over the dangers of installing proprietary software from unofficial repositories (by the way, I always just assumed MELPA was somehow official and related to ELPA, because its name is so similar to ELPA). This survey could provide a good opportunity for such information/education. Over the years, as I worked on my emacs configuration, I read many other confiruations, but none (that I recall) gave any warnings about MELPA, so I never thought twice about it. Any other caveats regarding unwittingly running proprietary software inside of Emacs? Sorry to derail the conversation. Marcel ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 6:02 ` Marcel Ventosa @ 2020-10-16 6:52 ` Thibaut Verron 2020-10-16 7:24 ` Marcel Ventosa ` (2 more replies) 2020-10-16 16:33 ` MELPA issues - " Jean Louis 2020-10-18 4:10 ` Richard Stallman 2 siblings, 3 replies; 838+ messages in thread From: Thibaut Verron @ 2020-10-16 6:52 UTC (permalink / raw) To: Marcel Ventosa; +Cc: Richard Stallman, Jean Louis, emacs-devel Le ven. 16 oct. 2020 à 08:03, Marcel Ventosa <mve1@runbox.com> a écrit : > > On Thu, 15 Oct 2020 23:59:07 -0400 > Richard Stallman <rms@gnu.org> wrote: > > > I hope that only a minority of Emacs users know about MELPA, and I'd > > rather not inform the rest about it. But if something is going to > > inform them anyway, it is better to do it with a denunciation. > > > I've been using Emacs (and MELPA) for the best part of a decade and > knew nothing about this! I'm concerned to use only free software and > actively avoid proprietary software, so this is a bit of a shock. As I understand it, Melpa packages cannot *be* or *install* non-free software. But some will not work without such software, which can in theory encourage users to install it. So unless you yourself installed non-free software, Melpa cannot have made your Emacs configuration non-free by accident. > In fact, I would go the extra mile and say Emacs should expressly warn > users over the dangers of installing proprietary software from > unofficial repositories (by the way, I always just assumed MELPA was > somehow official and related to ELPA, because its name is so similar to > ELPA). This survey could provide a good opportunity for such > information/education. ELPA means Emacs Lisp Package Archive, so both Melpa and GNU Elpa are ELPA's. I think that commonly referring to GNU Elpa as simply Elpa (which I am also guilty of) is a bigger source of confusion than Melpa and GNU Elpa sharing the same suffix. GNU Elpa and the future Non-GNU Elpa are (will be) activated by default as package archives, Melpa is not. The hope is that once 99% of the packages by the community are available in an archive activated by default, users will not rush to install Melpa in the same proportions as today. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 6:52 ` Thibaut Verron @ 2020-10-16 7:24 ` Marcel Ventosa 2020-10-16 7:53 ` Thibaut Verron 2020-10-16 17:08 ` Jean Louis 2020-10-16 17:04 ` Jean Louis 2020-10-18 4:09 ` Richard Stallman 2 siblings, 2 replies; 838+ messages in thread From: Marcel Ventosa @ 2020-10-16 7:24 UTC (permalink / raw) To: Thibaut Verron; +Cc: Richard Stallman, Jean Louis, emacs-devel On Fri, 16 Oct 2020 08:52:49 +0200 Thibaut Verron <thibaut.verron@gmail.com> wrote: > Le ven. 16 oct. 2020 à 08:03, Marcel Ventosa <mve1@runbox.com> a > écrit : > > > > On Thu, 15 Oct 2020 23:59:07 -0400 > > Richard Stallman <rms@gnu.org> wrote: > > > > > I hope that only a minority of Emacs users know about MELPA, and > > > I'd rather not inform the rest about it. But if something is > > > going to inform them anyway, it is better to do it with a > > > denunciation. > > > > > > I've been using Emacs (and MELPA) for the best part of a decade and > > knew nothing about this! I'm concerned to use only free software and > > actively avoid proprietary software, so this is a bit of a shock. > > As I understand it, Melpa packages cannot *be* or *install* non-free > software. But some will not work without such software, which can in > theory encourage users to install it. > > So unless you yourself installed non-free software, Melpa cannot have > made your Emacs configuration non-free by accident. I understand, thanks for the explanation. In that case, I think I'm well informed enough to have avoived the dangers. I wonder how many people are not. AFAIK, both Trisquel and Parabola keep out packages that recommend or encourage proprietary software, which seems essential to protect users' freedom. > > In fact, I would go the extra mile and say Emacs should expressly > > warn users over the dangers of installing proprietary software from > > unofficial repositories (by the way, I always just assumed MELPA was > > somehow official and related to ELPA, because its name is so > > similar to ELPA). This survey could provide a good opportunity for > > such information/education. > > ELPA means Emacs Lisp Package Archive, so both Melpa and GNU Elpa are > ELPA's. I think that commonly referring to GNU Elpa as simply Elpa > (which I am also guilty of) is a bigger source of confusion than > Melpa and GNU Elpa sharing the same suffix. As written on the MELPA Github about page: "MELPA is Milkypostman's ELPA or Milkypostman's Experimental Lisp Package Archive if you're not into the whole brevity thing." Perhaps the shared `E' in `Elpa' is purely coincidental? > GNU Elpa and the future Non-GNU Elpa are (will be) activated by > default as package archives, Melpa is not. > The hope is that once 99% of the packages by the community are > available in an archive activated by default, users will not rush to > install Melpa in the same proportions as today. This will be good news! In the meantime, I wonder how many others are unaware of the potential dangers of using MELPA. A prominent place to inform Emacs users about these dangers would be useful; perhaps this survey will provide a good first opportunity. In any case, I'm thankful to RMS and this survey related conversation for an important discovery. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 7:24 ` Marcel Ventosa @ 2020-10-16 7:53 ` Thibaut Verron 2020-10-16 8:25 ` Marcel Ventosa 2020-10-16 18:57 ` Jean Louis 2020-10-16 17:08 ` Jean Louis 1 sibling, 2 replies; 838+ messages in thread From: Thibaut Verron @ 2020-10-16 7:53 UTC (permalink / raw) To: Marcel Ventosa; +Cc: Richard Stallman, Jean Louis, emacs-devel Le ven. 16 oct. 2020 à 09:24, Marcel Ventosa <mve1@runbox.com> a écrit : > > On Fri, 16 Oct 2020 08:52:49 +0200 > Thibaut Verron <thibaut.verron@gmail.com> wrote: > > > Le ven. 16 oct. 2020 à 08:03, Marcel Ventosa <mve1@runbox.com> a > > écrit : > > > > > > On Thu, 15 Oct 2020 23:59:07 -0400 > > > Richard Stallman <rms@gnu.org> wrote: > > > > > > > I hope that only a minority of Emacs users know about MELPA, and > > > > I'd rather not inform the rest about it. But if something is > > > > going to inform them anyway, it is better to do it with a > > > > denunciation. > > > > > > > > > I've been using Emacs (and MELPA) for the best part of a decade and > > > knew nothing about this! I'm concerned to use only free software and > > > actively avoid proprietary software, so this is a bit of a shock. > > > > As I understand it, Melpa packages cannot *be* or *install* non-free > > software. But some will not work without such software, which can in > > theory encourage users to install it. > > > > So unless you yourself installed non-free software, Melpa cannot have > > made your Emacs configuration non-free by accident. > > I understand, thanks for the explanation. In that case, I think I'm > well informed enough to have avoived the dangers. I wonder how many > people are not. I personally don't think many users install non-free software because they saw it wrapped in a Melpa package. Taking the example of emacs-lastpass given above, I don't see how anyone would even find this package without searching for it with the keyword "lastpass". The audience, rather, is users who are currently using Lastpass in their browsers but are interested in bringing some of their online activities to Emacs, but rely on their password manager to do so. In due time, with the new "taste of freedom", they might even switch to Keepass or Bitwarden (note: I don't use a password manager in Emacs, so I have no idea of the quality of each support package, beyond their existence), but in any case, I believe that for those users, the existence of transitional solutions is a good thing. I absolutely support the fact that Melpa is not activated by default, and that there should be a warning about the existence of those packages everywhere possible. But I still consider that the value of those packages outweigh their dangers, just like the win32 build of Emacs. > > ELPA means Emacs Lisp Package Archive, so both Melpa and GNU Elpa are > > ELPA's. I think that commonly referring to GNU Elpa as simply Elpa > > (which I am also guilty of) is a bigger source of confusion than > > Melpa and GNU Elpa sharing the same suffix. > > As written on the MELPA Github about page: > > "MELPA is Milkypostman's ELPA or Milkypostman's Experimental Lisp > Package Archive if you're not into the whole brevity thing." > > Perhaps the shared `E' in `Elpa' is purely coincidental? I didn't know about the Experimental version, thanks. If anything, the quoted sentence is self-contradicting for me. Also, the title of the melpa.org page is "MELPA (Milkypostman’s Emacs Lisp Package Archive)". In any case, I don't know if an acronym with a different vowel but still ending with LPA, such as Milpa, would be less confusing. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 7:53 ` Thibaut Verron @ 2020-10-16 8:25 ` Marcel Ventosa 2020-10-16 12:17 ` Dmitry Gutov ` (2 more replies) 2020-10-16 18:57 ` Jean Louis 1 sibling, 3 replies; 838+ messages in thread From: Marcel Ventosa @ 2020-10-16 8:25 UTC (permalink / raw) To: Thibaut Verron; +Cc: Richard Stallman, Jean Louis, emacs-devel On Fri, 16 Oct 2020 09:53:22 +0200 Thibaut Verron <thibaut.verron@gmail.com> wrote: > Le ven. 16 oct. 2020 à 09:24, Marcel Ventosa <mve1@runbox.com> a > écrit : > > > > On Fri, 16 Oct 2020 08:52:49 +0200 > > Thibaut Verron <thibaut.verron@gmail.com> wrote: > > > > > Le ven. 16 oct. 2020 à 08:03, Marcel Ventosa <mve1@runbox.com> a > > > écrit : > > > > > > > > On Thu, 15 Oct 2020 23:59:07 -0400 > > > > Richard Stallman <rms@gnu.org> wrote: > > > > > > > > > I hope that only a minority of Emacs users know about MELPA, > > > > > and I'd rather not inform the rest about it. But if > > > > > something is going to inform them anyway, it is better to do > > > > > it with a denunciation. > > > > > > > > > > > > I've been using Emacs (and MELPA) for the best part of a decade > > > > and knew nothing about this! I'm concerned to use only free > > > > software and actively avoid proprietary software, so this is a > > > > bit of a shock. > > > > > > As I understand it, Melpa packages cannot *be* or *install* > > > non-free software. But some will not work without such software, > > > which can in theory encourage users to install it. > > > > > > So unless you yourself installed non-free software, Melpa cannot > > > have made your Emacs configuration non-free by accident. > > > > I understand, thanks for the explanation. In that case, I think I'm > > well informed enough to have avoived the dangers. I wonder how many > > people are not. > > I personally don't think many users install non-free software because > they saw it wrapped in a Melpa package. > > Taking the example of emacs-lastpass given above, I don't see how > anyone would even find this package without searching for it with the > keyword "lastpass". > > The audience, rather, is users who are currently using Lastpass in > their browsers but are interested in bringing some of their online > activities to Emacs, but rely on their password manager to do so. > > In due time, with the new "taste of freedom", they might even switch > to Keepass or Bitwarden (note: I don't use a password manager in > Emacs, so I have no idea of the quality of each support package, > beyond their existence), but in any case, I believe that for those > users, the existence of transitional solutions is a good thing. I understand your point, and transitional solutions may indeed be a good thing (though they can lead both ways). However, it's a long-standing position of GNU not to be seen to endorse these compromises, whether or not their existence is a good thing. For me, the name GNU has always signified a free software safe haven. The idea that one might be misled into installing proprietary software because of well earned trust in GNU should be avoided at all costs. I would posit the same if I was a member of a vegan organization that was relaxing their views on eating animals to ease the transition. While there is little doubt transitions can be beneficial, the vegan organization should not confuse it's tenets. Perhaps. Transitional solutions go both ways though. A cursory glance at Reddit's Emacs group is enough to notice not only ignorance of the philosophy behind GNU, but quite recurrent mockery of what it stands for. Usually in the form of deriding RMS. For the most recent example, one user comments under abrochard's survey post: "So, will you be censoring the survey to maintain ideological purity, like rms insisted?", to which abrochard responds: "I agree with you. The discussion around Melpa is a big factor as to why the survey is happening in parallel to the gnu project." > I absolutely support the fact that Melpa is not activated by default, > and that there should be a warning about the existence of those > packages everywhere possible. But I still consider that the value of > those packages outweigh their dangers, just like the win32 build of > Emacs. > > > > ELPA means Emacs Lisp Package Archive, so both Melpa and GNU Elpa > > > are ELPA's. I think that commonly referring to GNU Elpa as simply > > > Elpa (which I am also guilty of) is a bigger source of confusion > > > than Melpa and GNU Elpa sharing the same suffix. > > > > As written on the MELPA Github about page: > > > > "MELPA is Milkypostman's ELPA or Milkypostman's Experimental Lisp > > Package Archive if you're not into the whole brevity thing." > > > > Perhaps the shared `E' in `Elpa' is purely coincidental? > > I didn't know about the Experimental version, thanks. If anything, the > quoted sentence is self-contradicting for me. > Also, the title of the melpa.org page is "MELPA (Milkypostman’s Emacs > Lisp Package Archive)". > > In any case, I don't know if an acronym with a different vowel but > still ending with LPA, such as Milpa, would be less confusing. Yes, I see it as a problem when an unofficial offshoot of a project does not make it crystal clear that it is so. In fact, and on the same topic, a post was made about the survey yesterday on Reddit by Abrochard with the title "The Emacs User Survey 2020 will open on Oct 19th," which makes it sound as though it were an official survey. Further down the thread, a user criticized RMS of trying to censor the survey, mentioning the MELPA discussion in particular, to which Abrochard responded: "I agree with you. The discussion around Melpa is a big factor as to why the survey is happening in parallel to the gnu project." I'm not saying the obfuscation is purposeful either in the case of `MELPA' imitating the name of the existing `GNU ELPA', or of Adrien calling his survey *The* Emacs User survey", but what I do think is that all non-GNU initiatives that affect perception of GNU, particularly the ones that clearly do not share the GNU philosophy (the survey referred to `GNU/Linux' as `Linux', for example), would seem much more transparent if they were very clearly and visibly labeled as unofficial. My hope, of course, would be that these initiatives could respect the GNU philosophy, even if they did not share it. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 8:25 ` Marcel Ventosa @ 2020-10-16 12:17 ` Dmitry Gutov 2020-10-16 13:45 ` Marcel Ventosa ` (2 more replies) 2020-10-16 17:29 ` Jean Louis 2020-10-17 4:22 ` Richard Stallman 2 siblings, 3 replies; 838+ messages in thread From: Dmitry Gutov @ 2020-10-16 12:17 UTC (permalink / raw) To: Marcel Ventosa, Thibaut Verron; +Cc: Richard Stallman, Jean Louis, emacs-devel On 16.10.2020 11:25, Marcel Ventosa wrote: > Perhaps. Transitional solutions go both ways though. A cursory glance at > Reddit's Emacs group is enough to notice not only ignorance of the > philosophy behind GNU, but quite recurrent mockery of what it stands > for. Usually in the form of deriding RMS. For the most recent example, > one user comments under abrochard's survey post: "So, will you be > censoring the survey to maintain ideological purity, like rms > insisted?", to which abrochard responds: "I agree with you. The > discussion around Melpa is a big factor as to why the survey is > happening in parallel to the gnu project." Do you think the "mockery" is entirely without merit? It's not even so much real mockery as probably the only way the user could describe the conflict. When a survey purposefully omits a well-known and popular option, it is going to discount a sizable portion of our community, and ignore a project that has done a lot to popularize Emacs over the years. I think it's both insulting to its developers, and stinks of thought police. Far from the idea of user freedom I hope to expect from GNU and FSF. > I'm not saying the obfuscation is purposeful either in the case of > `MELPA' imitating the name of the existing `GNU ELPA', or of Adrien > calling his survey *The* Emacs User survey", but what I do think is that > all non-GNU initiatives that affect perception of GNU, particularly the > ones that clearly do not share the GNU philosophy (the survey referred > to `GNU/Linux' as `Linux', for example), would seem much more > transparent if they were very clearly and visibly labeled as unofficial. > My hope, of course, would be that these initiatives could respect the > GNU philosophy, even if they did not share it. Calling it "THE Emacs User survey" is perhaps unfortunate. But likewise it is unfortunate how Emacs leadership does little to follow the external, "unofficial" polls. A survey doesn't have to be "the official GNU survey" to be useful. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 12:17 ` Dmitry Gutov @ 2020-10-16 13:45 ` Marcel Ventosa 2020-10-16 14:04 ` Dmitry Gutov 2020-10-16 19:08 ` Jean Louis 2020-10-16 13:57 ` Ergus 2020-10-16 16:09 ` Alfred M. Szmidt 2 siblings, 2 replies; 838+ messages in thread From: Marcel Ventosa @ 2020-10-16 13:45 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Jean Louis, Richard Stallman, Thibaut Verron, emacs-devel On Fri, 16 Oct 2020 15:17:16 +0300 Dmitry Gutov <dgutov@yandex.ru> wrote: > Do you think the "mockery" is entirely without merit? Yes, and I think mockery precludes understanding, particularly as we are dealing with a thoughtful man and a well developed and time tested philosophy, successfully put into practice against the odds. > ignore a project that has done a lot to popularize Emacs over the years. I fail to understand the narrative that pushes popularity over all else. What would be the use of making Emacs the most popular editor if it discarded the philosophy that brought it about? I've noticed a trend of speaking about Emacs and other free software projects as if they were "commodities" and "products," but as I see them, it is precisely because they are community driven projects that they are not "commodities" or "products". > I think it's both insulting to its developers, and stinks of thought > police. Far from the idea of user freedom I hope to expect from GNU and FSF. You are conflating freedom, as in the freedom to do whatever you want, with software freedom as defined by GNU, which succintly means that users have the freedom to run, copy, distribute, study, change and improve software. I don't understand how refusing to draw attention to a repository that recommends proprietary software turns anyone into the "thought police". I see no reason why the GNU project or the FSF should raise awareness of solutions that go against their founding philosophy, except to raise awareness to its dangers. Further up the list, I read RMS suggesting mentioning MELPA with a disclaimer and warning about its use. In fact, one of the most worrying aspects of this survey idea, as I see it, is the suggested use of non-free Javascript to implement it. > it is unfortunate how Emacs leadership does little to follow the > external, "unofficial" polls. What do you mean by this? ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 13:45 ` Marcel Ventosa @ 2020-10-16 14:04 ` Dmitry Gutov 2020-10-16 14:33 ` Marcel Ventosa 2020-10-16 19:17 ` Jean Louis 2020-10-16 19:08 ` Jean Louis 1 sibling, 2 replies; 838+ messages in thread From: Dmitry Gutov @ 2020-10-16 14:04 UTC (permalink / raw) To: Marcel Ventosa; +Cc: Jean Louis, Richard Stallman, Thibaut Verron, emacs-devel On 16.10.2020 16:45, Marcel Ventosa wrote: > On Fri, 16 Oct 2020 15:17:16 +0300 > Dmitry Gutov <dgutov@yandex.ru> wrote: > >> Do you think the "mockery" is entirely without merit? > > Yes, and I think mockery precludes understanding, particularly as we > are dealing with a thoughtful man and a well developed and time tested > philosophy, successfully put into practice against the odds. Shutting our eyes to actual user behavior also precludes understanding. >> ignore a project that has done a lot to popularize Emacs over the years. > > I fail to understand the narrative that pushes popularity over all else. Strawman. > What would be the use of making Emacs the most popular editor if it > discarded the philosophy that brought it about? It doesn't. And picking on 2-3 "ideologically impure" packages (out of several thousands!) that are distributed on MELPA is counter-productive. >> I think it's both insulting to its developers, and stinks of thought >> police. Far from the idea of user freedom I hope to expect from GNU and FSF. > > You are conflating freedom, as in the freedom to do whatever you want, I don't. But a certain freedom of thought, knowledge and discussion is necessary, as should be apparent to any educated individual. > I don't understand how refusing to draw attention to a repository that > recommends proprietary software turns anyone into the "thought police". It's a *survey*! A survey is supposed to gather insight into what users do, and what they need. Not shape their behavior. You can't be effective at affecting change anyway, if you don't know what's going on outside. > Further up the list, I read RMS suggesting mentioning MELPA with a > disclaimer and warning about its use. That didn't seem to be the preferred option, in RMS's opinion. > In fact, one of the most worrying aspects of this survey idea, as I see > it, is the suggested use of non-free Javascript to implement it. Didn't Philip show a prototype that didn't use JavaScript? >> it is unfortunate how Emacs leadership does little to follow the >> external, "unofficial" polls. > > What do you mean by this? I don't recall any single change in Emacs' behavior that resulted from an external poll or survey. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 14:04 ` Dmitry Gutov @ 2020-10-16 14:33 ` Marcel Ventosa 2020-10-16 14:58 ` Thibaut Verron ` (3 more replies) 2020-10-16 19:17 ` Jean Louis 1 sibling, 4 replies; 838+ messages in thread From: Marcel Ventosa @ 2020-10-16 14:33 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Thibaut Verron, Richard Stallman, Jean Louis, emacs-devel On Fri, 16 Oct 2020 17:04:22 +0300 Dmitry Gutov <dgutov@yandex.ru> wrote: > On 16.10.2020 16:45, Marcel Ventosa wrote: > > On Fri, 16 Oct 2020 15:17:16 +0300 > > Dmitry Gutov <dgutov@yandex.ru> wrote: > > > >> Do you think the "mockery" is entirely without merit? > > > > Yes, and I think mockery precludes understanding, particularly as we > > are dealing with a thoughtful man and a well developed and time > > tested philosophy, successfully put into practice against the odds. > > > > Shutting our eyes to actual user behavior also precludes > understanding. From what I just read from Thibaut, a free software compatible solution to replace MELPA is underway. Refusing to draw attention to something is not "shutting our eyes". > >> ignore a project that has done a lot to popularize Emacs over the > >> years. > > > > I fail to understand the narrative that pushes popularity over all > > else. > > Strawman. I thought your argument was popularity, something that keeps coming up in these kinds of discussions. What was your argument? > > What would be the use of making Emacs the most popular editor if it > > discarded the philosophy that brought it about? > > It doesn't. > > And picking on 2-3 "ideologically impure" packages (out of several > thousands!) that are distributed on MELPA is counter-productive. We could turn this argument around and ask why the developers who maintain MELPA don't remove `2-3' packages that promote non-free software. What came first, the GNU Emacs or the MELPA? > >> I think it's both insulting to its developers, and stinks of > >> thought police. Far from the idea of user freedom I hope to expect > >> from GNU and FSF. > > > > You are conflating freedom, as in the freedom to do whatever you > > want, > > I don't. But a certain freedom of thought, knowledge and discussion > is necessary, as should be apparent to any educated individual. > > > I don't understand how refusing to draw attention to a repository > > that recommends proprietary software turns anyone into the "thought > > police". > > It's a *survey*! A survey is supposed to gather insight into what > users do, and what they need. Not shape their behavior. > > You can't be effective at affecting change anyway, if you don't know > what's going on outside. Indeed. As I recall, RMS suggested open questions instead of multiple choice questions that "shape their behavior". With open questions, there is no need to mention MELPA at all in fact. With open questions, the insights that could be derived would be much more interesting. > > Further up the list, I read RMS suggesting mentioning MELPA with a > > disclaimer and warning about its use. > > That didn't seem to be the preferred option, in RMS's opinion. > > > In fact, one of the most worrying aspects of this survey idea, as I > > see it, is the suggested use of non-free Javascript to implement > > it. > > Didn't Philip show a prototype that didn't use JavaScript? That's very good news if the issue has been settled. > >> it is unfortunate how Emacs leadership does little to follow the > >> external, "unofficial" polls. > > > > What do you mean by this? > > I don't recall any single change in Emacs' behavior that resulted > from an external poll or survey. Why should Emacs development be guided by (external) survey results? I would think it should be guided, for the most part, by what the people putting their time into it want to create, within the principles of the philosophy of the project and its goals. Also, anyone can suggest changes and convince the maintainers that these changes are in the best interest of the project (and contribute the actual changes if they are accepted). If they are not, Emacs makes it quite simple to implement changes for personal "improvements". I have written functions that serve me personally and change the behavior of Emacs to suit my needs. There are limits to what I can do, which could be pushed if I dedicated a greater effort to do so. How is that unfair? If I thought one of my changes could benefit the community at large, I would approach the maintainers and suggest it. If they disagreed with my view, I could publish the code and could still share it with anyone willing to run it. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 14:33 ` Marcel Ventosa @ 2020-10-16 14:58 ` Thibaut Verron 2020-10-16 15:51 ` Alfred M. Szmidt 2020-10-17 4:20 ` Richard Stallman 2020-10-16 15:36 ` Ergus ` (2 subsequent siblings) 3 siblings, 2 replies; 838+ messages in thread From: Thibaut Verron @ 2020-10-16 14:58 UTC (permalink / raw) To: Marcel Ventosa; +Cc: emacs-devel, Richard Stallman, Jean Louis, Dmitry Gutov > > And picking on 2-3 "ideologically impure" packages (out of several > > thousands!) that are distributed on MELPA is counter-productive. > > We could turn this argument around and ask why the developers who > maintain MELPA don't remove `2-3' packages that promote non-free > software. I sincerely hope it doesn't happen. Those packages might rely on non-free software, but they are still packages that some users find valuable or even vital, and that they would want to find somewhere else if not available on Melpa. Removing them from Melpa would only move the "problem". Also, is the goal of the GNU project to deny users the right to run the software they want or need? Or is it to give them a choice of free options to replace non-free software? Having those packages removed would make it more difficult to use non-free software, but it would do nothing to improve the power of free software. > What came first, the GNU Emacs or the MELPA? What does it have to do with the question? ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 14:58 ` Thibaut Verron @ 2020-10-16 15:51 ` Alfred M. Szmidt 2020-10-16 16:10 ` Thibaut Verron 2020-10-17 4:20 ` Richard Stallman 1 sibling, 1 reply; 838+ messages in thread From: Alfred M. Szmidt @ 2020-10-16 15:51 UTC (permalink / raw) To: thibaut.verron; +Cc: mve1, emacs-devel, rms, bugs, dgutov > > And picking on 2-3 "ideologically impure" packages (out of several > > thousands!) that are distributed on MELPA is counter-productive. > > We could turn this argument around and ask why the developers who > maintain MELPA don't remove `2-3' packages that promote non-free > software. I sincerely hope it doesn't happen. We should all hope that it does, since such software is bad, one way that is being done is with the non-GNU ELPA archive. Also, is the goal of the GNU project to deny users the right to run the software they want or need? Or is it to give them a choice of free options to replace non-free software? The goal of the GNU project is to replace all non-free sofware, since any non-free software is unjust. That means, we do not want to recommend users to install any kind of non-free software. This isn't the same thing as prohibiting users what they can do on their own accord, but rather that the project goal is to eliminate an injustice being done to all computer users. And with that means that we do not want to do anything that would work against our goals. Having those packages removed would make it more difficult to use non-free software, but it would do nothing to improve the power of free software. That may be so, but recommending users to use non-free software would be worse -- it would be immoral and unethical. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 15:51 ` Alfred M. Szmidt @ 2020-10-16 16:10 ` Thibaut Verron 2020-10-16 16:16 ` Alfred M. Szmidt 0 siblings, 1 reply; 838+ messages in thread From: Thibaut Verron @ 2020-10-16 16:10 UTC (permalink / raw) To: Alfred M. Szmidt Cc: Marcel Ventosa, emacs-devel, Richard Stallman, Jean Louis, Dmitry Gutov Le ven. 16 oct. 2020 à 17:51, Alfred M. Szmidt <ams@gnu.org> a écrit : > > > > And picking on 2-3 "ideologically impure" packages (out of several > > > thousands!) that are distributed on MELPA is counter-productive. > > > > We could turn this argument around and ask why the developers who > > maintain MELPA don't remove `2-3' packages that promote non-free > > software. > > I sincerely hope it doesn't happen. > > We should all hope that it does, since such software is bad, one way > that is being done is with the non-GNU ELPA archive. I hope that once the non-GNU Elpa archive exists, those non-free packages will still live on Melpa, and will die their just death, once, and not before, a free alternative exists. > > Also, is the goal of the GNU project to deny users the right to run > the software they want or need? Or is it to give them a choice of > free options to replace non-free software? > > The goal of the GNU project is to replace all non-free sofware, since > any non-free software is unjust. That means, we do not want to > recommend users to install any kind of non-free software. > > This isn't the same thing as prohibiting users what they can do on > their own accord, but rather that the project goal is to eliminate an > injustice being done to all computer users. And with that means that > we do not want to do anything that would work against our goals. The message I was answering to suggested asking the maintainers of Melpa to remove some packages. This is not about what the FSF and the GNU project do or don't do, or even recommend, this is about telling an Emacs user what to put in their privately maintained repository. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 16:10 ` Thibaut Verron @ 2020-10-16 16:16 ` Alfred M. Szmidt 2020-10-16 16:32 ` Thibaut Verron 0 siblings, 1 reply; 838+ messages in thread From: Alfred M. Szmidt @ 2020-10-16 16:16 UTC (permalink / raw) To: thibaut.verron; +Cc: mve1, emacs-devel, rms, bugs, dgutov Asking to for non-free software to be removed is a laudable thing to do and it is something I hope more people will do, but it is not telling someone what they should or shouldn't do. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 16:16 ` Alfred M. Szmidt @ 2020-10-16 16:32 ` Thibaut Verron 2020-10-16 16:50 ` Alfred M. Szmidt 0 siblings, 1 reply; 838+ messages in thread From: Thibaut Verron @ 2020-10-16 16:32 UTC (permalink / raw) To: Alfred M. Szmidt Cc: Marcel Ventosa, emacs-devel, Richard Stallman, Jean Louis, Dmitry Gutov Le ven. 16 oct. 2020 à 18:16, Alfred M. Szmidt <ams@gnu.org> a écrit : > > Asking to for non-free software to be removed is a laudable thing to > do and it is something I hope more people will do, but it is not > telling someone what they should or shouldn't do. Would you mind clarifying the difference between the two? As it is, your message reads like doublethink to me. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 16:32 ` Thibaut Verron @ 2020-10-16 16:50 ` Alfred M. Szmidt 2020-10-16 17:16 ` Thibaut Verron 0 siblings, 1 reply; 838+ messages in thread From: Alfred M. Szmidt @ 2020-10-16 16:50 UTC (permalink / raw) To: thibaut.verron; +Cc: mve1, emacs-devel, rms, bugs, dgutov > Asking to for non-free software to be removed is a laudable thing to > do and it is something I hope more people will do, but it is not > telling someone what they should or shouldn't do. Would you mind clarifying the difference between the two? Could you please get me a cup of tea? I want a cup of tea, get me one. Is there anyone who wants to implement frobnitz in Emacs? You must implement frobnitz in Emacs otherwise we will start using vi. As it is, your message reads like doublethink to me. That is unfriendly to say the least. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 16:50 ` Alfred M. Szmidt @ 2020-10-16 17:16 ` Thibaut Verron 2020-10-16 17:32 ` Alfred M. Szmidt 0 siblings, 1 reply; 838+ messages in thread From: Thibaut Verron @ 2020-10-16 17:16 UTC (permalink / raw) To: Alfred M. Szmidt Cc: mve1, emacs-devel, Richard Stallman, Jean Louis, Dmitry Gutov Le ven. 16 oct. 2020 à 18:50, Alfred M. Szmidt <ams@gnu.org> a écrit : > > > Asking to for non-free software to be removed is a laudable thing to > > do and it is something I hope more people will do, but it is not > > telling someone what they should or shouldn't do. > > Would you mind clarifying the difference between the two? > > Could you please get me a cup of tea? > > I want a cup of tea, get me one. > > Is there anyone who wants to implement frobnitz in Emacs? > > You must implement frobnitz in Emacs otherwise we will start using vi. So the difference is to say "please" and be polite when we ask them to remove some packages? What if they say no? Does it change our opinion of them? > > As it is, your message reads like doublethink to me. > That is unfriendly to say the least. I regret my choice of words, my intention was not to be offensive. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 17:16 ` Thibaut Verron @ 2020-10-16 17:32 ` Alfred M. Szmidt 2020-10-16 17:55 ` Thibaut Verron 0 siblings, 1 reply; 838+ messages in thread From: Alfred M. Szmidt @ 2020-10-16 17:32 UTC (permalink / raw) To: thibaut.verron; +Cc: mve1, emacs-devel, rms, bugs, dgutov [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1485 bytes --] Le ven. 16 oct. 2020 à 18:50, Alfred M. Szmidt <ams@gnu.org> a écrit : > > > Asking to for non-free software to be removed is a laudable thing to > > do and it is something I hope more people will do, but it is not > > telling someone what they should or shouldn't do. > > Would you mind clarifying the difference between the two? > > Could you please get me a cup of tea? > > I want a cup of tea, get me one. > > Is there anyone who wants to implement frobnitz in Emacs? > > You must implement frobnitz in Emacs otherwise we will start using vi. So the difference is to say "please" and be polite when we ask them to remove some packages? That is the differences between asking someone if they can do something for you, and giving them an order ... so yes? What if they say no? Does it change our opinion of them? If someone brings you a cup of tea, or does something for you, don't you hold them to a slightly higher regard? And if someone, or a project, removes something that we find problematic, instead of maybe insisting on keeping it around, don't you think that also changes the overal perception between the two parties? If they say no, then they said no. Maybe one can convince them of otherwise, but trying to force their hand would be unkind and unfair. Just like it is unkind to try and force the GNU project to for example recommend Melpa in Emacs since it would go against our principles. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 17:32 ` Alfred M. Szmidt @ 2020-10-16 17:55 ` Thibaut Verron 2020-10-16 18:16 ` Alfred M. Szmidt 0 siblings, 1 reply; 838+ messages in thread From: Thibaut Verron @ 2020-10-16 17:55 UTC (permalink / raw) To: Alfred M. Szmidt Cc: mve1, emacs-devel, Richard Stallman, Jean Louis, Dmitry Gutov Le ven. 16 oct. 2020 à 19:32, Alfred M. Szmidt <ams@gnu.org> a écrit : > So the difference is to say "please" and be polite when we ask them to > remove some packages? > > That is the differences between asking someone if they can do > something for you, and giving them an order ... so yes? Okay, with the slight difference that clearly they *can* do it: removing a package is a trivial action. The question is really whether they *want* to do it. > If they say no, then they said no. Maybe one can convince them of > otherwise, but trying to force their hand would be unkind and unfair. Okay, as long as their saying no would not immediately make them as "bad" as the few packages they refuse to remove. I still personally do not wish for them to remove those packages, and I explained why earlier, but that's just me. > Just like it is unkind to try and force the GNU project to for example > recommend Melpa in Emacs since it would go against our principles. As far as I can tell, nobody in this conversation is asking for that. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 17:55 ` Thibaut Verron @ 2020-10-16 18:16 ` Alfred M. Szmidt 0 siblings, 0 replies; 838+ messages in thread From: Alfred M. Szmidt @ 2020-10-16 18:16 UTC (permalink / raw) To: thibaut.verron; +Cc: mve1, emacs-devel, rms, bugs, dgutov > So the difference is to say "please" and be polite when we ask them to > remove some packages? > > That is the differences between asking someone if they can do > something for you, and giving them an order ... so yes? Okay, with the slight difference that clearly they *can* do it: removing a package is a trivial action. The question is really whether they *want* to do it. Indeed. > If they say no, then they said no. Maybe one can convince them of > otherwise, but trying to force their hand would be unkind and unfair. Okay, as long as their saying no would not immediately make them as "bad" as the few packages they refuse to remove. There is are large difference between calling them, which I am guessing you mean those who maintain a project, and the actions, or the situation bad. > Just like it is unkind to try and force the GNU project to for example > recommend Melpa in Emacs since it would go against our principles. As far as I can tell, nobody in this conversation is asking for that. When the discussion was raised before about a non-GNU ELPA, that was exactly what being demanded. And it is what is being demanded by having an Emacs survey that mentions MELPA for example. Maybe demand is slightly strong, but several harsh words have been used in describing why the GNU project does not wish to do that. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 14:58 ` Thibaut Verron 2020-10-16 15:51 ` Alfred M. Szmidt @ 2020-10-17 4:20 ` Richard Stallman 2020-10-17 4:50 ` Thibaut Verron 1 sibling, 1 reply; 838+ messages in thread From: Richard Stallman @ 2020-10-17 4:20 UTC (permalink / raw) To: thibaut.verron; +Cc: mve1, dgutov, bugs, emacs-devel [[[ 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. ]]] > > We could turn this argument around and ask why the developers who > > maintain MELPA don't remove `2-3' packages that promote non-free > > software. > I sincerely hope it doesn't happen. Those packages might rely on > non-free software, but they are still packages that some users find > valuable or even vital, and that they would want to find somewhere > else if not available on Melpa. Removing them from Melpa would only > move the "problem". I think you have picked up your values (your basis of judging what is good or bad) from what most people think, and that you took for granted we have the same values. But we don't. The goal of the GNU Project is not simply "to help users." It is to help users _escape from nonfree software_ (des logiciels pas libres), and ultimately to build a world where all software is free. Nonfree software is an injustice -- nonfree software subjugates users. Our goal is to _eradicate it_. See https://gnu.org/philosophy/free-software-even-more-important.html and fsf.org/tedx for explanation of these ideas. Suppose that a user finds some nonfree software because a Melpa package refers to it. Suppose the user considers that nonfree software very useful. What should we say about that? You, thinking based on your values, seem to consider that a good thing. You draw the conclusion that it would be unfortunate if Melpa deleted the Lisp package which refers to that nonfree program. We, based on the values we have followed since the 1980s say that it is bad that someone is using a nonfree program, that we wish the nonfree program did not exist, and that we hope someone will liberate its users soon by developing a free replacement for it. We would be very glad if Melpa deleted that Lisp package. If user A says, "I really like nonfree program X," my guess is that you would say, "I am glad you like it." If A had found out about X from you, you might feel proud to have "helped". We would say, "How sad, one step backwards away from freedom." If A had found out about X from us, we would say, "Oops! An own-goal! What did we do wrong, and how can we make sure we don't do it again?" We tend to expect that people joining in GNU Project discussion lists are familiar with the basic ideas and values of the GNU Project. But this is not always the case. It would be good if we could recognize this sooner and educate people about the basic ideas of the GNU Project sooner. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-17 4:20 ` Richard Stallman @ 2020-10-17 4:50 ` Thibaut Verron 2020-10-17 5:44 ` Jean Louis 2020-10-17 9:42 ` Yuri Khan 0 siblings, 2 replies; 838+ messages in thread From: Thibaut Verron @ 2020-10-17 4:50 UTC (permalink / raw) To: Richard Stallman; +Cc: mve1, Dmitry Gutov, Jean Louis, emacs-devel Le sam. 17 oct. 2020 à 06:21, Richard Stallman <rms@gnu.org> a écrit : > > [[[ 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. ]]] > > > > We could turn this argument around and ask why the developers who > > > maintain MELPA don't remove `2-3' packages that promote non-free > > > software. > > > I sincerely hope it doesn't happen. Those packages might rely on > > non-free software, but they are still packages that some users find > > valuable or even vital, and that they would want to find somewhere > > else if not available on Melpa. Removing them from Melpa would only > > move the "problem". > > I think you have picked up your values (your basis of judging what is > good or bad) from what most people think, and that you took for granted > we have the same values. But we don't. > The goal of the GNU Project is not simply "to help users." It is to > help users _escape from nonfree software_ (des logiciels pas libres), and > ultimately to build a world where all software is free. I gave my reasons above. It's not just about "helping users", it's about helping them move more of their activities to the free world. Those packages (helm-lastpass, lastpass) are helping users who already use lastpass at the moment do exactly that. > Nonfree > software is an injustice -- nonfree software subjugates users. > Our goal is to _eradicate it_. Again, the same question: by arranging for links to such software to be removed everywhere? Or by offering free alternatives? Incidentally, I see a lot of effort so far discussing how evil helm-lastpass and lastpass are, and how to get them moved to obscure parts of the internet. What I don't see is efforts discussing free alternatives. As far as I know the only free competitor for lastpass is bitwarden, why is nobody talking about developing an emacs interface to bitwarden and educating lastpass users about it? Isn't _that_ what the GNU project is about, rather than making it as hard as possible to find the software we don't like? > You, thinking based on your values, seem to consider that a good > thing. You draw the conclusion that it would be unfortunate if Melpa > deleted the Lisp package which refers to that nonfree program. > > We, based on the values we have followed since the 1980s say that it > is bad that someone is using a nonfree program, that we wish the > nonfree program did not exist, and that we hope someone will liberate > its users soon by developing a free replacement for it. We would > be very glad if Melpa deleted that Lisp package. Me too I guess, once and not before the free replacement exists. As long as it doesn't, it means that the aforementioned users will be trapped in the non-free ecosystem because they can't use their password manager in Emacs (or IceCat). How is that helping the cause of free software? > We tend to expect that people joining in GNU Project discussion lists > are familiar with the basic ideas and values of the GNU Project. But > this is not always the case. It would be good if we could recognize > this sooner and educate people about the basic ideas of the GNU > Project sooner. I am familiar with the ideas and values of the GNU Project, and to a large extent I agree with them. My points of disagreement lie in implementation details and priorities. Framing those disagreements as a lack of education is demeaning. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-17 4:50 ` Thibaut Verron @ 2020-10-17 5:44 ` Jean Louis 2020-10-17 6:42 ` Thibaut Verron 2020-10-17 9:42 ` Yuri Khan 1 sibling, 1 reply; 838+ messages in thread From: Jean Louis @ 2020-10-17 5:44 UTC (permalink / raw) To: Thibaut Verron; +Cc: mve1, Dmitry Gutov, Richard Stallman, emacs-devel * Thibaut Verron <thibaut.verron@gmail.com> [2020-10-17 07:50]: > I gave my reasons above. It's not just about "helping users", it's > about helping them move more of their activities to the free world. > Those packages (helm-lastpass, lastpass) are helping users who already > use lastpass at the moment do exactly that. > > > Nonfree > > software is an injustice -- nonfree software subjugates users. > > Our goal is to _eradicate it_. > > Again, the same question: by arranging for links to such software to > be removed everywhere? Or by offering free alternatives? > > Incidentally, I see a lot of effort so far discussing how evil > helm-lastpass and lastpass are, and how to get them moved to obscure > parts of the internet. What I don't see is efforts discussing free > alternatives. There are many password managers in any GNU/Linux system, including, I am sure, and there are cross platform free software password managers such as keepass, then there are packages that can manage passwords with Emacs only, those may not be well integrated, then both KDE/Gnome have their password managers, each browser has it password managers. Especially when we are talking about subject of password management, advising GNU Emacs users to keep their passwords online in a cloud, managed by proprietary software is very wrong. Thus there is no alternative to free software. From Wikipedia: https://en.wikipedia.org/wiki/LastPass https://en.wikipedia.org/wiki/LastPass#2011_security_incident https://en.wikipedia.org/wiki/LastPass#2015_security_breach https://en.wikipedia.org/wiki/LastPass#2016_security_incidents https://en.wikipedia.org/wiki/LastPass#2017_security_incidents https://en.wikipedia.org/wiki/LastPass#2019_security_incidents Those are only publicly announced security incidents. How many there are not announced? In that sense, knowing the background of the insecurities at the company producing proprietary software, the package lastpass for Emacs and helm-lastpass is only helping that company subjugates users to keep their passwords online and sooner or later abuse Emacs users. My system of keeping passwords is the file .passwords which is stored on encrypted partition. It is appendable only file by using chattr +a, and Emacs asks me for host name, username, email, etc. and it generates password which is appeneded to a file. Other simple function is grepping and finding list of passwords. It would be disaster to keep my 4362 passwords online, unsaid of keeping it in some cloud with a company known for security incidents. At MELPA bug tracking, or Github issue tracker, the issue is closed, there was no question if the package "lastpass" is driving users to insecurities, issue was simply closed, without possibility to publish this exact information. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-17 5:44 ` Jean Louis @ 2020-10-17 6:42 ` Thibaut Verron 2020-10-17 7:52 ` Jean Louis ` (3 more replies) 0 siblings, 4 replies; 838+ messages in thread From: Thibaut Verron @ 2020-10-17 6:42 UTC (permalink / raw) To: Jean Louis; +Cc: mve1, Dmitry Gutov, Richard Stallman, emacs-devel Le sam. 17 oct. 2020 à 07:44, Jean Louis <bugs@gnu.support> a écrit : > > * Thibaut Verron <thibaut.verron@gmail.com> [2020-10-17 07:50]: > > I gave my reasons above. It's not just about "helping users", it's > > about helping them move more of their activities to the free world. > > Those packages (helm-lastpass, lastpass) are helping users who already > > use lastpass at the moment do exactly that. > > > > > Nonfree > > > software is an injustice -- nonfree software subjugates users. > > > Our goal is to _eradicate it_. > > > > Again, the same question: by arranging for links to such software to > > be removed everywhere? Or by offering free alternatives? > > > > Incidentally, I see a lot of effort so far discussing how evil > > helm-lastpass and lastpass are, and how to get them moved to obscure > > parts of the internet. What I don't see is efforts discussing free > > alternatives. > > There are many password managers in any GNU/Linux system, including, I > am sure, and there are cross platform free software password managers > such as keepass, then there are packages that can manage passwords > with Emacs only, those may not be well integrated, then both KDE/Gnome > have their password managers, each browser has it password managers. Can you use Keepass with Emacs? Can you use Keepass on a phone? Can you use it on a computer without root access? > both KDE/Gnome have their password managers Can you use them with Emacs? Can you use them on a phone? > each browser has it password managers. I don't know what Edge does, and Chrome and Chromium use Google services for their password manager. Firefox offers Lockwise and Opera also has its in-house method, which at least work on phones (afaik). But then they require storage in the cloud in the same way as Lastpass. And can you use them with Emacs? I mentioned it before, but as far as I know, the only free software offering for a service similar to Lastpass is Bitwarden: free software for both the client and the server with the possibility to self-host, same features as Lastpass (including measuring the overall safety of your passwords, which I don't think those other password managers do) and same compatibility list. Focusing efforts towards evaluating the freedom (freeness?) of Bitwarden, and if applicable, extending the support for Bitwarden to the level of that of emacs-lastpass would make it a lot easier to convince users to abandon that bit of non-free software. > > Especially when we are talking about subject of password management, > advising GNU Emacs users to keep their passwords online in a cloud, > managed by proprietary software is very wrong. > > (...) > > From Wikipedia: > https://en.wikipedia.org/wiki/LastPass > > https://en.wikipedia.org/wiki/LastPass#2011_security_incident > https://en.wikipedia.org/wiki/LastPass#2015_security_breach > https://en.wikipedia.org/wiki/LastPass#2016_security_incidents > https://en.wikipedia.org/wiki/LastPass#2017_security_incidents > https://en.wikipedia.org/wiki/LastPass#2019_security_incidents > > Those are only publicly announced security incidents. How many there > are not announced? > > In that sense, knowing the background of the insecurities at the > company producing proprietary software, the package lastpass for Emacs > and helm-lastpass is only helping that company subjugates users to > keep their passwords online and sooner or later abuse Emacs users. > > (...) > > At MELPA bug tracking, or Github issue tracker, the issue is closed, > there was no question if the package "lastpass" is driving users to > insecurities, issue was simply closed, without possibility to publish > this exact information. Yes yes, but that's still about the availability of and the problems behind lastpass and the emacs packages. My question is about alternatives. Or, what would you tell users who currently use lastpass and emacs-lastpass, after you tell them they should stop using lastpass? Surely you don't want to convince them to use an inferior product just for purity of software? I would keep the issue of security incidents separate. Security flaws are regularly found in both free and non-free software. Lastpass makes it a policy to announce such breaches. And 5 incidents in 9 years does not make Lastpass "known for security incidents", not any more than OpenSSL would be known for security incidents (even though in the same period, 6 flaws were found and patched in OpenSSL). > My system of keeping passwords is the file .passwords which is stored > on encrypted partition. It is appendable only file by using chattr +a, > and Emacs asks me for host name, username, email, etc. and it > generates password which is appeneded to a file. Other simple function > is grepping and finding list of passwords. Do you use it across devices? On devices where you don't have root access? On phones? > It would be disaster to keep my 4362 passwords online Assuming that sufficiently strong encryption is used, why exactly? > Especially when we are talking about subject of password management, > advising GNU Emacs users to keep their passwords online in a cloud, > managed by proprietary software is very wrong. > > Thus there is no alternative to free software. I don't see what it has to do with the question, but it is factually wrong. There are plenty of alternatives to free software. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-17 6:42 ` Thibaut Verron @ 2020-10-17 7:52 ` Jean Louis 2020-10-18 4:16 ` Richard Stallman ` (2 subsequent siblings) 3 siblings, 0 replies; 838+ messages in thread From: Jean Louis @ 2020-10-17 7:52 UTC (permalink / raw) To: Thibaut Verron; +Cc: emacs-devel * Thibaut Verron <thibaut.verron@gmail.com> [2020-10-17 09:42]: > Can you use Keepass with Emacs? Can you use Keepass on a phone? Can > you use it on a computer without root access? > > > both KDE/Gnome have their password managers > > Can you use them with Emacs? Can you use them on a phone? Password by definition is a secret word or phrase known only to restricted group or individual, I do not share opinion that passwords should be placed with unknown group of people like lastpass, neither at all held in any type of remote cloud. In case of Keepass as free software, yes, it does work on many operating systems, probably more than the proprietary lastpass, and it seems that there is keepass-mode, at least to copy passwords to Emacs, I did not reseach command line. Overall it does not matter, those questions are not relevant, as for GNU project, proprietary software or supporting proprietary software by making Emacs packages that support such or interact with such, are simply no go, as such are controlling the user, and do not give freedom of computing to user. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-17 6:42 ` Thibaut Verron 2020-10-17 7:52 ` Jean Louis @ 2020-10-18 4:16 ` Richard Stallman 2020-10-18 5:49 ` Jean Louis 2020-10-18 4:16 ` Richard Stallman 2020-10-18 4:16 ` Richard Stallman 3 siblings, 1 reply; 838+ messages in thread From: Richard Stallman @ 2020-10-18 4:16 UTC (permalink / raw) To: thibaut.verron; +Cc: mve1, emacs-devel, bugs, dgutov [[[ 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. ]]] 1. Looking for free password managers on GNU/Linux makes sense, and perhaps developing another would be useful. However, neither of these possibly useful activities directly affects the ethical issue of leading users to use lastpass. 2. If and when the free password managers are miles above lastpass, it could happen that no one has a rational use for lastpass except due to habit. If and when that happens, perhaps people could modify the Lisp package for using lastpass so that it clearly informs users, that lastpass is not worth even trying and they should instead try the free password managers X, Y, Z. 3. Once that change is, perhaps that Lisp package would be so unlikely to lead anyone to use lastpass that we would have no reason to worry about informing users about its existence. In particular, it would not be a flaw in MELPA that MELPA contains it. 4. However, each of the other programs in MELPA that depends on a nonfree program would be a separate issue. 5. If someday MELPA contains no programs that might lead users to use a nonfree program, another one might be added at any time. As long as the MELPA maintainers say it is ok to add such packages, we have to suppose that more such packages may be added. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-18 4:16 ` Richard Stallman @ 2020-10-18 5:49 ` Jean Louis 0 siblings, 0 replies; 838+ messages in thread From: Jean Louis @ 2020-10-18 5:49 UTC (permalink / raw) To: Richard Stallman; +Cc: mve1, dgutov, thibaut.verron, emacs-devel * Richard Stallman <rms@gnu.org> [2020-10-18 07:17]: > [[[ 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. ]]] > > 1. Looking for free password managers on GNU/Linux makes sense, > and perhaps developing another would be useful. There are many password managers as free software including those that work on various operating system and mobile devices. There is GNU password manager: https://www.gnu.org/software/gnu-pw-mgr/ There are GUI password managers in Gnome and KDE, there is closs-platform keepass and many others: pass - lightweight directory-based password manager passwordsafe - Simple & Secure Password Management qtpass - GUI for password manager pass gnome-pass-search-provider - GNOME Shell search provider for the pass password manager impass - Simple and secure password management and retrieval system ylva - command line password manager What the proprietary software lastpass do, they provide online cloud service for people to store passwords so that they are accessible from various devices. Maybe 60 million people use that software. As I am not of opinion that passwords should be stored online, I will not say that such software is necessary. Other people will argue it is necessary. Additionally there are password management packages for Emacs out there that do not use proprietary software. There is Syncthing free software package that can synchronize files across devices, it could also synchronize passwords, it would not be well integrated. > 2. If and when the free password managers are miles above lastpass, it > could happen that no one has a rational use for lastpass except due to > habit. There is no rational use to store passwords at centralized server by using proprietary software, as one cannot know exactly how they encrypt those passwords, neither is management of their server and breahes of security transparent. What can make sense in free software world is cross platform password manager that users can host on their own server while knowing what type of encryption is used there. > If and when that happens, perhaps people could modify the Lisp package > for using lastpass so that it clearly informs users, that lastpass is > not worth even trying and they should instead try the free password > managers X, Y, Z. That is good idea, MELPA can be replicated and some packages could be automated to be made unusable with such warning. > 3. Once that change is, perhaps that Lisp package would be so unlikely > to lead anyone to use lastpass that we would have no reason to worry > about informing users about its existence. In particular, it would > not be a flaw in MELPA that MELPA contains it. It would not be flaw if package author would agree with you. The fact that package author made the package shows that there is opinion difference, so it cannot work that way. It can only work by third party that is not MELPA, to duplicate MELPA and offer it in safe way to users. > 5. If someday MELPA contains no programs that might lead users > to use a nonfree program, another one might be added at any time. > As long as the MELPA maintainers say it is ok to add such packages, > we have to suppose that more such packages may be added. That is right, exactly that is the problem, they consider if software package is GNU GPL, that it is enough regardless if package is subjugating user. What I consider larger problem at hand is that MELPA is developed on Github, Emacs package contributors have to use none free Javascript to become developers and they all bind themselves to centralized development system held by Microsoft. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-17 6:42 ` Thibaut Verron 2020-10-17 7:52 ` Jean Louis 2020-10-18 4:16 ` Richard Stallman @ 2020-10-18 4:16 ` Richard Stallman 2020-10-18 5:52 ` Jean Louis 2020-10-18 4:16 ` Richard Stallman 3 siblings, 1 reply; 838+ messages in thread From: Richard Stallman @ 2020-10-18 4:16 UTC (permalink / raw) To: thibaut.verron; +Cc: mve1, emacs-devel, bugs, dgutov [[[ 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. ]]] > I mentioned it before, but as far as I know, the only free software > offering for a service similar to Lastpass is Bitwarden: free software Are there any that run locally, just a program with no service involved? -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-18 4:16 ` Richard Stallman @ 2020-10-18 5:52 ` Jean Louis 0 siblings, 0 replies; 838+ messages in thread From: Jean Louis @ 2020-10-18 5:52 UTC (permalink / raw) To: Richard Stallman; +Cc: mve1, dgutov, thibaut.verron, emacs-devel * Richard Stallman <rms@gnu.org> [2020-10-18 07:19]: > [[[ 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. ]]] > > > I mentioned it before, but as far as I know, the only free software > > offering for a service similar to Lastpass is Bitwarden: free software > > > Are there any that run locally, just a program with no service > involved? There are several on any GNU/Linux distribution. Majority of them will not place passwords on cloud that data can be exchanged. Free software keepass is cross-platform, it already has free software package for Android/Replicant system and can read data from computer to other device and vice versa probably, I did not try it. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-17 6:42 ` Thibaut Verron ` (2 preceding siblings ...) 2020-10-18 4:16 ` Richard Stallman @ 2020-10-18 4:16 ` Richard Stallman 2020-10-18 8:36 ` Thibaut Verron 3 siblings, 1 reply; 838+ messages in thread From: Richard Stallman @ 2020-10-18 4:16 UTC (permalink / raw) To: thibaut.verron; +Cc: mve1, emacs-devel, bugs, dgutov [[[ 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. ]]] > Surely you don't want to convince them to use an inferior product just > for purity of software? Are you defining "superior" and "inferior" based on practical considerations only? Most people think that way; business and the media inculcate that way of thinking. However, the GNU Project follows the values of the free software movement, which hold that most important characteristic of a program is whether it respects the user's freedom or tramples it. If you value your freedom strongly, you will consider any free program better than any nonfree program. Based on these values, switching to a free program is always a step up. The people who use lastpass are probably not supporters of the free software movement. Probably they think that lastpass is better than no program at all. They might thing that lastpass is superior to some free programs. If we want to persuade them of something, we need to argue based on premises they agree with. We may need to make arguments that can persuade even a person who thinks that a nonfree program is a good thing. But we must be careful not to endorse the idea that a nonfree program is a good thing. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-18 4:16 ` Richard Stallman @ 2020-10-18 8:36 ` Thibaut Verron 2020-10-20 5:10 ` Richard Stallman 0 siblings, 1 reply; 838+ messages in thread From: Thibaut Verron @ 2020-10-18 8:36 UTC (permalink / raw) To: Richard Stallman; +Cc: Marcel Ventosa, emacs-devel, Jean Louis, Dmitry Gutov > > Surely you don't want to convince them to use an inferior product just > > for purity of software? > > Are you defining "superior" and "inferior" based on practical > considerations only? Most people think that way; business and the > media inculcate that way of thinking. > > However, the GNU Project follows the values of the free software > movement, which hold that most important characteristic of a program > is whether it respects the user's freedom or tramples it. If you > value your freedom strongly, you will consider any free program better > than any nonfree program. > > Based on these values, switching to a free program is always a step > up. > > The people who use lastpass are probably not supporters of the free > software movement. Probably they think that lastpass is better than > no program at all. They might thing that lastpass is superior to some > free programs. > > If we want to persuade them of something, we need to argue based on > premises they agree with. We may need to make arguments that can > persuade even a person who thinks that a nonfree program is a good > thing. I agree with all of that. But I'm an idealist: I think if the software is free and has as many or more functionalities (e.g. MS office vs Libreoffice, Sublime Text vs Emacs), the argument should convince everybody, no matter how much they care about freedom. As an aside, English is obviously not my native language, but in French, there is a subtle difference being persuade (persuader) and convince (convaincre): the latter appeals to reason and facts, the former to emotions. I don't know if the same difference exists in English, but if it does, I think that what we want is to convince people to use free software. > But we must be careful not to endorse the idea that a nonfree program > is a good thing. I don't think that I said that. But a feature available in a non-free program can be a good feature which we might want to add to free programs (assuming that it is possible without compromising on freedom, of course). ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-18 8:36 ` Thibaut Verron @ 2020-10-20 5:10 ` Richard Stallman 0 siblings, 0 replies; 838+ messages in thread From: Richard Stallman @ 2020-10-20 5:10 UTC (permalink / raw) To: thibaut.verron; +Cc: mve1, dgutov, bugs, emacs-devel [[[ 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. ]]] > But a feature available in a non-free program can be a good feature > which we might want to add to free programs (assuming that it is > possible without compromising on freedom, of course). The feature, in the abstract, might be good in the sense of convenient, and we might well want to implement it. However, it is clearer to call it "convenient" rather than "good", to delineate the contrast with the ethical meaning of "good". -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-17 4:50 ` Thibaut Verron 2020-10-17 5:44 ` Jean Louis @ 2020-10-17 9:42 ` Yuri Khan 1 sibling, 0 replies; 838+ messages in thread From: Yuri Khan @ 2020-10-17 9:42 UTC (permalink / raw) To: thibaut.verron Cc: mve1, emacs-devel, Richard Stallman, Jean Louis, Dmitry Gutov On Sat, 17 Oct 2020 at 07:51, Thibaut Verron <thibaut.verron@gmail.com> wrote: > Incidentally, I see a lot of effort so far discussing how evil > helm-lastpass and lastpass are, and how to get them moved to obscure > parts of the internet. What I don't see is efforts discussing free > alternatives. +1! > As far as I know the only free competitor for lastpass is bitwarden, > why is nobody talking about developing an emacs interface to bitwarden > and educating lastpass users about it? Have another one: https://www.passwordstore.org/ It is a convention for storing each password in a separate encrypted text file and a shell script wrapper around GPG and optionally Git implementing that convention. The store directory just happens to be easily browsable in Emacs without any additional interface packages — as you visit an encrypted file, Emacs asks for the decryption key passphrase and displays a buffer with decrypted password and any additional metadata associated with it. (I did not check what happens if you modify and save that buffer; whether it gets encrypted with all the keys it was originally encrypted with.) And it comes with a script that imports passwords from LastPass format. (I now looked at Bitwarden and it looks like its server component, while itself being Free, requires Microsoft SQL Server which is free-to-use but not Free; and without the server component the user is locked into using someone else’s server instance. So, ideologically, Bitwarden is not much better than LastPass.) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 14:33 ` Marcel Ventosa 2020-10-16 14:58 ` Thibaut Verron @ 2020-10-16 15:36 ` Ergus 2020-10-16 19:08 ` Dmitry Gutov 2020-10-16 19:22 ` Jean Louis 3 siblings, 0 replies; 838+ messages in thread From: Ergus @ 2020-10-16 15:36 UTC (permalink / raw) To: Marcel Ventosa Cc: Dmitry Gutov, Thibaut Verron, Richard Stallman, Jean Louis, emacs-devel On Fri, Oct 16, 2020 at 09:33:12PM +0700, Marcel Ventosa wrote: >On Fri, 16 Oct 2020 17:04:22 +0300 >Dmitry Gutov <dgutov@yandex.ru> wrote: > > >From what I just read from Thibaut, a free software compatible solution >to replace MELPA is underway. Refusing to draw attention to something is >not "shutting our eyes". > Melpa will never die. Specially because it is a more open community; has been around for long time and anyone can contribute almost anonymously. It is the equivalent to the AUR in arch linux. > >I thought your argument was popularity, something that keeps coming up >in these kinds of discussions. What was your argument? > Popularity, usability... there are many. Many packages in melpa are just unique and has a lot of work invested on them that nobody is planning to duplicate (ex: magit) > >We could turn this argument around and ask why the developers who >maintain MELPA don't remove `2-3' packages that promote non-free >software. What came first, the GNU Emacs or the MELPA? > Because this 1) don't improve free software alternatives in any way 2) will force the user to use free software instead of giving them the option to choose it 3) Because it will restrict melpa in a way opposed to its intention... Basically if a user is concerned then 1) will not add melpa to emacs 2) will read every package licenses... > >Indeed. As I recall, RMS suggested open questions instead of multiple >choice questions that "shape their behavior". With open questions, there >is no need to mention MELPA at all in fact. With open questions, the >insights that could be derived would be much more interesting. > > >That's very good news if the issue has been settled. > > >Why should Emacs development be guided by (external) survey results? I >would think it should be guided, for the most part, by what the people >putting their time into it want to create, within the principles of the >philosophy of the project and its goals. Also, anyone can suggest >changes and convince the maintainers that these changes are in the best >interest of the project (and contribute the actual changes if they are >accepted). > The main problem we have in emacs is the limited number of active developers. Half of the time the problem is not to convince the developers to do the work; but having someone to do it... So in that scenario, all the work invested in melpa packages is something we are not in conditions to reject; because those developers provide support and packages that we don't have the man power to do. >If they are not, Emacs makes it quite simple to implement changes for >personal "improvements". I have written functions that serve me >personally and change the behavior of Emacs to suit my needs. There are >limits to what I can do, which could be pushed if I dedicated a greater >effort to do so. How is that unfair? > >If I thought one of my changes could benefit the community at large, I >would approach the maintainers and suggest it. If they disagreed with my >view, I could publish the code and could still share it with anyone >willing to run it. > Exactly... and you can share those changes freely in melpa instead of keeping them to you if you don't have a copyright, the changes are small or just someone in your team don't want to register a copyright for any reason, your package is in an initial state or for very specific uses; your boss does don't give you a disclaim for your code, or you just want to share your changes with the hope that someone in the future improve what you did or find your idea useful in a more informal way. That's the freedom that many users find in melpa over elpa. (like AUR in arch linux). Share what they did freely without compromise and probably get improves and feedback from the community without asking who are you or if you have a copyright document or feeling the responsibility to maintain the package in the future. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 14:33 ` Marcel Ventosa 2020-10-16 14:58 ` Thibaut Verron 2020-10-16 15:36 ` Ergus @ 2020-10-16 19:08 ` Dmitry Gutov 2020-10-16 19:52 ` Jean Louis ` (2 more replies) 2020-10-16 19:22 ` Jean Louis 3 siblings, 3 replies; 838+ messages in thread From: Dmitry Gutov @ 2020-10-16 19:08 UTC (permalink / raw) To: Marcel Ventosa; +Cc: Thibaut Verron, Richard Stallman, Jean Louis, emacs-devel On 16.10.2020 17:33, Marcel Ventosa wrote: >> Shutting our eyes to actual user behavior also precludes >> understanding. > > From what I just read from Thibaut, a free software compatible solution > to replace MELPA is underway. Refusing to draw attention to something is > not "shutting our eyes". To make a replacement for something, you need to know what something is, and why it exists. >>>> ignore a project that has done a lot to popularize Emacs over the >>>> years. >>> >>> I fail to understand the narrative that pushes popularity over all >>> else. >> >> Strawman. > > I thought your argument was popularity, something that keeps coming up > in these kinds of discussions. What was your argument? You made a strawman claiming that I somehow push popularity "over all else". My argument is that they have done a lot for the community. Some of those effects reach the core too. >> And picking on 2-3 "ideologically impure" packages (out of several >> thousands!) that are distributed on MELPA is counter-productive. > > We could turn this argument around and ask why the developers who > maintain MELPA don't remove `2-3' packages that promote non-free > software. What came first, the GNU Emacs or the MELPA? No, we couldn't "turn this argument around". Those statements are not even remotely on the same level. Some Emacs maintainers themselves are known to use proprietary software. And use Emacs on proprietary OSes. And yet, somehow, MELPA is the odd one out? >> You can't be effective at affecting change anyway, if you don't know >> what's going on outside. > > Indeed. As I recall, RMS suggested open questions instead of multiple > choice questions that "shape their behavior". With open questions, there > is no need to mention MELPA at all in fact. With open questions, the > insights that could be derived would be much more interesting. So we won't suggest ELPA as an option either? What about the users who don't know the difference? MELPA is also an ELPA, after all (as in "Emacs Lisp Package Archive"). >> Didn't Philip show a prototype that didn't use JavaScript? > > That's very good news if the issue has been settled. It's solvable, let's put it this way. >>>> it is unfortunate how Emacs leadership does little to follow the >>>> external, "unofficial" polls. >>> >>> What do you mean by this? >> >> I don't recall any single change in Emacs' behavior that resulted >> from an external poll or survey. > > Why should Emacs development be guided by (external) survey results? Why should it use the scientific method? Why should it pay attention to other people, or the world at large? Is that what you're asking? > I > would think it should be guided, for the most part, by what the people > putting their time into it want to create, within the principles of the > philosophy of the project and its goals. It's not a painting or a novel. It's a software project, with certain expectations of practicality. > Also, anyone can suggest > changes and convince the maintainers that these changes are in the best > interest of the project (and contribute the actual changes if they are > accepted). No, not "anyone can convince". And like I said: no attention to external polls. Which is what you asked me to clarify. > If they are not, Emacs makes it quite simple to implement changes for > personal "improvements". I have written functions that serve me > personally and change the behavior of Emacs to suit my needs. There are > limits to what I can do, which could be pushed if I dedicated a greater > effort to do so. How is that unfair? You're veering the discussion off to the side for some reason. But if we're talking of "unfair", releasing Emacs under GPL, enabling such excellent extensibility that multiple communities spring up over years, ones brimming with creativity and people dedicating years of their spare time to the extensions, and then badmouthing them from afar as though they violated some existing contract (social or legal), *that* is unfair. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 19:08 ` Dmitry Gutov @ 2020-10-16 19:52 ` Jean Louis 2020-10-16 20:16 ` Dmitry Gutov 2020-10-16 20:17 ` Alfred M. Szmidt 2020-10-17 11:40 ` Marcel Ventosa 2 siblings, 1 reply; 838+ messages in thread From: Jean Louis @ 2020-10-16 19:52 UTC (permalink / raw) To: Dmitry Gutov Cc: Marcel Ventosa, Richard Stallman, Thibaut Verron, emacs-devel * Dmitry Gutov <dgutov@yandex.ru> [2020-10-16 22:08]: > My argument is that they have done a lot for the community. Some of > those effects reach the core too. That is right, and that still does not mean it is good to endorse MELPA as free software repository as it is for reasons of those packages in question, dangerous for users, as proprietary software in itself is dangerous. It may sound not logical, but contributions are welcome from anybody, and denunciation is good tool to point out to users that GNU and also FSF is not endorsing the non-free software distributions, and also non-free software repositories. > Some Emacs maintainers themselves are known to use proprietary > software. And use Emacs on proprietary OSes. And yet, somehow, MELPA > is the odd one out? Everybody is welcome to contribute to GNU. GNU policies do not mind if developers use proprietary software or operating systems, that is how free software entered proprietary operating systems. It does not matter if Emacs maintainers are themselves using proprietary software as they do not necessarily push or set the policies for the overall GNU project. In any case, everybody is welcome to contribute in creation and maintenance of free software operating systems and its parts. Denunciation would not discriminate between Emacs developers or non Emacs developers, but it would speaking out against publicly distribution of software that purports to be free, but its sole purpose was to run proprietary software or to interact with non-free software or interacting with proprietary Services as Software Substitutes: http://www.gnu.org/philosophy/who-does-that-server-really-serve.html Add your useful voice to Github issue on MELPA, to remove such software packages that wrap proprietary: https://github.com/melpa/melpa/issues/7185 > > Why should Emacs development be guided by (external) survey results? > > Why should it use the scientific method? I think it is far from being scientific. Those few people proposed it who do not have any experience in making a survey. If one has experience, one is not making any questions, one just do it. Finally, it was not a professional opinion poll agency. > > Also, anyone can suggest changes and convince the maintainers that > > these changes are in the best interest of the project (and > > contribute the actual changes if they are accepted). > > No, not "anyone can convince". Just {M-x report-emacs-bug} and they will not ask you for name, birth day, developers will look into the bug report, or suggestion improvement, it is a group decision. If you have something to propose, you are free, and anybody is free, it is so far I know, not even a subscription mailing list, people can write to mailing list without being subscribed, great thing. There are other mailing lists like help-gnu-emacs, also very friendly. I am only sorry for #emacs IRC channel being unfriendly especially towards free software movement at times, but that is due to few who do their personal hate promotion, or have nothing better to do in life, or simply work for proprietary software and hate themselves. > > If they are not, Emacs makes it quite simple to implement changes for > > personal "improvements". I have written functions that serve me > > personally and change the behavior of Emacs to suit my needs. There are > > limits to what I can do, which could be pushed if I dedicated a greater > > effort to do so. How is that unfair? > > You're veering the discussion off to the side for some reason. > > But if we're talking of "unfair", releasing Emacs under GPL, enabling such > excellent extensibility that multiple communities spring up over years, ones > brimming with creativity and people dedicating years of their spare time to > the extensions, and then badmouthing them from afar as though they violated > some existing contract (social or legal), *that* is unfair. Everybody is free to make proprietary software by using Emacs Lisp and run it with Emacs Lisp. So people are also free to sell such proprietary software. GNU is not supporting those communities. Similarly, packages can be made solely for purpose of running proprietary software or interacting with such, or interacting with Service as a Software Substitute, or fetching some proprietary information. When such software is promoted on supposedly free software repository, and free software repository has no clear policy on protecting users' freedom, then it is appropriate to speak out against it. There is maybe no written contract, yet there is unspoken understanding that if person is releasing free software such as Emacs package that such should not use proprietary software, as that defeats the purpose. - Hey brother... I made here one spectacular Emacs package. - wow, great, I hope you have free software license, that I can use it too. - sure it has free software license, fine GPL terms here inside - alright, give me that I try - sure, here it is, to run this software you only need to download the proprietary LastPass, then it will work - oh, is that so? And what does LastPass do to my computer? Do they track me? Read my information? Read my passwords? ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 19:52 ` Jean Louis @ 2020-10-16 20:16 ` Dmitry Gutov 0 siblings, 0 replies; 838+ messages in thread From: Dmitry Gutov @ 2020-10-16 20:16 UTC (permalink / raw) To: Jean Louis; +Cc: Marcel Ventosa, Richard Stallman, Thibaut Verron, emacs-devel On 16.10.2020 22:52, Jean Louis wrote: > - sure, here it is, to run this software you only need to download > the proprietary LastPass, then it will work I never said we should applaud individual packages like this. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 19:08 ` Dmitry Gutov 2020-10-16 19:52 ` Jean Louis @ 2020-10-16 20:17 ` Alfred M. Szmidt 2020-10-17 11:40 ` Marcel Ventosa 2 siblings, 0 replies; 838+ messages in thread From: Alfred M. Szmidt @ 2020-10-16 20:17 UTC (permalink / raw) To: Dmitry Gutov; +Cc: mve1, thibaut.verron, rms, bugs, emacs-devel When recommending someone to use Emacs, one is recommending free software, but when one recommends a package repository that can contain non-free software or software that depends on non-free software, then one could end up promoting non-free software -- at which point it is simpler to simply not refer to such repositories. (standards) References has a good section on it. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 19:08 ` Dmitry Gutov 2020-10-16 19:52 ` Jean Louis 2020-10-16 20:17 ` Alfred M. Szmidt @ 2020-10-17 11:40 ` Marcel Ventosa 2020-10-17 19:51 ` Dmitry Gutov 2 siblings, 1 reply; 838+ messages in thread From: Marcel Ventosa @ 2020-10-17 11:40 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Thibaut Verron, Richard Stallman, Jean Louis, emacs-devel On Fri, 16 Oct 2020 22:08:01 +0300 Dmitry Gutov <dgutov@yandex.ru> wrote: > >> You can't be effective at affecting change anyway, if you don't > >> know what's going on outside. > > > > Indeed. As I recall, RMS suggested open questions instead of > > multiple choice questions that "shape their behavior". With open > > questions, there is no need to mention MELPA at all in fact. With > > open questions, the insights that could be derived would be much > > more interesting. > > So we won't suggest ELPA as an option either? What about the users > who don't know the difference? MELPA is also an ELPA, after all (as > in "Emacs Lisp Package Archive"). Is it a survey then or is it an opportunity to "educate/advertise?" > > I > > would think it should be guided, for the most part, by what the people > > putting their time into it want to create, within the principles of the > > philosophy of the project and its goals. > It's not a painting or a novel. It's a software project, with certain > expectations of practicality. Are you claiming Emacs is not practical? > > If they are not, Emacs makes it quite simple to implement changes for > > personal "improvements". I have written functions that serve me > > personally and change the behavior of Emacs to suit my needs. There are > > limits to what I can do, which could be pushed if I dedicated a greater > > effort to do so. How is that unfair? > You're veering the discussion off to the side for some reason. I'm explaining how easy it is to modify Emacs to suit particular needs, and listing the possibilities that already exist for doing so. > But if we're talking of "unfair", releasing Emacs under GPL, enabling > such excellent extensibility that multiple communities spring up over > years, ones brimming with creativity and people dedicating years of > their spare time to the extensions, and then badmouthing them from afar > as though they violated some existing contract (social or legal), *that* > is unfair. It is GNU policy not to promote or encourage proprietary software. To the extent that any community does so, GNU must not promote or encourage that community. You mentioned it's a matter of 2 or 3 packages that recommend proprietary software, so the current impasse should be very easy to fix. I fail to see what injustice has been perpetrated on the MELPA maintainers here, or how they have been badmouthed. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-17 11:40 ` Marcel Ventosa @ 2020-10-17 19:51 ` Dmitry Gutov 2020-10-17 21:38 ` Alfred M. Szmidt 2020-10-18 2:58 ` Marcel Ventosa 0 siblings, 2 replies; 838+ messages in thread From: Dmitry Gutov @ 2020-10-17 19:51 UTC (permalink / raw) To: Marcel Ventosa; +Cc: Thibaut Verron, Richard Stallman, Jean Louis, emacs-devel On 17.10.2020 14:40, Marcel Ventosa wrote: >> So we won't suggest ELPA as an option either? What about the users >> who don't know the difference? MELPA is also an ELPA, after all (as >> in "Emacs Lisp Package Archive"). > > Is it a survey then or is it an opportunity to "educate/advertise?" Somebody else already explained that a poll where only one of the options is written and others are free-form will be biased anyway. >>> I >>> would think it should be guided, for the most part, by what the people >>> putting their time into it want to create, within the principles of the >>> philosophy of the project and its goals. > >> It's not a painting or a novel. It's a software project, with certain >> expectations of practicality. > > Are you claiming Emacs is not practical? It's less practical than it could be. And you seem to be claiming it doesn't need to. >>> If they are not, Emacs makes it quite simple to implement changes for >>> personal "improvements". I have written functions that serve me >>> personally and change the behavior of Emacs to suit my needs. There are >>> limits to what I can do, which could be pushed if I dedicated a greater >>> effort to do so. How is that unfair? > >> You're veering the discussion off to the side for some reason. > > I'm explaining how easy it is to modify Emacs to suit particular needs, > and listing the possibilities that already exist for doing so. Why are you explaining that to an Emacs developer? >> But if we're talking of "unfair", releasing Emacs under GPL, enabling >> such excellent extensibility that multiple communities spring up over >> years, ones brimming with creativity and people dedicating years of >> their spare time to the extensions, and then badmouthing them from afar >> as though they violated some existing contract (social or legal), *that* >> is unfair. > > It is GNU policy not to promote or encourage proprietary software. Those are not objective words, but a matter of opinion, to say the least. > To > the extent that any community does so, GNU must not promote or encourage > that community. You are saying that, by mentioning MELPA is the poll, GNU would promote MELPA. Right? Are you promoting proprietary software by saying the phrase "proprietary software", over and over, on this mailing list? And even giving examples sometimes. > I fail to see what injustice has been perpetrated on the > MELPA maintainers here, or how they have been badmouthed. Saying "MELPA promotes proprietary software" is like saying that GNU project promotes, I don't know... late-stage capitalism. Just by the virtue of being mostly developed in a capitalist country, and by being useful to many organizations participating in capitalist economies with high degree of inequality. Or that it promotes proprietary software by providing support for some of it. Let's disregard its mission, and all virtues and accomplishments, shall we? ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-17 19:51 ` Dmitry Gutov @ 2020-10-17 21:38 ` Alfred M. Szmidt 2020-10-18 2:58 ` Marcel Ventosa 1 sibling, 0 replies; 838+ messages in thread From: Alfred M. Szmidt @ 2020-10-17 21:38 UTC (permalink / raw) To: Dmitry Gutov; +Cc: mve1, thibaut.verron, rms, bugs, emacs-devel > It is GNU policy not to promote or encourage proprietary software. Those are not objective words, but a matter of opinion, to say the least. Most things in life are opinions, but those are the opinions of the GNU project, Emacs, and this list. > To > the extent that any community does so, GNU must not promote or encourage > that community. You are saying that, by mentioning MELPA is the poll, GNU would promote MELPA. Right? Reading the GNU Coding Standards (see (standards) References) would be a good start to understanding what the policies are; the short answer is yes. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-17 19:51 ` Dmitry Gutov 2020-10-17 21:38 ` Alfred M. Szmidt @ 2020-10-18 2:58 ` Marcel Ventosa 1 sibling, 0 replies; 838+ messages in thread From: Marcel Ventosa @ 2020-10-18 2:58 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Thibaut Verron, Richard Stallman, Jean Louis, emacs-devel The original discussion involved the following: - Richard suggested a survey with open questions (There is no need to mention any repository in an open question). - MELPA contains packages that promote proprietary software. - If MELPA *had* to be mentioned in the survey, Richard suggested mentioning it with a disclaimer to abide by GNU policy and warn unsuspecting survey takers. With respect, I don't see the point of discussing off-topic tangents or responding to apagogical arguments. P.S. For the record, I never provided examples of proprietary software. On Sat, 17 Oct 2020 22:51:54 +0300 Dmitry Gutov <dgutov@yandex.ru> wrote: > On 17.10.2020 14:40, Marcel Ventosa wrote: > > >> So we won't suggest ELPA as an option either? What about the users > >> who don't know the difference? MELPA is also an ELPA, after all (as > >> in "Emacs Lisp Package Archive"). > > > > Is it a survey then or is it an opportunity to "educate/advertise?" > > > > Somebody else already explained that a poll where only one of the > options is written and others are free-form will be biased anyway. > > >>> I > >>> would think it should be guided, for the most part, by what the > >>> people putting their time into it want to create, within the > >>> principles of the philosophy of the project and its goals. > > > >> It's not a painting or a novel. It's a software project, with > >> certain expectations of practicality. > > > > Are you claiming Emacs is not practical? > > It's less practical than it could be. > > And you seem to be claiming it doesn't need to. > > >>> If they are not, Emacs makes it quite simple to implement changes > >>> for personal "improvements". I have written functions that serve > >>> me personally and change the behavior of Emacs to suit my needs. > >>> There are limits to what I can do, which could be pushed if I > >>> dedicated a greater effort to do so. How is that unfair? > > > >> You're veering the discussion off to the side for some reason. > > > > I'm explaining how easy it is to modify Emacs to suit particular > > needs, and listing the possibilities that already exist for doing > > so. > > Why are you explaining that to an Emacs developer? > > >> But if we're talking of "unfair", releasing Emacs under GPL, > >> enabling such excellent extensibility that multiple communities > >> spring up over years, ones brimming with creativity and people > >> dedicating years of their spare time to the extensions, and then > >> badmouthing them from afar as though they violated some existing > >> contract (social or legal), *that* is unfair. > > > > It is GNU policy not to promote or encourage proprietary software. > > Those are not objective words, but a matter of opinion, to say the > least. > > > To > > the extent that any community does so, GNU must not promote or > > encourage that community. > > You are saying that, by mentioning MELPA is the poll, GNU would > promote MELPA. Right? > > Are you promoting proprietary software by saying the phrase > "proprietary software", over and over, on this mailing list? And even > giving examples sometimes. > > > I fail to see what injustice has been perpetrated on the > > MELPA maintainers here, or how they have been badmouthed. > > Saying "MELPA promotes proprietary software" is like saying that GNU > project promotes, I don't know... late-stage capitalism. Just by the > virtue of being mostly developed in a capitalist country, and by > being useful to many organizations participating in capitalist > economies with high degree of inequality. > > Or that it promotes proprietary software by providing support for > some of it. > > Let's disregard its mission, and all virtues and accomplishments, > shall we? ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 14:33 ` Marcel Ventosa ` (2 preceding siblings ...) 2020-10-16 19:08 ` Dmitry Gutov @ 2020-10-16 19:22 ` Jean Louis 3 siblings, 0 replies; 838+ messages in thread From: Jean Louis @ 2020-10-16 19:22 UTC (permalink / raw) To: Marcel Ventosa Cc: emacs-devel, Richard Stallman, Thibaut Verron, Dmitry Gutov * Marcel Ventosa <mve1@runbox.com> [2020-10-16 17:33]: > > I don't recall any single change in Emacs' behavior that resulted > > from an external poll or survey. > > Why should Emacs development be guided by (external) survey results? I > would think it should be guided, for the most part, by what the people > putting their time into it want to create, within the principles of the > philosophy of the project and its goals. Also, anyone can suggest > changes and convince the maintainers that these changes are in the best > interest of the project (and contribute the actual changes if they are > accepted). There is nothing wrong for Emacs developers to look into external survey results, to look into comments people are making around various websites, or any outside data, it is finally their creation, there is nothing wrong into looking into survey results, especially if something useful can be created out of it. There shall be even a checklist to look for bugs in various GNU/Linux distributions where users report various bugs, as such could be maybe overseen if not reported upstream, then to look into whatever data is available externally, that is all fine. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 14:04 ` Dmitry Gutov 2020-10-16 14:33 ` Marcel Ventosa @ 2020-10-16 19:17 ` Jean Louis 2020-10-16 19:36 ` Dmitry Gutov 1 sibling, 1 reply; 838+ messages in thread From: Jean Louis @ 2020-10-16 19:17 UTC (permalink / raw) To: Dmitry Gutov Cc: Marcel Ventosa, Richard Stallman, Thibaut Verron, emacs-devel * Dmitry Gutov <dgutov@yandex.ru> [2020-10-16 17:04]: > And picking on 2-3 "ideologically impure" packages (out of several > thousands!) that are distributed on MELPA is counter-productive. There are few only until letter C, and I did not finish letter C, so I guess there are many, number of downloads in thousands, that is pretty devastating for a repository that is supposed to push free software, in other words, repository is hypocritical. Would it be only hypocritical without influencing users, fine, but it does influence thousands of users and is promoting the download number of software that guides users to non-free software, so that is how it becomes not ethical. You know, in many countries, government is working for people, but from time to time, they will simply kill someone. You get the idea? Is it counter productive to complain on few killed? > > I don't understand how refusing to draw attention to a repository that > > recommends proprietary software turns anyone into the "thought police". > > It's a *survey*! A survey is supposed to gather insight into what users do, > and what they need. Not shape their behavior. Every professional public survey is there to shape their behavior. You do the survey, you find out what public wants, then you make changes in such manner to influence public to gather more around you. All professional surveys are like that. There is nothing wrong with it. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 19:17 ` Jean Louis @ 2020-10-16 19:36 ` Dmitry Gutov 2020-10-16 19:43 ` Dmitry Gutov 2020-10-16 20:03 ` Jean Louis 0 siblings, 2 replies; 838+ messages in thread From: Dmitry Gutov @ 2020-10-16 19:36 UTC (permalink / raw) To: Jean Louis; +Cc: Marcel Ventosa, Richard Stallman, Thibaut Verron, emacs-devel On 16.10.2020 22:17, Jean Louis wrote: > * Dmitry Gutov <dgutov@yandex.ru> [2020-10-16 17:04]: >> And picking on 2-3 "ideologically impure" packages (out of several >> thousands!) that are distributed on MELPA is counter-productive. > > There are few only until letter C, and I did not finish letter C, so I > guess there are many, number of downloads in thousands, that is pretty Not too long ago I went through the first 100 or so most popular packages on MELPA (at the request of RMS), and like 2-3 of them encouraged or required proprietary software to be installed. Ones near the tail of that 100, when sorted by popularity. It's a minor fraction. > devastating for a repository that is supposed to push free software, > in other words, repository is hypocritical. No, it's supposed to _publish_ free software. > Would it be only hypocritical without influencing users, fine, but it > does influence thousands of users and is promoting the download number > of software that guides users to non-free software, so that is how it > becomes not ethical. Some time ago I read an essay about infighting in the political left community. How a lot of members choose to find and attack progressively personal character faults in their fellow activists, instead of working together and presenting a united front against the capitalist oppressors. You can draw an easy parallel to the software community and the struggle vs proprietary software. > You know, in many countries, government is working for people, but > from time to time, they will simply kill someone. You get the idea? Is > it counter productive to complain on few killed? It's counter-productive to quarrel with your neighbor about unmowed lawns or whatever when the government is doing the killing. >>> I don't understand how refusing to draw attention to a repository that >>> recommends proprietary software turns anyone into the "thought police". >> >> It's a *survey*! A survey is supposed to gather insight into what users do, >> and what they need. Not shape their behavior. > > Every professional public survey is there to shape their behavior. You > do the survey, you find out what public wants, then you make changes > in such manner to influence public to gather more around you. That's what I said. But it doesn't work as well if the survey is biased from the outset. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 19:36 ` Dmitry Gutov @ 2020-10-16 19:43 ` Dmitry Gutov 2020-10-16 20:03 ` Jean Louis 1 sibling, 0 replies; 838+ messages in thread From: Dmitry Gutov @ 2020-10-16 19:43 UTC (permalink / raw) To: Jean Louis; +Cc: Marcel Ventosa, Richard Stallman, Thibaut Verron, emacs-devel Sorry, On 16.10.2020 22:36, Dmitry Gutov wrote: > Not too long ago I went through the first 100 or so most popular ^ 1000 > packages on MELPA ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 19:36 ` Dmitry Gutov 2020-10-16 19:43 ` Dmitry Gutov @ 2020-10-16 20:03 ` Jean Louis 2020-10-16 20:29 ` Thibaut Verron 2020-10-16 21:10 ` Dmitry Gutov 1 sibling, 2 replies; 838+ messages in thread From: Jean Louis @ 2020-10-16 20:03 UTC (permalink / raw) To: Dmitry Gutov Cc: Marcel Ventosa, Richard Stallman, Thibaut Verron, emacs-devel * Dmitry Gutov <dgutov@yandex.ru> [2020-10-16 22:37]: > > devastating for a repository that is supposed to push free software, > > in other words, repository is hypocritical. > > No, it's supposed to _publish_ free software. Alright, I just think of policies. Imagine if free software repository would publish only software that wraps around proprietary software, would that be free? So it is matter of policy. For same reaso Debian GNU/Linux cannot be said to be free, at many pages they guide users to include non-free software, unspoken from Archlinux or other distributions. So it is just matter of endorsement. > > Would it be only hypocritical without influencing users, fine, but it > > does influence thousands of users and is promoting the download number > > of software that guides users to non-free software, so that is how it > > becomes not ethical. > > Some time ago I read an essay about infighting in the political left > community. How a lot of members choose to find and attack progressively > personal character faults in their fellow activists, instead of working > together and presenting a united front against the capitalist oppressors. > > You can draw an easy parallel to the software community and the struggle vs > proprietary software. That question is best answered here: https://github.com/melpa/melpa/issues/7185 So that is request to remove those packages and to make a policy not to include such, that is best way to raise the issue and see if we are truly together in free software promotion. > But it doesn't work as well if the survey is biased from the outset. But survey is "biased" (opinionated) from beginning, it was not published on emacs-devel initially, it was published on Reddit initially and I am sure there are reasons for initiator for the survey, those reasons may be that whay you call biased, I call it opinions, but not necessarily unjust opinions (biased). It is better to say opinionated. Again I see nothing wrong against opinionated surveys as what Emacs teaches its users it to become opinionated, they constantly try to improve their configurations, themese, etc. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 20:03 ` Jean Louis @ 2020-10-16 20:29 ` Thibaut Verron 2020-10-16 20:40 ` Jean Louis 2020-10-17 4:19 ` Richard Stallman 2020-10-16 21:10 ` Dmitry Gutov 1 sibling, 2 replies; 838+ messages in thread From: Thibaut Verron @ 2020-10-16 20:29 UTC (permalink / raw) To: Jean Louis; +Cc: Marcel Ventosa, emacs-devel, Richard Stallman, Dmitry Gutov > Alright, I just think of policies. > > Imagine if free software repository would publish only software that > wraps around proprietary software, would that be free? So it is matter > of policy. Incidentally, if Melpa agrees to your request to remove all packages wrapping around proprietary software, it will be a matter of days before such a repository appears. And yes, it would be free, in my opinion. Because users are free to use Emacs in whichever way they want, including in workflows involving non-free software. > For same reaso Debian GNU/Linux cannot be said to be free, at many > pages they guide users to include non-free software, unspoken from > Archlinux or other distributions. This is, again, a matter of opinion. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 20:29 ` Thibaut Verron @ 2020-10-16 20:40 ` Jean Louis 2020-10-17 4:19 ` Richard Stallman 1 sibling, 0 replies; 838+ messages in thread From: Jean Louis @ 2020-10-16 20:40 UTC (permalink / raw) To: Thibaut Verron Cc: Marcel Ventosa, emacs-devel, Richard Stallman, Dmitry Gutov * Thibaut Verron <thibaut.verron@gmail.com> [2020-10-16 23:30]: > > For same reaso Debian GNU/Linux cannot be said to be free, at many > > pages they guide users to include non-free software, unspoken from > > Archlinux or other distributions. > > This is, again, a matter of opinion. It may be "user repository" but it is still advertised through Archlinux: https://aur.archlinux.org/packages/?K=proprietary&SB= It is hypocritical to say that one repository link or directory is official and other one is not official, of both of them are distributed from the same official domain "archlinux.org" See here: https://bbs.archlinux.org/viewtopic.php?pid=1924794#p1924794 > Arch does believe in free software -- we provide a free software operating system which doesn't depend on proprietary software to run. Any (well, most) Linux operating system could do that. > We *also* believe people have the right to use proprietary software addons if they want to, and in some cases we make it exceedingly easy for them to opt in. > All we care about is that we have written permission from the proprietary owners to do so, and we distribute these in /usr/share/licenses/ along with marking the package as possessing a "custom" license: > https://github.com/archlinux/svntogit-c … ISSION.eml > https://github.com/archlinux/svntogit-c … ibute.mbox Now for Debian: https://duckduckgo.com/?q=site%3Adebian.org+enable+non-free&t=ffab&ia=web Quote from some of links: > "Make sure to enable contrib and non-free in the /etc/apt/sources.list line" > "In some cases the installer detects the need for non-free firmware > and prompts the user to make the firmware available to the installer > to complete the installation. This can happen, for example, with > wireless network cards which often require non-free firmware to > function" > "First you have to enable the non-free repository in APT's > sources.list file: see Section 6.1, "Filling in the sources.list File" > for details about this file. Many firmware are proprietary and are > thus located in this repository." Debian directly instructs users to enable non-free repositories. So that opinion of mine is quite factual. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 20:29 ` Thibaut Verron 2020-10-16 20:40 ` Jean Louis @ 2020-10-17 4:19 ` Richard Stallman 2020-10-17 5:02 ` Thibaut Verron ` (2 more replies) 1 sibling, 3 replies; 838+ messages in thread From: Richard Stallman @ 2020-10-17 4:19 UTC (permalink / raw) To: thibaut.verron; +Cc: mve1, dgutov, bugs, emacs-devel [[[ 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. ]]] > > Imagine if free software repository would publish only software that > > wraps around proprietary software, would that be free? So it is matter > > of policy. > Incidentally, if Melpa agrees to your request to remove all packages > wrapping around proprietary software, it will be a matter of days > before such a repository appears. To move all the recommendations of nonfree software OUT of Melpa, and into some other obscure new repository, would be a great step forward! It would eliminate one of the reasons why currently we must not inform people about Melpa. If Melpa then were to eliminates the other reason, reported here today, that it requires use of nonfree software to contribute packages, and commits to stay on this path, that could make it possible for us to recommend Melpa! That would be a big change for the better. > And yes, it would be free, in my opinion. Because users are free to > use Emacs in whichever way they want, including in workflows involving > non-free software. Indeed they are, but you've changed to a different question. > > For same reaso Debian GNU/Linux cannot be said to be free, at many > > pages they guide users to include non-free software, unspoken from > > Archlinux or other distributions. > This is, again, a matter of opinion. You're entitled to your opinion, but this list is for discussing what to do in the GNU Project. In the GNU Project, this question is a matter of stated policy. In https://gnu.org/distros/free-system-distribution-guidelines.html, our criteria say this is not acceptable. That is why we classify Debian as nonfree in https://gnu.org/distros/common-distros.html. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-17 4:19 ` Richard Stallman @ 2020-10-17 5:02 ` Thibaut Verron 2020-10-17 13:13 ` Stefan Monnier 2020-10-17 5:07 ` Jean Louis 2020-10-17 12:34 ` Andy Moreton 2 siblings, 1 reply; 838+ messages in thread From: Thibaut Verron @ 2020-10-17 5:02 UTC (permalink / raw) To: Richard Stallman; +Cc: mve1, Dmitry Gutov, Jean Louis, emacs-devel Le sam. 17 oct. 2020 à 06:19, Richard Stallman <rms@gnu.org> a écrit : > > [[[ 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. ]]] > > > > Imagine if free software repository would publish only software that > > > wraps around proprietary software, would that be free? So it is matter > > > of policy. > > > Incidentally, if Melpa agrees to your request to remove all packages > > wrapping around proprietary software, it will be a matter of days > > before such a repository appears. > > To move all the recommendations of nonfree software > OUT of Melpa, and into some other obscure new repository, > would be a great step forward! It would eliminate one > of the reasons why currently we must not inform people about Melpa. It would not be obscure for very long, because most of the Emacs blogs would not refrain from advertising it. Moving the free packages to a GNU-managed non-GNU Elpa is imo a better way to achieve such separation between free and non-free community packages. > > > And yes, it would be free, in my opinion. Because users are free to > > use Emacs in whichever way they want, including in workflows involving > > non-free software. > > Indeed they are, but you've changed to a different question. > I don't think I did. Making it as hard as possible for users to find packages necessary for their workflow is acting against that freedom, in my opinion. > > > > For same reaso Debian GNU/Linux cannot be said to be free, at many > > > pages they guide users to include non-free software, unspoken from > > > Archlinux or other distributions. > > > This is, again, a matter of opinion. > > You're entitled to your opinion, but this list is for discussing what > to do in the GNU Project. In the GNU Project, this question is a > matter of stated policy. > > In https://gnu.org/distros/free-system-distribution-guidelines.html, > our criteria say this is not acceptable. That is why we classify > Debian as nonfree in https://gnu.org/distros/common-distros.html. As well as, apparently, all other major GNU/Linux distributions. I wonder how many users would know about the GNU project if not for those non-free distributions. And there seems to have been no problem in publishing that list on gnu.org, even though it names a number of non-free options. Why can't the same be done with Melpa ? ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-17 5:02 ` Thibaut Verron @ 2020-10-17 13:13 ` Stefan Monnier 0 siblings, 0 replies; 838+ messages in thread From: Stefan Monnier @ 2020-10-17 13:13 UTC (permalink / raw) To: Thibaut Verron Cc: mve1, emacs-devel, Richard Stallman, Jean Louis, Dmitry Gutov >> To move all the recommendations of nonfree software >> OUT of Melpa, and into some other obscure new repository, >> would be a great step forward! It would eliminate one >> of the reasons why currently we must not inform people about Melpa. > It would not be obscure for very long, because most of the Emacs blogs > would not refrain from advertising it. AFAIK they make up a very small fraction of the MELPA archive, both in terms of number of packages and in terms of popularity of those packages. Of course, those people who want those packages would still find a way to get to them, but that's OK, we're not in the business of disallowing people from shackling themselves to proprietary software. Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-17 4:19 ` Richard Stallman 2020-10-17 5:02 ` Thibaut Verron @ 2020-10-17 5:07 ` Jean Louis 2020-10-17 12:34 ` Andy Moreton 2 siblings, 0 replies; 838+ messages in thread From: Jean Louis @ 2020-10-17 5:07 UTC (permalink / raw) To: Richard Stallman; +Cc: mve1, dgutov, thibaut.verron, emacs-devel * Richard Stallman <rms@gnu.org> [2020-10-17 07:19]: > [[[ 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. ]]] > > > > Imagine if free software repository would publish only software that > > > wraps around proprietary software, would that be free? So it is matter > > > of policy. > > > Incidentally, if Melpa agrees to your request to remove all packages > > wrapping around proprietary software, it will be a matter of days > > before such a repository appears. > > To move all the recommendations of nonfree software > OUT of Melpa, and into some other obscure new repository, > would be a great step forward! It would eliminate one > of the reasons why currently we must not inform people about Melpa. Author said yesterday or was it today, they are not interested to impose a policy to remove questionable packages, issue is closed, there is no discussion about that at MELPA. Issue was: To remove packages that guide users to non-free software or wrap around proprietary software #7185 Answer by purcell maintainer was: The MELPA maintainers already take some care to host only Emacs Lisp packages with GPL or GPL-compatible licences. We are not aware of any packages which are in legal violation of this compatibility, including the packages you mention. Beyond that, we respectfully decline to institute a policy as proposed, and wish you all the best. > If Melpa then were to eliminates the other reason, reported here > today, that it requires use of nonfree software to contribute > packages, and commits to stay on this path, that could make it > possible for us to recommend Melpa! That would be a big > change for the better. I don't think so, the answer is clear, they will allow GPLG or GPL-compatible licenses without looking into purpose of the package, such open policy allows inclusion of new packages that are meant only to use, control proprietary software, or insecure remote websites, or similar. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-17 4:19 ` Richard Stallman 2020-10-17 5:02 ` Thibaut Verron 2020-10-17 5:07 ` Jean Louis @ 2020-10-17 12:34 ` Andy Moreton 2020-10-17 15:56 ` Alfred M. Szmidt 2 siblings, 1 reply; 838+ messages in thread From: Andy Moreton @ 2020-10-17 12:34 UTC (permalink / raw) To: emacs-devel On Sat 17 Oct 2020, Richard Stallman wrote: > You're entitled to your opinion, but this list is for discussing what > to do in the GNU Project. In the GNU Project, this question is a > matter of stated policy. No. This list is for discussion of emacs development. GNU policy is related but largely off topic. Please use a more appropriate advocacy list for policy discussion. AndyM ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-17 12:34 ` Andy Moreton @ 2020-10-17 15:56 ` Alfred M. Szmidt 2020-10-17 16:13 ` Eli Zaretskii 0 siblings, 1 reply; 838+ messages in thread From: Alfred M. Szmidt @ 2020-10-17 15:56 UTC (permalink / raw) To: Andy Moreton; +Cc: emacs-devel On Sat 17 Oct 2020, Richard Stallman wrote: > You're entitled to your opinion, but this list is for discussing what > to do in the GNU Project. In the GNU Project, this question is a > matter of stated policy. No. This list is for discussion of emacs development. GNU policy is related but largely off topic. When it comes to clarifying misconceptioons, or trying to clearing up policies that are relevant for the GNU project or a GNU project, then it is certainly on-topic. This list is after all part of the GNU project, and as such it follows the policies of the GNU project. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-17 15:56 ` Alfred M. Szmidt @ 2020-10-17 16:13 ` Eli Zaretskii 2020-10-17 21:38 ` Alfred M. Szmidt 2020-10-18 4:13 ` Richard Stallman 0 siblings, 2 replies; 838+ messages in thread From: Eli Zaretskii @ 2020-10-17 16:13 UTC (permalink / raw) To: Alfred M. Szmidt; +Cc: andrewjmoreton, emacs-devel > From: ams@gnu.org (Alfred M. Szmidt) > Date: Sat, 17 Oct 2020 11:56:26 -0400 > Cc: emacs-devel@gnu.org > > On Sat 17 Oct 2020, Richard Stallman wrote: > > You're entitled to your opinion, but this list is for discussing what > > to do in the GNU Project. In the GNU Project, this question is a > > matter of stated policy. > > No. This list is for discussion of emacs development. GNU policy is > related but largely off topic. > > When it comes to clarifying misconceptioons, or trying to clearing up > policies that are relevant for the GNU project or a GNU project, then > it is certainly on-topic. This list is after all part of the GNU > project, and as such it follows the policies of the GNU project. Be it as it may, the signal-to-noise ratio on this list is lately very low, which is a pity, and IME a clear sign that too many discussions are only very marginally on-topic, at best. Since these discussions never lead to any useful or even practical results, I wish people could stop trying convince one another on such "on-topic" subjects. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-17 16:13 ` Eli Zaretskii @ 2020-10-17 21:38 ` Alfred M. Szmidt 2020-10-18 2:40 ` Eli Zaretskii 2020-10-18 4:13 ` Richard Stallman 1 sibling, 1 reply; 838+ messages in thread From: Alfred M. Szmidt @ 2020-10-17 21:38 UTC (permalink / raw) To: Eli Zaretskii; +Cc: andrewjmoreton, emacs-devel > > You're entitled to your opinion, but this list is for discussing what > > to do in the GNU Project. In the GNU Project, this question is a > > matter of stated policy. > > No. This list is for discussion of emacs development. GNU policy is > related but largely off topic. > > When it comes to clarifying misconceptioons, or trying to clearing up > policies that are relevant for the GNU project or a GNU project, then > it is certainly on-topic. This list is after all part of the GNU > project, and as such it follows the policies of the GNU project. Be it as it may, the signal-to-noise ratio on this list is lately very low, which is a pity, and IME a clear sign that too many discussions are only very marginally on-topic, at best. That is true, but there are better ways to steer discussions to more Emacs related topics than to claim that GNU policies are off-topic for a GNU project. In this particular case, Richard was fully on-topic and worth noting.. Since these discussions never lead to any useful or even practical results, I wish people could stop trying convince one another on such "on-topic" subjects. I am not sure what discussion you are refering to, the policies for GNU are written down and are quite practical. There is little to discuss about them as well. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-17 21:38 ` Alfred M. Szmidt @ 2020-10-18 2:40 ` Eli Zaretskii 0 siblings, 0 replies; 838+ messages in thread From: Eli Zaretskii @ 2020-10-18 2:40 UTC (permalink / raw) To: Alfred M. Szmidt; +Cc: andrewjmoreton, emacs-devel > From: ams@gnu.org (Alfred M. Szmidt) > CC: andrewjmoreton@gmail.com, emacs-devel@gnu.org > Date: Sat, 17 Oct 2020 17:38:54 -0400 > > Since these discussions never lead to any useful or even practical > results, I wish people could stop trying convince one another on such > "on-topic" subjects. > > I am not sure what discussion you are refering to, the policies for > GNU are written down and are quite practical. There is little to > discuss about them as well. Exactly. So why waste everyone''s time by discussing them? ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-17 16:13 ` Eli Zaretskii 2020-10-17 21:38 ` Alfred M. Szmidt @ 2020-10-18 4:13 ` Richard Stallman 2020-10-18 15:20 ` Alfred M. Szmidt 1 sibling, 1 reply; 838+ messages in thread From: Richard Stallman @ 2020-10-18 4:13 UTC (permalink / raw) To: Eli Zaretskii, ams; +Cc: andrewjmoreton, emacs-devel [[[ 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. ]]] > Since these discussions never lead to any useful or even practical > results, I wish people could stop trying convince one another on such > "on-topic" subjects. People shouldn't bring up abstract questions here which are not relevant to Emacs development decisions. Please, everyone, don't discuss such topics here. But often nontechnical questions of our values and goals come up precisely because they are pertinent to the paqctical decision at hand. Then these questions are on-topic for the list. But they are not questions of personal opinion if the GNU Project has a position on them. When people state assertions which conflict with GNU Project policies or principles, we need to present an authoritative response. I will do that eventually, but I am typically more than a day behind. Alfred knows our policies and principles, and he often gets there long before me. That is useful. But often his messages don't state that they are authoritative. So people may think he is just stating a personal opinion, and argue. Alfred, when you state GNU Project policies and principles, perhaps you should say explicitly that "This is the GNU Project's position?" Also, could you refer to published statements of same? That could make your statements more effective. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-18 4:13 ` Richard Stallman @ 2020-10-18 15:20 ` Alfred M. Szmidt 0 siblings, 0 replies; 838+ messages in thread From: Alfred M. Szmidt @ 2020-10-18 15:20 UTC (permalink / raw) To: rms; +Cc: eliz, andrewjmoreton, emacs-devel Alfred, when you state GNU Project policies and principles, perhaps you should say explicitly that "This is the GNU Project's position?" Also, could you refer to published statements of same? That could make your statements more effective. Those are good points, I'll try to keep them in mind -- I'm just slightly lazy at times. Thank you. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 20:03 ` Jean Louis 2020-10-16 20:29 ` Thibaut Verron @ 2020-10-16 21:10 ` Dmitry Gutov 2020-10-16 22:02 ` Jean Louis 1 sibling, 1 reply; 838+ messages in thread From: Dmitry Gutov @ 2020-10-16 21:10 UTC (permalink / raw) To: Jean Louis; +Cc: Marcel Ventosa, Richard Stallman, Thibaut Verron, emacs-devel On 16.10.2020 23:03, Jean Louis wrote: > * Dmitry Gutov <dgutov@yandex.ru> [2020-10-16 22:37]: >>> devastating for a repository that is supposed to push free software, >>> in other words, repository is hypocritical. >> >> No, it's supposed to _publish_ free software. > > Alright, I just think of policies. As do I. > Imagine if free software repository would publish only software that > wraps around proprietary software, would that be free? So it is matter > of policy. If it had a policy to only publish wrappers for proprietary software, it would be a "repository for wrappers of proprietary software". But a repository which has a policy to only publish free software, is a repository for free software. > For same reaso Debian GNU/Linux cannot be said to be free, at many > pages they guide users to include non-free software, unspoken from > Archlinux or other distributions. I don't think that's how it works. If the software is free, we call it free. >>> Would it be only hypocritical without influencing users, fine, but it >>> does influence thousands of users and is promoting the download number >>> of software that guides users to non-free software, so that is how it >>> becomes not ethical. >> >> Some time ago I read an essay about infighting in the political left >> community. How a lot of members choose to find and attack progressively >> personal character faults in their fellow activists, instead of working >> together and presenting a united front against the capitalist oppressors. >> >> You can draw an easy parallel to the software community and the struggle vs >> proprietary software. > > That question is best answered here: > https://github.com/melpa/melpa/issues/7185 Good example of infighting. Not an answer. It would be a lot more polite to include your actual name in the account description, by the way. Calling yourself "GNU Support" looks like an overreach. > So that is request to remove those packages and to make a policy not > to include such, that is best way to raise the issue and see if we are > truly together in free software promotion. "No true Scotsman" >> But it doesn't work as well if the survey is biased from the outset. > > But survey is "biased" (opinionated) from beginning, it was not published on > emacs-devel initially, it was published on Reddit initially and I am That doesn't necessarily make it biased. That argument is weak. > sure there are reasons for initiator for the survey, those reasons may > be that whay you call biased, I call it opinions, but not necessarily > unjust opinions (biased). Removing a known popular option from the answers makes a survey biased. > It is better to say opinionated. Are we reinventing English words now? ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 21:10 ` Dmitry Gutov @ 2020-10-16 22:02 ` Jean Louis 0 siblings, 0 replies; 838+ messages in thread From: Jean Louis @ 2020-10-16 22:02 UTC (permalink / raw) To: Dmitry Gutov Cc: Marcel Ventosa, Richard Stallman, Thibaut Verron, emacs-devel * Dmitry Gutov <dgutov@yandex.ru> [2020-10-17 00:10]: > If it had a policy to only publish wrappers for proprietary software, it > would be a "repository for wrappers of proprietary software". > > But a repository which has a policy to only publish free software, is a > repository for free software. > > > For same reaso Debian GNU/Linux cannot be said to be free, at many > > pages they guide users to include non-free software, unspoken from > > Archlinux or other distributions. > > I don't think that's how it works. If the software is free, we call > it free. Maybe I have expressed myself wrongly. It is not a free software repository if it publishes non-free software, it is mixture of the two. So MELPA is also mixture of software that is truly free software and that other group of software which has the only purpose to interact with non-free software, more or less promotional tool in free software community to capture some users for proprietary software, or pathetic way to promote proprietary software. > > That question is best answered here: > > https://github.com/melpa/melpa/issues/7185 > > Good example of infighting. Not an answer. Question about MELPA will be answered there. It is best answered there, we will see if MELPA authors do like idea or maybe like Archlinux do not mind if some packages are steering users to access proprietary software. > It would be a lot more polite to include your actual name in the account > description, by the way. Calling yourself "GNU Support" looks like an > overreach. I could not register the really intended domain support.gnu, so it is other way around. > > sure there are reasons for initiator for the survey, those reasons may > > be that whay you call biased, I call it opinions, but not necessarily > > unjust opinions (biased). > > Removing a known popular option from the answers makes a survey biased. > > > It is better to say opinionated. > > Are we reinventing English words now? Maybe you are native English speaker, I am not. So I am consulting dictionaries for fine differences, like Wordnut. biased * Overview of verb bias The verb bias has 2 senses (no senses from tagged texts) 1. bias -- (influence in an unfair way; "you are biasing my choice by telling me yours") 2. bias, predetermine -- (cause to be biased) while opinionated: * Overview of adj opinionated The adj opinionated has 1 sense (first 1 from tagged texts) 1. (1) opinionated, opinionative, self-opinionated -- (obstinate in your opinions) * Overview of verb obstinate The verb obstinate has 1 sense (no senses from tagged texts) 1. obstinate -- (persist stubbornly; "he obstinates himself against all rational arguments") GNU project is obstinated stubbornly not to promote proprietary software and cannot endorse software repositories that do so. It is not biased because the stubborn opinion is not equal to being influenced in unfair way, quite opposite it is being influenced in just way. Free software is good because it helps the user to control its own computing. That package that is made for Emacs can be issued under GNU GPL, yet with the only reason to circumvent the purpose of GPL so that proprietary software makers can control such user, then such software repository is not ethical and questions about such repository are not relevant for GNU Emacs development, as it is already known that MELPA is not endorsed for the discussed reasons. In fact, how much we have written here, instead why you did not write to MELPA on that issue and ask them to remove those few packages? ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 13:45 ` Marcel Ventosa 2020-10-16 14:04 ` Dmitry Gutov @ 2020-10-16 19:08 ` Jean Louis 2020-10-16 19:47 ` Drew Adams 1 sibling, 1 reply; 838+ messages in thread From: Jean Louis @ 2020-10-16 19:08 UTC (permalink / raw) To: Marcel Ventosa Cc: emacs-devel, Richard Stallman, Thibaut Verron, Dmitry Gutov * Marcel Ventosa <mve1@runbox.com> [2020-10-16 16:45]: > I've noticed a trend of speaking about Emacs and other free software > projects as if they were "commodities" and "products," but as I see > them, it is precisely because they are community driven projects that > they are not "commodities" or "products". My opinion is that Emacs is a product, and it is software commodity as well. Definitions from Wordnet here below like 1. maybe 2, and 5 do apply, it is product in few definitions. It has been sold for money in past through GNU project, which is totally alright, and is probably sold even today, I just don't know where. If product is community driven, it still remains product. There is nothing wrong with that word or calling it a product, because it is, major and significant free software product made by Emacs developers. * Overview of noun product The noun product has 6 senses (first 4 from tagged texts) 1. (52) merchandise, ware, product -- (commodities offered for sale; "good business depends on having good merchandise"; "that store offers a variety of products") 2. (25) product, production -- (an artifact that has been created by someone or some process; "they improve their product every year"; "they export most of their agricultural production") 3. (8) product, mathematical product -- (a quantity obtained by multiplication; "the product of 2 and 3 is 6") 4. (2) product -- (a chemical substance formed as a result of a chemical reaction; "a product of lime and nitric acid") 5. product -- (a consequence of someone's efforts or of a particular set of circumstances; "skill is the product of hours of practice"; "his reaction was the product of hunger and fatigue") 6. intersection, product, Cartesian product -- (the set of elements common to two or more sets; "the set of red hats is the intersection of the set of hats and the set of red things") > > I think it's both insulting to its developers, and stinks of thought > > police. Far from the idea of user freedom I hope to expect from > > GNU and FSF. It is not important if somebody cals it a product, what is important is if the distributor or seller provides license with it and gives same rights to its buyers or users. > I don't understand how refusing to draw attention to a repository that > recommends proprietary software turns anyone into the "thought > police". It is "proprietary thought police" and there is nothing wrong with it. Even the thought police will not say there is anything wrong with thought police. :-p So when we distribute free software, we tend to speak out against proprietary software being distributed or promoted together with free software. In that sense we are policing various free software repositories and speaking out publicly against, or denouncing, the inclusion, usage, and dangers of proprietary software. So, next time somebody thinks of proprietary software, just remember, we are watching... slap on fingers. > In fact, one of the most worrying aspects of this survey idea, as I see > it, is the suggested use of non-free Javascript to implement it. Idea about Emacs survey is alright, only that awareness of free software has yet to arrive to those who initiated the survey, as they proposed using Google Spreadsheet and similar, which would in fact put Emacs users at direct risk. ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Proposal for an Emacs User Survey 2020-10-16 19:08 ` Jean Louis @ 2020-10-16 19:47 ` Drew Adams 2020-10-16 20:15 ` Jean Louis 0 siblings, 1 reply; 838+ messages in thread From: Drew Adams @ 2020-10-16 19:47 UTC (permalink / raw) To: Jean Louis, Marcel Ventosa Cc: Dmitry Gutov, Richard Stallman, Thibaut Verron, emacs-devel > My opinion is that Emacs is a product, Certainly. It is produced, by labor. It doesn't fall from the sky. > and it is software commodity as well. No, not really. A commodity is something that's produced for sale. And a common connation of "commodity" is something that is run-of-the-mill, as opposed to specially produced (even if for sale). > It has been sold for money in past through GNU > project, which is totally alright, and is probably > sold even today, I just don't know where. GNU Emacs is not produced for sale, and it's not, in general, sold. Generally, it's not a commodity. If someone sells GNU Emacs then yes, in that case it could be said to be a commodity. But as a general characterization that's not true: Emacs is not produced for sale. That's not why it's produced, and selling it is not typical. In particular, because in its usual form it's also provided for free (no sale). If someone sells it, they likely sell some specialized version of it, or they sell something else along with it, such as support services. Citing synonyms for "product" doesn't suffice, as a product can be, and most often is (in a market society), a commodity. Synonyms describe usage, and they're often given liberally, intended to include more than draw distinctions. Why? Because people often look to a thesaurus for a word that means something similar. Often they're looking for a given word that they can't quite think of. Whether the word they're looking for really means the same thing, or very close to it, doesn't always matter. The point is to help them find that related word. One shouldn't look to a thesaurus imagining that a list of synonyms it provides are really exact synonyms, or even very close. (And no two words are ever precisely synonymous. Every word has its own connotations.) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 19:47 ` Drew Adams @ 2020-10-16 20:15 ` Jean Louis 2020-10-16 20:59 ` Drew Adams 2020-10-17 4:19 ` Richard Stallman 0 siblings, 2 replies; 838+ messages in thread From: Jean Louis @ 2020-10-16 20:15 UTC (permalink / raw) To: Drew Adams Cc: Marcel Ventosa, Dmitry Gutov, Richard Stallman, Thibaut Verron, emacs-devel * Drew Adams <drew.adams@oracle.com> [2020-10-16 22:48]: > > and it is software commodity as well. > > No, not really. A commodity is something that's > produced for sale. Emacs have been sold and can be sold today, thus it is commodity by definition. > And a common connation of "commodity" is something > that is run-of-the-mill, as opposed to specially > produced (even if for sale). > > > It has been sold for money in past through GNU > > project, which is totally alright, and is probably > > sold even today, I just don't know where. > > GNU Emacs is not produced for sale, and it's not, > in general, sold. Generally, it's not a commodity. > > If someone sells GNU Emacs then yes, in that case > it could be said to be a commodity. > > But as a general characterization that's not true: > Emacs is not produced for sale. That's not why > it's produced, and selling it is not typical. Read: https://www.gnu.org/bulletins/bull24.html If it is typical or not, it was sold and can be sold any time now, there is no problem selling it, so it is still commodity. > In particular, because in its usual form it's also provided for free > (no sale). If someone sells it, they likely sell some specialized > version of it, or they sell something else along with it, such as > support services. Commodity is if traded, so you say, you cannot possibly know who sold it and how many times, and how. So it is impossible to say "it is not commodity" as "it is not sold" as you cannot oversee the planet. In fact it is sold on many GNU/Linux distributions, it is bundled in the GNU/Linux operating systems and sold through commercial distributions, including sold as part of pre-installed systems. When a customer purchases notebook with Windows, customer is in the same time indirectly getting the commodity named Windows, even though did not get any receipt for Windows, but for the notebook (depending of the shop and country). That does not make Windows less commodity in its term. GNU Emacs is pre-installed on many computers, and such installation require some time, effort, money spent for employees, DVDs, Internet, very similar to installation of proprietary software. Customer need not pay directly for the GNU/Linux distribution, but is paying indirectly. ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Proposal for an Emacs User Survey 2020-10-16 20:15 ` Jean Louis @ 2020-10-16 20:59 ` Drew Adams 2020-10-16 21:50 ` Jean Louis 2020-10-17 4:19 ` Richard Stallman 2020-10-17 4:19 ` Richard Stallman 1 sibling, 2 replies; 838+ messages in thread From: Drew Adams @ 2020-10-16 20:59 UTC (permalink / raw) To: Jean Louis Cc: Marcel Ventosa, Dmitry Gutov, Richard Stallman, Thibaut Verron, emacs-devel Maybe reread what I wrote. I said essentially what you're saying. Perhaps we don't disagree at all; dunno. But I distinguished the fact that something that is typically not a commodity (it's offered freely, not sold) _can_ be sold, and so might in that instance be said to be a commodity, is nevertheless not generally a commodity. GNU Emacs is not generally a commodity. (It's always a product. Not every product is a commodity, even in what is generally a "market" economy.) If I paint my car red and green stripes it becomes a red-and-green car. But generally cars aren't red and green. ___ "This division of a product into a useful thing and a value becomes practically important, only when exchange has acquired such an extension that useful articles are produced for the purpose of being exchanged, and their character as values has therefore to be taken into account, beforehand, during production." Commodity production: Products are produced with an eye to being sold. Selling and sales value are taken into account during production - they are part of the character of the product, as commodity. This is _production for exchange_. GNU Emacs is, in general, not that. The notes you write to yourself (in Org mode or whatever) are useful to you, and they weren't written with an eye to being sold. If someone sells those notes, say 100 years from now, they _could_ be considered a commodity as a result of that exchange transaction. But that would be useless hair-splitting. The notes weren't written with an eye to being sold (presumably). That wasn't the purpose for which they were produced. https://web.stanford.edu/~davies/Symbsys100-Spring0708/Marx-Commodity-Fetishism.pdf ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 20:59 ` Drew Adams @ 2020-10-16 21:50 ` Jean Louis 2020-10-17 4:19 ` Richard Stallman 1 sibling, 0 replies; 838+ messages in thread From: Jean Louis @ 2020-10-16 21:50 UTC (permalink / raw) To: Drew Adams Cc: Marcel Ventosa, Dmitry Gutov, Richard Stallman, Thibaut Verron, emacs-devel * Drew Adams <drew.adams@oracle.com> [2020-10-17 00:02]: > GNU Emacs is not generally a commodity. (It's always > a product. Not every product is a commodity, even in > what is generally a "market" economy.) > Commodity production: Products are produced with an eye to being > sold. Selling and sales value are taken into account during > production - they are part of the character of the product, as > commodity. This is _production for exchange_. Not necessarily, products can be natural, produced by nature, collected and sold, it can be still a product and commodity. It need not have a vision to be sold. Example are minerals, example are natural products collected by people and sold, let us say forest mushrooms, it is product and commodity. GNU Emacs was sold by GNU and is (probably) sold today by various Emacs promoters, I guess with books or DVD or similar. If it is sold or not currently does not make it less of a commodity, it could be sold, just as GNU/Linux full OSes can be sold, as nobody forbids it. It is exchangeable for money. Software as a community product and community commodity is exchangeable too, we can see that because it is free software, it moves people to create more free software, share and help others. That is the exchange that Emacs is creating itself. If you consider commodity only that what is exchanged for dollars, consider that before paper currencies there was maybe gold or shelves, or something else, like goats maybe, so at that time you could exchange GNU Emacs for a GNU Goat for example, and it would be just fine commodity without currency. > The notes you write to yourself (in Org mode or whatever) are useful > to you, and they weren't written with an eye to being sold. In particular on my side, I write instruction manuals that I do sell to my clients. Yet I get your point, but see above, products need not have in their creation the purpose to be sold, even though Emacs was sold by GNU project and FSF in past, maybe not today, but it was sold on CDs as source software or bundled with GNU software together, and is sold today by various individuals and companies, sometimes on CD/DVD with the book or instructions, more often in commercial GNU/Linux distributions, it need not be in English language, it can be Japanese language or other countries. GNU/Linux with GNU Emacs is sold here in Uganda, that is what I can say that I have seen practically, you come and you can buy it on DVD all together. So it is part of OS and can be sold with the OS. You probably want to say that it is not common for you to find GNU Emacs being sold, you do not consider it commodity. I am giving you few examples that you see it is indirectly sold, sometimes directly on DVD with books about Emacs, and as part of GNU/Linux distributions, probably other distributions as well. It is probably bundled with many BSD-based OSes as well which are sold as DVD, like shoplinuxonline.com It may not be common to you, as you download it, yet there are people who cannot and who need DVD, and they will buy it. The last big exchange that Emacs is creating is donations to Free Software Foundation and supporting GNU infrastructure and its management. There is nothing wrong calling it a product or commodity. Surely I understand your viewpoint, it is not a common for Emacs to be sold, but it is sold, I gave you few references. It is special commodity of its own kind. Note that there are countries without good Internet access, Internet may be expensive, where DVDs are quite popular in those countries, where software is sold on DVD and not accessible online. It is cheaper to purchase DVD with software then download it in those places. Free software movement have already made OS sellers like Red Hat and so many others to change into different direction, it also introduced it to Microsoft and other proprietary companies, but that all does not make it less of a product, as it is product of human effort, so it is exchangeable, if not for money then for donations, goodwill, contributions to the code, it is exchange of effort, so free software is currency within the community of free software. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 20:59 ` Drew Adams 2020-10-16 21:50 ` Jean Louis @ 2020-10-17 4:19 ` Richard Stallman 1 sibling, 0 replies; 838+ messages in thread From: Richard Stallman @ 2020-10-17 4:19 UTC (permalink / raw) To: Drew Adams; +Cc: mve1, emacs-devel, thibaut.verron, bugs, dgutov [[[ 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. ]]] It is not, strictly speaking, false to think about Emacs in ordinary economic terms. But it is not very illuminating to do so, since for the most part what we do is not driven by economic motives. That discussion is not pertinent to developing Emacs; would you please take it off this list? -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 20:15 ` Jean Louis 2020-10-16 20:59 ` Drew Adams @ 2020-10-17 4:19 ` Richard Stallman 1 sibling, 0 replies; 838+ messages in thread From: Richard Stallman @ 2020-10-17 4:19 UTC (permalink / raw) To: Jean Louis; +Cc: mve1, emacs-devel, thibaut.verron, drew.adams, dgutov [[[ 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. ]]] > > No, not really. A commodity is something that's > > produced for sale. > Emacs have been sold and can be sold today, thus it is commodity by > definition. Would people please take this discussion off the list emacs-devel? This list is for discussing practical questions about what to do in Emacs development. That discussion of semantics doesn't contribute, it is a tangent about semantics. Having disputes like this on the list makes the list unpleasant, so please move it. https://gnu.org/philosophy/kind-communication.html urges people to resist the temptation to discuss tangets. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 12:17 ` Dmitry Gutov 2020-10-16 13:45 ` Marcel Ventosa @ 2020-10-16 13:57 ` Ergus 2020-10-16 15:31 ` Eli Zaretskii 2020-10-16 19:11 ` Jean Louis 2020-10-16 16:09 ` Alfred M. Szmidt 2 siblings, 2 replies; 838+ messages in thread From: Ergus @ 2020-10-16 13:57 UTC (permalink / raw) To: Dmitry Gutov Cc: Marcel Ventosa, Thibaut Verron, Richard Stallman, Jean Louis, emacs-devel On Fri, Oct 16, 2020 at 03:17:16PM +0300, Dmitry Gutov wrote: >On 16.10.2020 11:25, Marcel Ventosa wrote: > >>Perhaps. Transitional solutions go both ways though. A cursory glance at >>Reddit's Emacs group is enough to notice not only ignorance of the >>philosophy behind GNU, but quite recurrent mockery of what it stands >>for. Usually in the form of deriding RMS. For the most recent example, >>one user comments under abrochard's survey post: "So, will you be >>censoring the survey to maintain ideological purity, like rms >>insisted?", to which abrochard responds: "I agree with you. The >>discussion around Melpa is a big factor as to why the survey is >>happening in parallel to the gnu project." > >Do you think the "mockery" is entirely without merit? > >It's not even so much real mockery as probably the only way the user >could describe the conflict. > >When a survey purposefully omits a well-known and popular option, it >is going to discount a sizable portion of our community, and ignore a >project that has done a lot to popularize Emacs over the years. > >I think it's both insulting to its developers, and stinks of thought >police. Far from the idea of user freedom I hope to expect from GNU >and FSF. > >>I'm not saying the obfuscation is purposeful either in the case of >>`MELPA' imitating the name of the existing `GNU ELPA', or of Adrien >>calling his survey *The* Emacs User survey", but what I do think is that >>all non-GNU initiatives that affect perception of GNU, particularly the >>ones that clearly do not share the GNU philosophy (the survey referred >>to `GNU/Linux' as `Linux', for example), would seem much more >>transparent if they were very clearly and visibly labeled as unofficial. >>My hope, of course, would be that these initiatives could respect the >>GNU philosophy, even if they did not share it. > >Calling it "THE Emacs User survey" is perhaps unfortunate. But >likewise it is unfortunate how Emacs leadership does little to follow >the external, "unofficial" polls. > >A survey doesn't have to be "the official GNU survey" to be useful. > I totally agree. I have contributed (and almost maintain) some melpa packages that have been abandoned by their creators. It is not possible to add them to elpa because most of the contributors are not active anymore or are hard to contact, or just don't care at all. This doesn't mean that they are "bad" or "dangerous" packages just because they can't follow the paperwork. And that doesn't mean that I should rewrite all the code just to avoid including the other authors to add them to elpa. That would be unethical. Some melpa packages like LSP, magit, elpy are basically the only alternative the users have to make emacs useful for their purposes. While others like helm, use-package, evil are essential for a huge part of the users. At the end anyone can use, read the code, distribute and improve that code... so it is free independently of what a piece of paper says (or don't say) and closing the code will just kill the packages. Reject using melpa for ideological reasons means that the users won't have alternatives for their work and emacs will become like a useless tool for a big part of our community; whitout melpa many users will go for more "useful" alternatives that really steal their freedom like VSCode or Atom... because they need to have the work done any way. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 13:57 ` Ergus @ 2020-10-16 15:31 ` Eli Zaretskii 2020-10-16 19:11 ` Jean Louis 1 sibling, 0 replies; 838+ messages in thread From: Eli Zaretskii @ 2020-10-16 15:31 UTC (permalink / raw) To: Ergus; +Cc: rms, bugs, mve1, emacs-devel, dgutov, thibaut.verron > Date: Fri, 16 Oct 2020 15:57:16 +0200 > From: Ergus <spacibba@aol.com> > Cc: Marcel Ventosa <mve1@runbox.com>, > Thibaut Verron <thibaut.verron@gmail.com>, > Richard Stallman <rms@gnu.org>, Jean Louis <bugs@gnu.support>, > emacs-devel <emacs-devel@gnu.org> > > Reject using melpa for ideological reasons means that the users won't > have alternatives for their work and emacs will become like a useless > tool for a big part of our community; whitout melpa many users will go > for more "useful" alternatives that really steal their freedom like > VSCode or Atom... because they need to have the work done any way. I believe the efforts to start nonGNU ELPA are intended to address that. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 13:57 ` Ergus 2020-10-16 15:31 ` Eli Zaretskii @ 2020-10-16 19:11 ` Jean Louis 1 sibling, 0 replies; 838+ messages in thread From: Jean Louis @ 2020-10-16 19:11 UTC (permalink / raw) To: Ergus Cc: Marcel Ventosa, emacs-devel, Richard Stallman, Thibaut Verron, Dmitry Gutov * Ergus <spacibba@aol.com> [2020-10-16 16:58]: > Reject using melpa for ideological reasons means that the users won't > have alternatives for their work and emacs will become like a useless > tool for a big part of our community; whitout melpa many users will go > for more "useful" alternatives that really steal their freedom like > VSCode or Atom... because they need to have the work done any way. Not true, it is very easy to replicate MELPA, and publish on a website, while removing any proprietary wrappers or accessors. In fact MELPA is free software project, so everybody is free to do it, all what you need is a standard server software, git, Emacs, web server, it is quite easy. Just git clone melpa, make, you will see what is happening, then you can modify it little and have all proprietary stuff removed. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 12:17 ` Dmitry Gutov 2020-10-16 13:45 ` Marcel Ventosa 2020-10-16 13:57 ` Ergus @ 2020-10-16 16:09 ` Alfred M. Szmidt 2 siblings, 0 replies; 838+ messages in thread From: Alfred M. Szmidt @ 2020-10-16 16:09 UTC (permalink / raw) To: Dmitry Gutov; +Cc: mve1, bugs, rms, thibaut.verron, emacs-devel When a survey purposefully omits a well-known and popular option, it is going to discount a sizable portion of our community, and ignore a project that has done a lot to popularize Emacs over the years. Only that wasn't what was being suggested, rather there where two solution purposed to solve that issue (either freeform text, or a disclaimer about why MELPA isn't recommended). And just because a different project popularizes a GNU project, doesn't mean that it must automatically be supported -- specially if there are ethical and moral reasons to not. I think it's both insulting to its developers, and stinks of thought police. Far from the idea of user freedom I hope to expect from GNU and FSF. What users do, and what the GNU or the FSF does are quite different things -- the GNU project and the FSF try to protect that users have the freedom, with that comes a responsibility to users to not point them towards software that is non-free. What users do, is up to them. That is neither insulting, or being thought police -- the GNU project has a specific goal, somethings are simply not related to it, or against it. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 8:25 ` Marcel Ventosa 2020-10-16 12:17 ` Dmitry Gutov @ 2020-10-16 17:29 ` Jean Louis 2020-10-16 19:11 ` Thibaut Verron 2020-10-17 4:22 ` Richard Stallman 2 siblings, 1 reply; 838+ messages in thread From: Jean Louis @ 2020-10-16 17:29 UTC (permalink / raw) To: Marcel Ventosa; +Cc: Richard Stallman, Thibaut Verron, emacs-devel * Marcel Ventosa <mve1@runbox.com> [2020-10-16 11:25]: > I understand your point, and transitional solutions may indeed be a good > thing (though they can lead both ways). However, it's a long-standing > position of GNU not to be seen to endorse these compromises, whether or > not their existence is a good thing. For me, the name GNU has always > signified a free software safe haven. The idea that one might be misled > into installing proprietary software because of well earned trust in GNU > should be avoided at all costs. That is right. > I would posit the same if I was a member of a vegan organization that > was relaxing their views on eating animals to ease the transition. While > there is little doubt transitions can be beneficial, the vegan > organization should not confuse it's tenets. That is right, some organization lose their purpose or deviate it. GNU project never deviates its purpose and is in that sense without compromises. > Perhaps. Transitional solutions go both ways though. A cursory > glance at Reddit's Emacs group is enough to notice not only > ignorance of the philosophy behind GNU, but quite recurrent mockery > of what it stands for. Usually in the form of deriding RMS. For the > most recent example, one user comments under abrochard's survey > post: "So, will you be censoring the survey to maintain ideological > purity, like rms insisted?", to which abrochard responds: "I agree > with you. The discussion around Melpa is a big factor as to why the > survey is happening in parallel to the gnu project." That is right, there is some mockery of free software philosophy, especially on IRC #emacs channel, that is very sad state that intelligent people cannot recognize they are being very rude, it is type of opression taking place on official GNU communication lines, as long as #emacs channel on IRC is considered official, that I do not know. Reddit is not. > Yes, I see it as a problem when an unofficial offshoot of a project does > not make it crystal clear that it is so. It is very easy to clone MELPA, to build packages, to exclude list of packages and to have your own ELPA locally installed, or to offer such on Internet for others, in a fixed mode, not continually built mode. It requires review, and collaboration of many developers to make it safe and secure for others. > In fact, and on the same topic, a post was made about the survey > yesterday on Reddit by Abrochard with the title "The Emacs User > Survey 2020 will open on Oct 19th," which makes it sound as though > it were an official survey. Further down the thread, a user > criticized RMS of trying to censor the survey, mentioning the MELPA > discussion in particular, to which Abrochard responded: "I agree > with you. The discussion around Melpa is a big factor as to why the > survey is happening in parallel to the gnu project." The Reddit page is hidden propaganda, they said "they contacted emacs-devel but got no response" which is not true. There were positive feedbacks overall, and acknowledgment including acknowledgment by RMS. > I'm not saying the obfuscation is purposeful either in the case of > `MELPA' imitating the name of the existing `GNU ELPA', or of Adrien > calling his survey *The* Emacs User survey", but what I do think is that > all non-GNU initiatives that affect perception of GNU, particularly the > ones that clearly do not share the GNU philosophy (the survey referred > to `GNU/Linux' as `Linux', for example), would seem much more > transparent if they were very clearly and visibly labeled as > unofficial. If it would be some belief or only philosophy, fine, but it is not. It is technical term. Obviously people do not call "Linux" for Android operating system, neither they call Android GNU because it is not GNU. Yet it runs on Linux kernel. Also Replicant operating system is not called GNU/Replicant as it is not GNU, so it is Replicant, operating system running in Linux kernel. Linux when published by Linus Torvalds in beginning, there is where he said that you need GNU for operating system, Linux is only kernel. How more clearer than that can it be? Now when somebody says: Archlinux that is derived name, it can be named of operating system. By the way, Archlinux is promoting proprietary software without differences, so I cannot recommend it. Jean ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 17:29 ` Jean Louis @ 2020-10-16 19:11 ` Thibaut Verron 2020-10-16 19:54 ` Jean Louis 0 siblings, 1 reply; 838+ messages in thread From: Thibaut Verron @ 2020-10-16 19:11 UTC (permalink / raw) To: Jean Louis; +Cc: Marcel Ventosa, Richard Stallman, emacs-devel > The Reddit page is hidden propaganda, they said "they contacted > emacs-devel but got no response" which is not true. Where exactly? The exact statement I find is this: > From there I got a lot of feedback around the set of questions itself but also how to distribute it. You can find the whole thread on the archives under "Proposal for an Emacs User Survey". That's quite far from "I got no response", so I'm curious as to which message you refer to. > > > I'm not saying the obfuscation is purposeful either in the case of > > `MELPA' imitating the name of the existing `GNU ELPA', or of Adrien > > calling his survey *The* Emacs User survey", but what I do think is that > > all non-GNU initiatives that affect perception of GNU, particularly the > > ones that clearly do not share the GNU philosophy (the survey referred > > to `GNU/Linux' as `Linux', for example), would seem much more > > transparent if they were very clearly and visibly labeled as > > unofficial. > > If it would be some belief or only philosophy, fine, but it is not. It > is technical term. > > Obviously people do not call "Linux" for Android operating system, > neither they call Android GNU because it is not GNU. Yet it runs on > Linux kernel. Also Replicant operating system is not called > GNU/Replicant as it is not GNU, so it is Replicant, operating system > running in Linux kernel. > > Linux when published by Linus Torvalds in beginning, there is where he > said that you need GNU for operating system, Linux is only kernel. How > more clearer than that can it be? > > Now when somebody says: Archlinux that is derived name, it can be > named of operating system. By the way, Archlinux is promoting > proprietary software without differences, so I cannot recommend it. > > Jean > ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 19:11 ` Thibaut Verron @ 2020-10-16 19:54 ` Jean Louis 2020-10-16 20:20 ` Thibaut Verron 0 siblings, 1 reply; 838+ messages in thread From: Jean Louis @ 2020-10-16 19:54 UTC (permalink / raw) To: Thibaut Verron; +Cc: Marcel Ventosa, Richard Stallman, emacs-devel * Thibaut Verron <thibaut.verron@gmail.com> [2020-10-16 22:12]: > > The Reddit page is hidden propaganda, they said "they contacted > > emacs-devel but got no response" which is not true. > > Where exactly? The exact statement I find is this: > > > From there I got a lot of feedback around the set of questions itself but also how to distribute it. You can find the whole thread on the archives under "Proposal for an Emacs User Survey". > > That's quite far from "I got no response", so I'm curious as to which > message you refer to. https://www.reddit.com/r/emacs/comments/j6x7ad/proposal_for_an_emacs_user_survey/g820ywv/?utm_source=reddit&utm_medium=web2x&context=3 ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 19:54 ` Jean Louis @ 2020-10-16 20:20 ` Thibaut Verron 0 siblings, 0 replies; 838+ messages in thread From: Thibaut Verron @ 2020-10-16 20:20 UTC (permalink / raw) To: Jean Louis; +Cc: Marcel Ventosa, Richard Stallman, emacs-devel Le ven. 16 oct. 2020 à 21:54, Jean Louis <bugs@gnu.support> a écrit : > > * Thibaut Verron <thibaut.verron@gmail.com> [2020-10-16 22:12]: > > > The Reddit page is hidden propaganda, they said "they contacted > > > emacs-devel but got no response" which is not true. > > > > Where exactly? The exact statement I find is this: > > > > > From there I got a lot of feedback around the set of questions itself but also how to distribute it. You can find the whole thread on the archives under "Proposal for an Emacs User Survey". > > > > That's quite far from "I got no response", so I'm curious as to which > > message you refer to. > > https://www.reddit.com/r/emacs/comments/j6x7ad/proposal_for_an_emacs_user_survey/g820ywv/?utm_source=reddit&utm_medium=web2x&context=3 I see, thanks. I was not looking for the correct thread or the correct user. In any case, I believe that it refers to the suggestion he posted below the remark, and not about the present survey suggestion: > :How about creating a new function that generates a report of how a user has configured emacs. Various options, global-minor-modes, faces, etc, similar to what report-emacs-bug generates. Setup a separate email address to receive reports and automatically tabulate what the popular settings are." I have not seen that thread, so I don't know can't comment about whether they got responses or not. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 8:25 ` Marcel Ventosa 2020-10-16 12:17 ` Dmitry Gutov 2020-10-16 17:29 ` Jean Louis @ 2020-10-17 4:22 ` Richard Stallman 2020-10-17 4:31 ` Qiantan Hong 2 siblings, 1 reply; 838+ messages in thread From: Richard Stallman @ 2020-10-17 4:22 UTC (permalink / raw) To: Marcel Ventosa; +Cc: bugs, thibaut.verron, emacs-devel [[[ 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. ]]] > Perhaps. Transitional solutions go both ways though. A cursory glance at > Reddit's Emacs group is enough to notice not only ignorance of the > philosophy behind GNU, but quite recurrent mockery of what it stands > for. Here is an ironic conflict. It would be good for someone to explain the GNU pilosophy there so that they understand that we have reasons for what we do. But I can't ask you to run nonfree software to post on Reddit. Is there any API that someone could use to make a free program that can post on Reddit? -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-17 4:22 ` Richard Stallman @ 2020-10-17 4:31 ` Qiantan Hong 2020-10-19 10:12 ` Robert Pluim 0 siblings, 1 reply; 838+ messages in thread From: Qiantan Hong @ 2020-10-17 4:31 UTC (permalink / raw) To: rms@gnu.org Cc: Marcel Ventosa, thibaut.verron@gmail.com, Jean Louis, emacs-devel [-- Attachment #1.1: Type: text/plain, Size: 730 bytes --] > > Here is an ironic conflict. It would be good for someone to explain > the GNU pilosophy there so that they understand that we have reasons > for what we do. But I can't ask you to run nonfree software to > post on Reddit. > > Is there any API that someone could use to make a free program > that can post on Reddit? > > -- > Dr Richard Stallman > Chief GNUisance of the GNU Project (https://gnu.org) > Founder, Free Software Foundation (https://fsf.org) > Internet Hall-of-Famer (https://internethalloffame.org) It seems that https://i.reddit.com/ <https://i.reddit.com/> works pretty well with LibreJS enabled. I assume it’s intended to be a JavaScript free version. Browsing and posting both works. [-- Attachment #1.2: Type: text/html, Size: 1369 bytes --] [-- Attachment #2: smime.p7s --] [-- Type: application/pkcs7-signature, Size: 1858 bytes --] ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-17 4:31 ` Qiantan Hong @ 2020-10-19 10:12 ` Robert Pluim 2020-10-19 16:15 ` Qiantan Hong 0 siblings, 1 reply; 838+ messages in thread From: Robert Pluim @ 2020-10-19 10:12 UTC (permalink / raw) To: Qiantan Hong Cc: Marcel Ventosa, Jean Louis, rms@gnu.org, thibaut.verron@gmail.com, emacs-devel >>>>> On Sat, 17 Oct 2020 04:31:09 +0000, Qiantan Hong <qhong@mit.edu> said: Qiantan> It seems that https://i.reddit.com/ <https://i.reddit.com/> works pretty well Qiantan> with LibreJS enabled. I assume it’s intended to Qiantan> be a JavaScript free version. Browsing and posting both works. Does that site also work for registering an account on reddit with LibreJS enabled? Robert -- ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-19 10:12 ` Robert Pluim @ 2020-10-19 16:15 ` Qiantan Hong 2020-10-20 13:45 ` Dmitry Gutov 0 siblings, 1 reply; 838+ messages in thread From: Qiantan Hong @ 2020-10-19 16:15 UTC (permalink / raw) To: Robert Pluim Cc: Marcel Ventosa, Jean Louis, rms@gnu.org, thibaut.verron@gmail.com, emacs-devel [-- Attachment #1.1: Type: text/plain, Size: 736 bytes --] The funny icon on the top right doesn’t work, But try https://www.reddit.com/register.compact <https://www.reddit.com/register.compact> and https://www.reddit.com/login.compact <https://www.reddit.com/login.compact> > On Oct 19, 2020, at 6:12 AM, Robert Pluim <rpluim@gmail.com> wrote: > >>>>>> On Sat, 17 Oct 2020 04:31:09 +0000, Qiantan Hong <qhong@mit.edu> said: > > Qiantan> It seems that https://i.reddit.com/ <https://i.reddit.com/> works pretty well > Qiantan> with LibreJS enabled. I assume it’s intended to > Qiantan> be a JavaScript free version. Browsing and posting both works. > > Does that site also work for registering an account on reddit with > LibreJS enabled? > > Robert > -- [-- Attachment #1.2: Type: text/html, Size: 1820 bytes --] [-- Attachment #2: smime.p7s --] [-- Type: application/pkcs7-signature, Size: 1858 bytes --] ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-19 16:15 ` Qiantan Hong @ 2020-10-20 13:45 ` Dmitry Gutov 0 siblings, 0 replies; 838+ messages in thread From: Dmitry Gutov @ 2020-10-20 13:45 UTC (permalink / raw) To: Qiantan Hong, Robert Pluim Cc: Marcel Ventosa, thibaut.verron@gmail.com, rms@gnu.org, Jean Louis, emacs-devel On 19.10.2020 19:15, Qiantan Hong wrote: > The funny icon on the top right doesn’t work, > But try > https://www.reddit.com/register.compact > and > https://www.reddit.com/login.compact Have you managed to register with it? It seems to want me to use a captcha anyway (looking at the network console), but fails to show said captcha. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 7:53 ` Thibaut Verron 2020-10-16 8:25 ` Marcel Ventosa @ 2020-10-16 18:57 ` Jean Louis 1 sibling, 0 replies; 838+ messages in thread From: Jean Louis @ 2020-10-16 18:57 UTC (permalink / raw) To: Thibaut Verron; +Cc: Marcel Ventosa, Richard Stallman, emacs-devel * Thibaut Verron <thibaut.verron@gmail.com> [2020-10-16 10:54]: > I personally don't think many users install non-free software because > they saw it wrapped in a Melpa package. - helm-lastpass was downloaded 777 times - lastpass was downloaded 987 times 1 user guided to use non-free software is already many. - chatwork package was downloaded 1093 times > Taking the example of emacs-lastpass given above, I don't see how > anyone would even find this package without searching for it with the > keyword "lastpass". They can find it in the list, for majority of packages I did not search by keyword, I was just downloading, inspecting code for short time, and trying to use it. > The audience, rather, is users who are currently using Lastpass in > their browsers but are interested in bringing some of their online > activities to Emacs, but rely on their password manager to do so. That is not based on data, unless you have made opinion poll for that specific package. I am really thinking that some of users will download lastpass when they see there is Emacs package for lastpass I have been downloading like espeak or festival speech packages, which are free software, when I have seen there are Emacs packages for speech, in the same way users will be guided to proprietary software. MELPA is to ELPA what Archlinux and Debian is to Guix and other free software distributions. They do not explicitly warn users about proprietary software, even though I do not think MELPA is letting non-free software being distributed. > I absolutely support the fact that Melpa is not activated by default, > and that there should be a warning about the existence of those > packages everywhere possible. But I still consider that the value of > those packages outweigh their dangers, just like the win32 build of > Emacs. Proprietary software wrapped is security issue, and largest danger is lack of security as MELPA is not reviewing software updates, any time malicious code can be inserted which could affect thousands of users. Here is example when Gentoo Linux was cracked on Github: https://nakedsecurity.sophos.com/2018/06/29/linux-distro-hacked-on-github-all-code-considered-compromised/ Here is example when Linux Mint distribution was cracked: https://www.techrepublic.com/article/why-the-linux-mint-hack-is-an-indicator-of-a-larger-problem/ ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 7:24 ` Marcel Ventosa 2020-10-16 7:53 ` Thibaut Verron @ 2020-10-16 17:08 ` Jean Louis 1 sibling, 0 replies; 838+ messages in thread From: Jean Louis @ 2020-10-16 17:08 UTC (permalink / raw) To: Marcel Ventosa; +Cc: Richard Stallman, Thibaut Verron, emacs-devel * Marcel Ventosa <mve1@runbox.com> [2020-10-16 10:24]: > I understand, thanks for the explanation. In that case, I think I'm > well informed enough to have avoived the dangers. I wonder how many > people are not. AFAIK, both Trisquel and Parabola keep out packages > that recommend or encourage proprietary software, which seems essential > to protect users' freedom. Which packages? Please report the issues in their issue trackers. Both of them are removing anything like that, that is what I know. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 6:52 ` Thibaut Verron 2020-10-16 7:24 ` Marcel Ventosa @ 2020-10-16 17:04 ` Jean Louis 2020-10-16 17:39 ` Vasilij Schneidermann 2020-10-18 4:09 ` Richard Stallman 2 siblings, 1 reply; 838+ messages in thread From: Jean Louis @ 2020-10-16 17:04 UTC (permalink / raw) To: Thibaut Verron; +Cc: Marcel Ventosa, Richard Stallman, emacs-devel * Thibaut Verron <thibaut.verron@gmail.com> [2020-10-16 09:53]: > Le ven. 16 oct. 2020 à 08:03, Marcel Ventosa <mve1@runbox.com> a écrit : > > > > On Thu, 15 Oct 2020 23:59:07 -0400 > > Richard Stallman <rms@gnu.org> wrote: > > > > > I hope that only a minority of Emacs users know about MELPA, and I'd > > > rather not inform the rest about it. But if something is going to > > > inform them anyway, it is better to do it with a denunciation. > > > > > > I've been using Emacs (and MELPA) for the best part of a decade and > > knew nothing about this! I'm concerned to use only free software and > > actively avoid proprietary software, so this is a bit of a shock. > > As I understand it, Melpa packages cannot *be* or *install* non-free > software. But some will not work without such software, which can in > theory encourage users to install it. MELPA as such is definitely free software project with few freedom issues with some pakages and lax attitude on usage of proprietary information through Emacs. For example, I like that when I find definition in a dictionary, that I can freely include it in the instruction book, and not that I am chased with licenses not allowing me to include such information. MELPA does have a checklist for packages: Checklist Please confirm with x: The package is released under a GPL-Compatible Free Software License. [x ] I've read CONTRIBUTING.org [ x] I've used the latest version of package-lint to check for packaging issues, and addressed its feedback [ x] My elisp byte-compiles cleanly [ x] M-x checkdoc is happy with my docstrings [ x] I've built and installed the package using the instructions in CONTRIBUTING.org I have confirmed some of these without doing them Example: https://github.com/melpa/melpa/pull/6387 People and MELPA maintainer are verifying packages, but they do not possibly verify it each time. So it is prone to security issues at any time. Once package is accepted, they are not automatically verifying the package, so far I understand, packages are built in real time and offered to users in real time. Any account can be cracked and malicious code introduced at any time. Github is in general unsafe place for development as it is held by major company providing proprietary software, one never knows what are they up to. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 17:04 ` Jean Louis @ 2020-10-16 17:39 ` Vasilij Schneidermann 0 siblings, 0 replies; 838+ messages in thread From: Vasilij Schneidermann @ 2020-10-16 17:39 UTC (permalink / raw) To: Jean Louis; +Cc: Marcel Ventosa, Richard Stallman, Thibaut Verron, emacs-devel [-- Attachment #1: Type: text/plain, Size: 527 bytes --] > Any account can be cracked and malicious code introduced at any > time. > > Github is in general unsafe place for development as it is held by > major company providing proprietary software, one never knows what are > they up to. And how is that different for, say, Savannah? In fact, I'd expect Github to have a dedicated security team, bug bounties to entice security researchers into discovering and reporting security issues and overall better security features for locking down your account, such as 2FA. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 6:52 ` Thibaut Verron 2020-10-16 7:24 ` Marcel Ventosa 2020-10-16 17:04 ` Jean Louis @ 2020-10-18 4:09 ` Richard Stallman 2 siblings, 0 replies; 838+ messages in thread From: Richard Stallman @ 2020-10-18 4:09 UTC (permalink / raw) To: thibaut.verron; +Cc: mve1, bugs, emacs-devel [[[ 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. ]]] > As I understand it, Melpa packages cannot *be* or *install* non-free > software. But some will not work without such software, which can in > theory encourage users to install it. Yes, that's exactly the issue. Listing a program for possible use can lead people to use it. If using that program requires running some nonfree program, the listing can lead people to run that nonfree program. > ELPA means Emacs Lisp Package Archive, so both Melpa and GNU Elpa are ELPA's. > I think that commonly referring to GNU Elpa as simply Elpa (which I am > also guilty of) is a bigger source of confusion than Melpa and GNU > Elpa sharing the same suffix. I agree. I sent another message about that issue. I think that the basic mistake was implementing support in GNU Emacs for other package archives. It may have seemed like the general thing to do, at the time; but it led to a bad situation. If I had thought more about this, maybe I would have realized it beforehand. > GNU Elpa and the future Non-GNU Elpa are (will be) activated by > default as package archives, Melpa is not. > The hope is that once 99% of the packages by the community are > available in an archive activated by default, users will not rush to > install Melpa in the same proportions as today. Yes, that's the aim. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* MELPA issues - Re: Proposal for an Emacs User Survey 2020-10-16 6:02 ` Marcel Ventosa 2020-10-16 6:52 ` Thibaut Verron @ 2020-10-16 16:33 ` Jean Louis 2020-10-16 18:09 ` Dmitry Gutov 2020-10-17 2:59 ` Marcel Ventosa 2020-10-18 4:10 ` Richard Stallman 2 siblings, 2 replies; 838+ messages in thread From: Jean Louis @ 2020-10-16 16:33 UTC (permalink / raw) To: Marcel Ventosa; +Cc: Richard Stallman, thibaut.verron, emacs-devel * Marcel Ventosa <mve1@runbox.com> [2020-10-16 09:03]: > On Thu, 15 Oct 2020 23:59:07 -0400 > Richard Stallman <rms@gnu.org> wrote: > > > I hope that only a minority of Emacs users know about MELPA, and I'd > > rather not inform the rest about it. But if something is going to > > inform them anyway, it is better to do it with a denunciation. > > > I've been using Emacs (and MELPA) for the best part of a decade and > knew nothing about this! I'm concerned to use only free software and > actively avoid proprietary software, so this is a bit of a shock. > > Is there anywhere I can read more about this issue? I have not checked all the software on MELPA, but due to Github policies that free (of charge)repositories should have only free (as in liberty)software licenses, I am assuming that probably none of those software is non-free. But there can be MELPA software that is vague because maybe maintainers have not put the proper license, which is often the case. The software provided by MELPA may lead users to non-free software or may control non-free software or be made exclusively for usage of free software. Example that I have found is ChatWork package, it works with ChatWork chat software, for which I only assume it is proprietary, I have not checked it very good, it seemed to be so from verification of their website. Corporations can very easily sponsor somebody to provide software for Emacs to provide features that control or interact with their proprietary software. It is also method of advertising. Then there is software to access various websites, let us say software that provides quotes from specific website, it could be funny quote or smart one, but maybe the purpose is simply advertising. Finally, fetching something from other website I consider dangerous, package itself need not be, but other packages following, could be easily dangerous. More danger from MELPA comes from the fact that MELPA is not verifying the packages, not that I know, I have read they said they are not doing it. There is plethora of insecurities on MELPA. It is far from harmless. So far I understood, the packages arriving to GNU ELPA are assigned with copyright to FSF, I am also assuming as user that such packages are somehow reviewed by developers, not just one developer, and that they are placed into ELPA as duplicate or copy from the upstream. I may be wrong in all that assumption, but I think that GNU ELPA packages are verified for freedom and mostly for security and safety of users. We are speaking of loading true programming language code and executing such on users' computers. It is not equivalent to Javascript, it is far more dangerous than Javascript which tend to execute in safe environment, which tends to execute in such way as not to abuse users' computers and data, yet people have found ways to crack browsers and to crack and enter into users' file systems, there are many ways how Javascript can be malicious. The more packages there are that are not verified, but simple offered for download through MELPA, the more and more insecurities are coming in future. MELPA is allowing Google to track users by using Google Analytics on their website, that speaks already about the webmaster's lack of skills in managing the website. There are so many free software programs for web statistics, and there is no need for third party tracking. Now, the real insecurity comes from program that are sourced from Github. If there are 4000+ packages, there can be 1000+ authors, maybe even 2000+ authors. Each of those authors represent insecurity to computing, as their packages are not verified each time they are pulled, they are blindly trusted. The blind trust to MELPA packages is what is making it highly insecure for computer users. It requires just 1 author for their accounts to be cracked and for malicious code to be inserted, thousands of computer users can be affected that way. Finally, author can go nut himself, and can become psychotic, there are programmers who became so, they can introduce malicious code themselves, or can do it by claiming it was somebody else. Packages that I think do not belong in free software repository for reason they are using proprietary information or wrapping proprietary software, or use known spying networks: babel - that uses non-free Babelfish translations (if I am mistaken tell me) chatwork - that uses non-free ChatWork proprietary chat software bing-dict - that uses Microsoft Bing proprietary dictionary calfw-gcal - to edit Google calendar Obviously I came to letter C, I could browse more and find more troublesome packages. Yet major insecurity is number of packages where they are not verified by human to be safe and blind offering and blind acceptance by users thinking they are safe. Jean ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: MELPA issues - Re: Proposal for an Emacs User Survey 2020-10-16 16:33 ` MELPA issues - " Jean Louis @ 2020-10-16 18:09 ` Dmitry Gutov 2020-10-16 22:00 ` Qiantan Hong 2020-10-17 2:59 ` Marcel Ventosa 1 sibling, 1 reply; 838+ messages in thread From: Dmitry Gutov @ 2020-10-16 18:09 UTC (permalink / raw) To: Jean Louis, Marcel Ventosa; +Cc: Richard Stallman, thibaut.verron, emacs-devel On 16.10.2020 19:33, Jean Louis wrote: > But there can be MELPA software that is > vague because maybe maintainers have not put the proper license, which > is often the case. "GPL compatible license" is among the requirements for inclusion. It's in their CONTRIBUTING.org, take a look: https://raw.githubusercontent.com/melpa/melpa/master/CONTRIBUTING.org ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: MELPA issues - Re: Proposal for an Emacs User Survey 2020-10-16 18:09 ` Dmitry Gutov @ 2020-10-16 22:00 ` Qiantan Hong 2020-10-16 22:08 ` Dmitry Gutov 2020-10-17 4:18 ` Richard Stallman 0 siblings, 2 replies; 838+ messages in thread From: Qiantan Hong @ 2020-10-16 22:00 UTC (permalink / raw) To: Dmitry Gutov Cc: Marcel Ventosa, thibaut.verron@gmail.com, rms@gnu.org, Jean Louis, emacs-devel [-- Attachment #1: Type: text/plain, Size: 208 bytes --] As a package writer, my main concern is that it seems that the package submission process require proprietary software (particularly non-free JavaScript by m$ Github). Do Melpa people provide any workaround? [-- Attachment #2: smime.p7s --] [-- Type: application/pkcs7-signature, Size: 1858 bytes --] ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: MELPA issues - Re: Proposal for an Emacs User Survey 2020-10-16 22:00 ` Qiantan Hong @ 2020-10-16 22:08 ` Dmitry Gutov 2020-10-17 4:18 ` Richard Stallman 1 sibling, 0 replies; 838+ messages in thread From: Dmitry Gutov @ 2020-10-16 22:08 UTC (permalink / raw) To: Qiantan Hong Cc: Marcel Ventosa, thibaut.verron@gmail.com, rms@gnu.org, Jean Louis, emacs-devel On 17.10.2020 01:00, Qiantan Hong wrote: > As a package writer, my main concern is that > it seems that the package submission process > require proprietary software (particularly non-free > JavaScript by m$ Github). > > Do Melpa people provide any workaround? You can ask someone else to do that for you. Email one of the MELPA maintainers, for example. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: MELPA issues - Re: Proposal for an Emacs User Survey 2020-10-16 22:00 ` Qiantan Hong 2020-10-16 22:08 ` Dmitry Gutov @ 2020-10-17 4:18 ` Richard Stallman 2020-10-17 4:59 ` chad 1 sibling, 1 reply; 838+ messages in thread From: Richard Stallman @ 2020-10-17 4:18 UTC (permalink / raw) To: Qiantan Hong; +Cc: mve1, emacs-devel, bugs, thibaut.verron, dgutov [[[ 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. ]]] > As a package writer, my main concern is that > it seems that the package submission process > require proprietary software (particularly non-free > JavaScript by m$ Github). What I would do, in that situation, is not submit my package to Melpa. Meanwhile, this aspect of Melpa is an additional reason not to do anything to lead people to use Melpa. I hope the developers of Melpa will fix this. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: MELPA issues - Re: Proposal for an Emacs User Survey 2020-10-17 4:18 ` Richard Stallman @ 2020-10-17 4:59 ` chad 2020-10-17 5:05 ` Qiantan Hong 2020-10-17 5:06 ` Thibaut Verron 0 siblings, 2 replies; 838+ messages in thread From: chad @ 2020-10-17 4:59 UTC (permalink / raw) To: Richard Stallman Cc: Qiantan Hong, bugs, thibaut.verron, mve1, EMACS development team, Dmitry Gutov [-- Attachment #1: Type: text/plain, Size: 1193 bytes --] On Fri, Oct 16, 2020 at 9:20 PM Richard Stallman <rms@gnu.org> wrote: > > As a package writer, my main concern is that > > it seems that the package submission process > > require proprietary software (particularly non-free > > JavaScript by m$ Github). > > What I would do, in that situation, is not submit my package to Melpa. > > Meanwhile, this aspect of Melpa is an additional reason not to do > anything to lead people to use Melpa. > This seems to be based on the incorrect assumption that package authors must use GitHub to use MELPA. According to the MELPA docs: MELPA supports git <http://git-scm.com/>, github <https://github.com/>, > gitlab <https://gitlab.com/>, and hg <https://www.mercurial-scm.org/> (Mercurial) > [...] > :url specifies the URL of the version control repository. > *required for the git, and hg fetchers. [...]*:repo specifies the github > or gitlab repository and is of the form user/repo-name. *required for > the github and gitlab fetchers*. Digging in a bit further, MELPA used to also support EmacsWiki, which it deprecated for security concerns, and Bazaar, CVS, Darcs, Fossil and Subversion, which it deprecated due to lack of use. ~Chad [-- Attachment #2: Type: text/html, Size: 8159 bytes --] ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: MELPA issues - Re: Proposal for an Emacs User Survey 2020-10-17 4:59 ` chad @ 2020-10-17 5:05 ` Qiantan Hong 2020-10-17 5:06 ` Thibaut Verron 1 sibling, 0 replies; 838+ messages in thread From: Qiantan Hong @ 2020-10-17 5:05 UTC (permalink / raw) To: chad Cc: Jean Louis, rms@gnu.org, thibaut.verron@gmail.com, Marcel Ventosa, EMACS development team, Dmitry Gutov [-- Attachment #1.1: Type: text/plain, Size: 1510 bytes --] However, I do need to use GitHub to open a Pull Request to add the receipt. As someone pointed out, one workaround might be just email the MELPA maintainers. I’ve never tried that myself. > On Oct 17, 2020, at 12:59 AM, chad <yandros@gmail.com> wrote: > > On Fri, Oct 16, 2020 at 9:20 PM Richard Stallman <rms@gnu.org <mailto:rms@gnu.org>> wrote: > > As a package writer, my main concern is that > > it seems that the package submission process > > require proprietary software (particularly non-free > > JavaScript by m$ Github). > > What I would do, in that situation, is not submit my package to Melpa. > > Meanwhile, this aspect of Melpa is an additional reason not to do > anything to lead people to use Melpa. > > This seems to be based on the incorrect assumption that package authors must use GitHub to use MELPA. According to the MELPA docs: > > MELPA supports git <http://git-scm.com/>, github <https://github.com/>, gitlab <https://gitlab.com/>, and hg <https://www.mercurial-scm.org/> (Mercurial) [...] > :url specifies the URL of the version control repository. required for the git, and hg fetchers. [...] > :repo specifies the github or gitlab repository and is of the form user/repo-name. required for the github and gitlab fetchers. > > Digging in a bit further, MELPA used to also support EmacsWiki, which it deprecated for security concerns, and Bazaar, CVS, Darcs, Fossil and Subversion, which it deprecated due to lack of use. > > ~Chad [-- Attachment #1.2: Type: text/html, Size: 9616 bytes --] [-- Attachment #2: smime.p7s --] [-- Type: application/pkcs7-signature, Size: 1858 bytes --] ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: MELPA issues - Re: Proposal for an Emacs User Survey 2020-10-17 4:59 ` chad 2020-10-17 5:05 ` Qiantan Hong @ 2020-10-17 5:06 ` Thibaut Verron 1 sibling, 0 replies; 838+ messages in thread From: Thibaut Verron @ 2020-10-17 5:06 UTC (permalink / raw) To: chad Cc: Qiantan Hong, Richard Stallman, Jean Louis, mve1, EMACS development team, Dmitry Gutov Le sam. 17 oct. 2020 à 06:59, chad <yandros@gmail.com> a écrit : > > On Fri, Oct 16, 2020 at 9:20 PM Richard Stallman <rms@gnu.org> wrote: >> >> > As a package writer, my main concern is that >> > it seems that the package submission process >> > require proprietary software (particularly non-free >> > JavaScript by m$ Github). >> >> What I would do, in that situation, is not submit my package to Melpa. >> >> Meanwhile, this aspect of Melpa is an additional reason not to do >> anything to lead people to use Melpa. > > > This seems to be based on the incorrect assumption that package authors must use GitHub to use MELPA. According to the MELPA docs: But can a user submit a new package without filing a pull request against Melpa's github repository? This requires using github to create an account, create the fork and file the pull request. There is a github cli program which might allow do the latter two, but creating the account will still require github's javascript. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: MELPA issues - Re: Proposal for an Emacs User Survey 2020-10-16 16:33 ` MELPA issues - " Jean Louis 2020-10-16 18:09 ` Dmitry Gutov @ 2020-10-17 2:59 ` Marcel Ventosa 2020-10-18 4:12 ` Richard Stallman 1 sibling, 1 reply; 838+ messages in thread From: Marcel Ventosa @ 2020-10-17 2:59 UTC (permalink / raw) To: Jean Louis; +Cc: Richard Stallman, thibaut.verron, emacs-devel Thank you for your explanation Jean Louis. On Fri, 16 Oct 2020 19:33:45 +0300 Jean Louis <bugs@gnu.support> wrote: > * Marcel Ventosa <mve1@runbox.com> [2020-10-16 09:03]: > > On Thu, 15 Oct 2020 23:59:07 -0400 > > Richard Stallman <rms@gnu.org> wrote: > > > > > I hope that only a minority of Emacs users know about MELPA, and > > > I'd rather not inform the rest about it. But if something is > > > going to inform them anyway, it is better to do it with a > > > denunciation. > > > > > > I've been using Emacs (and MELPA) for the best part of a decade and > > knew nothing about this! I'm concerned to use only free software and > > actively avoid proprietary software, so this is a bit of a shock. > > > > Is there anywhere I can read more about this issue? > > I have not checked all the software on MELPA, but due to Github > policies that free (of charge)repositories should have only free (as > in liberty)software licenses, I am assuming that probably none of > those software is non-free. But there can be MELPA software that is > vague because maybe maintainers have not put the proper license, which > is often the case. > > The software provided by MELPA may lead users to non-free software or > may control non-free software or be made exclusively for usage of free > software. > > Example that I have found is ChatWork package, it works with ChatWork > chat software, for which I only assume it is proprietary, I have not > checked it very good, it seemed to be so from verification of their > website. > > Corporations can very easily sponsor somebody to provide software for > Emacs to provide features that control or interact with their > proprietary software. > > It is also method of advertising. > > Then there is software to access various websites, let us say software > that provides quotes from specific website, it could be funny quote or > smart one, but maybe the purpose is simply advertising. Finally, > fetching something from other website I consider dangerous, package > itself need not be, but other packages following, could be easily > dangerous. > > More danger from MELPA comes from the fact that MELPA is not verifying > the packages, not that I know, I have read they said they are not > doing it. > > There is plethora of insecurities on MELPA. It is far from harmless. > > So far I understood, the packages arriving to GNU ELPA are assigned > with copyright to FSF, I am also assuming as user that such packages > are somehow reviewed by developers, not just one developer, and that > they are placed into ELPA as duplicate or copy from the upstream. I > may be wrong in all that assumption, but I think that GNU ELPA > packages are verified for freedom and mostly for security and safety > of users. We are speaking of loading true programming language code > and executing such on users' computers. > > It is not equivalent to Javascript, it is far more dangerous than > Javascript which tend to execute in safe environment, which tends to > execute in such way as not to abuse users' computers and data, yet > people have found ways to crack browsers and to crack and enter into > users' file systems, there are many ways how Javascript can be > malicious. > > The more packages there are that are not verified, but simple offered > for download through MELPA, the more and more insecurities are coming > in future. > > MELPA is allowing Google to track users by using Google Analytics on > their website, that speaks already about the webmaster's lack of > skills in managing the website. There are so many free software > programs for web statistics, and there is no need for third party > tracking. > > Now, the real insecurity comes from program that are sourced from > Github. If there are 4000+ packages, there can be 1000+ authors, maybe > even 2000+ authors. > > Each of those authors represent insecurity to computing, as their > packages are not verified each time they are pulled, they are blindly > trusted. > > The blind trust to MELPA packages is what is making it highly insecure > for computer users. > > It requires just 1 author for their accounts to be cracked and for > malicious code to be inserted, thousands of computer users can be > affected that way. > > Finally, author can go nut himself, and can become psychotic, there > are programmers who became so, they can introduce malicious code > themselves, or can do it by claiming it was somebody else. > > Packages that I think do not belong in free software repository for > reason they are using proprietary information or wrapping proprietary > software, or use known spying networks: > > babel - that uses non-free Babelfish translations (if I am mistaken > tell me) > > chatwork - that uses non-free ChatWork proprietary chat software > > bing-dict - that uses Microsoft Bing proprietary dictionary > > calfw-gcal - to edit Google calendar > > Obviously I came to letter C, I could browse more and find more > troublesome packages. > > Yet major insecurity is number of packages where they are not verified > by human to be safe and blind offering and blind acceptance by users > thinking they are safe. > > Jean > > > > ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: MELPA issues - Re: Proposal for an Emacs User Survey 2020-10-17 2:59 ` Marcel Ventosa @ 2020-10-18 4:12 ` Richard Stallman 2020-10-18 5:16 ` Jean Louis 0 siblings, 1 reply; 838+ messages in thread From: Richard Stallman @ 2020-10-18 4:12 UTC (permalink / raw) To: bugs; +Cc: emacs-devel [[[ 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. ]]] > > babel - that uses non-free Babelfish translations (if I am mistaken > > tell me) > > > > calfw-gcal - to edit Google calendar When you say that those things are non-free, what precisely does that mean? It might be a misunderstanding, because a service is neither free nor proprietary. Do these packages run any nonfree software or use some nonfree collection of data? Or are you referring to the fact that they send commands to a service? See https://www.gnu.org/philosophy/network-services-arent-free-or-nonfree.html. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: MELPA issues - Re: Proposal for an Emacs User Survey 2020-10-18 4:12 ` Richard Stallman @ 2020-10-18 5:16 ` Jean Louis 0 siblings, 0 replies; 838+ messages in thread From: Jean Louis @ 2020-10-18 5:16 UTC (permalink / raw) To: Richard Stallman; +Cc: bugs, emacs-devel * Richard Stallman <rms@gnu.org> [2020-10-18 07:12]: > [[[ 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. ]]] > > > > babel - that uses non-free Babelfish translations (if I am mistaken > > > tell me) > > > > > > calfw-gcal - to edit Google calendar > > When you say that those things are non-free, what precisely does that > mean? It might be a misunderstanding, because a service is neither > free nor proprietary. Service is neither free nor proprietary. That is right. It is my opinion that it does not give freedom to user: - the package "babel" is accessing non-free dictionary, their terms are that one shall not replicate, sell or reporduce content in any way. This warning may not be given to user by the package, and practically, I am using free dictionaries, which information I can embed, including sell as index or glossary. When using babel package, I would as user assume that information is free and would maybe incorporate it in other works, finally I am using Emacs which is meant for text editing. Using Wiktionary on the other hand gives me those freedoms. - for package calfw-gcal, it may allow me to access Google Calendar services. It also implies that me as user must register Google account, meaning I must submit to being tracked by Google, I have access non-free Javascript. Those actions that are necessary before I can use the package calfw-gcal. > Do these packages run any nonfree software or use some nonfree > collection of data? For Babelfish, I doubt that package maintainer complained legally to their terms, for Google calendar package is clear that one has to register Google account by using non-free Javascript in order to use the package. > Or are you referring to the fact that they send commands to a > service? No. I refer to practical facts above. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 6:02 ` Marcel Ventosa 2020-10-16 6:52 ` Thibaut Verron 2020-10-16 16:33 ` MELPA issues - " Jean Louis @ 2020-10-18 4:10 ` Richard Stallman 2020-10-18 7:51 ` Marcel Ventosa ` (2 more replies) 2 siblings, 3 replies; 838+ messages in thread From: Richard Stallman @ 2020-10-18 4:10 UTC (permalink / raw) To: Marcel Ventosa; +Cc: bugs, thibaut.verron, emacs-devel [[[ 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. ]]] > In fact, I would go the extra mile and say Emacs should expressly warn > users over the dangers of installing proprietary software from > unofficial repositories That could be a good idea. What would be good occasions on which to warn? Perhaps in list-packages when it sees a non-GNU repo, or when it sees MELPA? Perhaps in describe-package and packageinstall, when the package comes from a non-GNU repo, or specifically from MELPA? Any other ideas? (by the way, I always just assumed MELPA was > somehow official and related to ELPA, because its name is so similar to > ELPA). Yes, this is a source of confusion. Perhaps we should renamme GNU ELPA to a name that will avoid this confusion. Maybe GNU EP (GNU Emacs Packages)? EP is not meaningful to those who don't know what it means. But neither is ELPA. People understand it only if they have been told. So EP is no worse than ELPA. WDYT? -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-18 4:10 ` Richard Stallman @ 2020-10-18 7:51 ` Marcel Ventosa 2020-10-18 9:29 ` Dmitry Gutov 2020-10-18 9:36 ` Jean Louis 2020-10-18 8:57 ` Thibaut Verron 2020-10-18 15:57 ` Philip K. 2 siblings, 2 replies; 838+ messages in thread From: Marcel Ventosa @ 2020-10-18 7:51 UTC (permalink / raw) To: Richard Stallman; +Cc: bugs, thibaut.verron, emacs-devel On Sun, 18 Oct 2020 00:10:02 -0400 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. ]]] > > > In fact, I would go the extra mile and say Emacs should expressly > > warn users over the dangers of installing proprietary software > > from unofficial repositories > > That could be a good idea. What would be good occasions on which to > warn? > > Perhaps in list-packages when it sees a non-GNU repo, or when it sees > MELPA? Any non-GNU repo that has not made an express commitment to uphold free sofware values? > Perhaps in describe-package and packageinstall, when the package comes > from a non-GNU repo, or specifically from MELPA? > > Any other ideas? How about something similar to Parabola's `your-freedom' package approach? It doesn't necessarily have to prevent installation of nonfree programs like `your-freedom' does, but could present a warning where the user must expressly agree to run the nonfree package the first time it's loaded (something similar to the `load-theme' warning). I'm not sure what the technical difficulties implementing this would be. It would also require an interested party and an ongoing discussion to keep an up to date list of such packages. If it amounts to 2-3 packages as I was told, it might be a very simple task. This would have the added advantage that individual packages that are not distributed through repositories could be added as they are discovered, and that the responsibility for warning users about the dangers of nonfree programs rests with GNU itself. Who would have the final say for individual candidate packages? In the case of Parabola, I know there have been long discussions about whether certain components of certain programs (such as web browser engines) are unfree. I find these discussions to be a feature rather than an inconvenience though. > > (by the way, I always just assumed MELPA was > > somehow official and related to ELPA, because its name is so > > similar to ELPA). > > Yes, this is a source of confusion. > > Perhaps we should renamme GNU ELPA to a name that will avoid this > confusion. Maybe GNU EP (GNU Emacs Packages)? > > EP is not meaningful to those who don't know what it means. But > neither is ELPA. People understand it only if they have been told. > So EP is no worse than ELPA. > > WDYT? This solution would have saved me from the name related confusion. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-18 7:51 ` Marcel Ventosa @ 2020-10-18 9:29 ` Dmitry Gutov 2020-10-18 9:36 ` Jean Louis 1 sibling, 0 replies; 838+ messages in thread From: Dmitry Gutov @ 2020-10-18 9:29 UTC (permalink / raw) To: Marcel Ventosa, Richard Stallman; +Cc: thibaut.verron, bugs, emacs-devel On 18.10.2020 10:51, Marcel Ventosa wrote: > How about something similar to Parabola's `your-freedom' package > approach? It doesn't necessarily have to prevent installation of nonfree > programs like `your-freedom' does, but could present a warning where the > user must expressly agree to run the nonfree package the first time it's > loaded (something similar to the `load-theme' warning). You could propose something like that to MELPA guys, if that would lead to MELPA being endorsed. Could be an acceptable middle ground. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-18 7:51 ` Marcel Ventosa 2020-10-18 9:29 ` Dmitry Gutov @ 2020-10-18 9:36 ` Jean Louis 1 sibling, 0 replies; 838+ messages in thread From: Jean Louis @ 2020-10-18 9:36 UTC (permalink / raw) To: Marcel Ventosa; +Cc: Richard Stallman, thibaut.verron, emacs-devel * Marcel Ventosa <mve1@runbox.com> [2020-10-18 10:51]: > How about something similar to Parabola's `your-freedom' package > approach? It doesn't necessarily have to prevent installation of nonfree > programs like `your-freedom' does, but could present a warning where the > user must expressly agree to run the nonfree package the first time it's > loaded (something similar to the `load-theme' warning). That is good idea to make package for GNU ELPA that will recognize those packages using proprietary software and warn users about freedom issues. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-18 4:10 ` Richard Stallman 2020-10-18 7:51 ` Marcel Ventosa @ 2020-10-18 8:57 ` Thibaut Verron 2020-10-19 3:44 ` Richard Stallman 2020-10-18 15:57 ` Philip K. 2 siblings, 1 reply; 838+ messages in thread From: Thibaut Verron @ 2020-10-18 8:57 UTC (permalink / raw) To: Richard Stallman; +Cc: Marcel Ventosa, Jean Louis, emacs-devel Le dim. 18 oct. 2020 à 06:10, Richard Stallman <rms@gnu.org> a écrit : > > In fact, I would go the extra mile and say Emacs should expressly warn > > users over the dangers of installing proprietary software from > > unofficial repositories > > That could be a good idea. What would be good occasions on which to warn? > > Perhaps in list-packages when it sees a non-GNU repo, or when it sees MELPA? With the subtlety that non-GNU Elpa would not be a non-GNU repo? > Perhaps in describe-package and packageinstall, when the package comes > from a non-GNU repo, or specifically from MELPA? Not all users use package.el, some still use git (either manually or through a package manager). If such a warning becomes implemented, would that automatically make package managers which do not (or cannot) display the warning as dangerous as Melpa is currently? --- Fwiw I still believe that information about Melpa on the webpage should be available, with appropriate warnings. When researching options, I found this webpage: https://www.gnu.org/software/gnuzilla/addons.html about IceCat extensions. It does give the URL for the Mozilla store, with a warning that some extensions may not be compatible with the goals of the GNU project, and then it gives a list of vetted extensions. Those add-ons are vetted for their licence and their free character. Only the latter would be necessary for Melpa. A problem with that list is that a lot of those extensions might have since disappeared from the Mozilla store, but that is not something that happens frequently with Melpa, especially when it comes to extremely popular packages. (Another problem, obviously, is that this page is obsolete, but as I understand it that's due to technical changes in Firefox, not to the page being incompatible with GNU policy.) So, would a similar approach be viable for Melpa in the Emacs manual and/or webpage? The work of vetting packages would not be wasted, since the same list could be immediately reused to populate non-GNU Elpa. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-18 8:57 ` Thibaut Verron @ 2020-10-19 3:44 ` Richard Stallman 0 siblings, 0 replies; 838+ messages in thread From: Richard Stallman @ 2020-10-19 3:44 UTC (permalink / raw) To: thibaut.verron; +Cc: mve1, bugs, emacs-devel [[[ 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. ]]] > > Perhaps in list-packages when it sees a non-GNU repo, or when it sees MELPA? > With the subtlety that non-GNU Elpa would not be a non-GNU repo? Sorry that my words were confusing, but no, there would not be a warning about Non-GNU ELPA. We would make sure all the packages in that repo would be ok to recommend, and indeed we would recommend it. > It does give the URL for the Mozilla store, with a warning that some > extensions may not be compatible with the goals of the GNU project, > and then it gives a list of vetted extensions. As you've noticed, that issue and the MELPA issue are instances of the same general class of situations. They are affected by the same factors. However, the details are different, and what is right for one is not necessarily right for the other. The node References discusses these factors. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-18 4:10 ` Richard Stallman 2020-10-18 7:51 ` Marcel Ventosa 2020-10-18 8:57 ` Thibaut Verron @ 2020-10-18 15:57 ` Philip K. 2020-10-19 3:48 ` Richard Stallman 2 siblings, 1 reply; 838+ messages in thread From: Philip K. @ 2020-10-18 15:57 UTC (permalink / raw) To: Richard Stallman; +Cc: Marcel Ventosa, thibaut.verron, bugs, emacs-devel 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. ]]] > > > In fact, I would go the extra mile and say Emacs should expressly warn > > users over the dangers of installing proprietary software from > > unofficial repositories > > That could be a good idea. What would be good occasions on which to warn? > > Perhaps in list-packages when it sees a non-GNU repo, or when it sees MELPA? > > Perhaps in describe-package and packageinstall, when the package comes > from a non-GNU repo, or specifically from MELPA? > > Any other ideas? This is a weaker suggestion: Maybe packages could have a tag to signal that they are related to proprietary software, that could be then displayed both via list-packages and describe-package? I'm fairly sure that MELPA would encourage or even require people to add this tag. Most software on MELPA is "ok", and people (like me) choose to use it because is offers more packages than ELPA. > (by the way, I always just assumed MELPA was > > somehow official and related to ELPA, because its name is so similar to > > ELPA). > > Yes, this is a source of confusion. > > Perhaps we should renamme GNU ELPA to a name that will avoid this confusion. > Maybe GNU EP (GNU Emacs Packages)? > > EP is not meaningful to those who don't know what it means. But > neither is ELPA. People understand it only if they have been told. > So EP is no worse than ELPA. > > WDYT? There shouldn't be any reason for ELPA to rename itself, it should be clear that MELPA is not official, as it is not pre-configured. -- Philip K. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-18 15:57 ` Philip K. @ 2020-10-19 3:48 ` Richard Stallman 2020-10-19 11:36 ` Dmitry Gutov 0 siblings, 1 reply; 838+ messages in thread From: Richard Stallman @ 2020-10-19 3:48 UTC (permalink / raw) To: Philip K.; +Cc: mve1, bugs, thibaut.verron, emacs-devel [[[ 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. ]]] > This is a weaker suggestion: Maybe packages could have a tag to signal > that they are related to proprietary software, that could be then > displayed both via list-packages and describe-package? This approach depends on any number of people that we don't know to include a special marker whenever they release packages that lead the user to nonfree software. Since these people eapparently don't agree with our basic ideas about such packages, I don't think we could count on them to do that. > > EP is not meaningful to those who don't know what it means. But > > neither is ELPA. People understand it only if they have been told. > > So EP is no worse than ELPA. > > > > WDYT? > There shouldn't be any reason for ELPA to rename itself, it should be > clear that MELPA is not official, as it is not pre-configured. I have a feeling we are miscommunicating somehow here. The point of the renaming is simply to avoid a natural confusion in the minds of people. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-19 3:48 ` Richard Stallman @ 2020-10-19 11:36 ` Dmitry Gutov 2020-10-19 12:43 ` Proposal to include obligatory PGP verification of packages from any repository Jean Louis ` (2 more replies) 0 siblings, 3 replies; 838+ messages in thread From: Dmitry Gutov @ 2020-10-19 11:36 UTC (permalink / raw) To: rms, Philip K.; +Cc: mve1, thibaut.verron, bugs, emacs-devel On 19.10.2020 06:48, Richard Stallman 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. ]]] > > > This is a weaker suggestion: Maybe packages could have a tag to signal > > that they are related to proprietary software, that could be then > > displayed both via list-packages and describe-package? > > This approach depends on any number of people that we don't know > to include a special marker whenever they release packages that lead > the user to nonfree software. Since these people eapparently > don't agree with our basic ideas about such packages, I don't think > we could count on them to do that. MELPA to a large part consists of a database of "recipes", one for each package that it builds and distributes. This tag can be put inside recipes, and thus be controlled by MELPA maintainers, and not by the packages authors themselves. If we provide some well-defined criteria for such tags, and pick a neutral-enough name, I don't see why the MELPA maintainers (who are quite reasonable people IME) wouldn't go for it. Question is, would you agree to add MELPA to the default list of package archives if they do? We'll also have to discuss how the user interface would look when dealing with those tags. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Proposal to include obligatory PGP verification of packages from any repository 2020-10-19 11:36 ` Dmitry Gutov @ 2020-10-19 12:43 ` Jean Louis 2020-10-19 15:55 ` Stefan Kangas 2020-10-19 18:28 ` Vasilij Schneidermann 2020-10-19 15:46 ` Proposal for an Emacs User Survey Drew Adams 2020-10-20 5:14 ` Richard Stallman 2 siblings, 2 replies; 838+ messages in thread From: Jean Louis @ 2020-10-19 12:43 UTC (permalink / raw) To: Dmitry Gutov; +Cc: mve1, Philip K., rms, thibaut.verron, emacs-devel This is related to MELPA subject and future Emacs repositories. PROPRIETARY JAVASCRIPT ON MICROSOFT GITHUB ISSUE: ================================================= I just guess that Github.com cannot be used with LibreJS, as I have tried it, LibreJS report problems, this means all developers and contributors to MELPA are automatically subjugated by Microsoft Github, which is and was not the point of Emacs as free software part of free operating system. Additionally Github.com does not support many browsers, they publicly say so, which in turn means that many users of free software browsers from free software distributions are unable to access Github.com, users of Github are supposed to use Firefox or Chrome or Microsoft Browsers, while I am using Icecat and Iceweaseal-UXP from Hyperbola GNU/Linux-libre -- so my experience with Github.com is narrowed, I cannot access large parts of the website. Developers using MELPA are misguided by Microsoft Github, and MELPA is only following the popularity trend. Thus developers or old and new contributors for reasons of getting included in MELPA are forced to use non-free Javascript and browsers that are mostly not available on free software distributions. MELPA is telling users on its website that it is extensible, but please "contribute your recipes via github, and we'll build the packages", they are tageting Github, and thus lead Emacs users to use non-free Javascript on Github. This is contradictory to purposes why free software systems have been created. There is https://savannah.nongnu.org then there is Trisquel hosting, they would easily add Emacs packages without problem https://devel.trisquel.info/users/sign_in then there are other non-free Javascript and friendly free software hosting providers. Could you maybe ask MELPA to switch to some free software hosting sites for code, that way website would be accessible without using proprietary Javascript. That would be right direction to go for MELPA. It is good if we make incentive to those people who contribute to MELPA to switch their hosting from Microsoft Github with proprietary Javascript and their policies to some of free software hosting providers, but what is really best is that MELPA switches to free software hosting code providers. AVOIDING EMACS PACKAGES WRAPPING PROPRIETARY SOFTWARE: ====================================================== This is other issue, it could be solved (as already somebody mentioned) with one package to be developed in GNU ELPA, named similar to "freedom-check" or even better as a built-in package that would warn Emacs users about usage of non-free software or any other freedom issues, it could ask user to disable those packages discovered on system that are wrapping non-free software. The package "freedom-check" would be for Emacs what is LibreJS on browsers and what is "your-freedom" on Hyperbola GNU/Linux-libre and other free software distributions. It could disable or remove the packages that were installed to wrap proprietary software. Additionally, it could disable repositories that do not care about users' freedom and would tell users why is it so. It would be good direction if such package is developed and then beside being distributed on GNU ELPA, also injected in MELPA, as it would be innovative package in users' interest, thus fully complying with MELPA principles. Let us not forget that inclusion of packages wrapping proprietary software represents large security risk as well, not only that it subjugates users or bring about a moral dillema. OTHER SECURITY ISSUES ON MELPA: =============================== For me largest security problem on MELPA is that Github.com is run by Microsoft, we have no idea what principles they share beyond commercial principles, and the more Emacs packages are hosted on Microsoft Github, the more probability is there for mischievous conduct or security breaches. Same can be said for hosting providers that value free sofware, security breaches are possible, but then we would know that people maintaining the server do care of users enough, to prevent mischievous conduct. A package can be thus accepted in MELPA and become approved, then later continuously updated, meaning without any control or supervision, and then automatically offered to users. Backdoor can be injected into users' Emacs and run on their computers. If I am wrong on how MELPA works, you may tell me, that is what I understood from their website. SO FAR I KNOW there is no system of signing packages and verification of such. I have verified MELPA git, and I cannot find that they are using GnuPG or gpg or other system that packages were really made by the author they claim to be made. This may be true at GNU ELPA too, I did not verify it, but I know at that GNU ELPA is not automatically built and offered to users blindly without verification (I at least believe they are verified). 1. Github.com may not even know if somebody cracks some developer's account and changes few packages to misbehave, if they would be alerted, they would not maybe act in the best interest of the free software project, they would act in their own best interest. 2. MELPA managers do approve only GNU GPL or GPL compatible software to be included, they do not however continually verify or control the software, in fact they pull it by using recipes and build it automatically and offer automatically to users. Users in turn accept blindly packages, even though there is no mechanism to make sure that package was made by the author that was approved by MELPA. Let us say MELPA could maintain the list of public keys of authors, and then accept only packages that are signed by those same authors, before having them built, this would increase security this security issue, but not solve it, if packages are not verified by human. 3. Other issue is that users cannot trust MELPA only, as packages should be distributable from MELPA to other repositories, so each single package should be verifiable by user as well. It is written in the Emacs manual: 41.4 Creating and Maintaining Package Archives, that: Maintaining a public package archive entails a degree of responsibility. When Emacs users install packages from your archive, those packages can cause Emacs to run arbitrary code with the permissions of the installing user. (This is true for Emacs code in general, not just for packages.) So you should ensure that your archive is well-maintained and keep the hosting system secure. One way to increase the security of your packages is to “sign” them using a cryptographic key. If you have generated a private/public gpg key pair, you can use gpg to sign the package like this: gpg -ba -o FILE.sig FILE But it is not implemented into Emacs to verify packages being signed, so my proposal is that Emacs get obligatory verification of a package if such package is arriving from any repository and to warn user if package was not signed. This would give initiative to MELPA to start thinking about security issues. That is one of reasons why Hyperbola GNU/Linux-libre and other GNU/Linux distributions package some major Emacs packages, as that way the package maintainers verify the package before it is included in the free software distribution. In the same manner Emacs should have a built-in package installation procedure (that can be circumvented by users' configuration) to verify all packages being installed by default. Jean ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal to include obligatory PGP verification of packages from any repository 2020-10-19 12:43 ` Proposal to include obligatory PGP verification of packages from any repository Jean Louis @ 2020-10-19 15:55 ` Stefan Kangas 2020-10-19 16:38 ` Jean Louis 2020-10-19 18:28 ` Vasilij Schneidermann 1 sibling, 1 reply; 838+ messages in thread From: Stefan Kangas @ 2020-10-19 15:55 UTC (permalink / raw) To: Jean Louis, Dmitry Gutov Cc: mve1, Philip K., rms, thibaut.verron, emacs-devel Jean Louis <bugs@gnu.support> writes: > One way to increase the security of your packages is to “sign” them > using a cryptographic key. If you have generated a private/public gpg > key pair, you can use gpg to sign the package like this: > > gpg -ba -o FILE.sig FILE > > But it is not implemented into Emacs to verify packages being signed, > so my proposal is that Emacs get obligatory verification of a package > if such package is arriving from any repository and to warn user if > package was not signed. This would give initiative to MELPA to start > thinking about security issues. > > That is one of reasons why Hyperbola GNU/Linux-libre and other > GNU/Linux distributions package some major Emacs packages, as that way > the package maintainers verify the package before it is included in > the free software distribution. > > In the same manner Emacs should have a built-in package installation > procedure (that can be circumvented by users' configuration) to verify > all packages being installed by default. We have signing of packages on the package archive side that is verified by default when it exists. See `package-check-signature'. (If I'm not mistaken, GNU ELPA signs packages but MELPA doesn't. Please correct me if I'm wrong.) Note that package signatures still leaves us open to replay attacks. See Bug#19479 and the branch scratch/package-security for an attempt to improve the situation. I think it would be useful if package archives could implement a requirement for signed commits before building a new package. This could be optional or mandatory, and would buy us an additional layer of protection against compromised developer credentials. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal to include obligatory PGP verification of packages from any repository 2020-10-19 15:55 ` Stefan Kangas @ 2020-10-19 16:38 ` Jean Louis 2020-10-19 17:30 ` Stefan Monnier 0 siblings, 1 reply; 838+ messages in thread From: Jean Louis @ 2020-10-19 16:38 UTC (permalink / raw) To: Stefan Kangas Cc: Philip K., rms, thibaut.verron, mve1, emacs-devel, Dmitry Gutov * Stefan Kangas <stefankangas@gmail.com> [2020-10-19 18:55]: > We have signing of packages on the package archive side that is verified > by default when it exists. See `package-check-signature'. (If I'm not > mistaken, GNU ELPA signs packages but MELPA doesn't. Please correct me > if I'm wrong.) Now I know about that. It was allow-unsigned as default, correct me if mistaken. The more packages there are around, the more this becomes potential problem, it is security hole, as warnings about potential problems are too few. Now when I turned it on, I cannot see or feel that some package was verified, I tried installing from ELPA, but did not see any difference, and cannot find any .sig files. It would be good for user to get those verifications, as verification should be doable personally. Package signing is not ultimate security, it is just one level making packages more secure. > Note that package signatures still leaves us open to replay attacks. > See Bug#19479 and the branch scratch/package-security for an attempt to > improve the situation. > I think it would be useful if package archives could implement a > requirement for signed commits before building a new package. This > could be optional or mandatory, and would buy us an additional layer of > protection against compromised developer credentials. I have seen there apparently good recommendation for improvement of package security. But we do not have it. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal to include obligatory PGP verification of packages from any repository 2020-10-19 16:38 ` Jean Louis @ 2020-10-19 17:30 ` Stefan Monnier 2020-10-19 17:47 ` Jean Louis 2020-10-19 18:53 ` Stefan Kangas 0 siblings, 2 replies; 838+ messages in thread From: Stefan Monnier @ 2020-10-19 17:30 UTC (permalink / raw) To: Jean Louis Cc: Philip K., rms, thibaut.verron, mve1, emacs-devel, Stefan Kangas, Dmitry Gutov > verified, I tried installing from ELPA, but did not see any Side note: "ELPA" is the name of the protocol/infrastructure. So now I don't know if you installed from Mermelada, GNU ELPA, MELPA, or yet some other ELPA archive. Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal to include obligatory PGP verification of packages from any repository 2020-10-19 17:30 ` Stefan Monnier @ 2020-10-19 17:47 ` Jean Louis 2020-10-19 18:02 ` Stefan Monnier 2020-10-19 18:53 ` Stefan Kangas 1 sibling, 1 reply; 838+ messages in thread From: Jean Louis @ 2020-10-19 17:47 UTC (permalink / raw) To: Stefan Monnier Cc: Philip K., rms, thibaut.verron, mve1, emacs-devel, Stefan Kangas, Dmitry Gutov * Stefan Monnier <monnier@iro.umontreal.ca> [2020-10-19 20:31]: > > verified, I tried installing from ELPA, but did not see any > > Side note: "ELPA" is the name of the protocol/infrastructure. > So now I don't know if you installed from Mermelada, GNU ELPA, MELPA, or > yet some other ELPA archive. Alright I understood it so from info document. When enabled, that variable we spoke about that should be T to verify packages, it is I assume general for any package archive. So I have tried installing some from ELPA and did not see any difference. By the way, Marmelade is not eatable any more. There are just few well known, ELPA, Org and MELPA. It would be good that package authors start publishing their own repositories to decentralize and ensure better of security. I would trust some authors more if I am getting their packages from their domain, signed by their keys. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal to include obligatory PGP verification of packages from any repository 2020-10-19 17:47 ` Jean Louis @ 2020-10-19 18:02 ` Stefan Monnier 2020-10-19 19:04 ` Jean Louis 0 siblings, 1 reply; 838+ messages in thread From: Stefan Monnier @ 2020-10-19 18:02 UTC (permalink / raw) To: Jean Louis Cc: Philip K., rms, thibaut.verron, mve1, emacs-devel, Stefan Kangas, Dmitry Gutov > tried installing some from ELPA and did not see any difference. What difference did you expect to see? > There are just few well known, ELPA, Org and MELPA. Again, there is no ELPA archive named "ELPA". Please try and avoid spreading the confusion between ELPA and GNU ELPA. Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal to include obligatory PGP verification of packages from any repository 2020-10-19 18:02 ` Stefan Monnier @ 2020-10-19 19:04 ` Jean Louis 2020-10-19 20:17 ` Stefan Monnier 0 siblings, 1 reply; 838+ messages in thread From: Jean Louis @ 2020-10-19 19:04 UTC (permalink / raw) To: Stefan Monnier Cc: Philip K., rms, thibaut.verron, mve1, emacs-devel, Stefan Kangas, Dmitry Gutov * Stefan Monnier <monnier@iro.umontreal.ca> [2020-10-19 21:02]: > > tried installing some from ELPA and did not see any difference. > > What difference did you expect to see? I really expected to see that it is verified, like some message, feedback in the Message buffer, but it just goes very silent, thus user has to rely that package vas checked. The name of function package-check-signature gives me more impression that if I am the one who is setting the variable, that I would be in some kind of control to know that signature of the package is checked. Without message I see nothing, so Emacs is checking, but user does not know that package was checked for signature. I would rather expect message shown, just as it is not shown for unsigned packages. > > There are just few well known, ELPA, Org and MELPA. > > Again, there is no ELPA archive named "ELPA". > Please try and avoid spreading the confusion between ELPA and GNU ELPA. That is right, I understand, so instead of ELPA which is meant for general protocol, is better to say GNU ELPA. Regarding packages in GNU ELPA, can I now assume they are all signed? Is there a policy that GNU ELPA packages should be signed? That policy would be good to have. What I expect is a method for user to easily verify and know by which key was which package signed, such function should exist. I also expect that such verification should be by default, but default was to accept unsigned, which is security issue in Emacs. Today is common from package managers to expect at least automatic verification of signatures. It would be better if Emacs is delivered with the variable: package-check-signature to be by default at least T or ALL to verify all signatures. Right now default is to accept unsigned. I am very surprised. What I would like to see is: If the package-check-signature variable is for all types from packages, those downloaded any how, or from file system, and for those from archives, that ne wvariable is implemented so that packages downloaded from various centralized archives shall be checked for signature by DEFAULT. - new variable: package-from-archive-check-signature to be by default T to check signature, with the warning in the description of the variable. - current variable: package-check-signature, for this one, I still study if it is valid for any packages, I can see I could install package from file without being checked for signature. So that is not my expectation, it probably works only for packages from archive, but not for any packages. My expectation is when this variable is set that it verifies all packages that user is installing. If there is only intended use of this variable for archive packages, then it is fine, but then documentation should not just say: Non-nil means to check package signatures when installing, but it should refer to package installing from archives I am installing often packages from file system by using package-install-file - in that case that variable does not affect other sources but archives, users shall be warned in documentation strings or info that installing packages is risky activity. What I wish to say, which may not be liked by many, I would like that variable ensures that packages delivered through any current or future onlinen archives are by default verified to be signed. This would increase general security for Emacs users. This would make necessity for MELPA to secure the packages by signing them, thus giving little more safety to users. As the situation how we have it now, those users of MELPA who value the number of 4700+ packages being offered are more and more exposed to potential risks. There will be other repositories, anybody can then duplicate the packages, but they cannot change signatures, they would need to make new signatures, at least there would be some trace which key signed which package. Is making archive packages checkable by default for signatures difficult for some practical reasons other than forcing MELPA to offer new security level? ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal to include obligatory PGP verification of packages from any repository 2020-10-19 19:04 ` Jean Louis @ 2020-10-19 20:17 ` Stefan Monnier 2020-10-19 21:02 ` Jean Louis 0 siblings, 1 reply; 838+ messages in thread From: Stefan Monnier @ 2020-10-19 20:17 UTC (permalink / raw) To: Jean Louis Cc: Philip K., rms, thibaut.verron, mve1, emacs-devel, Stefan Kangas, Dmitry Gutov > I would rather expect message shown, just as it is not shown for > unsigned packages. `package.el` should emit a message when installing a package without any signature, since that's the odd and undesirable case. I find it perfectly normal not to say anything when the signature check succeeded. > Regarding packages in GNU ELPA, can I now assume they are all signed? Of course. It's been that way since Emacs-24.4, IIRC. > Is there a policy that GNU ELPA packages should be signed? Not sure what that would mean: *we* sign it, so there's no policy to enforce. At most there are bugs to fix if the sigs are missing or incorrect. > What I expect is a method for user to easily verify and know by which > key was which package signed, such function should exist. What does Debian do in this respect? > I also expect that such verification should be by default, but default > was to accept unsigned, which is security issue in Emacs. 2 reasons: - the sig-checking code (i.e. PGP) might not be installed and we did not want to add it as a prerequisite. - the signature system was introduced relatively shortly before it was deployed for Emacs-24.4, so we did not want to break it for the other ELPA archives. Regarding the second point, AFAICT Melpa still doesn't sign its packages, so its users presumably rely on `https` as their only line of defense. One of the main reasons might be that there is/was no easy way to add other trusted keys to Emacs's keyring (tho the `gnu-elpa-keyring-update` shows it can be done) so even if they signed their packages their users would have to take some extra step to add their key to the trusted keys. Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal to include obligatory PGP verification of packages from any repository 2020-10-19 20:17 ` Stefan Monnier @ 2020-10-19 21:02 ` Jean Louis [not found] ` <jwvft69evmy.fsf-monnier+emacs@gnu.org> 0 siblings, 1 reply; 838+ messages in thread From: Jean Louis @ 2020-10-19 21:02 UTC (permalink / raw) To: Stefan Monnier Cc: Philip K., rms, thibaut.verron, mve1, emacs-devel, Stefan Kangas, Dmitry Gutov * Stefan Monnier <monnier@iro.umontreal.ca> [2020-10-19 23:23]: > > I would rather expect message shown, just as it is not shown for > > unsigned packages. > > `package.el` should emit a message when installing a package without any > signature, since that's the odd and undesirable case. I find it > perfectly normal not to say anything when the signature check succeeded. > > > Regarding packages in GNU ELPA, can I now assume they are all signed? > > Of course. It's been that way since Emacs-24.4, IIRC. > > > Is there a policy that GNU ELPA packages should be signed? > > Not sure what that would mean: *we* sign it, so there's no policy to > enforce. At most there are bugs to fix if the sigs are missing > or incorrect. It would be good to implement the policy. > > What I expect is a method for user to easily verify and know by which > > key was which package signed, such function should exist. > > What does Debian do in this respect? There are ways to verify package authenticity, so it is automated and there is way to verify it package by package, I am on Hyperbola GNU/Linux-libre, derivative of Archlinux, there is way to use pacman package manager to verify authenticity. Vasilij pointed out how it should be done. Verifications in Debian or Archlinux how I see it, happen in real time during installation and that is by default. > > I also expect that such verification should be by default, but default > > was to accept unsigned, which is security issue in Emacs. > > 2 reasons: > - the sig-checking code (i.e. PGP) might not be installed and we did > not want to add it as a prerequisite. You know it better, maybe gnutls can be used as it is how I see it, part of GNU Emacs here, but may not be part on every OS, I do not know. It has OpenPGP API: https://www.gnutls.org/manual/html_node/OpenPGP-API.html So instead of using external gpg program, maybe you as developers could use gnutls library and that API to create signatures for packages in case that PGP/GnuPG cannot work. > - the signature system was introduced relatively shortly before it was > deployed for Emacs-24.4, so we did not want to break it for the other > ELPA archives. I understand and I find it unfortunate, and still suggest that it becomes enabled now, and not years there after. > Regarding the second point, AFAICT Melpa still doesn't sign its > packages, so its users presumably rely on `https` as their only line > of defense. One of the main reasons might be that there is/was no easy > way to add other trusted keys to Emacs's keyring (tho the > `gnu-elpa-keyring-update` shows it can be done) so even if they signed > their packages their users would have to take some extra step to add > their key to the trusted keys. And that is in best interest of users. I think that it sounds tedious, yet it is in best interest to users. ^ permalink raw reply [flat|nested] 838+ messages in thread
[parent not found: <jwvft69evmy.fsf-monnier+emacs@gnu.org>]
* Re: Proposal to include obligatory PGP verification of packages from any repository [not found] ` <jwvft69evmy.fsf-monnier+emacs@gnu.org> @ 2020-10-20 7:40 ` Jean Louis 2020-10-22 21:25 ` Stefan Monnier 0 siblings, 1 reply; 838+ messages in thread From: Jean Louis @ 2020-10-20 7:40 UTC (permalink / raw) To: Stefan Monnier Cc: Philip K., rms, thibaut.verron, mve1, emacs-devel, Stefan Kangas, Dmitry Gutov * Stefan Monnier <monnier@iro.umontreal.ca> [2020-10-20 00:53]: > >> > Is there a policy that GNU ELPA packages should be signed? > >> Not sure what that would mean: *we* sign it, so there's no policy to > >> enforce. At most there are bugs to fix if the sigs are missing > >> or incorrect. > > It would be good to implement the policy. > > I don't know what that means (neither "the policy" nor "implement"). Rules of maintenance simply said: - that every request to any ELPA goes over SSL connection, to totally disable non-SSL connections to archives. Many countries spy on their citizens, and in many of those countries citizens are using encryption features, even it could be illegal to use encryption. By using non-SSL connection or allowing such, possibility is there that user get in danger of life. This is one very real example, it will look unreal to many who are in normal countries. I have a friend in such country. - that all packages are signed by default and that Emacs expects such by default There is set of principles for Emacs Lisp packaging in the info manual, those changes are only beneficial for future. Read on this link that Vasilij have presented to me yesterday: https://medium.com/hackernoon/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5 That does happen. Research the report on this site: https://snyk.io/blog/javascript-frameworks-security-report-2019/ Compare insecurities on similar software package repositories with other languages to Emacs, and implement policies to prevent insecurities in future. To implement means in this context to follow through, follow up, follow out, carry out, implement, put through, go through -- pursue to a conclusion or bring to a successful issue; (Wordnet) there may be definitions in othe context. I speak of carrying out. Policy means a plan of action adopted by an individual or social group; "it was a policy of retribution"; "a politician keeps changing his policies" (Wordnet) -- there may be other definitons in other context, I speak of adopting plan of action for Emacs development. > >> > What I expect is a method for user to easily verify and know by which > >> > key was which package signed, such function should exist. > >> What does Debian do in this respect? > > There are ways to verify package authenticity, > > How? What does "package authenticity" mean? > Do you get to see which key signed which package? I skip this, I am sure you know it. > > Vasilij pointed out how it should be done. Verifications in Debian or > > Archlinux how I see it, happen in real time during installation and > > that is by default. > > Right, just as we do with GNU ELPA, AFAICT. It is not by default surprisingly to me. I had to turn on the option to have packages verified for signatures. > > So instead of using external gpg program, maybe you as developers > > could use gnutls library and that API to create signatures for > > packages in case that PGP/GnuPG cannot work. > > The problem is not to create signatures (which we do on our own machines > where we can easily make sure PGP is installed) but to verify them. Maybe gnutls offers that API, I cannot know technically, I could see the API is there. > >> - the signature system was introduced relatively shortly before it was > >> deployed for Emacs-24.4, so we did not want to break it for the other > >> ELPA archives. > > I understand and I find it unfortunate, and still suggest that it > > becomes enabled now, and not years there after. > > The current default made sense then. Maybe it should be changed > now, indeed. Thank you, Think about the growing number of: - users - developers - packages - fascism and varieties of oppression in the world Jean ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal to include obligatory PGP verification of packages from any repository 2020-10-20 7:40 ` Jean Louis @ 2020-10-22 21:25 ` Stefan Monnier 2020-10-23 9:17 ` Jean Louis 0 siblings, 1 reply; 838+ messages in thread From: Stefan Monnier @ 2020-10-22 21:25 UTC (permalink / raw) To: Jean Louis Cc: Philip K., rms, thibaut.verron, mve1, emacs-devel, Stefan Kangas, Dmitry Gutov >> >> > Is there a policy that GNU ELPA packages should be signed? >> >> Not sure what that would mean: *we* sign it, so there's no policy to >> >> enforce. At most there are bugs to fix if the sigs are missing >> >> or incorrect. >> > It would be good to implement the policy. >> I don't know what that means (neither "the policy" nor "implement"). > Rules of maintenance simply said: So by "implement" you mean: write it in the doc that describes the ELPA protocol? > - that every request to any ELPA goes over SSL connection, to totally > disable non-SSL connections to archives. Many countries spy on their > citizens, and in many of those countries citizens are using > encryption features, even it could be illegal to use encryption. By > using non-SSL connection or allowing such, possibility is there that > user get in danger of life. The part I don't understand here is "or allowing such". I see the danger of using a non-encrypted connection but not the danger of allowing such. >> >> > What I expect is a method for user to easily verify and know by which >> >> > key was which package signed, such function should exist. >> >> What does Debian do in this respect? >> > There are ways to verify package authenticity, >> How? What does "package authenticity" mean? >> Do you get to see which key signed which package? > I skip this, I am sure you know it. No, I don't, that's why I asked. More specifically, from where I sit, I don't see much difference between the way Debian does it and the way GNU ELPA does it. And as a Debian user I don't know how to "easily verify" nor "know by which key". >> > Vasilij pointed out how it should be done. Verifications in Debian or >> > Archlinux how I see it, happen in real time during installation and >> > that is by default. >> Right, just as we do with GNU ELPA, AFAICT. > It is not by default surprisingly to me. It is by default in my book. > I had to turn on the option to have packages verified for signatures. I think those users who posted questions about signature verification failures back when we changed to a new key are evidence to the contrary. >> The problem is not to create signatures (which we do on our own machines >> where we can easily make sure PGP is installed) but to verify them. > Maybe gnutls offers that API, I cannot know technically, I could see > the API is there. Patch welcome (as long as it doesn't end up reimplementing part of GPG). Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal to include obligatory PGP verification of packages from any repository 2020-10-22 21:25 ` Stefan Monnier @ 2020-10-23 9:17 ` Jean Louis 2020-10-23 14:52 ` Stefan Monnier 0 siblings, 1 reply; 838+ messages in thread From: Jean Louis @ 2020-10-23 9:17 UTC (permalink / raw) To: Stefan Monnier Cc: Philip K., rms, thibaut.verron, mve1, emacs-devel, Stefan Kangas, Dmitry Gutov * Stefan Monnier <monnier@iro.umontreal.ca> [2020-10-23 00:25]: > >> >> > Is there a policy that GNU ELPA packages should be signed? > >> >> Not sure what that would mean: *we* sign it, so there's no policy to > >> >> enforce. At most there are bugs to fix if the sigs are missing > >> >> or incorrect. > >> > It would be good to implement the policy. > >> I don't know what that means (neither "the policy" nor "implement"). > > Rules of maintenance simply said: > > So by "implement" you mean: write it in the doc that describes the > ELPA protocol? Thank you. I meant to make it as a rule to sign packages, and that is should be default in Emacs to accept only sign packages, that increases level of security rather than leaving it acceptable for users to get unsigned packages. It is definitely now everything about security, yet it is one level. Conditionally, if such feature is accepted in Emacs, than in Packaging section would be described that packages have to be signed, and not only that it is one way to increase the security. > > - that every request to any ELPA goes over SSL connection, to totally > > disable non-SSL connections to archives. Many countries spy on their > > citizens, and in many of those countries citizens are using > > encryption features, even it could be illegal to use encryption. By > > using non-SSL connection or allowing such, possibility is there that > > user get in danger of life. > > The part I don't understand here is "or allowing such". I see the > danger of using a non-encrypted connection but not the danger of > allowing such. My purpose was to tell you that if Emacs developers allow non-SSL by default that users are automatically put at certain risks and that is better to ask for SSL by default. Users who maybe do not have SSL, they can turn it off for themselves. > >> >> > What I expect is a method for user to easily verify and know by which > >> >> > key was which package signed, such function should exist. > >> >> What does Debian do in this respect? > >> > There are ways to verify package authenticity, > >> How? What does "package authenticity" mean? > >> Do you get to see which key signed which package? > > I skip this, I am sure you know it. > > No, I don't, that's why I asked. More specifically, from where I sit, > I don't see much difference between the way Debian does it and the way > GNU ELPA does it. And as a Debian user I don't know how to "easily > verify" nor "know by which key". You are right, it is vague to say easy.By easily I meant that there is option to verify the package. Let us see this as reference to some model design: https://debian-handbook.info/browse/stable/sect.package-authentication.html > When a third-party package source is added to the sources.list file, > APT needs to be told to trust the corresponding GPG authentication key So GNU Emacs users should maybe trust blindly packages from ELPA, but not all packages by default. To trust other packages they should be able transparently to import PGP keys and be able to see the fingerprints. By seeing fingerprints, users can at least see the same fingerprint on the website. For better verification it should be necessary to contact developers and make sure that fingerprints are same and valid. Packages are meant to be distributable as well, if they are signed, signature should be also fetched, but that is probably not original design of Emacs. In my opinion, it should be. Signatures should be inside of the package directory, ~/emcas.d/elpa/package-0.0/file.el.gpg As if packages are distributable, one user from club A could simply distribute packages on CD/USB/SD-card to other, or could transfer by network. The user receiving packages beyond GNU ELPA archive, even those without Internet, but having the trusted keys, should be able to verify that packages have been signed by trusted keys, by central authority in this case Emacs ELPA and trusted people maintaining such. -- Jean Louis ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal to include obligatory PGP verification of packages from any repository 2020-10-23 9:17 ` Jean Louis @ 2020-10-23 14:52 ` Stefan Monnier 2020-10-23 16:59 ` Jean Louis 0 siblings, 1 reply; 838+ messages in thread From: Stefan Monnier @ 2020-10-23 14:52 UTC (permalink / raw) To: Jean Louis Cc: Philip K., rms, thibaut.verron, mve1, emacs-devel, Stefan Kangas, Dmitry Gutov > I meant to make it as a rule to sign packages, and that is should be > default in Emacs to accept only sign packages, that increases level of > security rather than leaving it acceptable for users to get unsigned > packages. It is definitely now everything about security, yet it is > one level. IOW, you're just restating in other words your request to change `package-check-signature` to t? > My purpose was to tell you that if Emacs developers allow non-SSL by > default that users are automatically put at certain risks and that is > better to ask for SSL by default. And here you're suggesting that the default value of `package-archives` should always use `https` regardless of the `gnutls-available-p`? > So GNU Emacs users should maybe trust blindly packages from ELPA, but > not all packages by default. To trust other packages they should be > able transparently to import GPG keys and be able to see the > fingerprints. IIUC I basically said the same earlier when I explained that maybe one reason Melpa still doesn't sign its files is the lack of a clean/good way for the user to add Melpa's keys to `package.el`s keyring. Patches welcome in this area. > Packages are meant to be distributable as well, if they are signed, > signature should be also fetched, but that is probably not original > design of Emacs. In my opinion, it should be. Signatures should be > inside of the package directory, > ~/emcas.d/elpa/package-0.0/file.el.gpg This makes way too many assumptions to be worth discussing, IMO. For the case of "single file ELPA package" (i.e. those files distributed as a single .el file) maybe that can work without too much trouble (tho there's still the issue of trusting the accompanying .elc file), but for the more common packages distributed as tarballs, I think this is completely impractical. A saner approach might be to keep a "cache" of the packages in their original (not-installed) form and make that available as a "local ELPA archive" from which you can redistribute those packages to other machines. My impression is that this would be better served by a separate package than by trying to add the feature directly to `package.el`, especially since I suspect it would remain a fairly unusual scenario. Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal to include obligatory PGP verification of packages from any repository 2020-10-23 14:52 ` Stefan Monnier @ 2020-10-23 16:59 ` Jean Louis 2020-10-23 18:25 ` Stefan Monnier 0 siblings, 1 reply; 838+ messages in thread From: Jean Louis @ 2020-10-23 16:59 UTC (permalink / raw) To: Stefan Monnier Cc: Philip K., rms, thibaut.verron, mve1, emacs-devel, Stefan Kangas, Dmitry Gutov * Stefan Monnier <monnier@iro.umontreal.ca> [2020-10-23 17:52]: > > I meant to make it as a rule to sign packages, and that is should be > > default in Emacs to accept only sign packages, that increases level of > > security rather than leaving it acceptable for users to get unsigned > > packages. It is definitely now everything about security, yet it is > > one level. > > IOW, you're just restating in other words your request to change > `package-check-signature` to t? Yes. > > My purpose was to tell you that if Emacs developers allow non-SSL by > > default that users are automatically put at certain risks and that is > > better to ask for SSL by default. > > And here you're suggesting that the default value of `package-archives` > should always use `https` regardless of the `gnutls-available-p`? I understand from that statement that probably not every platform will have gnutls or whatever other solution. Let me mention that in some countries governments forbid usage of various networks and software, also encryption software, in particular I have a friend in Iran and I know what can happen to a person. And networks are spied over. This means in particular that misunderstanding or usage of encryption tools could lead to unjust arrests and broken families. Loading some packages from Emacs could automatically trigger spying governments to abuse their citizens. Reference: https://security.stackexchange.com/questions/10992/encryption-laws-in-iran There are other similar cases easy to find on search engines. Now if that cannot be made default, then every non-SSL connection should give serious warning to a user and should even ask user if one wants to connect or not, because it is non-SSL. Such warning should give good reference that data is visible on network and prone to Big Brother's eyes. > > Packages are meant to be distributable as well, if they are signed, > > signature should be also fetched, but that is probably not original > > design of Emacs. In my opinion, it should be. Signatures should be > > inside of the package directory, > > ~/emcas.d/elpa/package-0.0/file.el.gpg > > This makes way too many assumptions to be worth discussing, IMO. > For the case of "single file ELPA package" (i.e. those files > distributed as a single .el file) maybe that can work without too much > trouble (tho there's still the issue of trusting the accompanying .elc > file), but for the more common packages distributed as tarballs, I think > this is completely impractical. Maybe tar can be signed as such? > A saner approach might be to keep a "cache" of the packages in their > original (not-installed) form and make that available as a "local ELPA > archive" from which you can redistribute those packages to > other machines. Yes. For me is no problem. I speak for wide user base. Ability for each ELPA to download full set of packages and keep it as local ELPA would be convenient for many users who do not have stable Internet. -- Jean Louis ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal to include obligatory PGP verification of packages from any repository 2020-10-23 16:59 ` Jean Louis @ 2020-10-23 18:25 ` Stefan Monnier 2020-10-24 6:26 ` Jean Louis 0 siblings, 1 reply; 838+ messages in thread From: Stefan Monnier @ 2020-10-23 18:25 UTC (permalink / raw) To: Jean Louis Cc: Philip K., rms, thibaut.verron, mve1, emacs-devel, Stefan Kangas, Dmitry Gutov >> IOW, you're just restating in other words your request to change >> `package-check-signature` to t? > Yes. I'm find with it, but it's not up to me and I think it will require more code changes so that errors are reported in a way that's more friendly to the user (e.g. so the users can figure out whether the problem is with the signature, the lack of key, or the lack of GPG, for example). I suggest you `M-x report-emacs-bug` with this specific request and accompany it with a patch that improves the error handling. >> > My purpose was to tell you that if Emacs developers allow non-SSL by >> > default that users are automatically put at certain risks and that is >> > better to ask for SSL by default. >> And here you're suggesting that the default value of `package-archives` >> should always use `https` regardless of the `gnutls-available-p`? > I understand from that statement that probably not every platform will > have gnutls or whatever other solution. I believe it is available on all the platforms we support, but you can build Emacs without support for it (and under Windows, IIUC, you can build it with support for gnutls and later run it without libgnutls in which case it'll behave pretty much as if it had been built without support for gnutls). > Let me mention that ... Yes, you already said so, and I believe it's been common knowledge on this mailing-list for a while. >> This makes way too many assumptions to be worth discussing, IMO. >> For the case of "single file ELPA package" (i.e. those files >> distributed as a single .el file) maybe that can work without too much >> trouble (tho there's still the issue of trusting the accompanying .elc >> file), but for the more common packages distributed as tarballs, I think >> this is completely impractical. > Maybe tar can be signed as such? It is. But the installed files are not the tarball, and it's difficult to reproduce the tarball from the installed files in order to check that they still "match the signature". >> A saner approach might be to keep a "cache" of the packages in their >> original (not-installed) form and make that available as a "local ELPA >> archive" from which you can redistribute those packages to >> other machines. > Yes. For me is no problem. I speak for wide user base. Ability for > each ELPA to download full set of packages and keep it as local ELPA > would be convenient for many users who do not have stable Internet. You can mirror GNU ELPA via rsync. Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal to include obligatory PGP verification of packages from any repository 2020-10-23 18:25 ` Stefan Monnier @ 2020-10-24 6:26 ` Jean Louis 2020-10-24 15:29 ` Stefan Monnier 0 siblings, 1 reply; 838+ messages in thread From: Jean Louis @ 2020-10-24 6:26 UTC (permalink / raw) To: Stefan Monnier Cc: Philip K., rms, thibaut.verron, mve1, emacs-devel, Stefan Kangas, Dmitry Gutov * Stefan Monnier <monnier@iro.umontreal.ca> [2020-10-23 21:26]: > You can mirror GNU ELPA via rsync. Great. I cannot find instructions for that on website, do you have a reference? -- Jean Louis ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal to include obligatory PGP verification of packages from any repository 2020-10-24 6:26 ` Jean Louis @ 2020-10-24 15:29 ` Stefan Monnier 0 siblings, 0 replies; 838+ messages in thread From: Stefan Monnier @ 2020-10-24 15:29 UTC (permalink / raw) To: Jean Louis Cc: Philip K., rms, thibaut.verron, mve1, emacs-devel, Stefan Kangas, Dmitry Gutov >> You can mirror GNU ELPA via rsync. > Great. I cannot find instructions for that on website, do you have a > reference? searching for "elpa rsync" lead me (after a few steps) to: https://lists.gnu.org/archive/html/emacs-devel/2016-07/msg00709.html -- Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal to include obligatory PGP verification of packages from any repository 2020-10-19 17:30 ` Stefan Monnier 2020-10-19 17:47 ` Jean Louis @ 2020-10-19 18:53 ` Stefan Kangas 2020-10-19 18:57 ` Vasilij Schneidermann 2020-10-19 19:20 ` Stefan Monnier 1 sibling, 2 replies; 838+ messages in thread From: Stefan Kangas @ 2020-10-19 18:53 UTC (permalink / raw) To: Stefan Monnier, Jean Louis Cc: Philip K., rms, thibaut.verron, mve1, emacs-devel, Dmitry Gutov Stefan Monnier <monnier@iro.umontreal.ca> writes: > Side note: "ELPA" is the name of the protocol/infrastructure. > So now I don't know if you installed from Mermelada, GNU ELPA, MELPA, or > yet some other ELPA archive. Is Mermelada the Hispanic version of Marmalade? PS. In other news, I get a 502 Bad Gateway error now when visiting https://marmalade-repo.org/ ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal to include obligatory PGP verification of packages from any repository 2020-10-19 18:53 ` Stefan Kangas @ 2020-10-19 18:57 ` Vasilij Schneidermann 2020-10-19 19:20 ` Stefan Monnier 1 sibling, 0 replies; 838+ messages in thread From: Vasilij Schneidermann @ 2020-10-19 18:57 UTC (permalink / raw) To: Stefan Kangas Cc: Philip K., Jean Louis, thibaut.verron, mve1, emacs-devel, Stefan Monnier, Dmitry Gutov, rms [-- Attachment #1: Type: text/plain, Size: 298 bytes --] > PS. In other news, I get a 502 Bad Gateway error now when visiting > https://marmalade-repo.org/ I've poked other people to poke Nic Ferrier who then promised on Twitter to look into it soonish. His website seems to be affected as well, so I hope it's just a misconfiguration of the host. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal to include obligatory PGP verification of packages from any repository 2020-10-19 18:53 ` Stefan Kangas 2020-10-19 18:57 ` Vasilij Schneidermann @ 2020-10-19 19:20 ` Stefan Monnier 1 sibling, 0 replies; 838+ messages in thread From: Stefan Monnier @ 2020-10-19 19:20 UTC (permalink / raw) To: Stefan Kangas Cc: Philip K., Jean Louis, rms, thibaut.verron, mve1, emacs-devel, Dmitry Gutov >> Side note: "ELPA" is the name of the protocol/infrastructure. >> So now I don't know if you installed from Mermelada, GNU ELPA, MELPA, or >> yet some other ELPA archive. > Is Mermelada the Hispanic version of Marmalade? Interesting mistake, indeed ;-) Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal to include obligatory PGP verification of packages from any repository 2020-10-19 12:43 ` Proposal to include obligatory PGP verification of packages from any repository Jean Louis 2020-10-19 15:55 ` Stefan Kangas @ 2020-10-19 18:28 ` Vasilij Schneidermann 2020-10-19 19:00 ` ELPA security (was: Proposal to include obligatory PGP verification of packages from any repository) Stefan Monnier ` (2 more replies) 1 sibling, 3 replies; 838+ messages in thread From: Vasilij Schneidermann @ 2020-10-19 18:28 UTC (permalink / raw) To: Jean Louis Cc: Philip K., rms, thibaut.verron, mve1, emacs-devel, Dmitry Gutov [-- Attachment #1: Type: text/plain, Size: 15712 bytes --] As someone working in information security, I feel compelled to reply to this in detail as your email contains several claims I am not comfortable with being taken at face value. > I just guess that Github.com cannot be used with LibreJS, as I have > tried it, LibreJS report problems, this means all developers and > contributors to MELPA are automatically subjugated by Microsoft > Github, which is and was not the point of Emacs as free software part > of free operating system. There is a difference between trying (enabling LibreJS and looking at how many scripts it blocked) and trying (enabling LibreJS and actually using the website while paying attention to how functional it is). Out of curiosity I've attempted the latter as it's a more meaningful test, using the latest version of Firefox Developer Edition on Arch: - Repositories can be created - Issues can be created - Forks can be created - Pull requests can be created, with the limitation that the merge preview is broken. This doesn't matter though as it's up to MELPA maintainers to review the pull request. - Account creation is broken. I can fill out the first screen (username, email address, password), then get stuck on the second screen as it relies on an external CAPTCHA service. I suspect I can complete the process by temporarily allowing the JS script and continue contributing to repositories, but haven't verified that part. My verdict so far: Github almost passes the test. If one does have an account already (from what I've seen you do), there is no excuse for you to not contribute. If one doesn't, they'll have to ponder whether whitelisting the CAPTCHA is worth it. > Additionally Github.com does not support many browsers, they publicly > say so, which in turn means that many users of free software browsers > from free software distributions are unable to access Github.com, > users of Github are supposed to use Firefox or Chrome or Microsoft > Browsers, while I am using Icecat and Iceweaseal-UXP from Hyperbola > GNU/Linux-libre -- so my experience with Github.com is narrowed, I > cannot access large parts of the website. From a security perspective it's a bad idea to use any browser outside of the main stream as only the largest browser vendors manage keeping up to speed with security issues. While one can use a browser based on them, there will be issues. As a side point, Debian settled its trademark dispute with Mozilla and no longer offers rebranded versions of Firefox. Therefore Debian users will not face browser incompatibility problems and avoid such security issues. Something else worth trying is hub [1]. It seems to allow performing the expected contribution workflow from the command line. > Developers using MELPA are misguided by Microsoft Github, and MELPA is > only following the popularity trend. Thus developers or old and new > contributors for reasons of getting included in MELPA are forced to > use non-free Javascript and browsers that are mostly not available on > free software distributions. > > MELPA is telling users on its website that it is extensible, but > please "contribute your recipes via github, and we'll build the > packages", they are tageting Github, and thus lead Emacs users to use > non-free Javascript on Github. This is contradictory to purposes why > free software systems have been created. This is a regrettable aspect of MELPA (although I disagree with non-free JavaScript or security being a problem), I don't have expectations for it to change as MELPA's philosophy revolves around the central principle of going with the most convenient mode of operation for developers to publish their packages: - Use Github, the most popular gratis Git hosting service - Use Github's contribution workflow (forking and "pull requests") - Automatically fetch packages from developers (as opposed to having them submit/upload new versions) - Automatically rebuild packages after each detected commit - Remove support for unpopular alternative workflows to reduce maintenance effort (Emacswiki, Bazaar, CVS, Darcs, Fossil, Subversion) One does not share a package on MELPA to further the goals of the free software movement, one does so to reach as many Emacs users as possible with relatively little effort (which excludes GNU ELPA, we'll have to see whether the same holds true for non-GNU ELPA). > There is https://savannah.nongnu.org then there is Trisquel hosting, > they would easily add Emacs packages without problem > https://devel.trisquel.info/users/sign_in then there are other > non-free Javascript and friendly free software hosting providers. Savannah does not strike me as an adequate alternative for people used to Github. For starters it requires approval of each project before it's publicly visible. I'll have to do a proper evaluation of it though before I can comment further on this aspect. Gitlab is the closest equivalent, though not perfect either. For minimalism and integration of an email-centric workflow sourcehut looks ideal, once it leaves its alpha status. > Could you maybe ask MELPA to switch to some free software hosting > sites for code, that way website would be accessible without using > proprietary Javascript. > > That would be right direction to go for MELPA. > > It is good if we make incentive to those people who contribute to > MELPA to switch their hosting from Microsoft Github with proprietary > Javascript and their policies to some of free software hosting > providers, but what is really best is that MELPA switches to free > software hosting code providers. As elaborated above, it is unlikely to happen. Adherence to GNU principles for non-GNU projects is not a priority. See also the MELPA maintainers' response to a thread you've created [2]. > This is other issue, it could be solved (as already somebody > mentioned) with one package to be developed in GNU ELPA, named similar > to "freedom-check" or even better as a built-in package that would > warn Emacs users about usage of non-free software or any other freedom > issues, it could ask user to disable those packages discovered on > system that are wrapping non-free software. > > The package "freedom-check" would be for Emacs what is LibreJS on > browsers and what is "your-freedom" on Hyperbola GNU/Linux-libre and > other free software distributions. > > It could disable or remove the packages that were installed to wrap > proprietary software. Additionally, it could disable repositories that > do not care about users' freedom and would tell users why is it so. > > It would be good direction if such package is developed and then > beside being distributed on GNU ELPA, also injected in MELPA, as it > would be innovative package in users' interest, thus fully complying > with MELPA principles. This is an interesting idea, though it will require continuous updates for best effect. Even if it doesn't prove to be effective in practice, having a detailed list of what exactly is a problem to one's freedoms would be a useful side effect for users caring about this. > For me largest security problem on MELPA is that Github.com is run by > Microsoft, we have no idea what principles they share beyond > commercial principles, and the more Emacs packages are hosted on > Microsoft Github, the more probability is there for mischievous > conduct or security breaches. > > Same can be said for hosting providers that value free sofware, > security breaches are possible, but then we would know that people > maintaining the server do care of users enough, to prevent mischievous > conduct. This argument does not follow. A code forge can have security issues, no matter whether its code can be freely audited or the political alignment of its owners. Merely being concerned about free software doesn't mean that security issues will be investigated and acted upon, neither does ownership by an entity pursuing different goals mean it will neglect security issues. I've briefly looked into Savannah's source code and found enough evidence of it not being securely designed and requiring an in-depth source code review. While talking to a security-related contact person I've been told that there was indeed a little-known security breach long time ago. Linus' law [3] seems a more appropriate hypothesis to explain this behavior, depending on the visibility and amount of people actively looking into a code forge, there will be more publicized security incidents and attempts to improve overall security of the project. Freedom and political alignment of the project are at best tangentially related. > A package can be thus accepted in MELPA and become approved, then > later continuously updated, meaning without any control or > supervision, and then automatically offered to users. Backdoor can be > injected into users' Emacs and run on their computers. If I am wrong > on how MELPA works, you may tell me, that is what I understood from > their website. That is indeed correct, there is no further quality assurance after the initial submission. It takes a significant amount of time for that submission to be verified due to the few reviewers and given the sheer amount of packages (4750 packages at the time of writing), I do not see this working out with their current team. For comparison, Arch has "Trusted Users" responsible for their official packages, with anywhere between 5 and 90 packages assigned to each of them. Rest assured that they don't perform security audits, only basic quality assurance as packages are updated and bugs trickle in. Having the kind of work force a GNU/Linux distribution has is a luxury, not something to take for granted. That aside, how does this quality assurance look like for GNU ELPA? Is it users subscribing to a commit mailing list and looking out for anything suspect? Fewer releases overall? A basic level of vetting by asking for copyright assignment? I doubt that code is audited for every release either and that security issues are instead dealt with in a reactive instead of proactive manner (meaning, as soon as one is known of, appropriate measures such as a security release are taken). There is a lot more work to be done here, such as defining a comprehensive threat model to work with. Another important aspect: Say that non-GNU ELPA manages to catch up with MELPA in terms of package count, does the existing review system still work? Will new measures be necessary to guarantee security (for example by designing packages in terms of a more restrictive approach with permissions, sandboxing and whatnot)? I strongly suspect that they will be and merely mirroring MELPA packages won't suffice. > SO FAR I KNOW there is no system of signing packages and verification > of such. I have verified MELPA git, and I cannot find that they are > using GnuPG or gpg or other system that packages were really made by > the author they claim to be made. This may be true at GNU ELPA too, I > did not verify it, but I know at that GNU ELPA is not automatically > built and offered to users blindly without verification (I at least > believe they are verified). As mentioned above, MELPA's principle of going with the most convenient option makes this a non-starter. Vetting package authors for their identity, requiring a GPG key and signed releases is something I'd rather expect for GNU ELPA than them. > 1. Github.com may not even know if somebody cracks some developer's > account and changes few packages to misbehave, if they would be > alerted, they would not maybe act in the best interest of the free > software project, they would act in their own best interest. Github offers 2FA to protect accounts and has a dedicated security team reacting to incidents. I don't see signs of either for Savannah. The only point in favor of Savannah is it being relatively unknown and therefore of less interest to attackers, but I wouldn't rely on that as my only level of defense. That aside, it's not even necessary to hack an account to distribute malicious software. Popular package archives for other programming languages have seen attacks such as typo squatting [4]creating (uploading a package with a misleading name) and hostile maintainers [5] (where a package is transfered to a new maintainer who then abuses the trust created by the package by adding malicious code to it). I have to confess I've pondered creating a malicious package for demonstrating how easy it would be to sneak something in without anyone noticing, but I'm afraid it will only lead to more emails sowing Fear, Uncertainty and Doubt. Or people weaponizing the code, not sure is likelier. > 2. MELPA managers do approve only GNU GPL or GPL compatible software > to be included, they do not however continually verify or control > the software, in fact they pull it by using recipes and build it > automatically and offer automatically to users. Users in turn > accept blindly packages, even though there is no mechanism to make > sure that package was made by the author that was approved by > MELPA. Let us say MELPA could maintain the list of public keys of > authors, and then accept only packages that are signed by those > same authors, before having them built, this would increase > security this security issue, but not solve it, if packages are not > verified by human. For this to be effective, one needs to build upon trust. I doubt the average Emacs user has thought in depth what package developers to trust and whether they should verify packages installed to come from them. And again, with MELPA's philosophy being one of convenience, I don't see that happening. > One way to increase the security of your packages is to “sign” them > using a cryptographic key. If you have generated a private/public gpg > key pair, you can use gpg to sign the package like this: > > gpg -ba -o FILE.sig FILE > > But it is not implemented into Emacs to verify packages being signed, > so my proposal is that Emacs get obligatory verification of a package > if such package is arriving from any repository and to warn user if > package was not signed. This would give initiative to MELPA to start > thinking about security issues. Emacs does have basic verification already, but it is far from ideal. The failure case is not handled well at all, users are not told what to do when it fails verifying a package and are inclined to instead disable the mechanism once and for all. If an Emacs is too old to contain the appropriate GPG keys, the keyring will be needed to be updated outside of Emacs, a task that can fail for opaque reasons due to key servers being unreachable. There is initial work in form of the gnu-elpa-keyring-update package distributed via GNU ELPA, but it suffers from a bootstrapping problem and needs to be installed *before* the keys become outdated. Until this issue is solved, I cannot imagine making this opt-out or even mandatory. For comparison, Arch ships its own package manager specific GPG keyring and updates it during each package update operation. [1]: https://github.com/github/hub [2]: https://github.com/melpa/melpa/issues/7185 [3]: "Given enough eyeballs, all bugs are shallow." [4]: https://incolumitas.com/2016/06/08/typosquatting-package-managers/ [5]: https://snyk.io/blog/a-post-mortem-of-the-malicious-event-stream-backdoor/ [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 838+ messages in thread
* ELPA security (was: Proposal to include obligatory PGP verification of packages from any repository) 2020-10-19 18:28 ` Vasilij Schneidermann @ 2020-10-19 19:00 ` Stefan Monnier 2020-10-19 19:50 ` Proposal to include obligatory PGP verification of packages from any repository Jean Louis 2020-10-20 5:17 ` Richard Stallman 2 siblings, 0 replies; 838+ messages in thread From: Stefan Monnier @ 2020-10-19 19:00 UTC (permalink / raw) To: Jean Louis Cc: Philip K., rms, thibaut.verron, mve1, emacs-devel, Dmitry Gutov > That aside, how does this quality assurance look like for GNU ELPA? > Is it users subscribing to a commit mailing list and looking out for > anything suspect? Kind of, tho there's no such statement of intent. There's a mailing-list where most(!) commits get sent, and some people subscribe to it, but there's no reason to assume that they subscribe to it specifically to review commits, let alone keeping an eye out for quality or security issues. I'm pretty sure several commits sent to the list aren't (re)viewed by anyone at all. I do subscribe to that mailing-list and perform a basic amount of reviewing, but it's more geared towards catching mishaps and helping contributors improve their code. It wouldn't take much effort for an attacker to make sure I don't look at his backdoor, I think. > Fewer releases overall? Definitely. > I doubt that code is audited for every release either and that > security issues are instead dealt with in a reactive instead of > proactive manner (meaning, as soon as one is known of, appropriate > measures such as a security release are taken). Definitely. The main source of "proactive" security is the fact that the code is fully visible to anyone who wants to look, and the presumed low benefits of introducing a backdoor in an ELisp package. > Another important aspect: Say that non-GNU ELPA manages to catch up > with MELPA in terms of package count, does the existing review system > still work? I think it'd largely end up similar to MELPA. > Will new measures be necessary to guarantee security (for example by > designing packages in terms of a more restrictive approach with > permissions, sandboxing and whatnot)? I strongly suspect that they > will be and merely mirroring MELPA packages won't suffice. The nature of ELisp makes sandboxing/permissions pretty difficult to implement, so I think we'll just hope for the best, like MELPA does. An alternative might be a system where we force/require some minimal amount of code review before publishing a package, which may work if the ELPA archive is popular enough that the annoyance of delayed releases motivates people to contribute to the review effort rather than to move to a more permissive archive. Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal to include obligatory PGP verification of packages from any repository 2020-10-19 18:28 ` Vasilij Schneidermann 2020-10-19 19:00 ` ELPA security (was: Proposal to include obligatory PGP verification of packages from any repository) Stefan Monnier @ 2020-10-19 19:50 ` Jean Louis 2020-10-20 5:17 ` Richard Stallman 2 siblings, 0 replies; 838+ messages in thread From: Jean Louis @ 2020-10-19 19:50 UTC (permalink / raw) To: emacs-devel; +Cc: mve1, Philip K., rms, thibaut.verron, Dmitry Gutov * Vasilij Schneidermann <mail@vasilij.de> [2020-10-19 21:29]: > There is a difference between trying (enabling LibreJS and looking at > how many scripts it blocked) and trying (enabling LibreJS and actually > using the website while paying attention to how functional it is). Out > of curiosity I've attempted the latter as it's a more meaningful test, > using the latest version of Firefox Developer Edition on Arch: I am not using Arch for reason that they allow any kind of proprietary software in GNU/Linux distribution, there are some freedom issues with Firefox, so I am using IceCat derivative or Iceweasel-uxp and I could not access activities. Further, I am faced with the warning by Github that my browser is not supported. And I do know that with LibreJS enabled, many functions work, some functions do not work. I did not test extensively. > My verdict so far: Github almost passes the test. If one does have an > account already (from what I've seen you do), there is no excuse for you > to not contribute. I would also say if developers can use Github they can as well use various libre online hosting systems. > > Additionally Github.com does not support many browsers, they publicly > > say so, which in turn means that many users of free software browsers > > from free software distributions are unable to access Github.com, > > users of Github are supposed to use Firefox or Chrome or Microsoft > > Browsers, while I am using Icecat and Iceweaseal-UXP from Hyperbola > > GNU/Linux-libre -- so my experience with Github.com is narrowed, I > > cannot access large parts of the website. > > From a security perspective it's a bad idea to use any browser outside > of the main stream as only the largest browser vendors manage keeping up > to speed with security issues. While one can use a browser based on > them, there will be issues. As a side point, Debian settled its > trademark dispute with Mozilla and no longer offers rebranded versions > of Firefox. Therefore Debian users will not face browser > incompatibility problems and avoid such security issues. Since 2016, I am not using Debian GNU/Linux on our internal computers for reason that they guide users to non-free firmware and help users enable non-free repositories. I am using exclusively free software operating systems, see: http://www.gnu.org/distros/free-distros.html I am not sure for all of them, but I do not use what you use. And I am not following the main stream, and I am behind bad networks, my case is particular and personal, I am using eww, and even by using eww I can find github.com link to clone repository, in that sense github.com is usable, that still does not make their javascript free software, and users of free software should not be guided to non-free software, be it javascript. Trisquel project, and Savannah, many others, like Gitlab, they also offer free code hosting without proprietary software. It means all those developers could switch. > One does not share a package on MELPA to further the goals of the free > software movement, one does so to reach as many Emacs users as possible > with relatively little effort (which excludes GNU ELPA, we'll have to > see whether the same holds true for non-GNU ELPA). That is exactly what we are both talking about, thanks. Packages from MELPA are not signed, can you maybe recommend from security perspective that each author start signing their packages? > > There is https://savannah.nongnu.org then there is Trisquel hosting, > > they would easily add Emacs packages without problem > > https://devel.trisquel.info/users/sign_in then there are other > > non-free Javascript and friendly free software hosting providers. > > Savannah does not strike me as an adequate alternative for people used > to Github. For starters it requires approval of each project before > it's publicly visible. I'll have to do a proper evaluation of it though > before I can comment further on this aspect. Gitlab is the closest > equivalent, though not perfect either. For minimalism and integration > of an email-centric workflow sourcehut looks ideal, once it leaves its > alpha status. Maybe also the money is problem, as maintainers would by hosting themselves, be paying themselves. But price of freedom we all pay. I make extensive travels to find proper computers that I can liberate from Intel spying engine, and install libreboot, so the price I am paying personally, so the price for hosting can be also somehow paid. Various projects such as Trisquel would be welcoming new Emacs package developers on their Gitlab instances. > > For me largest security problem on MELPA is that Github.com is run by > > Microsoft, we have no idea what principles they share beyond > > commercial principles, and the more Emacs packages are hosted on > > Microsoft Github, the more probability is there for mischievous > > conduct or security breaches. > > > > Same can be said for hosting providers that value free sofware, > > security breaches are possible, but then we would know that people > > maintaining the server do care of users enough, to prevent mischievous > > conduct. > > This argument does not follow. A code forge can have security issues, > no matter whether its code can be freely audited or the political > alignment of its owners. Merely being concerned about free software > doesn't mean that security issues will be investigated and acted upon, > neither does ownership by an entity pursuing different goals mean it > will neglect security issues. I am very practical, I am trusting OpenBSD various teams to make the LibreSSL how it should be, I am trusting them with various security issues like in OpenSSH, for reasons of their principles set long time ago. So I am trusting various smaller communities such as those of Guix, Trisquel, Hyperbola GNU/Linux-libre, for reason that they act upon the notices related to freedom, security, you name it. For their agility and responsiveness. I trust GNU packages and people behind it for obviously good responsiveness in handling user issues or bugs. I cannot trust Archlinux to handle issues of freedom because their policy is such that they will include proprietary software if proprietor is allowing them, and if they have such policy, then I cannot trust them with security issues too. You are right that all hostings or let us say digital backgrounds can be compromised, but if proprietary background is compromised such as Microsoft Github, for reasons of their business interests I cannot trust them to be transparent, unless third party have found security issue. For free software communities, some of them I mentioned, I can trust them based on my experience with them, to be very transparent with security issues. > > A package can be thus accepted in MELPA and become approved, then > > later continuously updated, meaning without any control or > > supervision, and then automatically offered to users. Backdoor can be > > injected into users' Emacs and run on their computers. If I am wrong > > on how MELPA works, you may tell me, that is what I understood from > > their website. > > That is indeed correct, there is no further quality assurance after the > initial submission. It takes a significant amount of time for that > submission to be verified due to the few reviewers and given the sheer > amount of packages (4750 packages at the time of writing), I do not see > this working out with their current team. For comparison, Arch has > "Trusted Users" responsible for their official packages, with anywhere > between 5 and 90 packages assigned to each of them. Rest assured that > they don't perform security audits, only basic quality assurance as > packages are updated and bugs trickle in. Having the kind of work force > a GNU/Linux distribution has is a luxury, not something to take for > granted. What that setup of Archlinux does is that it decentralizes the package delivery, so some of those maintainers will indeed look into code and report issues when found, there is more care and automatically there is more responsibility. I do not say how much, I just can think that it is. Security and freedom issues are mostly promptly handled in those FSF endorsed distributions, those are significant differences originating from various group attitudes or set of principles. > That aside, how does this quality assurance look like for GNU ELPA? I understand it fully and I wish more security in any kind of package repository for GNU Emacs, as users are downloading blindly "packages" many of them will find it funny, and most of time nothing bad will happen until it happens. > Is it users subscribing to a commit mailing list and looking out for > anything suspect? Fewer releases overall? A basic level of vetting > by asking for copyright assignment? I doubt that code is audited > for every release either and that security issues are instead dealt > with in a reactive instead of proactive manner (meaning, as soon as > one is known of, appropriate measures such as a security release are > taken). There is a lot more work to be done here, such as defining > a comprehensive threat model to work with. Another important > aspect: Say that non-GNU ELPA manages to catch up with MELPA in > terms of package count, does the existing review system still work? > Will new measures be necessary to guarantee security (for example by > designing packages in terms of a more restrictive approach with > permissions, sandboxing and whatnot)? I strongly suspect that they > will be and merely mirroring MELPA packages won't suffice. Thank you for thinkering about security. Resource scarcity is security issue. For GNU ELPA I know that principle is that packages are assigned with copyright to FSF and by other principles which I am not authorized to represent. While it is great to have large choice, number of packages in an archive is for sure not the principle for GNU ELPA. For me personally, that count is not a feature, it is anti feature, the more packages they are, the more I get concerned for reasons explained by me, and reasons explained by you. > > SO FAR I KNOW there is no system of signing packages and verification > > of such. I have verified MELPA git, and I cannot find that they are > > using GnuPG or gpg or other system that packages were really made by > > the author they claim to be made. This may be true at GNU ELPA too, I > > did not verify it, but I know at that GNU ELPA is not automatically > > built and offered to users blindly without verification (I at least > > believe they are verified). > > As mentioned above, MELPA's principle of going with the most convenient > option makes this a non-starter. Vetting package authors for their > identity, requiring a GPG key and signed releases is something I'd > rather expect for GNU ELPA than them. Turn on the option package-check-signature and start verifying. > > 1. Github.com may not even know if somebody cracks some developer's > > account and changes few packages to misbehave, if they would be > > alerted, they would not maybe act in the best interest of the free > > software project, they would act in their own best interest. > > Github offers 2FA to protect accounts and has a dedicated security team > reacting to incidents. See this example: https://pberba.github.io/security/2020/05/28/lastpass-phishing/ You are right that neither free software repositories need be secure, they have though different motivation and different level of transparency as they do not work for their number of sales and good image, they are more proud if they find their security incidents themselves, speaking of OpenBSD principles of work. > That aside, it's not even necessary to hack an account to distribute > malicious software. Popular package archives for other programming > languages have seen attacks such as typo squatting [4]creating > (uploading a package with a misleading name) and hostile maintainers [5] > (where a package is transfered to a new maintainer who then abuses the > trust created by the package by adding malicious code to it). I have to > confess I've pondered creating a malicious package for demonstrating how > easy it would be to sneak something in without anyone noticing, but I'm > afraid it will only lead to more emails sowing Fear, Uncertainty and > Doubt. Or people weaponizing the code, not sure is likelier. You have got references, to me it is obvious. What I am surprised is that I do not know of serious security incidents within Emacs packages, that does not mean they are not about to come. > Emacs does have basic verification already, but it is far from ideal. > The failure case is not handled well at all, users are not told what to > do when it fails verifying a package and are inclined to instead disable > the mechanism once and for all. Right. > If an Emacs is too old to contain the appropriate GPG keys, the > keyring will be needed to be updated outside of Emacs, a task that > can fail for opaque reasons due to key servers being unreachable. > There is initial work in form of the gnu-elpa-keyring-update package > distributed via GNU ELPA, but it suffers from a bootstrapping > problem and needs to be installed *before* the keys become outdated. > Until this issue is solved, I cannot imagine making this opt-out or > even mandatory. For comparison, Arch ships its own package manager > specific GPG keyring and updates it during each package update > operation. That is about that what I expect for Emacs as well! Jean P.S. Think about implementing OMEMO in Jabber.el, my offer stands ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal to include obligatory PGP verification of packages from any repository 2020-10-19 18:28 ` Vasilij Schneidermann 2020-10-19 19:00 ` ELPA security (was: Proposal to include obligatory PGP verification of packages from any repository) Stefan Monnier 2020-10-19 19:50 ` Proposal to include obligatory PGP verification of packages from any repository Jean Louis @ 2020-10-20 5:17 ` Richard Stallman 2020-10-20 5:52 ` Stefan Monnier 2020-10-20 16:17 ` Vasilij Schneidermann 2 siblings, 2 replies; 838+ messages in thread From: Richard Stallman @ 2020-10-20 5:17 UTC (permalink / raw) To: Vasilij Schneidermann Cc: philipk, bugs, thibaut.verron, mve1, emacs-devel, dgutov [[[ 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. ]]] I have not tried to study each point in your message -- there were so many -- but I noticed criticism of Savannah for not offering two-factor authentication. When I was asked to do this, I couldn't do it, because it depended on carrying a protable listening and surveillance device (aka cellular phone). MIT had to make a special exception for me, turning that requirement off, when it demanded that I access its administrative systems. Savannah must not do this if it requires the user to use nonfree programs. If people are interested in discussing this point, let's use gnu-prog-discuss@gnu.org as it is off-topic here. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal to include obligatory PGP verification of packages from any repository 2020-10-20 5:17 ` Richard Stallman @ 2020-10-20 5:52 ` Stefan Monnier 2020-10-21 4:46 ` Richard Stallman 2020-10-20 16:17 ` Vasilij Schneidermann 1 sibling, 1 reply; 838+ messages in thread From: Stefan Monnier @ 2020-10-20 5:52 UTC (permalink / raw) To: Richard Stallman Cc: philipk, bugs, thibaut.verron, mve1, emacs-devel, dgutov, Vasilij Schneidermann > I have not tried to study each point in your message -- there were so > many -- but I noticed criticism of Savannah for not offering > two-factor authentication. > > When I was asked to do this, I couldn't do it, because it depended on > carrying a protable listening and surveillance device (aka cellular > phone). I don't see why: the way Gitlab does 2FA relies either on TOTP or on a secure-key (such as the somu), neither of which requires any kind of network correction (cellular or other). See https://en.wikipedia.org/wiki/FIDO2_Project and https://en.wikipedia.org/wiki/Time-based_One-time_Password_algorithm Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal to include obligatory PGP verification of packages from any repository 2020-10-20 5:52 ` Stefan Monnier @ 2020-10-21 4:46 ` Richard Stallman 0 siblings, 0 replies; 838+ messages in thread From: Richard Stallman @ 2020-10-21 4:46 UTC (permalink / raw) To: Stefan Monnier Cc: philipk, bugs, thibaut.verron, mve1, emacs-devel, dgutov, mail [[[ 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. ]]] > > When I was asked to do this, I couldn't do it, because it depended on > > carrying a protable listening and surveillance device (aka cellular > > phone). > I don't see why: Why MIT chose to offer the options it chose and no others? I don't know. Why I couldn't use them? I couldn't use them because each required me to run nonfree software. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal to include obligatory PGP verification of packages from any repository 2020-10-20 5:17 ` Richard Stallman 2020-10-20 5:52 ` Stefan Monnier @ 2020-10-20 16:17 ` Vasilij Schneidermann 1 sibling, 0 replies; 838+ messages in thread From: Vasilij Schneidermann @ 2020-10-20 16:17 UTC (permalink / raw) To: Richard Stallman; +Cc: philipk, bugs, thibaut.verron, mve1, emacs-devel, dgutov [-- Attachment #1: Type: text/plain, Size: 887 bytes --] > I have not tried to study each point in your message -- there were so > many -- but I noticed criticism of Savannah for not offering > two-factor authentication. > > When I was asked to do this, I couldn't do it, because it depended on > carrying a protable listening and surveillance device (aka cellular > phone). MIT had to make a special exception for me, turning that > requirement off, when it demanded that I access its administrative > systems. > > Savannah must not do this if it requires the user to use nonfree > programs. There are many ways of doing 2FA and normally it's opt-in. > If people are interested in discussing this point, let's use > gnu-prog-discuss@gnu.org as it is off-topic here. Sure, please include me in your mail there as I'm not subscribed to that mailing list. I could probably help out with the security side of Savannah. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Proposal for an Emacs User Survey 2020-10-19 11:36 ` Dmitry Gutov 2020-10-19 12:43 ` Proposal to include obligatory PGP verification of packages from any repository Jean Louis @ 2020-10-19 15:46 ` Drew Adams 2020-10-19 16:42 ` Jean Louis 2020-10-19 16:42 ` Thibaut Verron 2020-10-20 5:14 ` Richard Stallman 2 siblings, 2 replies; 838+ messages in thread From: Drew Adams @ 2020-10-19 15:46 UTC (permalink / raw) To: Dmitry Gutov, rms, Philip K.; +Cc: mve1, bugs, thibaut.verron, emacs-devel > MELPA to a large part consists of a database of "recipes", one for each > package that it builds and distributes. This tag can be put inside > recipes, and thus be controlled by MELPA maintainers, and not by the > packages authors themselves. > > If we provide some well-defined criteria for such tags, and pick a > neutral-enough name, I don't see why the MELPA maintainers (who are > quite reasonable people IME) wouldn't go for it. Just a minor comment/question about this, which I think would be the first time such a thing would be happening: Do we really want to set a precedent that someone other than the code author fiddles with their code, adding comments or whatever? Sure, the maintainers of a repo are, in a way, administrators. But should such administrators be changing source code? Adding other code or whatever, to administer, label, treat, etc. the code is, at least conceptually, different from changing the source code itself. No, adding a field/tag in a comment is not a big deal. And yes, GPL code is open to modification. Still, is this a good door to open? ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-19 15:46 ` Proposal for an Emacs User Survey Drew Adams @ 2020-10-19 16:42 ` Jean Louis 2020-10-20 5:19 ` Richard Stallman 2020-10-19 16:42 ` Thibaut Verron 1 sibling, 1 reply; 838+ messages in thread From: Jean Louis @ 2020-10-19 16:42 UTC (permalink / raw) To: Drew Adams Cc: Philip K., rms, thibaut.verron, mve1, emacs-devel, Dmitry Gutov * Drew Adams <drew.adams@oracle.com> [2020-10-19 18:48]: > > MELPA to a large part consists of a database of "recipes", one for each > > package that it builds and distributes. This tag can be put inside > > recipes, and thus be controlled by MELPA maintainers, and not by the > > packages authors themselves. > > > > If we provide some well-defined criteria for such tags, and pick a > > neutral-enough name, I don't see why the MELPA maintainers (who are > > quite reasonable people IME) wouldn't go for it. > > Just a minor comment/question about this, which > I think would be the first time such a thing > would be happening: > > Do we really want to set a precedent that > someone other than the code author fiddles with > their code, adding comments or whatever? > > Sure, the maintainers of a repo are, in a way, > administrators. But should such administrators > be changing source code? Adding other code or > whatever, to administer, label, treat, etc. the > code is, at least conceptually, different from > changing the source code itself. > > No, adding a field/tag in a comment is not a big > deal. And yes, GPL code is open to modification. > > Still, is this a good door to open? That is similar to how many GNU/Linux software packages are maintained, often they are modified before such enter distribution for final users. I do not care if package is original, not original, forked or not forked, modified, what I care is which group of people is making it trusted and by which principles. If nobody is making package verifications by looking into it, then such package is not trusted to me, with or without PGP signature, it does not matter any more. That is why some GNU/Linux distributions have so many maintainers, each is responsible for some packages, there is no warranty, but there is some implied moral obligation at least. Some OS like OpenBSD have better security policies, they verify the code for security, not just package and wrap it for delivery. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-19 16:42 ` Jean Louis @ 2020-10-20 5:19 ` Richard Stallman 0 siblings, 0 replies; 838+ messages in thread From: Richard Stallman @ 2020-10-20 5:19 UTC (permalink / raw) To: Jean Louis; +Cc: philipk, thibaut.verron, mve1, emacs-devel, dgutov, drew.adams [[[ 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. ]]] > > Sure, the maintainers of a repo are, in a way, > > administrators. But should such administrators > > be changing source code? Adding other code or > > whatever, to administer, label, treat, etc. the > > code is, at least conceptually, different from > > changing the source code itself. > That is similar to how many GNU/Linux software packages are > maintained, often they are modified before such enter distribution for > final users. > I do not care if package is original, not original, forked or not > forked, modified, what I care is which group of people is making it > trusted and by which principles. That is my view also. Free software means you're allowed to distribute a modified version. There is nothing wrong with making changes. The changes are good, or bad, based on what they say. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-19 15:46 ` Proposal for an Emacs User Survey Drew Adams 2020-10-19 16:42 ` Jean Louis @ 2020-10-19 16:42 ` Thibaut Verron 2020-10-19 16:53 ` Drew Adams 1 sibling, 1 reply; 838+ messages in thread From: Thibaut Verron @ 2020-10-19 16:42 UTC (permalink / raw) To: Drew Adams Cc: Philip K., Richard Stallman, Jean Louis, Marcel Ventosa, emacs-devel, Dmitry Gutov Le lun. 19 oct. 2020 à 17:48, Drew Adams <drew.adams@oracle.com> a écrit : > > > MELPA to a large part consists of a database of "recipes", one for each > > package that it builds and distributes. This tag can be put inside > > recipes, and thus be controlled by MELPA maintainers, and not by the > > packages authors themselves. > > > > If we provide some well-defined criteria for such tags, and pick a > > neutral-enough name, I don't see why the MELPA maintainers (who are > > quite reasonable people IME) wouldn't go for it. > > Just a minor comment/question about this, which > I think would be the first time such a thing > would be happening: > > Do we really want to set a precedent that > someone other than the code author fiddles with > their code, adding comments or whatever? > > Sure, the maintainers of a repo are, in a way, > administrators. But should such administrators > be changing source code? Adding other code or > whatever, to administer, label, treat, etc. the > code is, at least conceptually, different from > changing the source code itself. > > No, adding a field/tag in a comment is not a big > deal. And yes, GPL code is open to modification. > > Still, is this a good door to open? I'm not sure to understand the question. The recipes are stored in the Melpa repository, so the maintainers of the repo are really the maintainers of the source code (the recipes). The recipes are written by the authors of the package, by forking and filing a request to merge into the Melpa repository. So if the administrators of Melpa agree to it, they are entirely in their prerogative to alter the recipes provided by the users in their code (list of recipes). It's not really different from adding a comment to clarify a bug fix by an external contributor after the code is merged. They would not be modifying the code of the packages themselves, of course. ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Proposal for an Emacs User Survey 2020-10-19 16:42 ` Thibaut Verron @ 2020-10-19 16:53 ` Drew Adams 0 siblings, 0 replies; 838+ messages in thread From: Drew Adams @ 2020-10-19 16:53 UTC (permalink / raw) To: thibaut.verron Cc: Philip K., Richard Stallman, Jean Louis, Marcel Ventosa, emacs-devel, Dmitry Gutov > They would not be modifying the code of the packages themselves, of course. I see. I thought that was the case. I didn't realize the "tag" would be in the recipe, not in the submitted source code. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-19 11:36 ` Dmitry Gutov 2020-10-19 12:43 ` Proposal to include obligatory PGP verification of packages from any repository Jean Louis 2020-10-19 15:46 ` Proposal for an Emacs User Survey Drew Adams @ 2020-10-20 5:14 ` Richard Stallman 2020-10-20 10:47 ` Dmitry Gutov 2 siblings, 1 reply; 838+ messages in thread From: Richard Stallman @ 2020-10-20 5:14 UTC (permalink / raw) To: Dmitry Gutov; +Cc: mve1, philipk, bugs, thibaut.verron, emacs-devel [[[ 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. ]]] > If we provide some well-defined criteria for such tags, and pick a > neutral-enough name, I don't see why the MELPA maintainers (who are > quite reasonable people IME) wouldn't go for it. > Question is, would you agree to add MELPA to the default list of package > archives if they do? I do not have confidence that this will be sufficient. Melpa has caused other problems (discussed here some months ago). -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-20 5:14 ` Richard Stallman @ 2020-10-20 10:47 ` Dmitry Gutov 0 siblings, 0 replies; 838+ messages in thread From: Dmitry Gutov @ 2020-10-20 10:47 UTC (permalink / raw) To: rms; +Cc: mve1, philipk, bugs, thibaut.verron, emacs-devel On 20.10.2020 08:14, Richard Stallman wrote: > > If we provide some well-defined criteria for such tags, and pick a > > neutral-enough name, I don't see why the MELPA maintainers (who are > > quite reasonable people IME) wouldn't go for it. > > > Question is, would you agree to add MELPA to the default list of package > > archives if they do? > > I do not have confidence that this will be sufficient. > Melpa has caused other problems (discussed here some months ago). "Caused" or "has"? If the issue of it being hosted on Github is a show-stopper then ok, we'll probably not have much progress here. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 3:59 ` Richard Stallman 2020-10-16 6:02 ` Marcel Ventosa @ 2020-10-16 7:05 ` Thibaut Verron 2020-10-16 13:23 ` Philip K. ` (2 more replies) 1 sibling, 3 replies; 838+ messages in thread From: Thibaut Verron @ 2020-10-16 7:05 UTC (permalink / raw) To: Richard Stallman; +Cc: Jean Louis, emacs-devel Le ven. 16 oct. 2020 à 05:59, Richard Stallman <rms@gnu.org> a écrit : > I hope that only a minority of Emacs users know about MELPA, and I'd > rather not inform the rest about it. But if something is going to > inform them anyway, it is better to do it with a denunciation. I believe that it is too late for such hopes, and that a majority of Emacs users know about Melpa and/or uses it. Some people know about it without using it (most of them probably read this list) and some people use it without knowing it (users of pre-configured emacs'es). For instance, those three links were on the first page of a duckduckgo search for "install emacs packages": https://www.emacswiki.org/emacs/InstallingPackages http://ergoemacs.org/emacs/emacs_package_system.html http://pragmaticemacs.com/emacs/install-packages/ None of them denunciate anything, only one of them even mentions that Melpa is not official. I believe that if the Emacs webpage and manual were to mention Melpa, it would inform a lot of users about the potential risks to freedom of Melpa, and only inform a few users of the existence of Melpa. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 7:05 ` Thibaut Verron @ 2020-10-16 13:23 ` Philip K. 2020-10-16 18:46 ` Jean Louis 2020-10-17 4:22 ` Richard Stallman 2 siblings, 0 replies; 838+ messages in thread From: Philip K. @ 2020-10-16 13:23 UTC (permalink / raw) To: Thibaut Verron; +Cc: Richard Stallman, Jean Louis, emacs-devel Thibaut Verron <thibaut.verron@gmail.com> writes: > Le ven. 16 oct. 2020 à 05:59, Richard Stallman <rms@gnu.org> a écrit : >> I hope that only a minority of Emacs users know about MELPA, and I'd >> rather not inform the rest about it. But if something is going to >> inform them anyway, it is better to do it with a denunciation. > > I believe that it is too late for such hopes, and that a majority of > Emacs users know about Melpa and/or uses it. Some people know about it > without using it (most of them probably read this list) and some > people use it without knowing it (users of pre-configured emacs'es). > > For instance, those three links were on the first page of a duckduckgo > search for "install emacs packages": > > https://www.emacswiki.org/emacs/InstallingPackages > http://ergoemacs.org/emacs/emacs_package_system.html > http://pragmaticemacs.com/emacs/install-packages/ And that's only if the user already knows that they want to install packages (instead of "plug-ins" or "extensions", as other software would refer to the concept). From my experience, almost every non-official beginners tutorial will either mention or just give you the code to configure MELPA. And with all the starter-packages that offer to pre-configure Emacs, you don't even think about it. But that's currently unavoidable, a lot of the advocacy for Emacs is based on promoting certain packages (Magit, Evil, Org-mode extensions such as Roam, etc.) that are for the most part only available on MELPA. Non-GNU Elpa should help to mitigate this problem, as my impression is that most people intrigued in Emacs, would quickly loose interest, if it weren't for these specific packages. (In general I think that that kind promotion isn't good, at least in the long term. Emacs is seen as getting in the way of whatever package you need, and they therefore follow whatever method they find to avoid learning. While possible, it leaves many on a fragile tower of abstractions and hacks, that could break at any moment.) -- Philip K. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 7:05 ` Thibaut Verron 2020-10-16 13:23 ` Philip K. @ 2020-10-16 18:46 ` Jean Louis 2020-10-17 4:22 ` Richard Stallman 2 siblings, 0 replies; 838+ messages in thread From: Jean Louis @ 2020-10-16 18:46 UTC (permalink / raw) To: Thibaut Verron; +Cc: Richard Stallman, emacs-devel * Thibaut Verron <thibaut.verron@gmail.com> [2020-10-16 10:06]: > I believe that if the Emacs webpage and manual were to mention Melpa, > it would inform a lot of users about the potential risks to freedom of > Melpa, and only inform a few users of the existence of Melpa. It is alright to file issue at MELPA, to see if they will remedy any non-free issue. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-16 7:05 ` Thibaut Verron 2020-10-16 13:23 ` Philip K. 2020-10-16 18:46 ` Jean Louis @ 2020-10-17 4:22 ` Richard Stallman 2 siblings, 0 replies; 838+ messages in thread From: Richard Stallman @ 2020-10-17 4:22 UTC (permalink / raw) To: thibaut.verron; +Cc: bugs, emacs-devel [[[ 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. ]]] > I believe that it is too late for such hopes, and that a majority of > Emacs users know about Melpa and/or uses it. You may be right, but it is hard to tell. We don't know what fraction of Emacs users are even aware that there is such a thing as "packages". The survey that is now being done will not tell us, because it will be publicized in certain forums so it will reflect the subset of users that use those forums -- not a representative sample of all users. I woudl expoect that there is another population of users which has no contact with those forums or startup kits. So you might be right, but we don't know if that is actually so. It makes a difference. If we KNEW that almost all users of Emacs did know about Melpa, that would change our policy towards it. But it would be an own-goal to assume, erroneously that they already know and as a result end up being the ones to tell them. Can you change emacswiki to state the two things that are bad about Melpa? -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-12 5:33 ` Thibaut Verron ` (2 preceding siblings ...) 2020-10-13 3:53 ` Richard Stallman @ 2020-10-15 3:52 ` Richard Stallman 2020-10-15 5:57 ` Thibaut Verron 3 siblings, 1 reply; 838+ messages in thread From: Richard Stallman @ 2020-10-15 3:52 UTC (permalink / raw) To: thibaut.verron; +Cc: bugs, emacs-devel [[[ 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. ]]] > > Warning you mention is used on Emacs download page, see > > https://www.gnu.org/software/emacs/download.html > Great, so there is precedent ! Why is it acceptable and sufficient on > the main download page but not acceptable in a survey? I am not sure what those words mean. I looked at that page to see if I could figure it out, but I was stuck. Would people like to explain what part or aspect of that page is at issue here? -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-15 3:52 ` Richard Stallman @ 2020-10-15 5:57 ` Thibaut Verron 0 siblings, 0 replies; 838+ messages in thread From: Thibaut Verron @ 2020-10-15 5:57 UTC (permalink / raw) To: Richard Stallman; +Cc: Jean Louis, emacs-devel Le jeu. 15 oct. 2020 à 05:52, Richard Stallman <rms@gnu.org> a écrit : > > [[[ 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. ]]] > > > > Warning you mention is used on Emacs download page, see > > > https://www.gnu.org/software/emacs/download.html > > > Great, so there is precedent ! Why is it acceptable and sufficient on > > the main download page but not acceptable in a survey? > > I am not sure what those words mean. I looked at that page to see if > I could figure it out, but I was stuck. Would people like to explain > what part or aspect of that page is at issue here? As Jean-Louis said, the warning he was referring too is the preamble of the section "Non-free systems". ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-12 3:32 ` Thibaut Verron 2020-10-12 5:04 ` Jean Louis @ 2020-10-12 5:36 ` Jean Louis 2020-10-12 5:52 ` Thibaut Verron 1 sibling, 1 reply; 838+ messages in thread From: Jean Louis @ 2020-10-12 5:36 UTC (permalink / raw) To: Thibaut Verron Cc: emacs-devel, Adrien Brochard, Richard Stallman, Vasilij Schneidermann * Thibaut Verron <thibaut.verron@gmail.com> [2020-10-12 06:33]: > And I would be worried about selection bias in a survey which voluntarily > omits the most popular options from the lists of choices: how many people > would choose not to complete the survey of they feel that the questions are > biased? That is easy to solve: - [ ] Check here if you do not wish to complete this survey - [ ] Check here if you do not want to tell us anything about you etc. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-12 5:36 ` Jean Louis @ 2020-10-12 5:52 ` Thibaut Verron 0 siblings, 0 replies; 838+ messages in thread From: Thibaut Verron @ 2020-10-12 5:52 UTC (permalink / raw) To: Jean Louis Cc: emacs-devel, Adrien Brochard, Richard Stallman, Vasilij Schneidermann Le lun. 12 oct. 2020 à 07:37, Jean Louis <bugs@gnu.support> a écrit : > > * Thibaut Verron <thibaut.verron@gmail.com> [2020-10-12 06:33]: > > And I would be worried about selection bias in a survey which voluntarily > > omits the most popular options from the lists of choices: how many people > > would choose not to complete the survey of they feel that the questions are > > biased? > > That is easy to solve: > > - [ ] Check here if you do not wish to complete this survey > > - [ ] Check here if you do not want to tell us anything about you > > etc. Can't tell if you're serious. But just in case, no, they would just close the page/buffer/whatever and not send the results. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-11 7:35 ` Vasilij Schneidermann 2020-10-11 12:08 ` Jean Louis @ 2020-10-12 2:04 ` Richard Stallman 2020-10-12 2:04 ` Richard Stallman 2 siblings, 0 replies; 838+ messages in thread From: Richard Stallman @ 2020-10-12 2:04 UTC (permalink / raw) To: Vasilij Schneidermann; +Cc: abrochard, emacs-devel [[[ 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. ]]] > Not mentioning MELPA as an option because you feel uncomfortable about > it will distort survey results, especially for the part where you ask > what package archives people use. That is ok. This is not a research project. The reason we are interested in a survey's results is to make practical decisions about policies that we could possibly change. We do not mention places to get software if they lead people to nonfree software. See the GNU Coding Standards, node References. Our stance about MELPA is determined directly by this principle. Unless MELPA's policies change, our stance about it cannot change. We can do no other. > Remember, this is a > survey to find out how Emacs users use their editor, not about how much > they adhere to FSF ideology. Nobody would disagree with that point, but that abstract question is not where the disagreement is. We need to inform people that there is a grave moral flaw in MELPA, and we can't do that if we ask questions about it just the same as we do about other repositories. What we might do is ask Which of these exclusively libre Lisp package archives do you use with a list of those, then Do you use any Lisp package archives not in that list? and people could answer MELPA if they wish. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-11 7:35 ` Vasilij Schneidermann 2020-10-11 12:08 ` Jean Louis 2020-10-12 2:04 ` Richard Stallman @ 2020-10-12 2:04 ` Richard Stallman 2 siblings, 0 replies; 838+ messages in thread From: Richard Stallman @ 2020-10-12 2:04 UTC (permalink / raw) To: Vasilij Schneidermann; +Cc: abrochard, emacs-devel [[[ 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. ]]] ... > > > What is free software (libre software)? > > > > > Which of these are free liceenses? > > > > > How does GNU relate to free software? > See my last sentence above. What's the point of this quiz? Finding out > what percentage of Emacs users fully believes in GNU's goals? What will > that information be used for? We can use it to try to improve our efforts to communicate those crucial points about our overall goals and what we have achieved. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-11 5:23 ` Richard Stallman 2020-10-11 7:35 ` Vasilij Schneidermann @ 2020-10-12 15:16 ` Adrien Brochard 2020-10-12 16:55 ` Jean Louis ` (2 more replies) 1 sibling, 3 replies; 838+ messages in thread From: Adrien Brochard @ 2020-10-12 15:16 UTC (permalink / raw) To: rms, emacs-devel Thank you for your feedback! I've read many emails on this thread now and I think we've reached a point where some action needs to be taken. I have purchased emacssurvey.org and I will proceed to: - digest all the feedback I got into a final list of questions - announce the survey opening date on as many channels as I can - build emacssurvey.org as a no-JS site such that everyone can visit it - on the survey start date, emacssurvey.org will have two options for submitting responses - visit the questionnaire as plain text and email it to a dedicated address hosted on emacssurvey.org (which will be possible from Emacs) - use an online form which will potentially require non-free JS - the survey will remain open for 6 weeks, plus some extra time for late responders - I will post on as many channels every week to remind people who haven't responded yet (but obviously not share any partial results) - after the survey is over and all data is compiled, all results will be released on emacssurvey.org (and again it will be viewable from Emacs) By hosting the survey on a different website, I am hoping to accomplish something similar to the "Devil as Install Fest" (https://www.gnu.org/philosophy/install-fest-devil.en.html). What we could still discuss is a disclaimer on emacssurvey.org to be explicit on how gnu.org is not sponsoring the survey questions. It would be really helpful if gnu.org could link to emacssurvey.org, but if not, that's ok too. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-12 15:16 ` Adrien Brochard @ 2020-10-12 16:55 ` Jean Louis 2020-10-12 17:15 ` Drew Adams 2020-10-13 3:49 ` Richard Stallman 2 siblings, 0 replies; 838+ messages in thread From: Jean Louis @ 2020-10-12 16:55 UTC (permalink / raw) To: Adrien Brochard; +Cc: rms, emacs-devel * Adrien Brochard <abrochard@gmx.com> [2020-10-12 18:17]: > Thank you for your feedback! > > I've read many emails on this thread now and I think we've reached a > point where some action needs to be taken. I have purchased > emacssurvey.org and I will proceed to: Well that is what I said, you can do it independent of GNU project. > - digest all the feedback I got into a final list of questions I hope you will use "check all that apply" method, and not have "one option" among the choice of lists. > - announce the survey opening date on as many channels as I can > - build emacssurvey.org as a no-JS site such that everyone can visit > - it That is right, not hard to do, I have done very complex forms, there are many ways how to do complex forms, I was using CGI and Perl, but simple HTML could be just enough. Always add: "Other" field, which is enough wide and welcoming, to help people write what they wish else. When doing professional survey you could not change the parameters during the survey period, so changing questions would not be good. I suggest keeping versions, you may do more versions in future. I hope you will align the purpose of the survey with Emacs development, so that development may find out what is number one feature needed and wanted in Emacs, to improve Emacs that way. > - on the survey start date, emacssurvey.org will have two options for > submitting responses > - visit the questionnaire as plain text and email it to a dedicated > address hosted on emacssurvey.org (which will be possible from > Emacs) That is great. > - use an online form which will potentially require non-free JS It does not require non-free JS or any Javascript. It requires plain HTML, easy to do, it is even possible to make the Org file, and process by Emacs Lisp that in turn makes the full survey online. If your survey page is more complex, and the more complex you make it, the less results you will get, but if it is multi-page form, then there are nice Perl modules handling the job. Just see https://cpan.org and search for forms. But using any other programming language to generate the forms and capture its information in the database other than Emacs Lisp, would be disgrace for me, so just do it in Emacs Lisp, it will perform well. > - the survey will remain open for 6 weeks, plus some extra time for late > responders For 6 weeks survey, you need to put up some money to capture the users, and if you advertise, you should disclose on which communication channels you advertised, and evaluation should involve that advertising. Your advertising would need to run for exact time of the survey, like 6 weeks, and then the survey results are specific only for that specific communication channels you used. Let us say you advertise on Reddit, you would get quite different results then if you advertise on other network, attracting for example Github users, or if you advertise so that you attract Debian users, or scientists, students in universities and similar. > - I will post on as many channels every week to remind people who > haven't responded yet (but obviously not share any partial results) If you do a survey for which you still do various advertising during the survey time, that cannot be just survey, you would need to reach users quickly to answer quickly their questions. You could advertise on some networks using keywords like "emacs" and reach 1000 users within 24 hours, rather then posting links online for 6 weeks, as in that way you are changing the dynamic of the survey and also influencing it consciously or not consciously. How you have advertised it, and in what time, you would also need to take in evaluation, along with your personal experience or skills. Jean ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Proposal for an Emacs User Survey 2020-10-12 15:16 ` Adrien Brochard 2020-10-12 16:55 ` Jean Louis @ 2020-10-12 17:15 ` Drew Adams 2020-10-13 3:49 ` Richard Stallman 2 siblings, 0 replies; 838+ messages in thread From: Drew Adams @ 2020-10-12 17:15 UTC (permalink / raw) To: Adrien Brochard, rms, emacs-devel > I've read many emails on this thread now and I think we've reached a > point where some action needs to be taken. Why do you think so? > I have purchased emacssurvey.org and I will proceed to:... FWIW, I'm not in favor of proceeding this way. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-12 15:16 ` Adrien Brochard 2020-10-12 16:55 ` Jean Louis 2020-10-12 17:15 ` Drew Adams @ 2020-10-13 3:49 ` Richard Stallman 2 siblings, 0 replies; 838+ messages in thread From: Richard Stallman @ 2020-10-13 3:49 UTC (permalink / raw) To: Adrien Brochard; +Cc: emacs-devel [[[ 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. ]]] > - digest all the feedback I got into a final list of questions I am surprised and disappointed that you want to do this on your own, without the participation of the GNU Project. Nonetheless, would you please let me review and comment on your text before you publish it? > - after the survey is over and all data is compiled, all results will be > released on emacssurvey.org (and again it will be viewable from Emacs) Please make the results available in a simple textual format as a single file, as well as any other formats you like. > - use an online form which will potentially require non-free JS Please do not have any nonfree JS code for this site. That would work directly against the free software movement. Asking people to run nonfree software is an injustice. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-09 23:12 ` Adrien Brochard ` (4 preceding siblings ...) 2020-10-11 5:23 ` Richard Stallman @ 2020-10-11 20:54 ` Bonface M. K. 2020-10-16 13:30 ` Philip K. 6 siblings, 0 replies; 838+ messages in thread From: Bonface M. K. @ 2020-10-11 20:54 UTC (permalink / raw) To: Adrien Brochard; +Cc: rms, emacs-devel [-- Attachment #1: Type: text/plain, Size: 6164 bytes --] Hi all! Just some minor feedback. Adrien Brochard <abrochard@gmx.com> writes: [...] > > I also agree with this. I think no matter what we are going to get > selection bias and we should not rush any decision based on the survey > results. > > > * Survey Questions > (Please note that any "other" should allow for free text entry for the > respondent to elaborate) > > ** How would you characterize your use of Emacs? > - Use it for work > - I use it for serious "hobby" projects > - I'm just tinkering > - I use it for my studies > - Other > You could use Emacs for "everything". I'd propose you make this question open-ended? > ** What do you use Emacs for? > - Software development > - Research writing > - Data science > - Writing > - Other > Same as above. You could use Emacs as a combination of the above. > ** How long have you been using Emacs? > > ** Which version of Emacs do you use? > > ** What OS do you primary use? > - Linux > - Windows > - MacOS > - BSD > - Other > > ** How do you use Emacs? > - GUI > - Terminal (TUI) > - Both > > ** How do you run Emacs? > - Client/Server mode only > - Standalone application only > - Both > > ** Describe your configuration > - I am using vanilla emacs (little to no configuration). > - Custom configuration > - Spacemacs - https://github.com/syl20bnr/spacemacs > - Doom Emacs - https://github.com/hlissner/doom-emacs > - Prelude - https://github.com/bbatsov/prelude > - purcell emacs.d - https://github.com/purcell/emacs.d > - magnars emacs.d - https://github.com/magnars/.emacs.d > - Emacs Starter Kit - https://github.com/eschulte/emacs-starter-kit > - oh-my-emacs - https://github.com/xiaohanyu/oh-my-emacs > - Better Defaults - https://github.com/technomancy/better-defaults > - Graphene - https://github.com/rdallasgray/graphene > - ohai-emacs - https://github.com/bodil/ohai-emacs > - ergoemacs-mode - https://github.com/ergoemacs/ergoemacs-mode > - Rho Emacs - https://github.com/GChristensen/rho-emacs > - Radian - https://github.com/raxod502/radian > - Centaur Emacs - https://github.com/seagle0128/.emacs.d > - Other > > ** What keybindings do you use? > - Emacs defaults > - Evil/Spacemacs/Doom-Emacs (all the vim-likes) > - CUA-mode > - God-mode > - Boon > - Xah-Fly-Keys > - Custom modal (ryo-modal, etc) > - Custom modifiers (Emacs from scratch) > - Other > > ** Prior to using Emacs what was your primary editor? > - VIM > - VScode > - Eclipse > - Notepad++ > - Sublime > - Intelij > - Other > > ** org-mode usage > - I use emacs only for org-mode > - dayly > - from time to time > - Not a org-mode user > > ** Which completion/selection framework do you use? > - helm > - ivy > - ido > - icomplete > - other > - i don't use a completion framework > > ** How do you manage third-party elisp? > - built-in package.el > - Spacemacs does it for me > - straight.el > - borg > - leaf > - el-get > - Nix > - git submodules without Borg > - git subtrees > - git clones > - guix > - quelpa > - cask > - No third-party deps > - other > > ** How do you get emacs packages(if applicable)? > - No repos > - Gnu Elpa > - Melpa/Melpa Stable > - Directly from the source (e. g. using straight). > > ** Can you list some of your favorite package? > > ** What package do you use for error checking? > - Flymake > - Flycheck > - None > > ** Do you use TRAMP? > > ** DO you use Magit? > > ** What package do you use for project management? > - project.el > - projectile > - Other(mention) > - None > > ** Do you use shell/terminal emulator in Emacs? > - eshell > - shell > - term > - ansi-term > - do not use. > > ** Do you use mail client in Emacs? > - Mu4e > - Gnus > - Mut > - notmuch > - do not use > > ** What is your Elisp proficiency? > - Beginner/No knowledge > - Basic elisp understanding > - Intermediate > - Advanced > - Expert > > ** If you use Emacs for programming, which languages do you program in? > > ** do you use a language server with lsp-mode? With what languages? > > ** Do you use Emacs for debugging? What do you use? (Gdb, dap-mode etc) > > ** Which theme do you use? > > ** Have you ever contributed to GNU Emacs core/Elpa? > - No > - No, but I would do that if the process is changed(e. g. using > github pull requests instead of the mailing list, no papers, etc**. > - I do PRs from time to time > - I provide PRs regularly > - I am active contributor/maintainer > > ** Have you ever contributed to Melpa package? > - No > - I do PRs from time to time > - I provide PRs regularly > - I am a package maintainer > > ** What Emacs community forums have you visited in the past year? > Answers would be things like > - r/emacs > - Emacs mailing list > - irc > - Emacs meetups > - I follow twitter Emacs related accounts > - Other > > ** What are some of the Emacs improvements you are the most interested in? > ** what do you think are Emacs' greatest strengths? > ** can you recall any difficulties you faced initially learning Emacs? > ** What is the one thing you would like emacs to do differently? > ** How did you hear about this survey? > ** If there is another survey in 2021, would you be opposed to it > containing optional & general demographics questions? > It could include age backets, gender, country or language > ** Do you have a preferred platform for filling out the survey in the > future? > ** General feedback about the survey process? > > > -- Bonface M. K. (https://www.bonfacemunyoki.com) Chief Emacs Mchochezi / Twitter: @BonfaceKilz GPG key = D4F09EB110177E03C28E2FE1F5BBAE1E0392253F [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 869 bytes --] ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-09 23:12 ` Adrien Brochard ` (5 preceding siblings ...) 2020-10-11 20:54 ` Bonface M. K. @ 2020-10-16 13:30 ` Philip K. 6 siblings, 0 replies; 838+ messages in thread From: Philip K. @ 2020-10-16 13:30 UTC (permalink / raw) To: Adrien Brochard; +Cc: emacs-devel Adrien Brochard <abrochard@gmx.com> writes: > ** How do you use Emacs? > - GUI > - Terminal (TUI) > - Both I'd suggest also asking how they use the GUI. Do they keep everything as it is, or hide the scroll-, tool- and menu bar (or just parts). Perhaps, if it turns out that most people disable some feature, it could be turned off by default in the next release? If you ask me, just removing the tool-bar would improve the default look more than anything else. -- Philip K. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-08 15:30 Proposal for an Emacs User Survey Adrien Brochard ` (2 preceding siblings ...) 2020-10-09 3:35 ` Richard Stallman @ 2020-10-19 16:20 ` Philip K. 2020-10-19 19:44 ` Dmitry Gutov 2020-10-20 5:19 ` Richard Stallman 3 siblings, 2 replies; 838+ messages in thread From: Philip K. @ 2020-10-19 16:20 UTC (permalink / raw) To: emacs-devel I can't seem to find anyone here mentioning it, but it seems the survey has been opened today: https://emacssurvey.org/ Sadly, it seems like they decided to use non-free JS for the web-form variant :( Adrien Brochard <abrochard@gmx.com> writes: > Hi everyone, > > I posted on reddit.com/r/emacs yesterday a proposal to craft and > distribute a survey for Emacs users to better grasp the diversity and > various usages out there. I got some very good feedback but there could > always be more. > > The main points that need to be worked out are: > 1. the actual questions to be asked > 2. the platform to collect responses > > Regarding the questions, I have a decent skeleton and a lot of suggestions. > > But the for the platform to collect responses, this is where it gets > difficult. Something like a Google survey might the easiest/cheapest to > make and distribute and will work on most devices, but it obviously has > privacy concerns. On the other hand, doing something like self-hosting a > no-JS form is very time consuming. I was also thinking of allowing > responses via email for people who do not want to bother with a survey > link and then manually reconcile responses. > > Links to the posts with the tentative questions: > - > https://www.reddit.com/r/emacs/comments/j6x7ad/proposal_for_an_emacs_user_survey/ > - > https://www.reddit.com/r/emacs/comments/b2fh4y/help_reviewprovide_feedback_on_state_of_emacs/ > > Thank you for reading! > Best, > Adrien > > -- Philip K. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-19 16:20 ` Philip K. @ 2020-10-19 19:44 ` Dmitry Gutov 2020-10-20 5:19 ` Richard Stallman 1 sibling, 0 replies; 838+ messages in thread From: Dmitry Gutov @ 2020-10-19 19:44 UTC (permalink / raw) To: Philip K., emacs-devel On 19.10.2020 19:20, Philip K. wrote: > I can't seem to find anyone here mentioning it, but it seems the survey > has been opened today: > > https://emacssurvey.org/ > > Sadly, it seems like they decided to use non-free JS for the web-form > variant:( That's unfortunate. Still, they included added the free-form option. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-19 16:20 ` Philip K. 2020-10-19 19:44 ` Dmitry Gutov @ 2020-10-20 5:19 ` Richard Stallman 2020-10-20 8:22 ` Thibaut Verron 1 sibling, 1 reply; 838+ messages in thread From: Richard Stallman @ 2020-10-20 5:19 UTC (permalink / raw) To: Philip K.; +Cc: emacs-devel [[[ 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. ]]] > https://emacssurvey.org/ > Sadly, it seems like they decided to use non-free JS for the web-form > variant :( This means that the results will be biased in two ways: * In favor of people who use the forums he posted it in. * Against people who won't run nonfree software. The results may be of use anyway, but they will not describe a represent sample of all Emacs users. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-20 5:19 ` Richard Stallman @ 2020-10-20 8:22 ` Thibaut Verron 2020-10-20 9:48 ` Jean Louis 0 siblings, 1 reply; 838+ messages in thread From: Thibaut Verron @ 2020-10-20 8:22 UTC (permalink / raw) To: Richard Stallman; +Cc: Philip K., emacs-devel > This means that the results will be biased in two ways: > > * In favor of people who use the forums he posted it in. It has been (and can be) posted in many places, including presently emacs-devel. > * Against people who won't run nonfree software. The survey can be completed without running nonfree software, by sending an e-mail. > The results may be of use anyway, but they will not describe a > represent sample of all Emacs users. I agree, but that's because of difficulties inherent to polling, not because of a bias that could have been easily avoided. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-20 8:22 ` Thibaut Verron @ 2020-10-20 9:48 ` Jean Louis 2020-10-20 11:03 ` Thibaut Verron 0 siblings, 1 reply; 838+ messages in thread From: Jean Louis @ 2020-10-20 9:48 UTC (permalink / raw) To: Thibaut Verron; +Cc: Philip K., Richard Stallman, emacs-devel * Thibaut Verron <thibaut.verron@gmail.com> [2020-10-20 11:23]: > I agree, but that's because of difficulties inherent to polling, not > because of a bias that could have been easily avoided. It is not difficult, it is one simple stupid HTML, make it nice with CSS, form can be accepted and saved in file for later processing. Further there is free software for that, there are systems like Wordpres, Drupal and other website revision software. There is something like LimeSurvey for complexities: https://community.limesurvey.org/downloads/ You can survey in pure bash shell: https://blog.eduonix.com/shell-scripting/learn-cgi-scripting-using-bash-in-linux-shell-scripting/ I would do it in nothing else but Emacs to write the form, and to accept the form over CGI. It would then be stored as encrypted Emacs Lisp data in file, and later could be evaluated. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-20 9:48 ` Jean Louis @ 2020-10-20 11:03 ` Thibaut Verron 2020-10-20 11:38 ` Jean Louis 0 siblings, 1 reply; 838+ messages in thread From: Thibaut Verron @ 2020-10-20 11:03 UTC (permalink / raw) To: Jean Louis; +Cc: Philip K., Richard Stallman, emacs-devel Le mar. 20 oct. 2020 à 11:48, Jean Louis <bugs@gnu.support> a écrit : > > * Thibaut Verron <thibaut.verron@gmail.com> [2020-10-20 11:23]: > > I agree, but that's because of difficulties inherent to polling, not > > because of a bias that could have been easily avoided. > > It is not difficult, it is one simple stupid HTML, make it nice with > CSS, form can be accepted and saved in file for later processing. Yes, I thought I was clearly stating that the difficulties I was referring to were not related to the form of the survey, where in my opinion they did choose a reasonable path. The difficulties are inherent to polling and concern reaching a sufficiently large sample, weighing it for representativity, etc. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-20 11:03 ` Thibaut Verron @ 2020-10-20 11:38 ` Jean Louis 2020-10-26 17:43 ` Teemu Likonen 2020-10-26 18:13 ` Ivan Yonchovski 0 siblings, 2 replies; 838+ messages in thread From: Jean Louis @ 2020-10-20 11:38 UTC (permalink / raw) To: Thibaut Verron; +Cc: Philip K., Richard Stallman, emacs-devel * Thibaut Verron <thibaut.verron@gmail.com> [2020-10-20 14:04]: > Le mar. 20 oct. 2020 ?? 11:48, Jean Louis <bugs@gnu.support> a ??crit : > > > > * Thibaut Verron <thibaut.verron@gmail.com> [2020-10-20 11:23]: > > > I agree, but that's because of difficulties inherent to polling, not > > > because of a bias that could have been easily avoided. > > > > It is not difficult, it is one simple stupid HTML, make it nice with > > CSS, form can be accepted and saved in file for later processing. > > Yes, I thought I was clearly stating that the difficulties I was > referring to were not related to the form of the survey, where in my > opinion they did choose a reasonable path. 20 years ago we were handling forms with Perl's form.cgi For me is surprising that Emacs survey has to be done with third party providers. If anybody would ask me, I would make it in simple HTML, what I already proposed, and I could install the background CGI to accept the form. > The difficulties are inherent to polling and concern reaching a > sufficiently large sample, weighing it for representativity, etc. Both ways how the surve have been presented with the proprietary Javascript and with the download of the Org file, are not user friendly and cannot reach large sample. One also needs marketing skills. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-20 11:38 ` Jean Louis @ 2020-10-26 17:43 ` Teemu Likonen 2020-10-26 19:36 ` Jean Louis ` (2 more replies) 2020-10-26 18:13 ` Ivan Yonchovski 1 sibling, 3 replies; 838+ messages in thread From: Teemu Likonen @ 2020-10-26 17:43 UTC (permalink / raw) To: Jean Louis, Thibaut Verron; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 888 bytes --] * 2020-10-20 14:38:07+03, Jean Louis wrote: > For me is surprising that Emacs survey has to be done with third party > providers. If anybody would ask me, I would make it in simple HTML, > what I already proposed, and I could install the background CGI to > accept the form. > Both ways how the surve have been presented with the proprietary > Javascript and with the download of the Org file, are not user > friendly and cannot reach large sample. One also needs marketing > skills. I think we should appreciate the fact that the original poster (Adrien Brochard) actually did something. He is really conducting a survey. He is not just talking and designing a theoretically and ethically perfect survey, as the rest of us. https://emacssurvey.org/ -- /// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/ // OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 251 bytes --] ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-26 17:43 ` Teemu Likonen @ 2020-10-26 19:36 ` Jean Louis 2020-10-26 19:58 ` Jean Louis 2020-10-27 3:44 ` Richard Stallman 2 siblings, 0 replies; 838+ messages in thread From: Jean Louis @ 2020-10-26 19:36 UTC (permalink / raw) To: Teemu Likonen; +Cc: Thibaut Verron, emacs-devel * Teemu Likonen <tlikonen@iki.fi> [2020-10-26 20:44]: > * 2020-10-20 14:38:07+03, Jean Louis wrote: > > > For me is surprising that Emacs survey has to be done with third party > > providers. If anybody would ask me, I would make it in simple HTML, > > what I already proposed, and I could install the background CGI to > > accept the form. > > > Both ways how the surve have been presented with the proprietary > > Javascript and with the download of the Org file, are not user > > friendly and cannot reach large sample. One also needs marketing > > skills. > > I think we should appreciate the fact that the original poster (Adrien > Brochard) actually did something. He is really conducting a survey. He > is not just talking and designing a theoretically and ethically perfect > survey, as the rest of us. > > https://emacssurvey.org/ http://www.gnu.org/fun/jokes/users-lightbulb.html -- Jean Louis ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-26 17:43 ` Teemu Likonen 2020-10-26 19:36 ` Jean Louis @ 2020-10-26 19:58 ` Jean Louis 2020-10-27 3:44 ` Richard Stallman 2 siblings, 0 replies; 838+ messages in thread From: Jean Louis @ 2020-10-26 19:58 UTC (permalink / raw) To: Teemu Likonen; +Cc: Thibaut Verron, emacs-devel * Teemu Likonen <tlikonen@iki.fi> [2020-10-26 20:44]: > I think we should appreciate the fact that the original poster (Adrien > Brochard) actually did something. He is really conducting a survey. He > is not just talking and designing a theoretically and ethically perfect > survey, as the rest of us. > > https://emacssurvey.org/ The bug database https://debbugs.gnu.org/cgi/pkgreport.cgi?which=pkg&data=emacs is like a pinpointed poll on what people would like to have improved. While the survey is interesting, it went into public with little good preparation now driving users to . Impression is that there was impatience and rush to make the survey or poll. Comparing the Emacs bug system to the survey I see that bug system actually works very well including this mailing list. The type of discussions may seem talky though in background it is very productive and Emacs gets speedily improved. When doing such outreach it would be useful to reference to the bug system and help-gnu-emacs@gnu.org mailing list where every user may ask for general help on Emacs. > He is really conducting a survey. He is not just talking and > designing a theoretically and ethically perfect survey, as the rest > of us. The survey is not well planned and implemented technically. That is beyond theoretical or ethical subjects. Survey gives two options for user to fill it online and to fill the Org file, I did the last and signed it with my GPG key. Example is here: - HOW WOULD YOU CHARACTERIZE YOUR USE OF EMACS? - [X] Use it for work - [X] I use it for serious "hobby" projects - [X] I'm just tinkering - [X] I use it for my studies - [X] Other (please specify) - for browsing Internet - for database management - CRM or Customer Relationship Management - WRS or Website Revision System - for management of mailing lists and marketing The online form offers only one option among those above options. And so on for each section of the survey, there is option list instead of a checklist. To make a survey form like that is maybe 20 minutes to 60 minutes of work and it would cost maybe $5 to $20 to hire somebody to do it, many would do it for free and it would be technically readable and accessible page without any non-free Javascript or third parties being involved. -- Jean Louis ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-26 17:43 ` Teemu Likonen 2020-10-26 19:36 ` Jean Louis 2020-10-26 19:58 ` Jean Louis @ 2020-10-27 3:44 ` Richard Stallman 2 siblings, 0 replies; 838+ messages in thread From: Richard Stallman @ 2020-10-27 3:44 UTC (permalink / raw) To: Teemu Likonen; +Cc: thibaut.verron, bugs, emacs-devel [[[ 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. ]]] > I think we should appreciate the fact that the original poster (Adrien > Brochard) actually did something. He did something, in a way that has good effects and bad ones. He could have cooperated and done it in a way that would have had the same good effects and not the bad effects, but that's not what he chose. My appreciation will therefore be limited. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-20 11:38 ` Jean Louis 2020-10-26 17:43 ` Teemu Likonen @ 2020-10-26 18:13 ` Ivan Yonchovski 2020-10-26 20:21 ` Jean Louis 1 sibling, 1 reply; 838+ messages in thread From: Ivan Yonchovski @ 2020-10-26 18:13 UTC (permalink / raw) To: Jean Louis; +Cc: Philip K., Richard Stallman, Thibaut Verron, emacs-devel Jean Louis writes: > Both ways how the surve have been presented with the proprietary > Javascript and with the download of the Org file, are not user > friendly and cannot reach large sample. One also needs marketing > skills. What number of responders will be considered large enough sample? Thanks, Ivan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Proposal for an Emacs User Survey 2020-10-26 18:13 ` Ivan Yonchovski @ 2020-10-26 20:21 ` Jean Louis 0 siblings, 0 replies; 838+ messages in thread From: Jean Louis @ 2020-10-26 20:21 UTC (permalink / raw) To: Ivan Yonchovski; +Cc: Philip K., Richard Stallman, Thibaut Verron, emacs-devel * Ivan Yonchovski <yyoncho@gmail.com> [2020-10-26 21:14]: > > Jean Louis writes: > > > Both ways how the surve have been presented with the proprietary > > Javascript and with the download of the Org file, are not user > > friendly and cannot reach large sample. One also needs marketing > > skills. > > What number of responders will be considered large enough sample? That is not easy to determine. I would say that 1000 people would be minimum in each case and it would never be enough, as that comes from personal experience from work in two organizations, one was specifically a survey company and other was conducting always surveys for its own humanitarian purposes. From: https://www.cloudresearch.com/resources/guides/statistical-significance/determine-sample-size/ As you can see, even when a population is large, researchers can often understand the entire group with about 1,000 respondents. Population Size Sample Size Based on ±3% Sample Size Based on ±5% Sample Size Based on ±10% Margin of Error Margin of Error Margin of Error 500 345 220 80 1,000 525 285 90 3,000 810 350 100 5,000 910 370 100 10,000 1,000 385 100 100,00+ 1,100 400 100 ----- end of quote -------- Every survey should have its purpose, usually to improve the product or service, in this case Emacs. Improvements are constantly made and public opinion is looked upon. To discuss issues with people is human, friendly and vibrant activity and is way of taking opinions (bug reports, emails, opinions, package contributions) and putting them in reality (patches, improvements, ELPA...). To ask people questions online without opportunity for feedback is one-way, dead end type of a communication. There are few questions that look like there is question about accessibility yet we will see later what comes out of it. If website is not made well accessible those questions may not be productive. For solving usability issues, instead of 1000 people one could as well follow feedback from 5 users, reference: https://www.nngroup.com/articles/usability-101-introduction-to-usability/ Article refers to web, it may be applied on Emacs user interface. Quote: Usability is a quality attribute that assesses how easy user interfaces are to use. The word "usability" also refers to methods for improving ease-of-use during the design process. Usability is defined by 5 quality components: - Learnability: How easy is it for users to accomplish basic tasks the first time they encounter the design? - Efficiency: Once users have learned the design, how quickly can they perform tasks? - Memorability: When users return to the design after a period of not using it, how easily can they reestablish proficiency? - Errors: How many errors do users make, how severe are these errors, and how easily can they recover from the errors? - Satisfaction: How pleasant is it to use the design? -- Jean Louis ^ permalink raw reply [flat|nested] 838+ messages in thread
[parent not found: <<fdimdgyaxf.fsf@norden.tntech.edu>]
[parent not found: <<83r1s4ftc7.fsf@gnu.org>]
* RE: Delete variables obsolete since Emacs 23 [not found] ` <<83r1s4ftc7.fsf@gnu.org> @ 2020-08-18 16:13 ` Drew Adams 2020-08-18 19:27 ` Stefan Monnier 0 siblings, 1 reply; 838+ messages in thread From: Drew Adams @ 2020-08-18 16:13 UTC (permalink / raw) To: Eli Zaretskii, Jeff Norden Cc: rms, emacs-devel, monnier, ghe, drew.adams, stefankangas > I think the gentle annoyance we have now strikes the right balance > between not letting people forget the fact of obsolescence and not > annoying them too much. We are talking to adults, not to children, so > we can rely on them doing TRT. +1. It's obsolete, but we leave it in the product, so as to not annoy those who don't, or can't easily, work around its absence. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Delete variables obsolete since Emacs 23 2020-08-18 16:13 ` Delete variables obsolete since Emacs 23 Drew Adams @ 2020-08-18 19:27 ` Stefan Monnier 2020-08-18 20:21 ` Drew Adams ` (2 more replies) 0 siblings, 3 replies; 838+ messages in thread From: Stefan Monnier @ 2020-08-18 19:27 UTC (permalink / raw) To: Drew Adams Cc: rms, Jeff Norden, emacs-devel, stefankangas, ghe, Eli Zaretskii >> I think the gentle annoyance we have now strikes the right balance >> between not letting people forget the fact of obsolescence and not >> annoying them too much. We are talking to adults, not to children, so >> we can rely on them doing TRT. > +1. It's obsolete, but we leave it in the product, That is not what he said. > so as to not annoy those who don't, or can't easily, > work around its absence. If there's no intention to remove it in the future, then we don't declare it obsolete. Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Delete variables obsolete since Emacs 23 2020-08-18 19:27 ` Stefan Monnier @ 2020-08-18 20:21 ` Drew Adams 2020-08-18 21:00 ` Gregory Heytings via Emacs development discussions. 2020-08-18 21:30 ` Jeff Norden 2 siblings, 0 replies; 838+ messages in thread From: Drew Adams @ 2020-08-18 20:21 UTC (permalink / raw) To: Stefan Monnier Cc: rms, Jeff Norden, emacs-devel, stefankangas, ghe, Eli Zaretskii > >> I think the gentle annoyance we have now strikes the right balance > >> between not letting people forget the fact of obsolescence and not > >> annoying them too much. We are talking to adults, not to children, so > >> we can rely on them doing TRT. > > > > +1. It's obsolete, but we leave it in the product, > > That is not what he said. Eli can weigh in on whether it is or isn't. Isn't that exactly what "we have now": declaration of obsolescence, without removal? That's what I understood by "the gentle annoyance we have now". And I agree that that "strikes the right balance" by (1) reminding about obsolescence and (2) not annoying too much. > > so as to not annoy those who don't, or can't > > easily, work around its absence. > > If there's no intention to remove it in the future, > then we don't declare it obsolete. Is that written on the foundation stone of GNU Emacs somewhere? That's not how deprecation/obsolescence is viewed in general, e.g. outside Emacs. Something is deprecated or declared obsolete because we no longer want to commit to its active development, for WHATEVER reason (and the reasons can be several). Often, that's because some other, better thing replaces it, but that's not a requirement. Not wanting to commit to active development (e.g. improvement, new features) is not the same thing as an intention to remove. I think you have a very (unnecessarily) strong view of deprecation. One of the main ideas behind deprecation is to NOT tie your hands wrt future decisions. All that's decided is, so far, to not develop the thing further. The message to users is (1) the thing is still supported (it's not removed), but only AS IS, so (2) don't expect further development. Removing something is what's normally called "desupport": XYZ is no longer supported. Trying to use it raises an error, or is ignored (no-op), etc. You _cannot_ use something that's _desupported_. You're advised/warned that you might not want to use something that's deprecated. Even for commercial software, there are quite often features that are deprecated with NO intention to _ever_ remove them. Why? Because of an existing customer base, with legacy code. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Delete variables obsolete since Emacs 23 2020-08-18 19:27 ` Stefan Monnier 2020-08-18 20:21 ` Drew Adams @ 2020-08-18 21:00 ` Gregory Heytings via Emacs development discussions. 2020-08-18 21:55 ` Stefan Monnier 2020-08-18 21:30 ` Jeff Norden 2 siblings, 1 reply; 838+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-08-18 21:00 UTC (permalink / raw) To: emacs-devel > >> so as to not annoy those who don't, or can't easily, work around its >> absence. > > If there's no intention to remove it in the future, then we don't > declare it obsolete. > I think the discussion is too broad. It depends on what is declared obsolete. If it's a whole package, or a complex function, declaring that it is obsolete means that it won't be developed or supported in the future, and that because of this it might become non-functional at some point because the conditions it assumes will not hold anymore. At that moment there is a good reason to remove it: it does not work anymore. If on the contrary it's a function as trivial as (defun interactive-p () (called-interactively-p 'interactive)) then declaring that it is obsolete means that new code should preferably use the new style. But there is no reason to remove it. Gregory ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Delete variables obsolete since Emacs 23 2020-08-18 21:00 ` Gregory Heytings via Emacs development discussions. @ 2020-08-18 21:55 ` Stefan Monnier 0 siblings, 0 replies; 838+ messages in thread From: Stefan Monnier @ 2020-08-18 21:55 UTC (permalink / raw) To: Gregory Heytings via Emacs development discussions.; +Cc: Gregory Heytings > I think the discussion is too broad. It depends on what is > declared obsolete. IMNSHO it doesn't: if we don't intend to remove it ever, then we don't declare it obsolete. Of course, declaring it obsolete doesn't guarantee that we will remove it: it's just a declaration of intention. Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Delete variables obsolete since Emacs 23 2020-08-18 19:27 ` Stefan Monnier 2020-08-18 20:21 ` Drew Adams 2020-08-18 21:00 ` Gregory Heytings via Emacs development discussions. @ 2020-08-18 21:30 ` Jeff Norden 2 siblings, 0 replies; 838+ messages in thread From: Jeff Norden @ 2020-08-18 21:30 UTC (permalink / raw) To: Stefan Monnier; +Cc: rms, emacs-devel, stefankangas, ghe, eliz, drew.adams I said: >> The elisp manual says: >> You can mark a named function as "obsolete", meaning that it may be >> removed at some point in the future. This causes Emacs ... >> The phrase "may be removed" seems a bit vague. Would "will be removed" or >> "will probably be removed" be more accurate? To which Eli Zaretskii replied: > No, it won't. Primarily because we don't really know whether we will > remove it, let alone when. It depends on too many factors that we > cannot predict. But then Stefan Monnier wrote: > If there's no intention to remove it in the future, then we don't > declare it obsolete. I really like the use of 'obsolete' instead of 'deprecate'. Merriam-Webster gives a two-part definition: Definition of obsolete: 1 a: no longer in use or no longer useful b: of a kind or style no longer current : OLD-FASHIONED I personally think that there is a case for keeping a limited number of obsolete functions/variables long term, for backward compatibility. You can apply definition (b) to these, although it's not a perfect fit, since obsolete functions shouldn't be used in new code. Windows still supports 8.3 file names (a horrible example, since they never should have been created in the first place). My pickup truck still uses a carburetor, which was certainly made obsolete by fuel injection, but still works fine for me. Of course, obsolete features won't be maintained, updated, etc. (My local parts stores no longer stock an air filter that fits my truck.) But, if a function or variable fits (a), and is really no longer used or useful, then it only make sense to remove it. It may not be possible or practical to precisely label each obsolete emacs item with a category. But, it would be good to be clear as to whether or not (make-obsolete) should be regarded as including both possible cases. Thanks, -Jeff ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#42611: 26.3; edit-abbrevs lets me type and commit, but doesn't store anywhere and abbrevs don't work
@ 2020-07-30 4:01 Brett Randall
[not found] ` <handler.42611.B.159608273314264.ack@debbugs.gnu.org>
2020-10-17 8:41 ` Lars Ingebrigtsen
0 siblings, 2 replies; 838+ messages in thread
From: Brett Randall @ 2020-07-30 4:01 UTC (permalink / raw)
To: 42611
[-- Attachment #1: Type: text/plain, Size: 4444 bytes --]
Actions that triggered the bug:
M-x edit-abbrevs
Enter abbrevs in fundamental or global abbreviations at bottom of the list, e.g.:
"dfn" 0 "definition"
C-c C-c
Buffer appears committed (modified flag disappears). Close buffer, test the abbrev in "abbrev-mode" minor mode and nothing happens. M-x edit-abbrevs again. The definition I entered is no longer there. This is in the same session. Emacs was not closed/reopened. The definitions are not applying/temporarily saving.
In GNU Emacs 26.3 (build 1, x86_64-pc-cygwin)
of 2019-08-31 built on moufang2
Repository revision: 522486e90a3d9402d836c2186be9e73299423cd9
Windowing system distributor 'Microsoft Corp.', version 10.0.19041
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Quit
(New file)
Making completion list...
Abbrev mode enabled in current buffer
Saving all Org buffers... done
Configured using:
'configure
--srcdir=/home/kbrown/src/cygpackages/emacs/emacs-26.3-2.x86_64/src/emacs-26.3
--prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc
--docdir=/usr/share/doc/emacs --htmldir=/usr/share/doc/emacs/html -C
--with-w32 'CFLAGS=-ggdb -O2 -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-strong
--param=ssp-buffer-size=4
-fdebug-prefix-map=/home/kbrown/src/cygpackages/emacs/emacs-26.3-2.x86_64/build=/usr/src/debug/emacs-26.3-2
-fdebug-prefix-map=/home/kbrown/src/cygpackages/emacs/emacs-26.3-2.x86_64/src/emacs-26.3=/usr/src/debug/emacs-26.3-2'
CPPFLAGS= LDFLAGS='
Configured features:
XPM JPEG TIFF GIF PNG IMAGEMAGICK SOUND DBUS GLIB NOTIFY ACL GNUTLS
LIBXML2 ZLIB TOOLKIT_SCROLL_BARS XIM THREADS LCMS2
Important settings:
locale-coding-system: nil
Major mode: Info
Minor modes in effect:
global-auto-revert-mode: t
tooltip-mode: t
global-eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
buffer-read-only: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg gnus-util rmail rmail-loaddefs
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils jka-compr info elec-pair org-element avl-tree generator org
org-macro org-footnote org-pcomplete pcomplete org-list org-faces
org-entities noutline outline easy-mmode org-version ob-emacs-lisp ob
ob-tangle org-src ob-ref ob-lob ob-table ob-keys ob-exp ob-comint comint
ansi-color ring ob-core ob-eval org-compat org-macs org-loaddefs
format-spec find-func cal-menu calendar cal-loaddefs edmacro kmacro
advice autorevert filenotify arjen-theme finder-inf package easymenu
epg-config url-handlers url-parse auth-source cl-seq eieio eieio-core
cl-macs eieio-loaddefs password-cache url-vars seq byte-opt gv bytecomp
byte-compile cconv cl-loaddefs cl-lib time-date mule-util tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel disp-table
term/w32-win w32-win w32-vars term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind gfilenotify w32 lcms2 multi-tty
make-network-process emacs)
Memory information:
((conses 16 165726 13709)
(symbols 48 27132 1)
(miscs 40 72 220)
(strings 32 55598 1442)
(string-bytes 1 1610203)
(vectors 16 22900)
(vector-slots 8 589906 9136)
(floats 8 97 210)
(intervals 56 320 176)
(buffers 992 16))
Brett
[-- Attachment #2: Type: text/html, Size: 6111 bytes --]
^ permalink raw reply [flat|nested] 838+ messages in thread[parent not found: <handler.42611.B.159608273314264.ack@debbugs.gnu.org>]
[parent not found: <(Brett>]
* bug#42611: 26.3; edit-abbrevs lets me type and commit, but doesn't store anywhere and abbrevs don't work 2020-07-30 4:01 bug#42611: 26.3; edit-abbrevs lets me type and commit, but doesn't store anywhere and abbrevs don't work Brett Randall [not found] ` <handler.42611.B.159608273314264.ack@debbugs.gnu.org> @ 2020-10-17 8:41 ` Lars Ingebrigtsen 2020-10-27 10:36 ` brett.randall 1 sibling, 1 reply; 838+ messages in thread From: Lars Ingebrigtsen @ 2020-10-17 8:41 UTC (permalink / raw) To: Brett Randall; +Cc: 42611 Brett Randall <brett.randall@gmail.com> writes: > Actions that triggered the bug: > > M-x edit-abbrevs > > Enter abbrevs in fundamental or global abbreviations at bottom of the list, e.g.: > > "dfn" 0 "definition" > > C-c C-c > > Buffer appears committed (modified flag disappears). Close buffer, test the abbrev > in "abbrev-mode" minor mode and nothing happens. M-x edit-abbrevs again. The > definition I entered is no longer there. This is in the same session. Emacs was not > closed/reopened. The definitions are not applying/temporarily saving. I'm unable to reproduce this bug either in Emacs 26.3 or on the trunk. `C-c C-c' in the *Abbrevs* buffer updates the abbreviation for me. Are you able to reproduce this bug starting from "emacs -Q"? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#42611: 26.3; edit-abbrevs lets me type and commit, but doesn't store anywhere and abbrevs don't work 2020-10-17 8:41 ` Lars Ingebrigtsen @ 2020-10-27 10:36 ` brett.randall [not found] ` <(brett> 2020-10-27 10:43 ` Lars Ingebrigtsen 0 siblings, 2 replies; 838+ messages in thread From: brett.randall @ 2020-10-27 10:36 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 42611 [-- Attachment #1: Type: text/plain, Size: 969 bytes --] --- original message --- On October 17, 2020, 7:41 PM GMT+11 larsi@gnus.org wrote: Brett Randall <brett.randall@gmail.com> writes: >> Actions that triggered the bug: >> >> M-x edit-abbrevs >> >> Enter abbrevs in fundamental or global abbreviations at bottom of the list, e.g.: >> >> "dfn" 0 "definition" >> >> C-c C-c >> >> Buffer appears committed (modified flag disappears). Close buffer, test the abbrev >> in "abbrev-mode" minor mode and nothing happens. M-x edit-abbrevs again. The >> definition I entered is no longer there. This is in the same session. Emacs was not >> closed/reopened. The definitions are not applying/temporarily saving. > I'm unable to reproduce this bug either in Emacs 26.3 or on the trunk. > `C-c C-c' in the *Abbrevs* buffer updates the abbreviation for me. > Are you able to reproduce this bug starting from "emacs -Q"? Yes, the bug exists from there too. Brett --- end of original message --- [-- Attachment #2: Type: text/html, Size: 1806 bytes --] ^ permalink raw reply [flat|nested] 838+ messages in thread
[parent not found: <(brett>]
* bug#42611: 26.3; edit-abbrevs lets me type and commit, but doesn't store anywhere and abbrevs don't work 2020-10-27 10:36 ` brett.randall [not found] ` <(brett> @ 2020-10-27 10:43 ` Lars Ingebrigtsen 2020-10-27 10:49 ` Brett Randall 1 sibling, 1 reply; 838+ messages in thread From: Lars Ingebrigtsen @ 2020-10-27 10:43 UTC (permalink / raw) To: brett.randall; +Cc: 42611 brett.randall@gmail.com writes: > I'm unable to reproduce this bug either in Emacs 26.3 or on the trunk. > `C-c C-c' in the *Abbrevs* buffer updates the abbreviation for me. > > Are you able to reproduce this bug starting from "emacs -Q"? > > Yes, the bug exists from there too. Can you give a recipe for how to reproduce the bug, starting from "emacs -Q"? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#42611: 26.3; edit-abbrevs lets me type and commit, but doesn't store anywhere and abbrevs don't work 2020-10-27 10:43 ` Lars Ingebrigtsen @ 2020-10-27 10:49 ` Brett Randall 2020-10-27 11:08 ` Lars Ingebrigtsen 0 siblings, 1 reply; 838+ messages in thread From: Brett Randall @ 2020-10-27 10:49 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 42611 [-- Attachment #1: Type: text/plain, Size: 888 bytes --] Brett --- original message --- On October 27, 2020, 9:43 PM GMT+11 larsi@gnus.org wrote: brett.randall@gmail.com writes: >> I'm unable to reproduce this bug either in Emacs 26.3 or on the trunk. >> `C-c C-c' in the *Abbrevs* buffer updates the abbreviation for me. >> >> Are you able to reproduce this bug starting from "emacs -Q"? >> >> Yes, the bug exists from there too. > Can you give a recipe for how to reproduce the bug, starting from > "emacs -Q"? Yes: emacs -Q M-x edit-abbrevs Scroll to last line - (global-abbrev-table) Append: "dfn" 0 "definition" C-c C-c (removes "modified" flag) C-x k M-x edit-abbrevs Scroll down to last line - abbreviation is not there C-x C-c (results in "Save abbrevs in ~/.emacs.d/abbrev_defs? (y or n) ") "y" to above Inspect .emacs.d/abbrev_defs - only contains one line: ;;-*-coding: utf-8;-*- --- end of original message --- [-- Attachment #2: Type: text/html, Size: 1980 bytes --] ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#42611: 26.3; edit-abbrevs lets me type and commit, but doesn't store anywhere and abbrevs don't work 2020-10-27 10:49 ` Brett Randall @ 2020-10-27 11:08 ` Lars Ingebrigtsen [not found] ` <(Lars> 2020-10-27 11:19 ` bug#42611: (no subject) Lars Ingebrigtsen 0 siblings, 2 replies; 838+ messages in thread From: Lars Ingebrigtsen @ 2020-10-27 11:08 UTC (permalink / raw) To: Brett Randall; +Cc: 42611 Brett Randall <brett.randall@gmail.com> writes: > 1 emacs -Q > 2 M-x edit-abbrevs > 3 Scroll to last line - (global-abbrev-table) > 4 Append: "dfn" 0 "definition" > 5 C-c C-c (removes "modified" flag) > 6 C-x k > 7 M-x edit-abbrevs > 8 Scroll down to last line - abbreviation is not there Thanks. The format of that buffer is very specific, though. The entries must be on the format: (global-abbrev-table) "def" 0 "definition" with one blank line between the name of the section and the start of the definitions; neither more nor less. If you do it that way, does the mode work for you? In any case, I don't quite see why it's that strict about the format: It should just grok all the lines between the sections, I think? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 838+ messages in thread
[parent not found: <(Lars>]
[parent not found: <Ingebrigtsen's>]
[parent not found: <12:08:50>]
* bug#42611: (no subject) 2020-10-27 11:08 ` Lars Ingebrigtsen [not found] ` <(Lars> @ 2020-10-27 11:19 ` Lars Ingebrigtsen [not found] ` <877drbhq6c.fsf@gnus.org> 1 sibling, 1 reply; 838+ messages in thread From: Lars Ingebrigtsen @ 2020-10-27 11:19 UTC (permalink / raw) To: Brett Randall; +Cc: 42611 Lars Ingebrigtsen <larsi@gnus.org> writes: > In any case, I don't quite see why it's that strict about the format: It > should just grok all the lines between the sections, I think? I've now altered the parser to just ignore blank lines in Emacs 28, which should make the mode somewhat less brittle. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 838+ messages in thread
[parent not found: <877drbhq6c.fsf@gnus.org>]
[parent not found: <handler.42611.C.160379757411378.notifdonectrl.0@debbugs.gnu.org>]
* bug#42611: 26.3; edit-abbrevs lets me type and commit, but doesn't store anywhere and abbrevs don't work [not found] ` <handler.42611.C.160379757411378.notifdonectrl.0@debbugs.gnu.org> @ 2020-10-27 22:22 ` Brett Randall 0 siblings, 0 replies; 838+ messages in thread From: Brett Randall @ 2020-10-27 22:22 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 42611 [-- Attachment #1: Type: text/plain, Size: 1161 bytes --] Thanks Lars, it works now that I understand the formatting requirement. Appreciate your help. Brett --- original message --- On October 27, 2020, 10:08 PM GMT+11 larsi@gnus.org wrote: Brett Randall <brett.randall@gmail.com> writes: >> 1 emacs -Q >> 2 M-x edit-abbrevs >> 3 Scroll to last line - (global-abbrev-table) >> 4 Append: "dfn" 0 "definition" >> 5 C-c C-c (removes "modified" flag) >> 6 C-x k >> 7 M-x edit-abbrevs >> 8 Scroll down to last line - abbreviation is not there > Thanks. > The format of that buffer is very specific, though. The entries must be > on the format: > (global-abbrev-table) > "def" 0 "definition" > with one blank line between the name of the section and the start of the > definitions; neither more nor less. If you do it that way, does the > mode work for you? > In any case, I don't quite see why it's that strict about the format: It > should just grok all the lines between the sections, I think? > -- > (domestic pets only, the antidote for overdose, milk.) > bloggy blog: http://lars.ingebrigtsen.no --- end of original message --- [-- Attachment #2: Type: text/html, Size: 2063 bytes --] ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers
@ 2020-05-21 16:56 Philip K.
2020-05-21 22:18 ` Juri Linkov
2020-06-26 19:46 ` Philip K.
0 siblings, 2 replies; 838+ messages in thread
From: Philip K. @ 2020-05-21 16:56 UTC (permalink / raw)
To: 41438
[-- Attachment #1: Type: text/plain, Size: 1091 bytes --]
Hi,
I'm probably not the only one who tends to use C-{f,b,n,p} over the
arrow keys, but also sometimes gets annoyed by navigating windows. I
recently realised that the reason I didn't use windmove as much as I
would want to, was that I coudln't find a satisfying modifier-key. My
idea was then to try windmove without any modifier, and I quite like
it. The only "annoying" thing is that I have to bind all keys
manually, instead of using a function like
`windmove-default-keybindings', because `nil' is interpreted as a
default binding.
This patch adds a pseudo-modifier (`none') to allow bindings the
windmove functions without any real modifier or prefix key, depending on
the function.
--
Another question I'd like to ask before trying it out: Would there be
any interest in adding user options for the "default" modifiers that
windmove should use? If yes, one could add a :set function that
automatically calls the apropriate bindings function, when it's value
is non-nil. I have a very customize-centric configuration, where something
this would fit in very well.
--
Philip K.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Allow-windmove-keys-to-be-bound-without-prefix-or-mo.patch --]
[-- Type: text/x-diff, Size: 3810 bytes --]
From 0fb951817fc11983498052f2a4fdb8815bc89b92 Mon Sep 17 00:00:00 2001
From: Philip K <philip@warpmail.net>
Date: Thu, 21 May 2020 18:44:10 +0200
Subject: [PATCH] Allow windmove keys to be bound without prefix or modifiers
---
lisp/windmove.el | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/lisp/windmove.el b/lisp/windmove.el
index f96383197b..3d7f86b9af 100644
--- a/lisp/windmove.el
+++ b/lisp/windmove.el
@@ -431,9 +431,12 @@ windmove-default-keybindings
"Set up keybindings for `windmove'.
Keybindings are of the form MODIFIERS-{left,right,up,down},
where MODIFIERS is either a list of modifiers or a single modifier.
+If MODIFIERS is `none', the keybindings will be directly bound to
+the arrow keys.
Default value of MODIFIERS is `shift'."
(interactive)
(unless modifiers (setq modifiers 'shift))
+ (when (eq modifiers 'none) (setq modifiers nil))
(unless (listp modifiers) (setq modifiers (list modifiers)))
(global-set-key (vector (append modifiers '(left))) 'windmove-left)
(global-set-key (vector (append modifiers '(right))) 'windmove-right)
@@ -568,9 +571,12 @@ windmove-display-default-keybindings
Keys are bound to commands that display the next buffer in the specified
direction. Keybindings are of the form MODIFIERS-{left,right,up,down},
where MODIFIERS is either a list of modifiers or a single modifier.
+If MODIFIERS is `none', the keybindings will be directly bound to
+the arrow keys.
Default value of MODIFIERS is `shift-meta'."
(interactive)
(unless modifiers (setq modifiers '(shift meta)))
+ (when (eq modifiers 'none) (setq modifiers nil))
(unless (listp modifiers) (setq modifiers (list modifiers)))
(global-set-key (vector (append modifiers '(left))) 'windmove-display-left)
(global-set-key (vector (append modifiers '(right))) 'windmove-display-right)
@@ -640,11 +646,16 @@ windmove-delete-default-keybindings
Keys are bound to commands that delete windows in the specified
direction. Keybindings are of the form PREFIX MODIFIERS-{left,right,up,down},
where PREFIX is a prefix key and MODIFIERS is either a list of modifiers or
-a single modifier. Default value of PREFIX is `C-x' and MODIFIERS is `shift'."
+a single modifier.
+If PREFIX is `none', no prefix is used. If MODIFIERS is `none', the keybindings
+are directly bound to the arrow keys.
+Default value of PREFIX is `C-x' and MODIFIERS is `shift'."
(interactive)
(unless prefix (setq prefix '(?\C-x)))
+ (when (eq prefix 'none) (setq prefix nil))
(unless (listp prefix) (setq prefix (list prefix)))
(unless modifiers (setq modifiers '(shift)))
+ (when (eq modifiers 'none) (setq modifiers nil))
(unless (listp modifiers) (setq modifiers (list modifiers)))
(global-set-key (vector prefix (append modifiers '(left))) 'windmove-delete-left)
(global-set-key (vector prefix (append modifiers '(right))) 'windmove-delete-right)
@@ -695,9 +706,13 @@ windmove-swap-states-default-keybindings
Keys are bound to commands that swap the states of the selected window
with the window in the specified direction. Keybindings are of the form
MODIFIERS-{left,right,up,down}, where MODIFIERS is either a list of modifiers
-or a single modifier. Default value of MODIFIERS is `shift-super'."
+or a single modifier.
+If MODIFIERS is `none', the keybindings will be directly bound to the
+arrow keys.
+Default value of MODIFIERS is `shift-super'."
(interactive)
(unless modifiers (setq modifiers '(shift super)))
+ (when (eq modifiers 'none) (setq modifiers nil))
(unless (listp modifiers) (setq modifiers (list modifiers)))
(global-set-key (vector (append modifiers '(left))) 'windmove-swap-states-left)
(global-set-key (vector (append modifiers '(right))) 'windmove-swap-states-right)
--
2.20.1
^ permalink raw reply related [flat|nested] 838+ messages in thread* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2020-05-21 16:56 bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers Philip K. @ 2020-05-21 22:18 ` Juri Linkov 2020-05-22 18:26 ` Philip K. 2020-05-22 18:26 ` Philip K. 2020-06-26 19:46 ` Philip K. 1 sibling, 2 replies; 838+ messages in thread From: Juri Linkov @ 2020-05-21 22:18 UTC (permalink / raw) To: Philip K.; +Cc: 41438 > I'm probably not the only one who tends to use C-{f,b,n,p} over the > arrow keys, but also sometimes gets annoyed by navigating windows. I > recently realised that the reason I didn't use windmove as much as I > would want to, was that I coudln't find a satisfying modifier-key. My > idea was then to try windmove without any modifier, and I quite like > it. The only "annoying" thing is that I have to bind all keys > manually, instead of using a function like > `windmove-default-keybindings', because `nil' is interpreted as a > default binding. > > This patch adds a pseudo-modifier (`none') to allow bindings the > windmove functions without any real modifier or prefix key, depending on > the function. Thanks, since `nil' means a default binding it seems there is no other way than using a pseudo-modifier `none'. > Another question I'd like to ask before trying it out: Would there be > any interest in adding user options for the "default" modifiers that > windmove should use? If yes, one could add a :set function that > automatically calls the apropriate bindings function, when it's value > is non-nil. I have a very customize-centric configuration, where something > this would fit in very well. I think that adding defcustoms (including a new const `none') would be the most natural way to customize windmove modifiers (provided that the existing functions should remain). ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2020-05-21 22:18 ` Juri Linkov @ 2020-05-22 18:26 ` Philip K. 2020-05-22 18:26 ` Philip K. 1 sibling, 0 replies; 838+ messages in thread From: Philip K. @ 2020-05-22 18:26 UTC (permalink / raw) To: Juri Linkov; +Cc: 41438, emacs-devel [-- Attachment #1: Type: text/plain, Size: 863 bytes --] Juri Linkov <juri@linkov.net> writes: >> Another question I'd like to ask before trying it out: Would there be >> any interest in adding user options for the "default" modifiers that >> windmove should use? If yes, one could add a :set function that >> automatically calls the apropriate bindings function, when it's value >> is non-nil. I have a very customize-centric configuration, where something >> this would fit in very well. > > I think that adding defcustoms (including a new const `none') > would be the most natural way to customize windmove modifiers > (provided that the existing functions should remain). I made a first concept, but it doesn't work unless windmove is explicity required (see below). As far as I know, autoloading variables isn't good style, so is there any other way to invoke the :set property of a user option? -- Philip K. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-Implement-user-options-for-windmove-modifiers-and-pr.patch --] [-- Type: text/x-diff, Size: 8273 bytes --] From b35173936e681e170172eb3d4548a2f91f70dad3 Mon Sep 17 00:00:00 2001 From: Philip K <philip@warpmail.net> Date: Fri, 22 May 2020 20:21:59 +0200 Subject: [PATCH] Implement user options for windmove modifiers and prefixes --- lisp/windmove.el | 103 +++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 95 insertions(+), 8 deletions(-) diff --git a/lisp/windmove.el b/lisp/windmove.el index 3d7f86b9af..95f74bfb81 100644 --- a/lisp/windmove.el +++ b/lisp/windmove.el @@ -162,6 +162,19 @@ windmove-window-distance-delta (make-obsolete-variable 'windmove-window-distance-delta "no longer used." "27.1") +(defconst windmove-modifier-type + '(choice (set :tag "Modifier Symbols" + :greedy t + ;; See `(elisp) Keyboard Events' + (const :tag "Meta" meta) + (const :tag "Control" control) + (const :tag "Shift" shift) + (const :tag "Hyper" hyper) + (const :tag "Super" super) + (const :tag "Alt" alt)) + (const :tag "No modifier" none)) + "Customisation type for windmove modifiers") + \f ;; Note: ;; @@ -419,6 +432,7 @@ windmove-down (interactive "P") (windmove-do-window-select 'down (and arg (prefix-numeric-value arg)))) +(defvar windmove-modifiers) ;;; set up keybindings ;; Idea for this function is from iswitchb.el, by Stephen Eglen @@ -433,9 +447,10 @@ windmove-default-keybindings where MODIFIERS is either a list of modifiers or a single modifier. If MODIFIERS is `none', the keybindings will be directly bound to the arrow keys. -Default value of MODIFIERS is `shift'." +Default value of MODIFIERS is stored in `windmove-modifiers'." (interactive) - (unless modifiers (setq modifiers 'shift)) + (unless modifiers + (setq modifiers windmove-modifiers)) (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) (global-set-key (vector (append modifiers '(left))) 'windmove-left) @@ -443,6 +458,25 @@ windmove-default-keybindings (global-set-key (vector (append modifiers '(up))) 'windmove-up) (global-set-key (vector (append modifiers '(down))) 'windmove-down)) +;; has to be declared AFTER windmove-default-keybindings, or else +;; windmove is recursivly loaded +;;;###autoload +(defcustom windmove-modifiers '(shift super) + "Modifiers for `windmove-default-keybindings'. +Can either be a symbol or list of modifier symbols, +i.e. `meta',`control', `shift', `hyper', `super', or `alt' +representing modifier keys to use with the arrow keys. + +If the value is just `none', the arrow keys will be directly +bound to the windmove functions." + :type windmove-modifier-type + :require 'windmove + :initialize #'custom-initialize-changed + :set (lambda (sym val) + (when val + (windmove-swap-states-default-keybindings val)) + (set-default sym val))) + \f ;;; Directional window display and selection @@ -565,6 +599,8 @@ windmove-display-new-tab (interactive "P") (windmove-display-in-direction 'new-tab arg)) +(defvar windmove-display-modifiers) + ;;;###autoload (defun windmove-display-default-keybindings (&optional modifiers) "Set up keybindings for directional buffer display. @@ -573,7 +609,7 @@ windmove-display-default-keybindings where MODIFIERS is either a list of modifiers or a single modifier. If MODIFIERS is `none', the keybindings will be directly bound to the arrow keys. -Default value of MODIFIERS is `shift-meta'." +Default value of MODIFIERS is stored in `windmove-display-modifiers'." (interactive) (unless modifiers (setq modifiers '(shift meta))) (when (eq modifiers 'none) (setq modifiers nil)) @@ -586,6 +622,17 @@ windmove-display-default-keybindings (global-set-key (vector (append modifiers '(?f))) 'windmove-display-new-frame) (global-set-key (vector (append modifiers '(?t))) 'windmove-display-new-tab)) +(defcustom windmove-display-modifiers '(shift meta) + "Modifiers for `windmove-display-default-keybindings'. +Analogous to `windmove-modifiers'." + :type windmove-modifier-type + :require 'windmove + :initialize #'custom-initialize-changed + :set (lambda (sym val) + (when val + (windmove-display-default-keybindings val)) + (set-default sym val))) + \f ;;; Directional window deletion @@ -640,6 +687,9 @@ windmove-delete-down (interactive "P") (windmove-delete-in-direction 'down arg)) +(defvar windmove-delete-prefix) +(defvar windmove-delete-modifiers) + ;;;###autoload (defun windmove-delete-default-keybindings (&optional prefix modifiers) "Set up keybindings for directional window deletion. @@ -649,12 +699,13 @@ windmove-delete-default-keybindings a single modifier. If PREFIX is `none', no prefix is used. If MODIFIERS is `none', the keybindings are directly bound to the arrow keys. -Default value of PREFIX is `C-x' and MODIFIERS is `shift'." +The default values for PREFIX and MODIFIERS are stored in `windmove-delete-prefix' +and `windmove-delete-modifiers' respectively." (interactive) - (unless prefix (setq prefix '(?\C-x))) + (unless prefix (setq prefix (list windmove-delete-prefix))) (when (eq prefix 'none) (setq prefix nil)) (unless (listp prefix) (setq prefix (list prefix))) - (unless modifiers (setq modifiers '(shift))) + (unless modifiers (setq modifiers windmove-delete-modifiers)) (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) (global-set-key (vector prefix (append modifiers '(left))) 'windmove-delete-left) @@ -662,6 +713,28 @@ windmove-delete-default-keybindings (global-set-key (vector prefix (append modifiers '(up))) 'windmove-delete-up) (global-set-key (vector prefix (append modifiers '(down))) 'windmove-delete-down)) +(defcustom windmove-delete-prefix (kbd "C-x") + "Prefix for `windmove-delete-default-keybindings'." + :type 'key-sequence + :require 'windmove + :initialize #'custom-initialize-changed + :set (lambda (sym val) + (windmove-delete-default-keybindings + val windmove-delete-modifiers) + (set-default sym val))) + +(defcustom windmove-delete-modifiers '(shift) + "Modifiers for `windmove-delete-default-keybindings'. +See `windmove-modifiers' for more details" + :type windmove-modifier-type + :require 'windmove + :initialize #'custom-initialize-changed + :set (lambda (sym val) + (when val + (windmove-delete-default-keybindings + windmove-delete-prefix val)) + (set-default sym val))) + \f ;;; Directional window swap states @@ -700,6 +773,8 @@ windmove-swap-states-right (interactive) (windmove-swap-states-in-direction 'right)) +(defvar windmove-swap-states-modifiers) + ;;;###autoload (defun windmove-swap-states-default-keybindings (&optional modifiers) "Set up keybindings for directional window swap states. @@ -709,9 +784,10 @@ windmove-swap-states-default-keybindings or a single modifier. If MODIFIERS is `none', the keybindings will be directly bound to the arrow keys. -Default value of MODIFIERS is `shift-super'." +Default value of MODIFIERS is stored in `windmove-swap-states-modifiers'." (interactive) - (unless modifiers (setq modifiers '(shift super))) + (unless modifiers + (setq modifiers windmove-swap-states-modifiers)) (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) (global-set-key (vector (append modifiers '(left))) 'windmove-swap-states-left) @@ -719,6 +795,17 @@ windmove-swap-states-default-keybindings (global-set-key (vector (append modifiers '(up))) 'windmove-swap-states-up) (global-set-key (vector (append modifiers '(down))) 'windmove-swap-states-down)) +(defcustom windmove-swap-states-modifiers + '(shift super) + "Modifiers for `windmove-swap-states-default-keybindings'. +Analogous to `windmove-modifiers'." + :type windmove-modifier-type + :require 'windmove + :initialize #'custom-initialize-changed + :set (lambda (sym val) + (windmove-swap-states-default-keybindings val) + (set-default sym val))) + \f (provide 'windmove) -- 2.20.1 ^ permalink raw reply related [flat|nested] 838+ messages in thread
* Re: bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2020-05-21 22:18 ` Juri Linkov 2020-05-22 18:26 ` Philip K. @ 2020-05-22 18:26 ` Philip K. 2020-05-22 19:15 ` Drew Adams 2020-05-23 22:12 ` Juri Linkov 1 sibling, 2 replies; 838+ messages in thread From: Philip K. @ 2020-05-22 18:26 UTC (permalink / raw) To: Juri Linkov; +Cc: 41438, emacs-devel [-- Attachment #1: Type: text/plain, Size: 863 bytes --] Juri Linkov <juri@linkov.net> writes: >> Another question I'd like to ask before trying it out: Would there be >> any interest in adding user options for the "default" modifiers that >> windmove should use? If yes, one could add a :set function that >> automatically calls the apropriate bindings function, when it's value >> is non-nil. I have a very customize-centric configuration, where something >> this would fit in very well. > > I think that adding defcustoms (including a new const `none') > would be the most natural way to customize windmove modifiers > (provided that the existing functions should remain). I made a first concept, but it doesn't work unless windmove is explicity required (see below). As far as I know, autoloading variables isn't good style, so is there any other way to invoke the :set property of a user option? -- Philip K. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-Implement-user-options-for-windmove-modifiers-and-pr.patch --] [-- Type: text/x-diff, Size: 8273 bytes --] From b35173936e681e170172eb3d4548a2f91f70dad3 Mon Sep 17 00:00:00 2001 From: Philip K <philip@warpmail.net> Date: Fri, 22 May 2020 20:21:59 +0200 Subject: [PATCH] Implement user options for windmove modifiers and prefixes --- lisp/windmove.el | 103 +++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 95 insertions(+), 8 deletions(-) diff --git a/lisp/windmove.el b/lisp/windmove.el index 3d7f86b9af..95f74bfb81 100644 --- a/lisp/windmove.el +++ b/lisp/windmove.el @@ -162,6 +162,19 @@ windmove-window-distance-delta (make-obsolete-variable 'windmove-window-distance-delta "no longer used." "27.1") +(defconst windmove-modifier-type + '(choice (set :tag "Modifier Symbols" + :greedy t + ;; See `(elisp) Keyboard Events' + (const :tag "Meta" meta) + (const :tag "Control" control) + (const :tag "Shift" shift) + (const :tag "Hyper" hyper) + (const :tag "Super" super) + (const :tag "Alt" alt)) + (const :tag "No modifier" none)) + "Customisation type for windmove modifiers") + \f ;; Note: ;; @@ -419,6 +432,7 @@ windmove-down (interactive "P") (windmove-do-window-select 'down (and arg (prefix-numeric-value arg)))) +(defvar windmove-modifiers) ;;; set up keybindings ;; Idea for this function is from iswitchb.el, by Stephen Eglen @@ -433,9 +447,10 @@ windmove-default-keybindings where MODIFIERS is either a list of modifiers or a single modifier. If MODIFIERS is `none', the keybindings will be directly bound to the arrow keys. -Default value of MODIFIERS is `shift'." +Default value of MODIFIERS is stored in `windmove-modifiers'." (interactive) - (unless modifiers (setq modifiers 'shift)) + (unless modifiers + (setq modifiers windmove-modifiers)) (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) (global-set-key (vector (append modifiers '(left))) 'windmove-left) @@ -443,6 +458,25 @@ windmove-default-keybindings (global-set-key (vector (append modifiers '(up))) 'windmove-up) (global-set-key (vector (append modifiers '(down))) 'windmove-down)) +;; has to be declared AFTER windmove-default-keybindings, or else +;; windmove is recursivly loaded +;;;###autoload +(defcustom windmove-modifiers '(shift super) + "Modifiers for `windmove-default-keybindings'. +Can either be a symbol or list of modifier symbols, +i.e. `meta',`control', `shift', `hyper', `super', or `alt' +representing modifier keys to use with the arrow keys. + +If the value is just `none', the arrow keys will be directly +bound to the windmove functions." + :type windmove-modifier-type + :require 'windmove + :initialize #'custom-initialize-changed + :set (lambda (sym val) + (when val + (windmove-swap-states-default-keybindings val)) + (set-default sym val))) + \f ;;; Directional window display and selection @@ -565,6 +599,8 @@ windmove-display-new-tab (interactive "P") (windmove-display-in-direction 'new-tab arg)) +(defvar windmove-display-modifiers) + ;;;###autoload (defun windmove-display-default-keybindings (&optional modifiers) "Set up keybindings for directional buffer display. @@ -573,7 +609,7 @@ windmove-display-default-keybindings where MODIFIERS is either a list of modifiers or a single modifier. If MODIFIERS is `none', the keybindings will be directly bound to the arrow keys. -Default value of MODIFIERS is `shift-meta'." +Default value of MODIFIERS is stored in `windmove-display-modifiers'." (interactive) (unless modifiers (setq modifiers '(shift meta))) (when (eq modifiers 'none) (setq modifiers nil)) @@ -586,6 +622,17 @@ windmove-display-default-keybindings (global-set-key (vector (append modifiers '(?f))) 'windmove-display-new-frame) (global-set-key (vector (append modifiers '(?t))) 'windmove-display-new-tab)) +(defcustom windmove-display-modifiers '(shift meta) + "Modifiers for `windmove-display-default-keybindings'. +Analogous to `windmove-modifiers'." + :type windmove-modifier-type + :require 'windmove + :initialize #'custom-initialize-changed + :set (lambda (sym val) + (when val + (windmove-display-default-keybindings val)) + (set-default sym val))) + \f ;;; Directional window deletion @@ -640,6 +687,9 @@ windmove-delete-down (interactive "P") (windmove-delete-in-direction 'down arg)) +(defvar windmove-delete-prefix) +(defvar windmove-delete-modifiers) + ;;;###autoload (defun windmove-delete-default-keybindings (&optional prefix modifiers) "Set up keybindings for directional window deletion. @@ -649,12 +699,13 @@ windmove-delete-default-keybindings a single modifier. If PREFIX is `none', no prefix is used. If MODIFIERS is `none', the keybindings are directly bound to the arrow keys. -Default value of PREFIX is `C-x' and MODIFIERS is `shift'." +The default values for PREFIX and MODIFIERS are stored in `windmove-delete-prefix' +and `windmove-delete-modifiers' respectively." (interactive) - (unless prefix (setq prefix '(?\C-x))) + (unless prefix (setq prefix (list windmove-delete-prefix))) (when (eq prefix 'none) (setq prefix nil)) (unless (listp prefix) (setq prefix (list prefix))) - (unless modifiers (setq modifiers '(shift))) + (unless modifiers (setq modifiers windmove-delete-modifiers)) (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) (global-set-key (vector prefix (append modifiers '(left))) 'windmove-delete-left) @@ -662,6 +713,28 @@ windmove-delete-default-keybindings (global-set-key (vector prefix (append modifiers '(up))) 'windmove-delete-up) (global-set-key (vector prefix (append modifiers '(down))) 'windmove-delete-down)) +(defcustom windmove-delete-prefix (kbd "C-x") + "Prefix for `windmove-delete-default-keybindings'." + :type 'key-sequence + :require 'windmove + :initialize #'custom-initialize-changed + :set (lambda (sym val) + (windmove-delete-default-keybindings + val windmove-delete-modifiers) + (set-default sym val))) + +(defcustom windmove-delete-modifiers '(shift) + "Modifiers for `windmove-delete-default-keybindings'. +See `windmove-modifiers' for more details" + :type windmove-modifier-type + :require 'windmove + :initialize #'custom-initialize-changed + :set (lambda (sym val) + (when val + (windmove-delete-default-keybindings + windmove-delete-prefix val)) + (set-default sym val))) + \f ;;; Directional window swap states @@ -700,6 +773,8 @@ windmove-swap-states-right (interactive) (windmove-swap-states-in-direction 'right)) +(defvar windmove-swap-states-modifiers) + ;;;###autoload (defun windmove-swap-states-default-keybindings (&optional modifiers) "Set up keybindings for directional window swap states. @@ -709,9 +784,10 @@ windmove-swap-states-default-keybindings or a single modifier. If MODIFIERS is `none', the keybindings will be directly bound to the arrow keys. -Default value of MODIFIERS is `shift-super'." +Default value of MODIFIERS is stored in `windmove-swap-states-modifiers'." (interactive) - (unless modifiers (setq modifiers '(shift super))) + (unless modifiers + (setq modifiers windmove-swap-states-modifiers)) (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) (global-set-key (vector (append modifiers '(left))) 'windmove-swap-states-left) @@ -719,6 +795,17 @@ windmove-swap-states-default-keybindings (global-set-key (vector (append modifiers '(up))) 'windmove-swap-states-up) (global-set-key (vector (append modifiers '(down))) 'windmove-swap-states-down)) +(defcustom windmove-swap-states-modifiers + '(shift super) + "Modifiers for `windmove-swap-states-default-keybindings'. +Analogous to `windmove-modifiers'." + :type windmove-modifier-type + :require 'windmove + :initialize #'custom-initialize-changed + :set (lambda (sym val) + (windmove-swap-states-default-keybindings val) + (set-default sym val))) + \f (provide 'windmove) -- 2.20.1 ^ permalink raw reply related [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2020-05-22 18:26 ` Philip K. @ 2020-05-22 19:15 ` Drew Adams 2020-05-23 22:12 ` Juri Linkov 1 sibling, 0 replies; 838+ messages in thread From: Drew Adams @ 2020-05-22 19:15 UTC (permalink / raw) To: philip, Juri Linkov; +Cc: 41438, emacs-devel Please don't send the same mail to both the bug list and emacs-devel. Thx. ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2020-05-22 18:26 ` Philip K. 2020-05-22 19:15 ` Drew Adams @ 2020-05-23 22:12 ` Juri Linkov 1 sibling, 0 replies; 838+ messages in thread From: Juri Linkov @ 2020-05-23 22:12 UTC (permalink / raw) To: Philip K.; +Cc: 41438 >>> Another question I'd like to ask before trying it out: Would there be >>> any interest in adding user options for the "default" modifiers that >>> windmove should use? If yes, one could add a :set function that >>> automatically calls the apropriate bindings function, when it's value >>> is non-nil. I have a very customize-centric configuration, where something >>> this would fit in very well. >> >> I think that adding defcustoms (including a new const `none') >> would be the most natural way to customize windmove modifiers >> (provided that the existing functions should remain). > > I made a first concept, but it doesn't work unless windmove is explicity > required (see below). As far as I know, autoloading variables isn't good > style, so is there any other way to invoke the :set property of a user > option? Recently we had a similar problem in char-fold.el that was solved using defconst for the default value and a :set function, this might help here. ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2020-05-21 16:56 bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers Philip K. 2020-05-21 22:18 ` Juri Linkov @ 2020-06-26 19:46 ` Philip K. 2020-06-27 23:53 ` Juri Linkov 1 sibling, 1 reply; 838+ messages in thread From: Philip K. @ 2020-06-26 19:46 UTC (permalink / raw) To: juri; +Cc: 41438 > Recently we had a similar problem in char-fold.el that was solved > using defconst for the default value and a :set function, this might > help here. I've been trying to understand what was changed there (I presume you're referring to 376f5df), but I don't think I can quite follow. What difference does adding the defconst forms to the eval-and-compile block do? -- Philip K. ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2020-06-26 19:46 ` Philip K. @ 2020-06-27 23:53 ` Juri Linkov 2020-06-28 8:30 ` Philip K. 0 siblings, 1 reply; 838+ messages in thread From: Juri Linkov @ 2020-06-27 23:53 UTC (permalink / raw) To: Philip K.; +Cc: 41438, 41438 >> Recently we had a similar problem in char-fold.el that was solved >> using defconst for the default value and a :set function, this might >> help here. > > I've been trying to understand what was changed there (I presume you're > referring to 376f5df), but I don't think I can quite follow. What > difference does adding the defconst forms to the eval-and-compile block > do? Actually, I meant not so much the defconst form (that is an unimportant detail), but more the :set function, and also I forgot to mention :initialize. Their combination in char-fold.el looks like: :initialize #'custom-initialize-default :set (lambda (sym val) (custom-set-default sym val) (char-fold-update-table)) Then after loading char-fold.el, this function is executed at the top level: (char-fold-update-table) Maybe something like this could help to initialize default keybindings after loading windmove.el. ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2020-06-27 23:53 ` Juri Linkov @ 2020-06-28 8:30 ` Philip K. 2020-06-28 23:37 ` Juri Linkov 0 siblings, 1 reply; 838+ messages in thread From: Philip K. @ 2020-06-28 8:30 UTC (permalink / raw) To: Juri Linkov; +Cc: 41438 Juri Linkov <juri@linkov.net> writes: > Actually, I meant not so much the defconst form (that is an unimportant > detail), but more the :set function, and also I forgot to mention > :initialize. Their combination in char-fold.el looks like: > > :initialize #'custom-initialize-default > :set (lambda (sym val) > (custom-set-default sym val) > (char-fold-update-table)) > > Then after loading char-fold.el, this function is executed at the top level: > > (char-fold-update-table) > > Maybe something like this could help to initialize default keybindings > after loading windmove.el. I get what you were saying, but it seems the issue with windmove is the opposite. Just loading windmove shouldn't create any new keybindings, but customising the new user options should, *even if* windmove hasn't been loaded yet (ideally). -- Philip K. ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2020-06-28 8:30 ` Philip K. @ 2020-06-28 23:37 ` Juri Linkov 2020-08-05 18:05 ` Lars Ingebrigtsen 0 siblings, 1 reply; 838+ messages in thread From: Juri Linkov @ 2020-06-28 23:37 UTC (permalink / raw) To: Philip K.; +Cc: 41438 > I get what you were saying, but it seems the issue with windmove is the > opposite. Just loading windmove shouldn't create any new keybindings, > but customising the new user options should, *even if* windmove hasn't > been loaded yet (ideally). Then it seems explicitly requiring windmove and autoloading variables is unavoidable, so your previous patch was the right thing to do. ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2020-06-28 23:37 ` Juri Linkov @ 2020-08-05 18:05 ` Lars Ingebrigtsen 2020-08-05 23:40 ` Juri Linkov 0 siblings, 1 reply; 838+ messages in thread From: Lars Ingebrigtsen @ 2020-08-05 18:05 UTC (permalink / raw) To: Juri Linkov; +Cc: 41438, Philip K. Juri Linkov <juri@linkov.net> writes: >> I get what you were saying, but it seems the issue with windmove is the >> opposite. Just loading windmove shouldn't create any new keybindings, >> but customising the new user options should, *even if* windmove hasn't >> been loaded yet (ideally). > > Then it seems explicitly requiring windmove and autoloading variables > is unavoidable, so your previous patch was the right thing to do. The patch wasn't applied, though? I know nothing about windmove, so I'm not really qualified to have an opinion, but if you think it's the right thing to do, then you should apply it? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2020-08-05 18:05 ` Lars Ingebrigtsen @ 2020-08-05 23:40 ` Juri Linkov 2020-08-06 9:28 ` Philip K. 0 siblings, 1 reply; 838+ messages in thread From: Juri Linkov @ 2020-08-05 23:40 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 41438, Philip K. >>> I get what you were saying, but it seems the issue with windmove is the >>> opposite. Just loading windmove shouldn't create any new keybindings, >>> but customising the new user options should, *even if* windmove hasn't >>> been loaded yet (ideally). >> >> Then it seems explicitly requiring windmove and autoloading variables >> is unavoidable, so your previous patch was the right thing to do. > > The patch wasn't applied, though? I know nothing about windmove, so I'm > not really qualified to have an opinion, but if you think it's the right > thing to do, then you should apply it? Philip, could you please prepare the final version of your patch (I see there were some unfinished parts in your previous patch). ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2020-08-05 23:40 ` Juri Linkov @ 2020-08-06 9:28 ` Philip K. 2020-08-06 23:43 ` Juri Linkov 0 siblings, 1 reply; 838+ messages in thread From: Philip K. @ 2020-08-06 9:28 UTC (permalink / raw) To: Juri Linkov; +Cc: 41438, larsi Juri Linkov <juri@linkov.net> writes: > Philip, could you please prepare the final version of your patch Sure, I'll try to finish it today. > (I see there were some unfinished parts in your previous patch). It's been a while since I submitted it, so I had to re-read the thread, but I'm not quite sure what the "unfinished" parts were, aside from the missing autoload cookies. Sorry if I missed something :/ Also, the second patch (the one with the user options) depended on the previous one in this thread[0], that introduced the "none" prefix. Is that fine, or should I just merge both patches into one. [0] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41438#5 -- Philip K. ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2020-08-06 9:28 ` Philip K. @ 2020-08-06 23:43 ` Juri Linkov 2020-08-07 10:53 ` Philip K. 0 siblings, 1 reply; 838+ messages in thread From: Juri Linkov @ 2020-08-06 23:43 UTC (permalink / raw) To: Philip K.; +Cc: 41438, larsi >> (I see there were some unfinished parts in your previous patch). > > It's been a while since I submitted it, so I had to re-read the thread, > but I'm not quite sure what the "unfinished" parts were, aside from the > missing autoload cookies. Sorry if I missed something :/ I don't know, my impression seems to suggest the first version was not completely tested, for example, windmove-modifiers defcustom called windmove-swap-states-default-keybindings, not windmove-default-keybindings. But maybe you already fixed this. > Also, the second patch (the one with the user options) depended on the > previous one in this thread[0], that introduced the "none" prefix. Is > that fine, or should I just merge both patches into one. This is perfectly fine - better to commit two separate patches. ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2020-08-06 23:43 ` Juri Linkov @ 2020-08-07 10:53 ` Philip K. 2020-08-08 23:54 ` Juri Linkov 2021-05-12 20:38 ` Lars Ingebrigtsen 0 siblings, 2 replies; 838+ messages in thread From: Philip K. @ 2020-08-07 10:53 UTC (permalink / raw) To: Juri Linkov; +Cc: 41438, larsi [-- Attachment #1: Type: text/plain, Size: 2002 bytes --] Juri Linkov <juri@linkov.net> writes: >>> (I see there were some unfinished parts in your previous patch). >> >> It's been a while since I submitted it, so I had to re-read the thread, >> but I'm not quite sure what the "unfinished" parts were, aside from the >> missing autoload cookies. Sorry if I missed something :/ > > I don't know, my impression seems to suggest the first version was not > completely tested, for example, windmove-modifiers defcustom called > windmove-swap-states-default-keybindings, not windmove-default-keybindings. > But maybe you already fixed this. You're right, I still had a few local changes. A noteworthy addition is that the user options unbind their previous bindings, before binding the new ones. This should lead to more consistent behaviour when updating the option a few times in the same session. >> Also, the second patch (the one with the user options) depended on the >> previous one in this thread[0], that introduced the "none" prefix. Is >> that fine, or should I just merge both patches into one. > > This is perfectly fine - better to commit two separate patches. Ok. I added both below. But there are a few general issues I noticed: 1. windmove-display-{same-window,new-{frame,tab}} can disturb regular input when the modifier is set to shift or none. Possible solutions could be to prohibit using these modifiers or to add a prefix key and generate a warning when eg. "S-t" or "t" would be rebound. 2. The new function windmove--unbind works with the global-map, so when someone sets a prefix to none, and then changes it to something else, the arrow keys are left undefined. I could either see this being fixed by using a separate map or by somehow memorising what the previous key was (eg. by using the property list of the windmove command's symbol). These are the only edge-cases I found, but I didn't fix them yet, as I'm not sure what would be preferred. So the patches should not be applies yet. -- Philip K. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-Allow-windmove-keys-to-be-bound-without-prefix-or-mo.patch --] [-- Type: text/x-diff, Size: 3810 bytes --] From f87d057b72f0cc374c132100664c5b8553bd58e2 Mon Sep 17 00:00:00 2001 From: Philip K <philip@warpmail.net> Date: Thu, 21 May 2020 18:44:10 +0200 Subject: [PATCH] Allow windmove keys to be bound without prefix or modifiers --- lisp/windmove.el | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/lisp/windmove.el b/lisp/windmove.el index 6557960064..613727f8ed 100644 --- a/lisp/windmove.el +++ b/lisp/windmove.el @@ -431,9 +431,12 @@ windmove-default-keybindings "Set up keybindings for `windmove'. Keybindings are of the form MODIFIERS-{left,right,up,down}, where MODIFIERS is either a list of modifiers or a single modifier. +If MODIFIERS is `none', the keybindings will be directly bound to +the arrow keys. Default value of MODIFIERS is `shift'." (interactive) (unless modifiers (setq modifiers 'shift)) + (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) (global-set-key (vector (append modifiers '(left))) 'windmove-left) (global-set-key (vector (append modifiers '(right))) 'windmove-right) @@ -546,9 +549,12 @@ windmove-display-default-keybindings Keys are bound to commands that display the next buffer in the specified direction. Keybindings are of the form MODIFIERS-{left,right,up,down}, where MODIFIERS is either a list of modifiers or a single modifier. +If MODIFIERS is `none', the keybindings will be directly bound to +the arrow keys. Default value of MODIFIERS is `shift-meta'." (interactive) (unless modifiers (setq modifiers '(shift meta))) + (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) (global-set-key (vector (append modifiers '(left))) 'windmove-display-left) (global-set-key (vector (append modifiers '(right))) 'windmove-display-right) @@ -618,11 +624,16 @@ windmove-delete-default-keybindings Keys are bound to commands that delete windows in the specified direction. Keybindings are of the form PREFIX MODIFIERS-{left,right,up,down}, where PREFIX is a prefix key and MODIFIERS is either a list of modifiers or -a single modifier. Default value of PREFIX is `C-x' and MODIFIERS is `shift'." +a single modifier. +If PREFIX is `none', no prefix is used. If MODIFIERS is `none', the keybindings +are directly bound to the arrow keys. +Default value of PREFIX is `C-x' and MODIFIERS is `shift'." (interactive) (unless prefix (setq prefix '(?\C-x))) + (when (eq prefix 'none) (setq prefix nil)) (unless (listp prefix) (setq prefix (list prefix))) (unless modifiers (setq modifiers '(shift))) + (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) (global-set-key (vector prefix (append modifiers '(left))) 'windmove-delete-left) (global-set-key (vector prefix (append modifiers '(right))) 'windmove-delete-right) @@ -673,9 +684,13 @@ windmove-swap-states-default-keybindings Keys are bound to commands that swap the states of the selected window with the window in the specified direction. Keybindings are of the form MODIFIERS-{left,right,up,down}, where MODIFIERS is either a list of modifiers -or a single modifier. Default value of MODIFIERS is `shift-super'." +or a single modifier. +If MODIFIERS is `none', the keybindings will be directly bound to the +arrow keys. +Default value of MODIFIERS is `shift-super'." (interactive) (unless modifiers (setq modifiers '(shift super))) + (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) (global-set-key (vector (append modifiers '(left))) 'windmove-swap-states-left) (global-set-key (vector (append modifiers '(right))) 'windmove-swap-states-right) -- 2.20.1 [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #3: 0001-Add-user-options-to-bind-windmove-commands.patch --] [-- Type: text/x-diff, Size: 11235 bytes --] From c009311887372e1e822739edc050a802bfa4d1d8 Mon Sep 17 00:00:00 2001 From: Philip K <philipk@posteo.net> Date: Fri, 7 Aug 2020 12:35:49 +0200 Subject: [PATCH] Add user options to bind windmove commands * windmove.el (windmove-modifier-type): Create (windmove--unbind): New constant (windmove-modifiers): New user option (windmove-default-keybindings): Use windmove-modifiers (windmove-display-modifiers): New user option (windmove-display-default-keybindings): Use windmove-display-modifiers (windmove-delete-prefix): New user option (windmove-delete-modifiers): New user option (windmove-delete-default-keybindings): Use windmove-delete-prefix and windmove-delete-modifiers (windmove-swap-states-modifiers): New user option (windmove-swap-states-default-keybindings): Use windmove-swap-states-modifiers --- lisp/windmove.el | 154 ++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 145 insertions(+), 9 deletions(-) diff --git a/lisp/windmove.el b/lisp/windmove.el index 613727f8ed..9b68f9a5b9 100644 --- a/lisp/windmove.el +++ b/lisp/windmove.el @@ -162,6 +162,40 @@ windmove-window-distance-delta (make-obsolete-variable 'windmove-window-distance-delta "no longer used." "27.1") +(defconst windmove-modifier-type + '(choice (set :tag "Modifier Symbols" + :greedy t + ;; See `(elisp) Keyboard Events' + (const :tag "Meta" meta) + (const :tag "Control" control) + (const :tag "Shift" shift) + (const :tag "Hyper" hyper) + (const :tag "Super" super) + (const :tag "Alt" alt)) + (const :tag "No modifier" none) + (const :tag "Not bound" nil)) + "Customisation type for windmove modifiers") + +(defun windmove--unbind (prefix modifiers fns &optional extra) + "Unbind windmove commands, bound by PREFIX and MODIFIER. +To ensure that only windmove functions are unbound, the command +must be member of the list FNS. +By default only the left, right, up and down keys are unbound, +but further keys can be added via EXTRA." + (setq prefix + (cond ((eq prefix 'none) nil) + ((not (listp prefix)) (list prefix)) + (t prefix))) + (setq modifiers + (cond ((eq modifiers 'none) nil) + ((not (listp modifiers)) (list modifiers)) + (t modifiers))) + (dolist (dir (append '(left right up down) extra)) + (let* ((key (append modifiers (list dir))) + (key (vconcat prefix (list key)))) + (when (memq (lookup-key global-map key) fns) + (global-set-key key nil))))) + \f ;; Note: ;; @@ -419,6 +453,7 @@ windmove-down (interactive "P") (windmove-do-window-select 'down (and arg (prefix-numeric-value arg)))) +(defvar windmove-modifiers) ;;; set up keybindings ;; Idea for this function is from iswitchb.el, by Stephen Eglen @@ -433,16 +468,41 @@ windmove-default-keybindings where MODIFIERS is either a list of modifiers or a single modifier. If MODIFIERS is `none', the keybindings will be directly bound to the arrow keys. -Default value of MODIFIERS is `shift'." +Default value of MODIFIERS is stored in `windmove-modifiers'." (interactive) - (unless modifiers (setq modifiers 'shift)) (when (eq modifiers 'none) (setq modifiers nil)) + (unless modifiers + (setq modifiers windmove-modifiers)) (unless (listp modifiers) (setq modifiers (list modifiers))) (global-set-key (vector (append modifiers '(left))) 'windmove-left) (global-set-key (vector (append modifiers '(right))) 'windmove-right) (global-set-key (vector (append modifiers '(up))) 'windmove-up) (global-set-key (vector (append modifiers '(down))) 'windmove-down)) +;; has to be declared AFTER windmove-default-keybindings, or else +;; windmove is recursivly loaded +;;;###autoload +(defcustom windmove-modifiers '(shift super) + "Modifiers for `windmove-default-keybindings'. +Can either be a symbol or list of modifier symbols, +i.e. `meta',`control', `shift', `hyper', `super', or `alt' +representing modifier keys to use with the arrow keys. + +If the value is just `none', the arrow keys will be directly +bound to the windmove functions." + :type windmove-modifier-type + :require 'windmove + :initialize #'custom-initialize-changed + :set (lambda (sym val) + (windmove--unbind nil (default-value sym) + '(windmove-left + windmove-right + windmove-up + windmove-down)) + (when val + (windmove-default-keybindings val)) + (set-default sym val))) + \f ;;; Directional window display and selection @@ -543,6 +603,8 @@ windmove-display-new-tab (interactive "P") (windmove-display-in-direction 'new-tab arg)) +(defvar windmove-display-modifiers) + ;;;###autoload (defun windmove-display-default-keybindings (&optional modifiers) "Set up keybindings for directional buffer display. @@ -551,9 +613,10 @@ windmove-display-default-keybindings where MODIFIERS is either a list of modifiers or a single modifier. If MODIFIERS is `none', the keybindings will be directly bound to the arrow keys. -Default value of MODIFIERS is `shift-meta'." +Default value of MODIFIERS is stored in `windmove-display-modifiers'." (interactive) - (unless modifiers (setq modifiers '(shift meta))) + (unless modifiers + (setq modifiers windmove-display-modifiers)) (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) (global-set-key (vector (append modifiers '(left))) 'windmove-display-left) @@ -564,6 +627,27 @@ windmove-display-default-keybindings (global-set-key (vector (append modifiers '(?f))) 'windmove-display-new-frame) (global-set-key (vector (append modifiers '(?t))) 'windmove-display-new-tab)) +;;;###autoload +(defcustom windmove-display-modifiers '(shift meta) + "Modifiers for `windmove-display-default-keybindings'. +Analogous to `windmove-modifiers'." + :type windmove-modifier-type + :require 'windmove + :initialize #'custom-initialize-changed + :set (lambda (sym val) + (windmove--unbind nil (default-value sym) + '(windmove-display-left + windmove-display-right + windmove-display-up + windmove-display-down + windmove-display-same-window + windmove-display-new-frame + windmove-display-new-tab) + '(?0 ?f ?t)) + (when val + (windmove-display-default-keybindings val)) + (set-default sym val))) + \f ;;; Directional window deletion @@ -618,6 +702,9 @@ windmove-delete-down (interactive "P") (windmove-delete-in-direction 'down arg)) +(defvar windmove-delete-prefix) +(defvar windmove-delete-modifiers) + ;;;###autoload (defun windmove-delete-default-keybindings (&optional prefix modifiers) "Set up keybindings for directional window deletion. @@ -627,12 +714,15 @@ windmove-delete-default-keybindings a single modifier. If PREFIX is `none', no prefix is used. If MODIFIERS is `none', the keybindings are directly bound to the arrow keys. -Default value of PREFIX is `C-x' and MODIFIERS is `shift'." +The default values for PREFIX and MODIFIERS are stored in `windmove-delete-prefix' +and `windmove-delete-modifiers' respectively." (interactive) - (unless prefix (setq prefix '(?\C-x))) + (unless prefix + (setq prefix (list windmove-delete-prefix))) (when (eq prefix 'none) (setq prefix nil)) (unless (listp prefix) (setq prefix (list prefix))) - (unless modifiers (setq modifiers '(shift))) + (unless modifiers + (setq modifiers windmove-delete-modifiers)) (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) (global-set-key (vector prefix (append modifiers '(left))) 'windmove-delete-left) @@ -640,6 +730,32 @@ windmove-delete-default-keybindings (global-set-key (vector prefix (append modifiers '(up))) 'windmove-delete-up) (global-set-key (vector prefix (append modifiers '(down))) 'windmove-delete-down)) +(defcustom windmove-delete-prefix (kbd "C-x") + "Prefix for `windmove-delete-default-keybindings'." + :type 'key-sequence + :require 'windmove + :initialize #'custom-initialize-changed) + +;;;###autoload +(defcustom windmove-delete-modifiers '(shift) + "Modifiers for `windmove-delete-default-keybindings'. +See `windmove-modifiers' for more details" + :type windmove-modifier-type + :require 'windmove + :initialize #'custom-initialize-changed + :set-after '(windmove-delete-prefix) + :set (lambda (sym val) + (windmove--unbind windmove-delete-prefix + (default-value sym) + '(windmove-delete-left + windmove-delete-right + windmove-delete-up + windmove-delete-down)) + (when val + (windmove-delete-default-keybindings + windmove-delete-prefix val)) + (set-default sym val))) + \f ;;; Directional window swap states @@ -678,6 +794,8 @@ windmove-swap-states-right (interactive) (windmove-swap-states-in-direction 'right)) +(defvar windmove-swap-states-modifiers) + ;;;###autoload (defun windmove-swap-states-default-keybindings (&optional modifiers) "Set up keybindings for directional window swap states. @@ -687,9 +805,10 @@ windmove-swap-states-default-keybindings or a single modifier. If MODIFIERS is `none', the keybindings will be directly bound to the arrow keys. -Default value of MODIFIERS is `shift-super'." +Default value of MODIFIERS is stored in `windmove-swap-states-modifiers'." (interactive) - (unless modifiers (setq modifiers '(shift super))) + (unless modifiers + (setq modifiers windmove-swap-states-modifiers)) (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) (global-set-key (vector (append modifiers '(left))) 'windmove-swap-states-left) @@ -697,6 +816,23 @@ windmove-swap-states-default-keybindings (global-set-key (vector (append modifiers '(up))) 'windmove-swap-states-up) (global-set-key (vector (append modifiers '(down))) 'windmove-swap-states-down)) +;;;###autoload +(defcustom windmove-swap-states-modifiers '(shift super) + "Modifiers for `windmove-swap-states-default-keybindings'. +Analogous to `windmove-modifiers'." + :type windmove-modifier-type + :require 'windmove + :initialize #'custom-initialize-changed + :set (lambda (sym val) + (windmove--unbind nil (default-value sym) + '(windmove-swap-states-left + windmove-swap-states-right + windmove-swap-states-up + windmove-swap-states-downp)) + (when val + (windmove-swap-states-default-keybindings val)) + (set-default sym val))) + \f (provide 'windmove) -- 2.20.1 ^ permalink raw reply related [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2020-08-07 10:53 ` Philip K. @ 2020-08-08 23:54 ` Juri Linkov 2021-05-12 20:38 ` Lars Ingebrigtsen 1 sibling, 0 replies; 838+ messages in thread From: Juri Linkov @ 2020-08-08 23:54 UTC (permalink / raw) To: Philip K.; +Cc: 41438, larsi > But there are a few general issues I noticed: > > 1. windmove-display-{same-window,new-{frame,tab}} can disturb regular > input when the modifier is set to shift or none. Possible solutions > could be to prohibit using these modifiers or to add a prefix key and > generate a warning when eg. "S-t" or "t" would be rebound. Perhaps displaying a warning should be sufficient. > 2. The new function windmove--unbind works with the global-map, so when > someone sets a prefix to none, and then changes it to something else, > the arrow keys are left undefined. I could either see this being > fixed by using a separate map or by somehow memorising what the > previous key was (eg. by using the property list of the windmove > command's symbol). I'm not sure whether such complication is necessary. Usually users will try to customize the option and then restart Emacs. ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2020-08-07 10:53 ` Philip K. 2020-08-08 23:54 ` Juri Linkov @ 2021-05-12 20:38 ` Lars Ingebrigtsen 2021-05-12 21:27 ` Philip Kaludercic 2021-05-22 20:29 ` Philip Kaludercic 1 sibling, 2 replies; 838+ messages in thread From: Lars Ingebrigtsen @ 2021-05-12 20:38 UTC (permalink / raw) To: Philip K.; +Cc: 41438, Juri Linkov "Philip K." <philipk@posteo.net> writes: > These are the only edge-cases I found, but I didn't fix them yet, as I'm > not sure what would be preferred. So the patches should not be applies yet. Have you done any further work on this? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2021-05-12 20:38 ` Lars Ingebrigtsen @ 2021-05-12 21:27 ` Philip Kaludercic 2021-05-22 20:29 ` Philip Kaludercic 1 sibling, 0 replies; 838+ messages in thread From: Philip Kaludercic @ 2021-05-12 21:27 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 41438, Juri Linkov Lars Ingebrigtsen <larsi@gnus.org> writes: > "Philip K." <philipk@posteo.net> writes: > >> These are the only edge-cases I found, but I didn't fix them yet, as I'm >> not sure what would be preferred. So the patches should not be applies yet. > > Have you done any further work on this? No, not since whenever that message was sent. -- Philip K. ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2021-05-12 20:38 ` Lars Ingebrigtsen 2021-05-12 21:27 ` Philip Kaludercic @ 2021-05-22 20:29 ` Philip Kaludercic 2021-05-22 21:09 ` Philip Kaludercic 2021-05-25 5:12 ` Lars Ingebrigtsen 1 sibling, 2 replies; 838+ messages in thread From: Philip Kaludercic @ 2021-05-22 20:29 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 41438, Juri Linkov [-- Attachment #1: Type: text/plain, Size: 1033 bytes --] Lars Ingebrigtsen <larsi@gnus.org> writes: > "Philip K." <philipk@posteo.net> writes: > >> These are the only edge-cases I found, but I didn't fix them yet, as I'm >> not sure what would be preferred. So the patches should not be applies yet. > > Have you done any further work on this? I have been thinking about this a bit more, and tried a different approach. The implementation is not prefect, but basically I am playing with emulation-mode-map-alists to bind the keys, instead of using the global map. The should solve the two issues I brought up, because I do not have to worry about restoring the previous keys, and some edge-cases are avoided, where e.g. doc-view would override up and down breaking the expected behaviour when setting the prefix to 'none. The code should probably be refactored, moving more of the common functionality into it's own function, but I am primarily wondering if using emulation-mode-map-alists the way I am proposing it here is ok. Or should I prefer minor-mode-map-alist? -- Philip K. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-Allow-windmove-keys-to-be-bound-without-prefix-or-mo.patch --] [-- Type: text/x-diff, Size: 7384 bytes --] From eba161853d50c2a6ce27af5907efdae4f6ab81eb Mon Sep 17 00:00:00 2001 From: Philip K <philipk@posteo.net> Date: Sat, 22 May 2021 22:03:22 +0200 Subject: [PATCH] Allow windmove keys to be bound without prefix or modifiers --- lisp/windmove.el | 91 +++++++++++++++++++++++++++++++++++++----------- 1 file changed, 70 insertions(+), 21 deletions(-) diff --git a/lisp/windmove.el b/lisp/windmove.el index e4ea8e0f69..acd9cb41fc 100644 --- a/lisp/windmove.el +++ b/lisp/windmove.el @@ -426,19 +426,35 @@ windmove-down ;; I don't think these bindings will work on non-X terminals; you ;; probably want to use different bindings in that case. +(defvar windmove-map (make-sparse-keymap) + "Keymap to bind windmove keys to.") + +(add-to-list 'emulation-mode-map-alists + (list (cons t windmove-map))) + ;;;###autoload (defun windmove-default-keybindings (&optional modifiers) "Set up keybindings for `windmove'. Keybindings are of the form MODIFIERS-{left,right,up,down}, where MODIFIERS is either a list of modifiers or a single modifier. +If MODIFIERS is `none', the keybindings will be directly bound to +the arrow keys. Default value of MODIFIERS is `shift'." (interactive) (unless modifiers (setq modifiers 'shift)) + (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) - (global-set-key (vector (append modifiers '(left))) 'windmove-left) - (global-set-key (vector (append modifiers '(right))) 'windmove-right) - (global-set-key (vector (append modifiers '(up))) 'windmove-up) - (global-set-key (vector (append modifiers '(down))) 'windmove-down)) + (dolist (bind '((windmove-left left) + (windmove-right right) + (windmove-up up) + (windmove-down down))) + (when (or (memq (cadr bind) '(left right up down)) + (not (null modifiers))) + (dolist (old (where-is-internal (car bind) windmove-map)) + (define-key windmove-map old nil)) + (define-key windmove-map + (vector (append modifiers (cdr bind))) + (car bind))))) \f ;;; Directional window display and selection @@ -546,17 +562,27 @@ windmove-display-default-keybindings Keys are bound to commands that display the next buffer in the specified direction. Keybindings are of the form MODIFIERS-{left,right,up,down}, where MODIFIERS is either a list of modifiers or a single modifier. +If MODIFIERS is `none', the keybindings will be directly bound to +the arrow keys. Default value of MODIFIERS is `shift-meta'." (interactive) (unless modifiers (setq modifiers '(shift meta))) + (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) - (global-set-key (vector (append modifiers '(left))) 'windmove-display-left) - (global-set-key (vector (append modifiers '(right))) 'windmove-display-right) - (global-set-key (vector (append modifiers '(up))) 'windmove-display-up) - (global-set-key (vector (append modifiers '(down))) 'windmove-display-down) - (global-set-key (vector (append modifiers '(?0))) 'windmove-display-same-window) - (global-set-key (vector (append modifiers '(?f))) 'windmove-display-new-frame) - (global-set-key (vector (append modifiers '(?t))) 'windmove-display-new-tab)) + (dolist (bind '((windmove-display-left left) + (windmove-display-right right) + (windmove-display-up up) + (windmove-display-down down) + (windmove-display-same-window ?0) + (windmove-display-new-frame ?f) + (windmove-display-new-tab ?t))) + (when (or (memq (cadr bind) '(left right up down)) + (not (null modifiers))) + (dolist (old (where-is-internal (car bind) windmove-map)) + (define-key windmove-map old nil)) + (define-key windmove-map + (vector (append modifiers (cdr bind))) + (car bind))))) \f ;;; Directional window deletion @@ -618,16 +644,28 @@ windmove-delete-default-keybindings Keys are bound to commands that delete windows in the specified direction. Keybindings are of the form PREFIX MODIFIERS-{left,right,up,down}, where PREFIX is a prefix key and MODIFIERS is either a list of modifiers or -a single modifier. Default value of PREFIX is `C-x' and MODIFIERS is `shift'." +a single modifier. +If PREFIX is `none', no prefix is used. If MODIFIERS is `none', the keybindings +are directly bound to the arrow keys. +Default value of PREFIX is `C-x' and MODIFIERS is `shift'." (interactive) (unless prefix (setq prefix '(?\C-x))) + (when (eq prefix 'none) (setq prefix nil)) (unless (listp prefix) (setq prefix (list prefix))) (unless modifiers (setq modifiers '(shift))) + (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) - (global-set-key (vector prefix (append modifiers '(left))) 'windmove-delete-left) - (global-set-key (vector prefix (append modifiers '(right))) 'windmove-delete-right) - (global-set-key (vector prefix (append modifiers '(up))) 'windmove-delete-up) - (global-set-key (vector prefix (append modifiers '(down))) 'windmove-delete-down)) + (dolist (bind '((windmove-delete-left left) + (windmove-delete-right right) + (windmove-delete-up up) + (windmove-delete-down down))) + (when (or (memq (cadr bind) '(left right up down)) + (not (null modifiers))) + (dolist (old (where-is-internal (car bind) windmove-map)) + (define-key windmove-map old nil)) + (define-key windmove-map + (vector (append modifiers (cdr bind))) + (car bind))))) \f ;;; Directional window swap states @@ -673,14 +711,25 @@ windmove-swap-states-default-keybindings Keys are bound to commands that swap the states of the selected window with the window in the specified direction. Keybindings are of the form MODIFIERS-{left,right,up,down}, where MODIFIERS is either a list of modifiers -or a single modifier. Default value of MODIFIERS is `shift-super'." +or a single modifier. +If MODIFIERS is `none', the keybindings will be directly bound to the +arrow keys. +Default value of MODIFIERS is `shift-super'." (interactive) (unless modifiers (setq modifiers '(shift super))) + (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) - (global-set-key (vector (append modifiers '(left))) 'windmove-swap-states-left) - (global-set-key (vector (append modifiers '(right))) 'windmove-swap-states-right) - (global-set-key (vector (append modifiers '(up))) 'windmove-swap-states-up) - (global-set-key (vector (append modifiers '(down))) 'windmove-swap-states-down)) + (dolist (bind '((windmove-swap-states-left left) + (windmove-swap-states-right right) + (windmove-swap-states-up up) + (windmove-swap-states-down down))) + (when (or (memq (cadr bind) '(left right up down)) + (not (null modifiers))) + (dolist (old (where-is-internal (car bind) windmove-map)) + (define-key windmove-map old nil)) + (define-key windmove-map + (vector (append modifiers (cdr bind))) + (car bind))))) \f (provide 'windmove) -- 2.30.2 ^ permalink raw reply related [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2021-05-22 20:29 ` Philip Kaludercic @ 2021-05-22 21:09 ` Philip Kaludercic 2021-05-23 6:49 ` Eli Zaretskii 2021-05-25 5:12 ` Lars Ingebrigtsen 1 sibling, 1 reply; 838+ messages in thread From: Philip Kaludercic @ 2021-05-22 21:09 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 41438, Juri Linkov [-- Attachment #1: Type: text/plain, Size: 358 bytes --] Philip Kaludercic <philipk@posteo.net> writes: > The code should probably be refactored, moving more of the common > functionality into it's own function, but I am primarily wondering if > using emulation-mode-map-alists the way I am proposing it here is ok. Or > should I prefer minor-mode-map-alist? Here is a slightly cleaner version. -- Philip K. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-Allow-windmove-keys-to-be-bound-without-prefix-or-mo.patch --] [-- Type: text/x-diff, Size: 7168 bytes --] From 03248e79527f9603aa944e7e147fc67a8886eb3a Mon Sep 17 00:00:00 2001 From: Philip K <philipk@posteo.net> Date: Sat, 22 May 2021 22:03:22 +0200 Subject: [PATCH] Allow windmove keys to be bound without prefix or modifiers --- lisp/windmove.el | 79 +++++++++++++++++++++++++++++++++++------------- 1 file changed, 58 insertions(+), 21 deletions(-) diff --git a/lisp/windmove.el b/lisp/windmove.el index e4ea8e0f69..bb9478eab4 100644 --- a/lisp/windmove.el +++ b/lisp/windmove.el @@ -426,19 +426,41 @@ windmove-down ;; I don't think these bindings will work on non-X terminals; you ;; probably want to use different bindings in that case. +(defvar windmove-default-map (make-sparse-keymap) + "Map used by `windmove-install-defaults'.") + +(defun windmove-install-defaults (modifiers alist) + "Install keys as specified by ALIST. +Every element of ALIST has the form (FN KEY), where KEY is +appended to MODIFIERS, before installing the key. Previous +bindings of FN are unbound." + (add-to-list 'emulation-mode-map-alists `((t . ,windmove-default-map))) + (dolist (bind alist) + (when (or (memq (cadr bind) '(left right up down)) + (not (null modifiers))) + (dolist (old (where-is-internal (car bind) windmove-default-map)) + (define-key windmove-default-map old nil)) + (define-key windmove-default-map + (vector (append modifiers (cdr bind))) + (car bind))))) + ;;;###autoload (defun windmove-default-keybindings (&optional modifiers) "Set up keybindings for `windmove'. Keybindings are of the form MODIFIERS-{left,right,up,down}, where MODIFIERS is either a list of modifiers or a single modifier. +If MODIFIERS is `none', the keybindings will be directly bound to +the arrow keys. Default value of MODIFIERS is `shift'." (interactive) (unless modifiers (setq modifiers 'shift)) + (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) - (global-set-key (vector (append modifiers '(left))) 'windmove-left) - (global-set-key (vector (append modifiers '(right))) 'windmove-right) - (global-set-key (vector (append modifiers '(up))) 'windmove-up) - (global-set-key (vector (append modifiers '(down))) 'windmove-down)) + (windmove-install-defaults modifiers + '((windmove-left left) + (windmove-right right) + (windmove-up up) + (windmove-down down)))) \f ;;; Directional window display and selection @@ -546,17 +568,21 @@ windmove-display-default-keybindings Keys are bound to commands that display the next buffer in the specified direction. Keybindings are of the form MODIFIERS-{left,right,up,down}, where MODIFIERS is either a list of modifiers or a single modifier. +If MODIFIERS is `none', the keybindings will be directly bound to +the arrow keys. Default value of MODIFIERS is `shift-meta'." (interactive) (unless modifiers (setq modifiers '(shift meta))) + (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) - (global-set-key (vector (append modifiers '(left))) 'windmove-display-left) - (global-set-key (vector (append modifiers '(right))) 'windmove-display-right) - (global-set-key (vector (append modifiers '(up))) 'windmove-display-up) - (global-set-key (vector (append modifiers '(down))) 'windmove-display-down) - (global-set-key (vector (append modifiers '(?0))) 'windmove-display-same-window) - (global-set-key (vector (append modifiers '(?f))) 'windmove-display-new-frame) - (global-set-key (vector (append modifiers '(?t))) 'windmove-display-new-tab)) + (windmove-install-defaults modifiers + '((windmove-display-left left) + (windmove-display-right right) + (windmove-display-up up) + (windmove-display-down down) + (windmove-display-same-window ?0) + (windmove-display-new-frame ?f) + (windmove-display-new-tab ?t)))) \f ;;; Directional window deletion @@ -618,16 +644,22 @@ windmove-delete-default-keybindings Keys are bound to commands that delete windows in the specified direction. Keybindings are of the form PREFIX MODIFIERS-{left,right,up,down}, where PREFIX is a prefix key and MODIFIERS is either a list of modifiers or -a single modifier. Default value of PREFIX is `C-x' and MODIFIERS is `shift'." +a single modifier. +If PREFIX is `none', no prefix is used. If MODIFIERS is `none', the keybindings +are directly bound to the arrow keys. +Default value of PREFIX is `C-x' and MODIFIERS is `shift'." (interactive) (unless prefix (setq prefix '(?\C-x))) + (when (eq prefix 'none) (setq prefix nil)) (unless (listp prefix) (setq prefix (list prefix))) (unless modifiers (setq modifiers '(shift))) + (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) - (global-set-key (vector prefix (append modifiers '(left))) 'windmove-delete-left) - (global-set-key (vector prefix (append modifiers '(right))) 'windmove-delete-right) - (global-set-key (vector prefix (append modifiers '(up))) 'windmove-delete-up) - (global-set-key (vector prefix (append modifiers '(down))) 'windmove-delete-down)) + (windmove-install-defaults modifiers + '((windmove-delete-left left) + (windmove-delete-right right) + (windmove-delete-up up) + (windmove-delete-down down)))) \f ;;; Directional window swap states @@ -673,14 +705,19 @@ windmove-swap-states-default-keybindings Keys are bound to commands that swap the states of the selected window with the window in the specified direction. Keybindings are of the form MODIFIERS-{left,right,up,down}, where MODIFIERS is either a list of modifiers -or a single modifier. Default value of MODIFIERS is `shift-super'." +or a single modifier. +If MODIFIERS is `none', the keybindings will be directly bound to the +arrow keys. +Default value of MODIFIERS is `shift-super'." (interactive) (unless modifiers (setq modifiers '(shift super))) + (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) - (global-set-key (vector (append modifiers '(left))) 'windmove-swap-states-left) - (global-set-key (vector (append modifiers '(right))) 'windmove-swap-states-right) - (global-set-key (vector (append modifiers '(up))) 'windmove-swap-states-up) - (global-set-key (vector (append modifiers '(down))) 'windmove-swap-states-down)) + (windmove-install-defaults modifiers + '((windmove-swap-states-left left) + (windmove-swap-states-right right) + (windmove-swap-states-up up) + (windmove-swap-states-down down)))) \f (provide 'windmove) -- 2.30.2 ^ permalink raw reply related [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2021-05-22 21:09 ` Philip Kaludercic @ 2021-05-23 6:49 ` Eli Zaretskii 2021-05-23 12:36 ` Philip Kaludercic 0 siblings, 1 reply; 838+ messages in thread From: Eli Zaretskii @ 2021-05-23 6:49 UTC (permalink / raw) To: Philip Kaludercic; +Cc: 41438, larsi, juri > From: Philip Kaludercic <philipk@posteo.net> > Date: Sat, 22 May 2021 21:09:00 +0000 > Cc: 41438@debbugs.gnu.org, Juri Linkov <juri@linkov.net> > > Philip Kaludercic <philipk@posteo.net> writes: > > > The code should probably be refactored, moving more of the common > > functionality into it's own function, but I am primarily wondering if > > using emulation-mode-map-alists the way I am proposing it here is ok. Or > > should I prefer minor-mode-map-alist? > > Here is a slightly cleaner version. Thanks. Should this be in NEWS? ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2021-05-23 6:49 ` Eli Zaretskii @ 2021-05-23 12:36 ` Philip Kaludercic 0 siblings, 0 replies; 838+ messages in thread From: Philip Kaludercic @ 2021-05-23 12:36 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 41438, larsi, juri Eli Zaretskii <eliz@gnu.org> writes: >> From: Philip Kaludercic <philipk@posteo.net> >> Date: Sat, 22 May 2021 21:09:00 +0000 >> Cc: 41438@debbugs.gnu.org, Juri Linkov <juri@linkov.net> >> >> Philip Kaludercic <philipk@posteo.net> writes: >> >> > The code should probably be refactored, moving more of the common >> > functionality into it's own function, but I am primarily wondering if >> > using emulation-mode-map-alists the way I am proposing it here is ok. Or >> > should I prefer minor-mode-map-alist? >> >> Here is a slightly cleaner version. > > Thanks. Should this be in NEWS? I think so. IIRC the plan was to add a few additional user options to make it easier to configure. -- Philip K. ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2021-05-22 20:29 ` Philip Kaludercic 2021-05-22 21:09 ` Philip Kaludercic @ 2021-05-25 5:12 ` Lars Ingebrigtsen 2021-05-25 7:25 ` Philip Kaludercic 2021-05-25 9:53 ` Philip Kaludercic 1 sibling, 2 replies; 838+ messages in thread From: Lars Ingebrigtsen @ 2021-05-25 5:12 UTC (permalink / raw) To: Philip Kaludercic; +Cc: 41438, Juri Linkov Philip Kaludercic <philipk@posteo.net> writes: > The code should probably be refactored, moving more of the common > functionality into it's own function, but I am primarily wondering if > using emulation-mode-map-alists the way I am proposing it here is ok. Or > should I prefer minor-mode-map-alist? Making windmove into a regular (global) minor mode would be less surprising, I think, but I'm not really familiar with windmove, and whether that would be an easy rewrite? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2021-05-25 5:12 ` Lars Ingebrigtsen @ 2021-05-25 7:25 ` Philip Kaludercic 2021-05-25 9:53 ` Philip Kaludercic 1 sibling, 0 replies; 838+ messages in thread From: Philip Kaludercic @ 2021-05-25 7:25 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 41438, Juri Linkov Lars Ingebrigtsen <larsi@gnus.org> writes: > Philip Kaludercic <philipk@posteo.net> writes: > >> The code should probably be refactored, moving more of the common >> functionality into it's own function, but I am primarily wondering if >> using emulation-mode-map-alists the way I am proposing it here is ok. Or >> should I prefer minor-mode-map-alist? > > Making windmove into a regular (global) minor mode would be less > surprising, I think, but I'm not really familiar with windmove, and > whether that would be an easy rewrite? From my experience, it should be possible, I'll try preparing a patch. The only issue is that most people won't realize there is a minor mode at first, but that should be OK as long as the actual windmove commands do not depend on said minor mode. -- Philip K. ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2021-05-25 5:12 ` Lars Ingebrigtsen 2021-05-25 7:25 ` Philip Kaludercic @ 2021-05-25 9:53 ` Philip Kaludercic 2021-05-25 11:16 ` Arthur Miller ` (3 more replies) 1 sibling, 4 replies; 838+ messages in thread From: Philip Kaludercic @ 2021-05-25 9:53 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 41438, Juri Linkov [-- Attachment #1: Type: text/plain, Size: 682 bytes --] Lars Ingebrigtsen <larsi@gnus.org> writes: > Philip Kaludercic <philipk@posteo.net> writes: > >> The code should probably be refactored, moving more of the common >> functionality into it's own function, but I am primarily wondering if >> using emulation-mode-map-alists the way I am proposing it here is ok. Or >> should I prefer minor-mode-map-alist? > > Making windmove into a regular (global) minor mode would be less > surprising, I think, but I'm not really familiar with windmove, and > whether that would be an easy rewrite? I have tried this out, and it seems somewhat elegant. From my testing, it seems to behave the same way as the previous approach. -- Philip K. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-Improve-windmove-default-keybindings-fuctions.patch --] [-- Type: text/x-diff, Size: 7751 bytes --] From 2f7a8d89cdb5835cf875bc1f2bcfcb6755a0e0c0 Mon Sep 17 00:00:00 2001 From: Philip Kaludercic <philipk@posteo.net> Date: Tue, 25 May 2021 11:47:51 +0200 Subject: [PATCH] Improve windmove-*-default-keybindings fuctions * windmove.el (windmove-default-map): Add special map for windmove commands (windmove-mode): Add minor mode for activating windmove-default-map (windmove-install-defaults): Add general function for manipulating windmove-default-map (windmove-default-keybindings): Use windmove-install-defaults (windmove-display-default-keybindings): Use windmove-install-defaults (windmove-delete-default-keybindings): Use windmove-install-defaults (windmove-swap-states-default-keybindings): Use windmove-install-defaults --- lisp/windmove.el | 84 ++++++++++++++++++++++++++++++++++++------------ 1 file changed, 63 insertions(+), 21 deletions(-) diff --git a/lisp/windmove.el b/lisp/windmove.el index e4ea8e0f69..5a81893bf9 100644 --- a/lisp/windmove.el +++ b/lisp/windmove.el @@ -426,19 +426,46 @@ windmove-down ;; I don't think these bindings will work on non-X terminals; you ;; probably want to use different bindings in that case. +(defvar windmove-default-map (make-sparse-keymap) + "Map used by `windmove-install-defaults'.") + +(define-minor-mode windmove-mode + "Global minor mode for default windmove commands." + :keymap windmove-default-map + :init-value t + :global t) + +(defun windmove-install-defaults (modifiers alist) + "Install keys as specified by ALIST. +Every element of ALIST has the form (FN KEY), where KEY is +appended to MODIFIERS, before installing the key. Previous +bindings of FN are unbound." + (dolist (bind alist) + (when (or (memq (cadr bind) '(left right up down)) + (not (null modifiers))) + (dolist (old (where-is-internal (car bind) windmove-default-map)) + (define-key windmove-default-map old nil)) + (define-key windmove-default-map + (vector (append modifiers (cdr bind))) + (car bind))))) + ;;;###autoload (defun windmove-default-keybindingsq (&optional modifiers) "Set up keybindings for `windmove'. Keybindings are of the form MODIFIERS-{left,right,up,down}, where MODIFIERS is either a list of modifiers or a single modifier. +If MODIFIERS is `none', the keybindings will be directly bound to +the arrow keys. Default value of MODIFIERS is `shift'." (interactive) (unless modifiers (setq modifiers 'shift)) + (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) - (global-set-key (vector (append modifiers '(left))) 'windmove-left) - (global-set-key (vector (append modifiers '(right))) 'windmove-right) - (global-set-key (vector (append modifiers '(up))) 'windmove-up) - (global-set-key (vector (append modifiers '(down))) 'windmove-down)) + (windmove-install-defaults modifiers + '((windmove-left left) + (windmove-right right) + (windmove-up up) + (windmove-down down)))) \f ;;; Directional window display and selection @@ -546,17 +573,21 @@ windmove-display-default-keybindings Keys are bound to commands that display the next buffer in the specified direction. Keybindings are of the form MODIFIERS-{left,right,up,down}, where MODIFIERS is either a list of modifiers or a single modifier. +If MODIFIERS is `none', the keybindings will be directly bound to +the arrow keys. Default value of MODIFIERS is `shift-meta'." (interactive) (unless modifiers (setq modifiers '(shift meta))) + (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) - (global-set-key (vector (append modifiers '(left))) 'windmove-display-left) - (global-set-key (vector (append modifiers '(right))) 'windmove-display-right) - (global-set-key (vector (append modifiers '(up))) 'windmove-display-up) - (global-set-key (vector (append modifiers '(down))) 'windmove-display-down) - (global-set-key (vector (append modifiers '(?0))) 'windmove-display-same-window) - (global-set-key (vector (append modifiers '(?f))) 'windmove-display-new-frame) - (global-set-key (vector (append modifiers '(?t))) 'windmove-display-new-tab)) + (windmove-install-defaults modifiers + '((windmove-display-left left) + (windmove-display-right right) + (windmove-display-up up) + (windmove-display-down down) + (windmove-display-same-window ?0) + (windmove-display-new-frame ?f) + (windmove-display-new-tab ?t)))) \f ;;; Directional window deletion @@ -618,16 +649,22 @@ windmove-delete-default-keybindings Keys are bound to commands that delete windows in the specified direction. Keybindings are of the form PREFIX MODIFIERS-{left,right,up,down}, where PREFIX is a prefix key and MODIFIERS is either a list of modifiers or -a single modifier. Default value of PREFIX is `C-x' and MODIFIERS is `shift'." +a single modifier. +If PREFIX is `none', no prefix is used. If MODIFIERS is `none', the keybindings +are directly bound to the arrow keys. +Default value of PREFIX is `C-x' and MODIFIERS is `shift'." (interactive) (unless prefix (setq prefix '(?\C-x))) + (when (eq prefix 'none) (setq prefix nil)) (unless (listp prefix) (setq prefix (list prefix))) (unless modifiers (setq modifiers '(shift))) + (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) - (global-set-key (vector prefix (append modifiers '(left))) 'windmove-delete-left) - (global-set-key (vector prefix (append modifiers '(right))) 'windmove-delete-right) - (global-set-key (vector prefix (append modifiers '(up))) 'windmove-delete-up) - (global-set-key (vector prefix (append modifiers '(down))) 'windmove-delete-down)) + (windmove-install-defaults modifiers + '((windmove-delete-left left) + (windmove-delete-right right) + (windmove-delete-up up) + (windmove-delete-down down)))) \f ;;; Directional window swap states @@ -673,14 +710,19 @@ windmove-swap-states-default-keybindings Keys are bound to commands that swap the states of the selected window with the window in the specified direction. Keybindings are of the form MODIFIERS-{left,right,up,down}, where MODIFIERS is either a list of modifiers -or a single modifier. Default value of MODIFIERS is `shift-super'." +or a single modifier. +If MODIFIERS is `none', the keybindings will be directly bound to the +arrow keys. +Default value of MODIFIERS is `shift-super'." (interactive) (unless modifiers (setq modifiers '(shift super))) + (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) - (global-set-key (vector (append modifiers '(left))) 'windmove-swap-states-left) - (global-set-key (vector (append modifiers '(right))) 'windmove-swap-states-right) - (global-set-key (vector (append modifiers '(up))) 'windmove-swap-states-up) - (global-set-key (vector (append modifiers '(down))) 'windmove-swap-states-down)) + (windmove-install-defaults modifiers + '((windmove-swap-states-left left) + (windmove-swap-states-right right) + (windmove-swap-states-up up) + (windmove-swap-states-down down)))) \f (provide 'windmove) -- 2.30.2 ^ permalink raw reply related [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2021-05-25 9:53 ` Philip Kaludercic @ 2021-05-25 11:16 ` Arthur Miller 2021-05-25 11:42 ` Philip Kaludercic 2021-05-25 11:36 ` Arthur Miller ` (2 subsequent siblings) 3 siblings, 1 reply; 838+ messages in thread From: Arthur Miller @ 2021-05-25 11:16 UTC (permalink / raw) To: Philip Kaludercic; +Cc: 41438, Lars Ingebrigtsen, Juri Linkov Philip Kaludercic <philipk@posteo.net> writes: > Lars Ingebrigtsen <larsi@gnus.org> writes: > >> Philip Kaludercic <philipk@posteo.net> writes: >> >>> The code should probably be refactored, moving more of the common >>> functionality into it's own function, but I am primarily wondering if >>> using emulation-mode-map-alists the way I am proposing it here is ok. Or >>> should I prefer minor-mode-map-alist? >> >> Making windmove into a regular (global) minor mode would be less >> surprising, I think, but I'm not really familiar with windmove, and >> whether that would be an easy rewrite? > > I have tried this out, and it seems somewhat elegant. From my testing, > it seems to behave the same way as the previous approach. > > -- > Philip K. > > From 2f7a8d89cdb5835cf875bc1f2bcfcb6755a0e0c0 Mon Sep 17 00:00:00 2001 > From: Philip Kaludercic <philipk@posteo.net> > Date: Tue, 25 May 2021 11:47:51 +0200 > Subject: [PATCH] Improve windmove-*-default-keybindings fuctions > > * windmove.el (windmove-default-map): Add special map for windmove > commands > (windmove-mode): Add minor mode for activating windmove-default-map > (windmove-install-defaults): Add general function for manipulating > windmove-default-map > (windmove-default-keybindings): Use windmove-install-defaults > (windmove-display-default-keybindings): Use windmove-install-defaults > (windmove-delete-default-keybindings): Use windmove-install-defaults > (windmove-swap-states-default-keybindings): Use > windmove-install-defaults > --- > lisp/windmove.el | 84 ++++++++++++++++++++++++++++++++++++------------ > 1 file changed, 63 insertions(+), 21 deletions(-) > > diff --git a/lisp/windmove.el b/lisp/windmove.el > index e4ea8e0f69..5a81893bf9 100644 > --- a/lisp/windmove.el > +++ b/lisp/windmove.el > @@ -426,19 +426,46 @@ windmove-down > ;; I don't think these bindings will work on non-X terminals; you > ;; probably want to use different bindings in that case. > > +(defvar windmove-default-map (make-sparse-keymap) > + "Map used by `windmove-install-defaults'.") Sorry if I ask, but wouldn't ordinary windmove-mode-map do here? Since it is a convention to have mode maps called modename-mode-maps, if people would like to change, or add a binding in the windmove mode they would probably automatically try to alter windmove-mode-map instead of windmove-default-map. > +(define-minor-mode windmove-mode > + "Global minor mode for default windmove commands." > + :keymap windmove-default-map > + :init-value t > + :global t) > + > +(defun windmove-install-defaults (modifiers alist) > + "Install keys as specified by ALIST. > +Every element of ALIST has the form (FN KEY), where KEY is > +appended to MODIFIERS, before installing the key. Previous > +bindings of FN are unbound." > + (dolist (bind alist) > + (when (or (memq (cadr bind) '(left right up down)) > + (not (null modifiers))) > + (dolist (old (where-is-internal (car bind) windmove-default-map)) > + (define-key windmove-default-map old nil)) > + (define-key windmove-default-map > + (vector (append modifiers (cdr bind))) > + (car bind))))) > + > ;;;###autoload > (defun windmove-default-keybindingsq (&optional modifiers) > "Set up keybindings for `windmove'. > Keybindings are of the form MODIFIERS-{left,right,up,down}, > where MODIFIERS is either a list of modifiers or a single modifier. > +If MODIFIERS is `none', the keybindings will be directly bound to > +the arrow keys. > Default value of MODIFIERS is `shift'." > (interactive) > (unless modifiers (setq modifiers 'shift)) > + (when (eq modifiers 'none) (setq modifiers nil)) > (unless (listp modifiers) (setq modifiers (list modifiers))) > - (global-set-key (vector (append modifiers '(left))) 'windmove-left) > - (global-set-key (vector (append modifiers '(right))) 'windmove-right) > - (global-set-key (vector (append modifiers '(up))) 'windmove-up) > - (global-set-key (vector (append modifiers '(down))) 'windmove-down)) > + (windmove-install-defaults modifiers > + '((windmove-left left) > + (windmove-right right) > + (windmove-up up) > + (windmove-down down)))) > > \f > ;;; Directional window display and selection > @@ -546,17 +573,21 @@ windmove-display-default-keybindings > Keys are bound to commands that display the next buffer in the specified > direction. Keybindings are of the form MODIFIERS-{left,right,up,down}, > where MODIFIERS is either a list of modifiers or a single modifier. > +If MODIFIERS is `none', the keybindings will be directly bound to > +the arrow keys. > Default value of MODIFIERS is `shift-meta'." > (interactive) > (unless modifiers (setq modifiers '(shift meta))) > + (when (eq modifiers 'none) (setq modifiers nil)) > (unless (listp modifiers) (setq modifiers (list modifiers))) > - (global-set-key (vector (append modifiers '(left))) 'windmove-display-left) > - (global-set-key (vector (append modifiers '(right))) 'windmove-display-right) > - (global-set-key (vector (append modifiers '(up))) 'windmove-display-up) > - (global-set-key (vector (append modifiers '(down))) 'windmove-display-down) > - (global-set-key (vector (append modifiers '(?0))) 'windmove-display-same-window) > - (global-set-key (vector (append modifiers '(?f))) 'windmove-display-new-frame) > - (global-set-key (vector (append modifiers '(?t))) 'windmove-display-new-tab)) > + (windmove-install-defaults modifiers > + '((windmove-display-left left) > + (windmove-display-right right) > + (windmove-display-up up) > + (windmove-display-down down) > + (windmove-display-same-window ?0) > + (windmove-display-new-frame ?f) > + (windmove-display-new-tab ?t)))) > > \f > ;;; Directional window deletion > @@ -618,16 +649,22 @@ windmove-delete-default-keybindings > Keys are bound to commands that delete windows in the specified > direction. Keybindings are of the form PREFIX MODIFIERS-{left,right,up,down}, > where PREFIX is a prefix key and MODIFIERS is either a list of modifiers or > -a single modifier. Default value of PREFIX is `C-x' and MODIFIERS is `shift'." > +a single modifier. > +If PREFIX is `none', no prefix is used. If MODIFIERS is `none', the keybindings > +are directly bound to the arrow keys. > +Default value of PREFIX is `C-x' and MODIFIERS is `shift'." > (interactive) > (unless prefix (setq prefix '(?\C-x))) > + (when (eq prefix 'none) (setq prefix nil)) > (unless (listp prefix) (setq prefix (list prefix))) > (unless modifiers (setq modifiers '(shift))) > + (when (eq modifiers 'none) (setq modifiers nil)) > (unless (listp modifiers) (setq modifiers (list modifiers))) > - (global-set-key (vector prefix (append modifiers '(left))) 'windmove-delete-left) > - (global-set-key (vector prefix (append modifiers '(right))) 'windmove-delete-right) > - (global-set-key (vector prefix (append modifiers '(up))) 'windmove-delete-up) > - (global-set-key (vector prefix (append modifiers '(down))) 'windmove-delete-down)) > + (windmove-install-defaults modifiers > + '((windmove-delete-left left) > + (windmove-delete-right right) > + (windmove-delete-up up) > + (windmove-delete-down down)))) > > \f > ;;; Directional window swap states > @@ -673,14 +710,19 @@ windmove-swap-states-default-keybindings > Keys are bound to commands that swap the states of the selected window > with the window in the specified direction. Keybindings are of the form > MODIFIERS-{left,right,up,down}, where MODIFIERS is either a list of modifiers > -or a single modifier. Default value of MODIFIERS is `shift-super'." > +or a single modifier. > +If MODIFIERS is `none', the keybindings will be directly bound to the > +arrow keys. > +Default value of MODIFIERS is `shift-super'." > (interactive) > (unless modifiers (setq modifiers '(shift super))) > + (when (eq modifiers 'none) (setq modifiers nil)) > (unless (listp modifiers) (setq modifiers (list modifiers))) > - (global-set-key (vector (append modifiers '(left))) 'windmove-swap-states-left) > - (global-set-key (vector (append modifiers '(right))) 'windmove-swap-states-right) > - (global-set-key (vector (append modifiers '(up))) 'windmove-swap-states-up) > - (global-set-key (vector (append modifiers '(down))) 'windmove-swap-states-down)) > + (windmove-install-defaults modifiers > + '((windmove-swap-states-left left) > + (windmove-swap-states-right right) > + (windmove-swap-states-up up) > + (windmove-swap-states-down down)))) > > \f > (provide 'windmove) ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2021-05-25 11:16 ` Arthur Miller @ 2021-05-25 11:42 ` Philip Kaludercic 2021-05-25 13:31 ` Arthur Miller 0 siblings, 1 reply; 838+ messages in thread From: Philip Kaludercic @ 2021-05-25 11:42 UTC (permalink / raw) To: Arthur Miller; +Cc: 41438, Lars Ingebrigtsen, Juri Linkov Arthur Miller <arthur.miller@live.com> writes: > Philip Kaludercic <philipk@posteo.net> writes: >> +(defvar windmove-default-map (make-sparse-keymap) >> + "Map used by `windmove-install-defaults'.") > > Sorry if I ask, but wouldn't ordinary windmove-mode-map do here? You are probably right -- my thought was that the minor mode exists for the sake of the map. > Since it is a convention to have mode maps called modename-mode-maps, > if people would like to change, or add a binding in the windmove mode > they would probably automatically try to alter windmove-mode-map instead > of windmove-default-map. That's the question: should windmove-default-map be accessed by default or only via the -default-keybindings functions? Either way something should be changed, if windmove-default-map it should be renamed to windmove--default-map to explicitly mark it as an internal map. Otherwise it should be renamed to windmove-mode-map as you suggest. -- Philip K. ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2021-05-25 11:42 ` Philip Kaludercic @ 2021-05-25 13:31 ` Arthur Miller 2021-05-25 14:39 ` Philip Kaludercic 0 siblings, 1 reply; 838+ messages in thread From: Arthur Miller @ 2021-05-25 13:31 UTC (permalink / raw) To: Philip Kaludercic; +Cc: 41438, Lars Ingebrigtsen, Juri Linkov Philip Kaludercic <philipk@posteo.net> writes: > Arthur Miller <arthur.miller@live.com> writes: > >> Philip Kaludercic <philipk@posteo.net> writes: >>> +(defvar windmove-default-map (make-sparse-keymap) >>> + "Map used by `windmove-install-defaults'.") >> >> Sorry if I ask, but wouldn't ordinary windmove-mode-map do here? > > You are probably right -- my thought was that the minor mode exists for > the sake of the map. Yeah, exactly in this case. I am not sure if I understand correctly, you mean people will set new map for the mode to change bindings? I just remarked on the name you choose for the mode map, most peeps like me probably expect it to be names after the convention 'modename-mode-map'. >> Since it is a convention to have mode maps called modename-mode-maps, >> if people would like to change, or add a binding in the windmove mode >> they would probably automatically try to alter windmove-mode-map instead >> of windmove-default-map. > > That's the question: should windmove-default-map be accessed by default > or only via the -default-keybindings functions? Either way something I think you are thinking about default keybindings reather than default map. If I assume correctly. If I understand corectly you would like to preserve some default bindings, the map is just a mean to accomplish it. > should be changed, if windmove-default-map it should be renamed to > windmove--default-map to explicitly mark it as an internal > map. Otherwise it shsould be renamed to windmove-mode-map as you suggest. Either use default map stored some "default var", and add a function that restores mode map, or just add a function that resets keybindings into mode map directly, which might be sufficient. I don't know matter of taste? A default mode map in a variable is cleaner but more costly? Emacs provides windows, so I think there should also be a default way of moving cursor between them, manipulate them and so on. Thus I think windmove operations should be on by default, I don't think C-x 1/2/3/o are satisfying when we have more then 2 widows. A minor mode is probably a good balance between altering Emacs defaults, so not break someones config, and to give people an option to easily turn on some useful feature/configuration. ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2021-05-25 13:31 ` Arthur Miller @ 2021-05-25 14:39 ` Philip Kaludercic 0 siblings, 0 replies; 838+ messages in thread From: Philip Kaludercic @ 2021-05-25 14:39 UTC (permalink / raw) To: Arthur Miller; +Cc: 41438, Lars Ingebrigtsen, Juri Linkov Arthur Miller <arthur.miller@live.com> writes: > Philip Kaludercic <philipk@posteo.net> writes: > >> Arthur Miller <arthur.miller@live.com> writes: >> >>> Philip Kaludercic <philipk@posteo.net> writes: >>>> +(defvar windmove-default-map (make-sparse-keymap) >>>> + "Map used by `windmove-install-defaults'.") >>> >>> Sorry if I ask, but wouldn't ordinary windmove-mode-map do here? >> >> You are probably right -- my thought was that the minor mode exists for >> the sake of the map. > > Yeah, exactly in this case. I am not sure if I understand correctly, you > mean people will set new map for the mode to change bindings? No, that is why the minor mode is active by default. The only reason the minor mode is defined is to modify minor-mode-map-alist. >> That's the question: should windmove-default-map be accessed by default >> or only via the -default-keybindings functions? Either way something > > I think you are thinking about default keybindings reather than default > map. If I assume correctly. If I understand corectly you would like to > preserve some default bindings, the map is just a mean to accomplish it. I am not sure what you are referring to, the map is manipulated by windmove-install-defaults, which in turn is used by * windmove-default-keybindings * windmove-display-default-keybindings * windmove-delete-default-keybindings * windmove-swap-states-default-keybindings So it is not just about preserving some default bindings, but ensuring that the explicitly requested bindings are installed correctly. >> should be changed, if windmove-default-map it should be renamed to >> windmove--default-map to explicitly mark it as an internal >> map. Otherwise it shsould be renamed to windmove-mode-map as you suggest. > > Either use default map stored some "default var", and add a function > that restores mode map, or just add a function that resets keybindings > into mode map directly, which might be sufficient. I don't know matter > of taste? A default mode map in a variable is cleaner but more costly? > > Emacs provides windows, so I think there should also be a default way of > moving cursor between them, manipulate them and so on. Thus I think > windmove operations should be on by default, I don't think C-x 1/2/3/o > are satisfying when we have more then 2 widows. > > A minor mode is probably a good balance between altering Emacs defaults, > so not break someones config, and to give people an option to easily > turn on some useful feature/configuration. I'm sorry, either I am missing something or we are talking besides one another. -- Philip K. ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2021-05-25 9:53 ` Philip Kaludercic 2021-05-25 11:16 ` Arthur Miller @ 2021-05-25 11:36 ` Arthur Miller 2021-05-25 11:46 ` Philip Kaludercic 2021-05-25 19:13 ` Lars Ingebrigtsen 2021-05-25 19:16 ` Lars Ingebrigtsen 2021-05-25 20:18 ` Juri Linkov 3 siblings, 2 replies; 838+ messages in thread From: Arthur Miller @ 2021-05-25 11:36 UTC (permalink / raw) To: Philip Kaludercic; +Cc: 41438, Lars Ingebrigtsen, Juri Linkov Philip Kaludercic <philipk@posteo.net> writes: If you are already patching windmove.el, can you consider adding bindings for these funcitions too (defined in window.el): enlarge-window-horizontally shrink-window-horizontally As well as add these two wrappers for vertical operations: #+begin_src emacs-lisp ;;;###autoload (defun enlarge-window-vertically (delta) "Make selected window DELTA columns wider. Interactively, if no argument is given, make selected window one column wider." (interactive "p") (enlarge-window delta nil)) ;;;###autoload (defun shrink-window-vertically (delta) "Make selected window DELTA columns narrower. Interactively, if no argument is given, make selected window one column narrower." (interactive "p") (shrink-window delta nil)) #+end_src I have been using those for long time myself since I prefer to do everything from the keyboard. Maybe someone else finds them useful too; they have been in my config on GH for long time. > Lars Ingebrigtsen <larsi@gnus.org> writes: > >> Philip Kaludercic <philipk@posteo.net> writes: >> >>> The code should probably be refactored, moving more of the common >>> functionality into it's own function, but I am primarily wondering if >>> using emulation-mode-map-alists the way I am proposing it here is ok. Or >>> should I prefer minor-mode-map-alist? >> >> Making windmove into a regular (global) minor mode would be less >> surprising, I think, but I'm not really familiar with windmove, and >> whether that would be an easy rewrite? > > I have tried this out, and it seems somewhat elegant. From my testing, > it seems to behave the same way as the previous approach. > > -- > Philip K. > > From 2f7a8d89cdb5835cf875bc1f2bcfcb6755a0e0c0 Mon Sep 17 00:00:00 2001 > From: Philip Kaludercic <philipk@posteo.net> > Date: Tue, 25 May 2021 11:47:51 +0200 > Subject: [PATCH] Improve windmove-*-default-keybindings fuctions > > * windmove.el (windmove-default-map): Add special map for windmove > commands > (windmove-mode): Add minor mode for activating windmove-default-map > (windmove-install-defaults): Add general function for manipulating > windmove-default-map > (windmove-default-keybindings): Use windmove-install-defaults > (windmove-display-default-keybindings): Use windmove-install-defaults > (windmove-delete-default-keybindings): Use windmove-install-defaults > (windmove-swap-states-default-keybindings): Use > windmove-install-defaults > --- > lisp/windmove.el | 84 ++++++++++++++++++++++++++++++++++++------------ > 1 file changed, 63 insertions(+), 21 deletions(-) > > diff --git a/lisp/windmove.el b/lisp/windmove.el > index e4ea8e0f69..5a81893bf9 100644 > --- a/lisp/windmove.el > +++ b/lisp/windmove.el > @@ -426,19 +426,46 @@ windmove-down > ;; I don't think these bindings will work on non-X terminals; you > ;; probably want to use different bindings in that case. > > +(defvar windmove-default-map (make-sparse-keymap) > + "Map used by `windmove-install-defaults'.") > + > +(define-minor-mode windmove-mode > + "Global minor mode for default windmove commands." > + :keymap windmove-default-map > + :init-value t > + :global t) > + > +(defun windmove-install-defaults (modifiers alist) > + "Install keys as specified by ALIST. > +Every element of ALIST has the form (FN KEY), where KEY is > +appended to MODIFIERS, before installing the key. Previous > +bindings of FN are unbound." > + (dolist (bind alist) > + (when (or (memq (cadr bind) '(left right up down)) > + (not (null modifiers))) > + (dolist (old (where-is-internal (car bind) windmove-default-map)) > + (define-key windmove-default-map old nil)) > + (define-key windmove-default-map > + (vector (append modifiers (cdr bind))) > + (car bind))))) > + > ;;;###autoload > (defun windmove-default-keybindingsq (&optional modifiers) > "Set up keybindings for `windmove'. > Keybindings are of the form MODIFIERS-{left,right,up,down}, > where MODIFIERS is either a list of modifiers or a single modifier. > +If MODIFIERS is `none', the keybindings will be directly bound to > +the arrow keys. > Default value of MODIFIERS is `shift'." > (interactive) > (unless modifiers (setq modifiers 'shift)) > + (when (eq modifiers 'none) (setq modifiers nil)) > (unless (listp modifiers) (setq modifiers (list modifiers))) > - (global-set-key (vector (append modifiers '(left))) 'windmove-left) > - (global-set-key (vector (append modifiers '(right))) 'windmove-right) > - (global-set-key (vector (append modifiers '(up))) 'windmove-up) > - (global-set-key (vector (append modifiers '(down))) 'windmove-down)) > + (windmove-install-defaults modifiers > + '((windmove-left left) > + (windmove-right right) > + (windmove-up up) > + (windmove-down down)))) > > \f > ;;; Directional window display and selection > @@ -546,17 +573,21 @@ windmove-display-default-keybindings > Keys are bound to commands that display the next buffer in the specified > direction. Keybindings are of the form MODIFIERS-{left,right,up,down}, > where MODIFIERS is either a list of modifiers or a single modifier. > +If MODIFIERS is `none', the keybindings will be directly bound to > +the arrow keys. > Default value of MODIFIERS is `shift-meta'." > (interactive) > (unless modifiers (setq modifiers '(shift meta))) > + (when (eq modifiers 'none) (setq modifiers nil)) > (unless (listp modifiers) (setq modifiers (list modifiers))) > - (global-set-key (vector (append modifiers '(left))) 'windmove-display-left) > - (global-set-key (vector (append modifiers '(right))) 'windmove-display-right) > - (global-set-key (vector (append modifiers '(up))) 'windmove-display-up) > - (global-set-key (vector (append modifiers '(down))) 'windmove-display-down) > - (global-set-key (vector (append modifiers '(?0))) 'windmove-display-same-window) > - (global-set-key (vector (append modifiers '(?f))) 'windmove-display-new-frame) > - (global-set-key (vector (append modifiers '(?t))) 'windmove-display-new-tab)) > + (windmove-install-defaults modifiers > + '((windmove-display-left left) > + (windmove-display-right right) > + (windmove-display-up up) > + (windmove-display-down down) > + (windmove-display-same-window ?0) > + (windmove-display-new-frame ?f) > + (windmove-display-new-tab ?t)))) > > \f > ;;; Directional window deletion > @@ -618,16 +649,22 @@ windmove-delete-default-keybindings > Keys are bound to commands that delete windows in the specified > direction. Keybindings are of the form PREFIX MODIFIERS-{left,right,up,down}, > where PREFIX is a prefix key and MODIFIERS is either a list of modifiers or > -a single modifier. Default value of PREFIX is `C-x' and MODIFIERS is `shift'." > +a single modifier. > +If PREFIX is `none', no prefix is used. If MODIFIERS is `none', the keybindings > +are directly bound to the arrow keys. > +Default value of PREFIX is `C-x' and MODIFIERS is `shift'." > (interactive) > (unless prefix (setq prefix '(?\C-x))) > + (when (eq prefix 'none) (setq prefix nil)) > (unless (listp prefix) (setq prefix (list prefix))) > (unless modifiers (setq modifiers '(shift))) > + (when (eq modifiers 'none) (setq modifiers nil)) > (unless (listp modifiers) (setq modifiers (list modifiers))) > - (global-set-key (vector prefix (append modifiers '(left))) 'windmove-delete-left) > - (global-set-key (vector prefix (append modifiers '(right))) 'windmove-delete-right) > - (global-set-key (vector prefix (append modifiers '(up))) 'windmove-delete-up) > - (global-set-key (vector prefix (append modifiers '(down))) 'windmove-delete-down)) > + (windmove-install-defaults modifiers > + '((windmove-delete-left left) > + (windmove-delete-right right) > + (windmove-delete-up up) > + (windmove-delete-down down)))) > > \f > ;;; Directional window swap states > @@ -673,14 +710,19 @@ windmove-swap-states-default-keybindings > Keys are bound to commands that swap the states of the selected window > with the window in the specified direction. Keybindings are of the form > MODIFIERS-{left,right,up,down}, where MODIFIERS is either a list of modifiers > -or a single modifier. Default value of MODIFIERS is `shift-super'." > +or a single modifier. > +If MODIFIERS is `none', the keybindings will be directly bound to the > +arrow keys. > +Default value of MODIFIERS is `shift-super'." > (interactive) > (unless modifiers (setq modifiers '(shift super))) > + (when (eq modifiers 'none) (setq modifiers nil)) > (unless (listp modifiers) (setq modifiers (list modifiers))) > - (global-set-key (vector (append modifiers '(left))) 'windmove-swap-states-left) > - (global-set-key (vector (append modifiers '(right))) 'windmove-swap-states-right) > - (global-set-key (vector (append modifiers '(up))) 'windmove-swap-states-up) > - (global-set-key (vector (append modifiers '(down))) 'windmove-swap-states-down)) > + (windmove-install-defaults modifiers > + '((windmove-swap-states-left left) > + (windmove-swap-states-right right) > + (windmove-swap-states-up up) > + (windmove-swap-states-down down)))) > > \f > (provide 'windmove) ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2021-05-25 11:36 ` Arthur Miller @ 2021-05-25 11:46 ` Philip Kaludercic 2021-05-25 13:58 ` Arthur Miller 2021-05-25 19:13 ` Lars Ingebrigtsen 1 sibling, 1 reply; 838+ messages in thread From: Philip Kaludercic @ 2021-05-25 11:46 UTC (permalink / raw) To: Arthur Miller; +Cc: 41438, Lars Ingebrigtsen, Juri Linkov Arthur Miller <arthur.miller@live.com> writes: > If you are already patching windmove.el, can you consider adding > bindings for these funcitions too (defined in window.el): > > enlarge-window-horizontally > shrink-window-horizontally > > As well as add these two wrappers for vertical operations: > > #+begin_src emacs-lisp > > ;;;###autoload > (defun enlarge-window-vertically (delta) > "Make selected window DELTA columns wider. > Interactively, if no argument is given, make selected window one > column wider." > (interactive "p") > (enlarge-window delta nil)) > > ;;;###autoload > (defun shrink-window-vertically (delta) > "Make selected window DELTA columns narrower. > Interactively, if no argument is given, make selected window one > column narrower." > (interactive "p") > (shrink-window delta nil)) > > #+end_src > > I have been using those for long time myself since I prefer to do > everything from the keyboard. Maybe someone else finds them useful too; > they have been in my config on GH for long time. I am not sure if these commands should be added as part of the same changeset. The point of this commit is to make configuring windmove keys using windmove-default-keybindings & co. more consistent. -- Philip K. ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2021-05-25 11:46 ` Philip Kaludercic @ 2021-05-25 13:58 ` Arthur Miller 0 siblings, 0 replies; 838+ messages in thread From: Arthur Miller @ 2021-05-25 13:58 UTC (permalink / raw) To: Philip Kaludercic; +Cc: 41438, Lars Ingebrigtsen, Juri Linkov Philip Kaludercic <philipk@posteo.net> writes: > Arthur Miller <arthur.miller@live.com> writes: > >> If you are already patching windmove.el, can you consider adding >> bindings for these funcitions too (defined in window.el): >> >> enlarge-window-horizontally >> shrink-window-horizontally >> >> As well as add these two wrappers for vertical operations: >> >> #+begin_src emacs-lisp >> >> ;;;###autoload >> (defun enlarge-window-vertically (delta) >> "Make selected window DELTA columns wider. >> Interactively, if no argument is given, make selected window one >> column wider." >> (interactive "p") >> (enlarge-window delta nil)) >> >> ;;;###autoload >> (defun shrink-window-vertically (delta) >> "Make selected window DELTA columns narrower. >> Interactively, if no argument is given, make selected window one >> column narrower." >> (interactive "p") >> (shrink-window delta nil)) >> >> #+end_src >> >> I have been using those for long time myself since I prefer to do >> everything from the keyboard. Maybe someone else finds them useful too; >> they have been in my config on GH for long time. > > I am not sure if these commands should be added as part of the same > changeset. Those two wrappers itself are not necessary to add, they are just they for the sake of naming. It looks better and more clear what a binding does in "whick-key" window, in help buffers, and provides better symmetry to shrink/enlarge-window-horizontally. original functions are all in window.el: shrink-window enlarge-window shrink-window-horizontally enlarge-window-horizontally > The point of this commit is to make configuring windmove keys > using windmove-default-keybindings & co. more consistent. I completeley understand you are concentrated just on windmove keys. This is just a suggestion. I think windmove should have probably be named from the beginning as "windoperations", since it does more than just move corsor between windows. Shrinking and enlarging windows is definitely a useful window operation to beind on a key, in my opinion should have been in windmove.el since beginning. ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2021-05-25 11:36 ` Arthur Miller 2021-05-25 11:46 ` Philip Kaludercic @ 2021-05-25 19:13 ` Lars Ingebrigtsen 1 sibling, 0 replies; 838+ messages in thread From: Lars Ingebrigtsen @ 2021-05-25 19:13 UTC (permalink / raw) To: Arthur Miller; +Cc: 41438, Philip Kaludercic, Juri Linkov Arthur Miller <arthur.miller@live.com> writes: > If you are already patching windmove.el, can you consider adding > bindings for these funcitions too (defined in window.el): This seems unrelated to this current bug report, but you could open a new wishlist bug report for this. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2021-05-25 9:53 ` Philip Kaludercic 2021-05-25 11:16 ` Arthur Miller 2021-05-25 11:36 ` Arthur Miller @ 2021-05-25 19:16 ` Lars Ingebrigtsen 2021-05-25 19:25 ` Philip Kaludercic 2021-05-25 20:18 ` Juri Linkov 3 siblings, 1 reply; 838+ messages in thread From: Lars Ingebrigtsen @ 2021-05-25 19:16 UTC (permalink / raw) To: Philip Kaludercic; +Cc: 41438, Juri Linkov Philip Kaludercic <philipk@posteo.net> writes: > I have tried this out, and it seems somewhat elegant. From my testing, > it seems to behave the same way as the previous approach. Looks good to me. One minor thing: > +(defvar windmove-default-map (make-sparse-keymap) > + "Map used by `windmove-install-defaults'.") This should be called -mode-map. I don't actually use windmove -- could somebody else who's using this try this patch out and see whether it works well for them? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2021-05-25 19:16 ` Lars Ingebrigtsen @ 2021-05-25 19:25 ` Philip Kaludercic 0 siblings, 0 replies; 838+ messages in thread From: Philip Kaludercic @ 2021-05-25 19:25 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 41438, Juri Linkov [-- Attachment #1: Type: text/plain, Size: 684 bytes --] Lars Ingebrigtsen <larsi@gnus.org> writes: > Philip Kaludercic <philipk@posteo.net> writes: > >> I have tried this out, and it seems somewhat elegant. From my testing, >> it seems to behave the same way as the previous approach. > > Looks good to me. One minor thing: > >> +(defvar windmove-default-map (make-sparse-keymap) >> + "Map used by `windmove-install-defaults'.") > > This should be called -mode-map. Ok, the patch is below. I also added warning this time to net people know if automatically bound keys would conflict. > I don't actually use windmove -- could somebody else who's using this > try this patch out and see whether it works well for them? -- Philip K. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-Improve-windmove-default-keybindings-fuctions.patch --] [-- Type: text/x-diff, Size: 7733 bytes --] From d572168a4fce653dcded2c4ca54f324dca78e280 Mon Sep 17 00:00:00 2001 From: Philip Kaludercic <philipk@posteo.net> Date: Tue, 25 May 2021 11:47:51 +0200 Subject: [PATCH] Improve windmove-*-default-keybindings fuctions * windmove.el (windmove-mode-map): Add special map for windmove commands (windmove-mode): Add minor mode for activating windmove-mode-map (windmove-install-defaults): Add general function for manipulating windmove-mode-map (windmove-default-keybindings): Use windmove-install-defaults (windmove-display-default-keybindings): Use windmove-install-defaults (windmove-delete-default-keybindings): Use windmove-install-defaults (windmove-swap-states-default-keybindings): Use windmove-install-defaults --- lisp/windmove.el | 80 +++++++++++++++++++++++++++++++++++------------- 1 file changed, 59 insertions(+), 21 deletions(-) diff --git a/lisp/windmove.el b/lisp/windmove.el index e4ea8e0f69..479fdef512 100644 --- a/lisp/windmove.el +++ b/lisp/windmove.el @@ -426,19 +426,42 @@ windmove-down ;; I don't think these bindings will work on non-X terminals; you ;; probably want to use different bindings in that case. +(defvar windmove-mode-map (make-sparse-keymap) + "Map used by `windmove-install-defaults'.") + +(defun windmove-install-defaults (modifiers alist) + "Install keys as specified by ALIST. +Every element of ALIST has the form (FN KEY), where KEY is +appended to MODIFIERS, before installing the key. Previous +bindings of FN are unbound." + (dolist (bind alist) + (when (or (memq (cadr bind) '(left right up down)) + (not (null modifiers))) + (dolist (old (where-is-internal (car bind) windmove-mode-map)) + (define-key windmove-mode-map old nil)) + (let ((key (vector (append modifiers (cdr bind))))) + (let ((old-fn (lookup-key windmove-mode-map key))) + (when old-fn + (warn "Overriding %S with %S" old-fn (car bind)))) + (define-key windmove-mode-map key (car bind)))))) + ;;;###autoload (defun windmove-default-keybindings (&optional modifiers) "Set up keybindings for `windmove'. Keybindings are of the form MODIFIERS-{left,right,up,down}, where MODIFIERS is either a list of modifiers or a single modifier. +If MODIFIERS is `none', the keybindings will be directly bound to +the arrow keys. Default value of MODIFIERS is `shift'." (interactive) (unless modifiers (setq modifiers 'shift)) + (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) - (global-set-key (vector (append modifiers '(left))) 'windmove-left) - (global-set-key (vector (append modifiers '(right))) 'windmove-right) - (global-set-key (vector (append modifiers '(up))) 'windmove-up) - (global-set-key (vector (append modifiers '(down))) 'windmove-down)) + (windmove-install-defaults modifiers + '((windmove-left left) + (windmove-right right) + (windmove-up up) + (windmove-down down)))) \f ;;; Directional window display and selection @@ -546,17 +569,21 @@ windmove-display-default-keybindings Keys are bound to commands that display the next buffer in the specified direction. Keybindings are of the form MODIFIERS-{left,right,up,down}, where MODIFIERS is either a list of modifiers or a single modifier. +If MODIFIERS is `none', the keybindings will be directly bound to +the arrow keys. Default value of MODIFIERS is `shift-meta'." (interactive) (unless modifiers (setq modifiers '(shift meta))) + (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) - (global-set-key (vector (append modifiers '(left))) 'windmove-display-left) - (global-set-key (vector (append modifiers '(right))) 'windmove-display-right) - (global-set-key (vector (append modifiers '(up))) 'windmove-display-up) - (global-set-key (vector (append modifiers '(down))) 'windmove-display-down) - (global-set-key (vector (append modifiers '(?0))) 'windmove-display-same-window) - (global-set-key (vector (append modifiers '(?f))) 'windmove-display-new-frame) - (global-set-key (vector (append modifiers '(?t))) 'windmove-display-new-tab)) + (windmove-install-defaults modifiers + '((windmove-display-left left) + (windmove-display-right right) + (windmove-display-up up) + (windmove-display-down down) + (windmove-display-same-window ?0) + (windmove-display-new-frame ?f) + (windmove-display-new-tab ?t)))) \f ;;; Directional window deletion @@ -618,16 +645,22 @@ windmove-delete-default-keybindings Keys are bound to commands that delete windows in the specified direction. Keybindings are of the form PREFIX MODIFIERS-{left,right,up,down}, where PREFIX is a prefix key and MODIFIERS is either a list of modifiers or -a single modifier. Default value of PREFIX is `C-x' and MODIFIERS is `shift'." +a single modifier. +If PREFIX is `none', no prefix is used. If MODIFIERS is `none', the keybindings +are directly bound to the arrow keys. +Default value of PREFIX is `C-x' and MODIFIERS is `shift'." (interactive) (unless prefix (setq prefix '(?\C-x))) + (when (eq prefix 'none) (setq prefix nil)) (unless (listp prefix) (setq prefix (list prefix))) (unless modifiers (setq modifiers '(shift))) + (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) - (global-set-key (vector prefix (append modifiers '(left))) 'windmove-delete-left) - (global-set-key (vector prefix (append modifiers '(right))) 'windmove-delete-right) - (global-set-key (vector prefix (append modifiers '(up))) 'windmove-delete-up) - (global-set-key (vector prefix (append modifiers '(down))) 'windmove-delete-down)) + (windmove-install-defaults modifiers + '((windmove-delete-left left) + (windmove-delete-right right) + (windmove-delete-up up) + (windmove-delete-down down)))) \f ;;; Directional window swap states @@ -673,14 +706,19 @@ windmove-swap-states-default-keybindings Keys are bound to commands that swap the states of the selected window with the window in the specified direction. Keybindings are of the form MODIFIERS-{left,right,up,down}, where MODIFIERS is either a list of modifiers -or a single modifier. Default value of MODIFIERS is `shift-super'." +or a single modifier. +If MODIFIERS is `none', the keybindings will be directly bound to the +arrow keys. +Default value of MODIFIERS is `shift-super'." (interactive) (unless modifiers (setq modifiers '(shift super))) + (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) - (global-set-key (vector (append modifiers '(left))) 'windmove-swap-states-left) - (global-set-key (vector (append modifiers '(right))) 'windmove-swap-states-right) - (global-set-key (vector (append modifiers '(up))) 'windmove-swap-states-up) - (global-set-key (vector (append modifiers '(down))) 'windmove-swap-states-down)) + (windmove-install-defaults modifiers + '((windmove-swap-states-left left) + (windmove-swap-states-right right) + (windmove-swap-states-up up) + (windmove-swap-states-down down)))) \f (provide 'windmove) -- 2.30.2 ^ permalink raw reply related [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2021-05-25 9:53 ` Philip Kaludercic ` (2 preceding siblings ...) 2021-05-25 19:16 ` Lars Ingebrigtsen @ 2021-05-25 20:18 ` Juri Linkov 2021-05-25 21:45 ` Philip Kaludercic 3 siblings, 1 reply; 838+ messages in thread From: Juri Linkov @ 2021-05-25 20:18 UTC (permalink / raw) To: Philip Kaludercic; +Cc: 41438, Lars Ingebrigtsen > - (global-set-key (vector prefix (append modifiers '(left))) 'windmove-delete-left) > - (global-set-key (vector prefix (append modifiers '(right))) 'windmove-delete-right) > - (global-set-key (vector prefix (append modifiers '(up))) 'windmove-delete-up) > - (global-set-key (vector prefix (append modifiers '(down))) 'windmove-delete-down)) > + (windmove-install-defaults modifiers > + '((windmove-delete-left left) > + (windmove-delete-right right) > + (windmove-delete-up up) > + (windmove-delete-down down)))) I haven't yet tested your patch, but after reading it seems 'prefix' is unused now? ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2021-05-25 20:18 ` Juri Linkov @ 2021-05-25 21:45 ` Philip Kaludercic 2021-05-26 21:35 ` Juri Linkov 0 siblings, 1 reply; 838+ messages in thread From: Philip Kaludercic @ 2021-05-25 21:45 UTC (permalink / raw) To: Juri Linkov; +Cc: 41438, Lars Ingebrigtsen [-- Attachment #1: Type: text/plain, Size: 1177 bytes --] Juri Linkov <juri@linkov.net> writes: >> - (global-set-key (vector prefix (append modifiers '(left))) 'windmove-delete-left) >> - (global-set-key (vector prefix (append modifiers '(right))) 'windmove-delete-right) >> - (global-set-key (vector prefix (append modifiers '(up))) 'windmove-delete-up) >> - (global-set-key (vector prefix (append modifiers '(down))) 'windmove-delete-down)) >> + (windmove-install-defaults modifiers >> + '((windmove-delete-left left) >> + (windmove-delete-right right) >> + (windmove-delete-up up) >> + (windmove-delete-down down)))) > > I haven't yet tested your patch, but after reading it seems 'prefix' is unused now? You are right, I didn't test that specific function properly. windmove-install-defaults had to be extended by another argument to fix this. What I don't really like is that only windmove-delete-default-keybindings can make use of prefixes, while all commands only use modifiers. Could it make sense to deprecate these functions in favour of either new functions or user-options? -- Philip K. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-Improve-windmove-default-keybindings-fuctions.patch --] [-- Type: text/x-diff, Size: 8010 bytes --] From ecbed85db9622ef5b1680472273163cb7789ae3f Mon Sep 17 00:00:00 2001 From: Philip Kaludercic <philipk@posteo.net> Date: Tue, 25 May 2021 11:47:51 +0200 Subject: [PATCH] Improve windmove-*-default-keybindings fuctions * windmove.el (windmove-mode-map): Add special map for windmove commands (windmove-mode): Add minor mode for activating windmove-mode-map (windmove-install-defaults): Add general function for manipulating windmove-mode-map (windmove-default-keybindings): Use windmove-install-defaults (windmove-display-default-keybindings): Use windmove-install-defaults (windmove-delete-default-keybindings): Use windmove-install-defaults (windmove-swap-states-default-keybindings): Use windmove-install-defaults --- lisp/windmove.el | 87 ++++++++++++++++++++++++++++++++++++------------ 1 file changed, 66 insertions(+), 21 deletions(-) diff --git a/lisp/windmove.el b/lisp/windmove.el index e4ea8e0f69..d7c1d25d82 100644 --- a/lisp/windmove.el +++ b/lisp/windmove.el @@ -426,19 +426,49 @@ windmove-down ;; I don't think these bindings will work on non-X terminals; you ;; probably want to use different bindings in that case. +(defvar windmove-mode-map (make-sparse-keymap) + "Map used by `windmove-install-defaults'.") + +(define-minor-mode windmove-mode + "Global minor mode for default windmove commands." + :keymap windmove-mode-map + :init-value t + :global t) + +(defun windmove-install-defaults (prefix modifiers alist) + "Install keys as specified by ALIST. +Every element of ALIST has the form (FN KEY), where KEY is +appended to MODIFIERS, adding PREFIX to the beginning, before +installing the key. Previous bindings of FN are unbound." + (dolist (bind alist) + (when (or (memq (cadr bind) '(left right up down)) + (not (null modifiers))) + (dolist (old (where-is-internal (car bind) windmove-mode-map)) + (define-key windmove-mode-map old nil)) + (let ((key (vconcat (if (eq prefix 'none) nil prefix) + (list (append modifiers (cdr bind)))))) + (let ((old-fn (lookup-key windmove-mode-map key))) + (when old-fn + (warn "Overriding %S with %S" old-fn (car bind)))) + (define-key windmove-mode-map key (car bind)))))) + ;;;###autoload (defun windmove-default-keybindings (&optional modifiers) "Set up keybindings for `windmove'. Keybindings are of the form MODIFIERS-{left,right,up,down}, where MODIFIERS is either a list of modifiers or a single modifier. +If MODIFIERS is `none', the keybindings will be directly bound to +the arrow keys. Default value of MODIFIERS is `shift'." (interactive) (unless modifiers (setq modifiers 'shift)) + (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) - (global-set-key (vector (append modifiers '(left))) 'windmove-left) - (global-set-key (vector (append modifiers '(right))) 'windmove-right) - (global-set-key (vector (append modifiers '(up))) 'windmove-up) - (global-set-key (vector (append modifiers '(down))) 'windmove-down)) + (windmove-install-defaults nil modifiers + '((windmove-left left) + (windmove-right right) + (windmove-up up) + (windmove-down down)))) \f ;;; Directional window display and selection @@ -546,17 +576,21 @@ windmove-display-default-keybindings Keys are bound to commands that display the next buffer in the specified direction. Keybindings are of the form MODIFIERS-{left,right,up,down}, where MODIFIERS is either a list of modifiers or a single modifier. +If MODIFIERS is `none', the keybindings will be directly bound to +the arrow keys. Default value of MODIFIERS is `shift-meta'." (interactive) (unless modifiers (setq modifiers '(shift meta))) + (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) - (global-set-key (vector (append modifiers '(left))) 'windmove-display-left) - (global-set-key (vector (append modifiers '(right))) 'windmove-display-right) - (global-set-key (vector (append modifiers '(up))) 'windmove-display-up) - (global-set-key (vector (append modifiers '(down))) 'windmove-display-down) - (global-set-key (vector (append modifiers '(?0))) 'windmove-display-same-window) - (global-set-key (vector (append modifiers '(?f))) 'windmove-display-new-frame) - (global-set-key (vector (append modifiers '(?t))) 'windmove-display-new-tab)) + (windmove-install-defaults nil modifiers + '((windmove-display-left left) + (windmove-display-right right) + (windmove-display-up up) + (windmove-display-down down) + (windmove-display-same-window ?0) + (windmove-display-new-frame ?f) + (windmove-display-new-tab ?t)))) \f ;;; Directional window deletion @@ -618,16 +652,22 @@ windmove-delete-default-keybindings Keys are bound to commands that delete windows in the specified direction. Keybindings are of the form PREFIX MODIFIERS-{left,right,up,down}, where PREFIX is a prefix key and MODIFIERS is either a list of modifiers or -a single modifier. Default value of PREFIX is `C-x' and MODIFIERS is `shift'." +a single modifier. +If PREFIX is `none', no prefix is used. If MODIFIERS is `none', the keybindings +are directly bound to the arrow keys. +Default value of PREFIX is `C-x' and MODIFIERS is `shift'." (interactive) (unless prefix (setq prefix '(?\C-x))) + (when (eq prefix 'none) (setq prefix nil)) (unless (listp prefix) (setq prefix (list prefix))) (unless modifiers (setq modifiers '(shift))) + (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) - (global-set-key (vector prefix (append modifiers '(left))) 'windmove-delete-left) - (global-set-key (vector prefix (append modifiers '(right))) 'windmove-delete-right) - (global-set-key (vector prefix (append modifiers '(up))) 'windmove-delete-up) - (global-set-key (vector prefix (append modifiers '(down))) 'windmove-delete-down)) + (windmove-install-defaults prefix modifiers + '((windmove-delete-left left) + (windmove-delete-right right) + (windmove-delete-up up) + (windmove-delete-down down)))) \f ;;; Directional window swap states @@ -673,14 +713,19 @@ windmove-swap-states-default-keybindings Keys are bound to commands that swap the states of the selected window with the window in the specified direction. Keybindings are of the form MODIFIERS-{left,right,up,down}, where MODIFIERS is either a list of modifiers -or a single modifier. Default value of MODIFIERS is `shift-super'." +or a single modifier. +If MODIFIERS is `none', the keybindings will be directly bound to the +arrow keys. +Default value of MODIFIERS is `shift-super'." (interactive) (unless modifiers (setq modifiers '(shift super))) + (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) - (global-set-key (vector (append modifiers '(left))) 'windmove-swap-states-left) - (global-set-key (vector (append modifiers '(right))) 'windmove-swap-states-right) - (global-set-key (vector (append modifiers '(up))) 'windmove-swap-states-up) - (global-set-key (vector (append modifiers '(down))) 'windmove-swap-states-down)) + (windmove-install-defaults nil modifiers + '((windmove-swap-states-left left) + (windmove-swap-states-right right) + (windmove-swap-states-up up) + (windmove-swap-states-down down)))) \f (provide 'windmove) -- 2.30.2 ^ permalink raw reply related [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2021-05-25 21:45 ` Philip Kaludercic @ 2021-05-26 21:35 ` Juri Linkov 2021-05-27 11:09 ` Philip Kaludercic 0 siblings, 1 reply; 838+ messages in thread From: Juri Linkov @ 2021-05-26 21:35 UTC (permalink / raw) To: Philip Kaludercic; +Cc: 41438, Lars Ingebrigtsen > What I don't really like is that only > windmove-delete-default-keybindings can make use of prefixes, while all > commands only use modifiers. Could it make sense to deprecate these > functions in favour of either new functions or user-options? Maybe it's possible to add new user options without deprecating the existing functions? Then for users an alternative way would be to customize these options, and enable windmove-mode in the init file. Or maybe there will be a need to create separate modes for every keymap, e.g. windmove-display-mode, windmove-delete-mode? ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2021-05-26 21:35 ` Juri Linkov @ 2021-05-27 11:09 ` Philip Kaludercic 2021-05-30 22:11 ` Juri Linkov 0 siblings, 1 reply; 838+ messages in thread From: Philip Kaludercic @ 2021-05-27 11:09 UTC (permalink / raw) To: Juri Linkov; +Cc: 41438, Lars Ingebrigtsen [-- Attachment #1: Type: text/plain, Size: 822 bytes --] Juri Linkov <juri@linkov.net> writes: >> What I don't really like is that only >> windmove-delete-default-keybindings can make use of prefixes, while all >> commands only use modifiers. Could it make sense to deprecate these >> functions in favour of either new functions or user-options? > > Maybe it's possible to add new user options without deprecating the > existing functions? Then for users an alternative way would be to > customize these options, and enable windmove-mode in the init file. Of course, why not? The patches below should implement that. > Or maybe there will be a need to create separate modes for every > keymap, e.g. windmove-display-mode, windmove-delete-mode? I don't see why that should be necessary, as the proposed windmove-mode doesn't even have the interest the user. -- Philip K. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-Improve-windmove-default-keybindings-fuctions.patch --] [-- Type: text/x-diff, Size: 8244 bytes --] From 42a66e87af83817b9e989624fdbf9c7ee7c347c7 Mon Sep 17 00:00:00 2001 From: Philip Kaludercic <philipk@posteo.net> Date: Tue, 25 May 2021 11:47:51 +0200 Subject: [PATCH 1/2] Improve windmove-*-default-keybindings fuctions * windmove.el (windmove-mode-map): Add special map for windmove commands (windmove-mode): Add minor mode for activating windmove-mode-map (windmove-install-defaults): Add general function for manipulating windmove-mode-map (windmove-default-keybindings): Use windmove-install-defaults (windmove-display-default-keybindings): Use windmove-install-defaults (windmove-delete-default-keybindings): Use windmove-install-defaults (windmove-swap-states-default-keybindings): Use windmove-install-defaults --- lisp/windmove.el | 91 +++++++++++++++++++++++++++++++++++++----------- 1 file changed, 70 insertions(+), 21 deletions(-) diff --git a/lisp/windmove.el b/lisp/windmove.el index e4ea8e0f69..cd8592f341 100644 --- a/lisp/windmove.el +++ b/lisp/windmove.el @@ -426,19 +426,53 @@ windmove-down ;; I don't think these bindings will work on non-X terminals; you ;; probably want to use different bindings in that case. +(defvar windmove-mode-map (make-sparse-keymap) + "Map used by `windmove-install-defaults'.") + +(define-minor-mode windmove-mode + "Global minor mode for default windmove commands." + :keymap windmove-mode-map + :init-value t + :global t) + +(defun windmove-install-defaults (prefix modifiers alist &optional uninstall) + "Install keys as specified by ALIST. +Every element of ALIST has the form (FN KEY), where KEY is +appended to MODIFIERS, adding PREFIX to the beginning, before +installing the key. Previous bindings of FN are unbound. +If UNINSTALL is non-nil, just remove the keys from ALIST." + (dolist (bind alist) + (dolist (old (where-is-internal (car bind) windmove-mode-map)) + (define-key windmove-mode-map old nil)) + (unless uninstall + (let ((key (vconcat (if (or (equal prefix [ignore]) + (eq prefix 'none)) + nil prefix) + (list (append modifiers (cdr bind)))))) + (when (eq (key-binding key) #'self-insert-command) + (warn "Command %S is shadowing self-insert-key" (car bind))) + (let ((old-fn (lookup-key windmove-mode-map key))) + (when old-fn + (warn "Overriding %S with %S" old-fn (car bind)))) + (define-key windmove-mode-map key (car bind)))))) + ;;;###autoload (defun windmove-default-keybindings (&optional modifiers) "Set up keybindings for `windmove'. Keybindings are of the form MODIFIERS-{left,right,up,down}, where MODIFIERS is either a list of modifiers or a single modifier. +If MODIFIERS is `none', the keybindings will be directly bound to +the arrow keys. Default value of MODIFIERS is `shift'." (interactive) (unless modifiers (setq modifiers 'shift)) + (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) - (global-set-key (vector (append modifiers '(left))) 'windmove-left) - (global-set-key (vector (append modifiers '(right))) 'windmove-right) - (global-set-key (vector (append modifiers '(up))) 'windmove-up) - (global-set-key (vector (append modifiers '(down))) 'windmove-down)) + (windmove-install-defaults nil modifiers + '((windmove-left left) + (windmove-right right) + (windmove-up up) + (windmove-down down)))) \f ;;; Directional window display and selection @@ -546,17 +580,21 @@ windmove-display-default-keybindings Keys are bound to commands that display the next buffer in the specified direction. Keybindings are of the form MODIFIERS-{left,right,up,down}, where MODIFIERS is either a list of modifiers or a single modifier. +If MODIFIERS is `none', the keybindings will be directly bound to +the arrow keys. Default value of MODIFIERS is `shift-meta'." (interactive) (unless modifiers (setq modifiers '(shift meta))) + (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) - (global-set-key (vector (append modifiers '(left))) 'windmove-display-left) - (global-set-key (vector (append modifiers '(right))) 'windmove-display-right) - (global-set-key (vector (append modifiers '(up))) 'windmove-display-up) - (global-set-key (vector (append modifiers '(down))) 'windmove-display-down) - (global-set-key (vector (append modifiers '(?0))) 'windmove-display-same-window) - (global-set-key (vector (append modifiers '(?f))) 'windmove-display-new-frame) - (global-set-key (vector (append modifiers '(?t))) 'windmove-display-new-tab)) + (windmove-install-defaults nil modifiers + '((windmove-display-left left) + (windmove-display-right right) + (windmove-display-up up) + (windmove-display-down down) + (windmove-display-same-window ?0) + (windmove-display-new-frame ?f) + (windmove-display-new-tab ?t)))) \f ;;; Directional window deletion @@ -618,16 +656,22 @@ windmove-delete-default-keybindings Keys are bound to commands that delete windows in the specified direction. Keybindings are of the form PREFIX MODIFIERS-{left,right,up,down}, where PREFIX is a prefix key and MODIFIERS is either a list of modifiers or -a single modifier. Default value of PREFIX is `C-x' and MODIFIERS is `shift'." +a single modifier. +If PREFIX is `none', no prefix is used. If MODIFIERS is `none', the keybindings +are directly bound to the arrow keys. +Default value of PREFIX is `C-x' and MODIFIERS is `shift'." (interactive) (unless prefix (setq prefix '(?\C-x))) + (when (eq prefix 'none) (setq prefix nil)) (unless (listp prefix) (setq prefix (list prefix))) (unless modifiers (setq modifiers '(shift))) + (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) - (global-set-key (vector prefix (append modifiers '(left))) 'windmove-delete-left) - (global-set-key (vector prefix (append modifiers '(right))) 'windmove-delete-right) - (global-set-key (vector prefix (append modifiers '(up))) 'windmove-delete-up) - (global-set-key (vector prefix (append modifiers '(down))) 'windmove-delete-down)) + (windmove-install-defaults prefix modifiers + '((windmove-delete-left left) + (windmove-delete-right right) + (windmove-delete-up up) + (windmove-delete-down down)))) \f ;;; Directional window swap states @@ -673,14 +717,19 @@ windmove-swap-states-default-keybindings Keys are bound to commands that swap the states of the selected window with the window in the specified direction. Keybindings are of the form MODIFIERS-{left,right,up,down}, where MODIFIERS is either a list of modifiers -or a single modifier. Default value of MODIFIERS is `shift-super'." +or a single modifier. +If MODIFIERS is `none', the keybindings will be directly bound to the +arrow keys. +Default value of MODIFIERS is `shift-super'." (interactive) (unless modifiers (setq modifiers '(shift super))) + (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) - (global-set-key (vector (append modifiers '(left))) 'windmove-swap-states-left) - (global-set-key (vector (append modifiers '(right))) 'windmove-swap-states-right) - (global-set-key (vector (append modifiers '(up))) 'windmove-swap-states-up) - (global-set-key (vector (append modifiers '(down))) 'windmove-swap-states-down)) + (windmove-install-defaults nil modifiers + '((windmove-swap-states-left left) + (windmove-swap-states-right right) + (windmove-swap-states-up up) + (windmove-swap-states-down down)))) \f (provide 'windmove) -- 2.30.2 [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #3: 0002-Add-user-options-for-default-windmove-commands.patch --] [-- Type: text/x-diff, Size: 3780 bytes --] From 21a8a8854249d24d62d4dd8e17c1f1d20de04fd6 Mon Sep 17 00:00:00 2001 From: Philip Kaludercic <philipk@posteo.net> Date: Thu, 27 May 2021 12:24:42 +0200 Subject: [PATCH 2/2] Add user options for default windmove commands * windmove.el (windmove--default-keybindings-type): Add type (windmove-default-keybindings): Add user option (windmove-display-default-keybindings): Add user option (windmove-delete-default-keybindings): Add user option (windmove-swap-states-default-keybindings): Add user option --- lisp/windmove.el | 80 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 80 insertions(+) diff --git a/lisp/windmove.el b/lisp/windmove.el index cd8592f341..488962c063 100644 --- a/lisp/windmove.el +++ b/lisp/windmove.el @@ -731,6 +731,86 @@ windmove-swap-states-default-keybindings (windmove-swap-states-up up) (windmove-swap-states-down down)))) +\f + +(defconst windmove--default-keybindings-type + `(choice (const :tag "Don't bind" nil) + (cons :tag "Bind using" + (key-sequence :tag "Prefix") + (set :tag "Modifier" + :greedy t + ;; See `(elisp) Keyboard Events' + (const :tag "Meta" meta) + (const :tag "Control" control) + (const :tag "Shift" shift) + (const :tag "Hyper" hyper) + (const :tag "Super" super) + (const :tag "Alt" alt)))) + "Customisation type for windmove modifiers.") + +(defcustom windmove-default-keybindings nil + "Default bindings for regular windmove commands." + :set (lambda (sym val) + (windmove-install-defaults + (car val) (cdr val) + '((windmove-left left) + (windmove-right right) + (windmove-up up) + (windmove-down down)) + (null val)) + (set-default sym val)) + :type windmove--default-keybindings-type + :version "28.1" + :group 'windmove) + +(defcustom windmove-display-default-keybindings nil + "Default bindings for display windmove commands." + :set (lambda (sym val) + (windmove-install-defaults + (car val) (cdr val) + '((windmove-display-left left) + (windmove-display-right right) + (windmove-display-up up) + (windmove-display-down down) + (windmove-display-same-window ?0) + (windmove-display-new-frame ?f) + (windmove-display-new-tab ?t)) + (null val)) + (set-default sym val)) + :type windmove--default-keybindings-type + :version "28.1" + :group 'windmove) + +(defcustom windmove-delete-default-keybindings nil + "Default bindings for delete windmove commands." + :set (lambda (sym val) + (windmove-install-defaults + (car val) (cdr val) + '((windmove-delete-left left) + (windmove-delete-right right) + (windmove-delete-up up) + (windmove-delete-down down)) + (null val)) + (set-default sym val)) + :type windmove--default-keybindings-type + :version "28.1" + :group 'windmove) + +(defcustom windmove-swap-states-default-keybindings nil + "Default bindings for swap-state windmove commands." + :set (lambda (sym val) + (windmove-install-defaults + (car val) (cdr val) + '((windmove-swap-states-left left) + (windmove-swap-states-right right) + (windmove-swap-states-up up) + (windmove-swap-states-down down)) + (null val)) + (set-default sym val)) + :type windmove--default-keybindings-type + :version "28.1" + :group 'windmove) + \f (provide 'windmove) -- 2.30.2 ^ permalink raw reply related [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2021-05-27 11:09 ` Philip Kaludercic @ 2021-05-30 22:11 ` Juri Linkov 2021-05-31 8:50 ` Philip Kaludercic 0 siblings, 1 reply; 838+ messages in thread From: Juri Linkov @ 2021-05-30 22:11 UTC (permalink / raw) To: Philip Kaludercic; +Cc: 41438, Lars Ingebrigtsen >> Maybe it's possible to add new user options without deprecating the >> existing functions? Then for users an alternative way would be to >> customize these options, and enable windmove-mode in the init file. > > Of course, why not? The patches below should implement that. Thanks, I tried out your patches. The customization saved them in such format: '(windmove-default-keybindings '([ignore] hyper)) '(windmove-delete-default-keybindings '("\30" hyper)) '(windmove-display-default-keybindings '([ignore] meta hyper)) '(windmove-swap-states-default-keybindings '([ignore] shift hyper)) But I guess it's not a problem that it saves nil as [ignore]. The real problem is that after replacing this with a manual configuration: (use-package windmove :custom (windmove-default-keybindings '(nil hyper)) (windmove-delete-default-keybindings `(,(kbd "C-x") hyper)) (windmove-display-default-keybindings '(nil meta hyper)) (windmove-swap-states-default-keybindings '(nil shift hyper))) Then every startup pops up the *Warnings* buffer with: Warning (emacs): Overriding 1 with windmove-delete-left [Disable showing] [Disable logging] But still all keybindings work correctly. ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2021-05-30 22:11 ` Juri Linkov @ 2021-05-31 8:50 ` Philip Kaludercic 2021-05-31 20:15 ` Juri Linkov 0 siblings, 1 reply; 838+ messages in thread From: Philip Kaludercic @ 2021-05-31 8:50 UTC (permalink / raw) To: Juri Linkov; +Cc: 41438, Lars Ingebrigtsen [-- Attachment #1: Type: text/plain, Size: 1891 bytes --] Juri Linkov <juri@linkov.net> writes: >>> Maybe it's possible to add new user options without deprecating the >>> existing functions? Then for users an alternative way would be to >>> customize these options, and enable windmove-mode in the init file. >> >> Of course, why not? The patches below should implement that. > > Thanks, I tried out your patches. The customization saved them > in such format: > > '(windmove-default-keybindings '([ignore] hyper)) > '(windmove-delete-default-keybindings '("\30" hyper)) > '(windmove-display-default-keybindings '([ignore] meta hyper)) > '(windmove-swap-states-default-keybindings '([ignore] shift hyper)) > > But I guess it's not a problem that it saves nil as [ignore]. > > The real problem is that after replacing this with a manual configuration: > > (use-package windmove > :custom > (windmove-default-keybindings '(nil hyper)) > (windmove-delete-default-keybindings `(,(kbd "C-x") hyper)) > (windmove-display-default-keybindings '(nil meta hyper)) > (windmove-swap-states-default-keybindings '(nil shift hyper))) > > Then every startup pops up the *Warnings* buffer with: > > Warning (emacs): Overriding 1 with windmove-delete-left [Disable showing] [Disable logging] > > But still all keybindings work correctly. I was under the impression that this was fixed, but it turns out I did not read the lookup-key doc string carefully enough: A number as value means KEY is "too long"; that is, characters or symbols in it except for the last one fail to be a valid sequence of prefix characters in KEYMAP. The number is how many characters at the front of KEY it takes to reach a non-prefix key. But this case can be safely ignored, as define-key will take care of the prefix. To solve this, the warning is only trigged when a function is over-riden. -- Philip K. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-Improve-windmove-default-keybindings-fuctions.patch --] [-- Type: text/x-diff, Size: 8244 bytes --] From 42a66e87af83817b9e989624fdbf9c7ee7c347c7 Mon Sep 17 00:00:00 2001 From: Philip Kaludercic <philipk@posteo.net> Date: Tue, 25 May 2021 11:47:51 +0200 Subject: [PATCH 1/2] Improve windmove-*-default-keybindings fuctions * windmove.el (windmove-mode-map): Add special map for windmove commands (windmove-mode): Add minor mode for activating windmove-mode-map (windmove-install-defaults): Add general function for manipulating windmove-mode-map (windmove-default-keybindings): Use windmove-install-defaults (windmove-display-default-keybindings): Use windmove-install-defaults (windmove-delete-default-keybindings): Use windmove-install-defaults (windmove-swap-states-default-keybindings): Use windmove-install-defaults --- lisp/windmove.el | 91 +++++++++++++++++++++++++++++++++++++----------- 1 file changed, 70 insertions(+), 21 deletions(-) diff --git a/lisp/windmove.el b/lisp/windmove.el index e4ea8e0f69..cd8592f341 100644 --- a/lisp/windmove.el +++ b/lisp/windmove.el @@ -426,19 +426,53 @@ windmove-down ;; I don't think these bindings will work on non-X terminals; you ;; probably want to use different bindings in that case. +(defvar windmove-mode-map (make-sparse-keymap) + "Map used by `windmove-install-defaults'.") + +(define-minor-mode windmove-mode + "Global minor mode for default windmove commands." + :keymap windmove-mode-map + :init-value t + :global t) + +(defun windmove-install-defaults (prefix modifiers alist &optional uninstall) + "Install keys as specified by ALIST. +Every element of ALIST has the form (FN KEY), where KEY is +appended to MODIFIERS, adding PREFIX to the beginning, before +installing the key. Previous bindings of FN are unbound. +If UNINSTALL is non-nil, just remove the keys from ALIST." + (dolist (bind alist) + (dolist (old (where-is-internal (car bind) windmove-mode-map)) + (define-key windmove-mode-map old nil)) + (unless uninstall + (let ((key (vconcat (if (or (equal prefix [ignore]) + (eq prefix 'none)) + nil prefix) + (list (append modifiers (cdr bind)))))) + (when (eq (key-binding key) #'self-insert-command) + (warn "Command %S is shadowing self-insert-key" (car bind))) + (let ((old-fn (lookup-key windmove-mode-map key))) + (when old-fn + (warn "Overriding %S with %S" old-fn (car bind)))) + (define-key windmove-mode-map key (car bind)))))) + ;;;###autoload (defun windmove-default-keybindings (&optional modifiers) "Set up keybindings for `windmove'. Keybindings are of the form MODIFIERS-{left,right,up,down}, where MODIFIERS is either a list of modifiers or a single modifier. +If MODIFIERS is `none', the keybindings will be directly bound to +the arrow keys. Default value of MODIFIERS is `shift'." (interactive) (unless modifiers (setq modifiers 'shift)) + (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) - (global-set-key (vector (append modifiers '(left))) 'windmove-left) - (global-set-key (vector (append modifiers '(right))) 'windmove-right) - (global-set-key (vector (append modifiers '(up))) 'windmove-up) - (global-set-key (vector (append modifiers '(down))) 'windmove-down)) + (windmove-install-defaults nil modifiers + '((windmove-left left) + (windmove-right right) + (windmove-up up) + (windmove-down down)))) \f ;;; Directional window display and selection @@ -546,17 +580,21 @@ windmove-display-default-keybindings Keys are bound to commands that display the next buffer in the specified direction. Keybindings are of the form MODIFIERS-{left,right,up,down}, where MODIFIERS is either a list of modifiers or a single modifier. +If MODIFIERS is `none', the keybindings will be directly bound to +the arrow keys. Default value of MODIFIERS is `shift-meta'." (interactive) (unless modifiers (setq modifiers '(shift meta))) + (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) - (global-set-key (vector (append modifiers '(left))) 'windmove-display-left) - (global-set-key (vector (append modifiers '(right))) 'windmove-display-right) - (global-set-key (vector (append modifiers '(up))) 'windmove-display-up) - (global-set-key (vector (append modifiers '(down))) 'windmove-display-down) - (global-set-key (vector (append modifiers '(?0))) 'windmove-display-same-window) - (global-set-key (vector (append modifiers '(?f))) 'windmove-display-new-frame) - (global-set-key (vector (append modifiers '(?t))) 'windmove-display-new-tab)) + (windmove-install-defaults nil modifiers + '((windmove-display-left left) + (windmove-display-right right) + (windmove-display-up up) + (windmove-display-down down) + (windmove-display-same-window ?0) + (windmove-display-new-frame ?f) + (windmove-display-new-tab ?t)))) \f ;;; Directional window deletion @@ -618,16 +656,22 @@ windmove-delete-default-keybindings Keys are bound to commands that delete windows in the specified direction. Keybindings are of the form PREFIX MODIFIERS-{left,right,up,down}, where PREFIX is a prefix key and MODIFIERS is either a list of modifiers or -a single modifier. Default value of PREFIX is `C-x' and MODIFIERS is `shift'." +a single modifier. +If PREFIX is `none', no prefix is used. If MODIFIERS is `none', the keybindings +are directly bound to the arrow keys. +Default value of PREFIX is `C-x' and MODIFIERS is `shift'." (interactive) (unless prefix (setq prefix '(?\C-x))) + (when (eq prefix 'none) (setq prefix nil)) (unless (listp prefix) (setq prefix (list prefix))) (unless modifiers (setq modifiers '(shift))) + (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) - (global-set-key (vector prefix (append modifiers '(left))) 'windmove-delete-left) - (global-set-key (vector prefix (append modifiers '(right))) 'windmove-delete-right) - (global-set-key (vector prefix (append modifiers '(up))) 'windmove-delete-up) - (global-set-key (vector prefix (append modifiers '(down))) 'windmove-delete-down)) + (windmove-install-defaults prefix modifiers + '((windmove-delete-left left) + (windmove-delete-right right) + (windmove-delete-up up) + (windmove-delete-down down)))) \f ;;; Directional window swap states @@ -673,14 +717,19 @@ windmove-swap-states-default-keybindings Keys are bound to commands that swap the states of the selected window with the window in the specified direction. Keybindings are of the form MODIFIERS-{left,right,up,down}, where MODIFIERS is either a list of modifiers -or a single modifier. Default value of MODIFIERS is `shift-super'." +or a single modifier. +If MODIFIERS is `none', the keybindings will be directly bound to the +arrow keys. +Default value of MODIFIERS is `shift-super'." (interactive) (unless modifiers (setq modifiers '(shift super))) + (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) - (global-set-key (vector (append modifiers '(left))) 'windmove-swap-states-left) - (global-set-key (vector (append modifiers '(right))) 'windmove-swap-states-right) - (global-set-key (vector (append modifiers '(up))) 'windmove-swap-states-up) - (global-set-key (vector (append modifiers '(down))) 'windmove-swap-states-down)) + (windmove-install-defaults nil modifiers + '((windmove-swap-states-left left) + (windmove-swap-states-right right) + (windmove-swap-states-up up) + (windmove-swap-states-down down)))) \f (provide 'windmove) -- 2.30.2 [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #3: 0002-Add-user-options-for-default-windmove-commands.patch --] [-- Type: text/x-diff, Size: 3780 bytes --] From 21a8a8854249d24d62d4dd8e17c1f1d20de04fd6 Mon Sep 17 00:00:00 2001 From: Philip Kaludercic <philipk@posteo.net> Date: Thu, 27 May 2021 12:24:42 +0200 Subject: [PATCH 2/2] Add user options for default windmove commands * windmove.el (windmove--default-keybindings-type): Add type (windmove-default-keybindings): Add user option (windmove-display-default-keybindings): Add user option (windmove-delete-default-keybindings): Add user option (windmove-swap-states-default-keybindings): Add user option --- lisp/windmove.el | 80 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 80 insertions(+) diff --git a/lisp/windmove.el b/lisp/windmove.el index cd8592f341..488962c063 100644 --- a/lisp/windmove.el +++ b/lisp/windmove.el @@ -731,6 +731,86 @@ windmove-swap-states-default-keybindings (windmove-swap-states-up up) (windmove-swap-states-down down)))) +\f + +(defconst windmove--default-keybindings-type + `(choice (const :tag "Don't bind" nil) + (cons :tag "Bind using" + (key-sequence :tag "Prefix") + (set :tag "Modifier" + :greedy t + ;; See `(elisp) Keyboard Events' + (const :tag "Meta" meta) + (const :tag "Control" control) + (const :tag "Shift" shift) + (const :tag "Hyper" hyper) + (const :tag "Super" super) + (const :tag "Alt" alt)))) + "Customisation type for windmove modifiers.") + +(defcustom windmove-default-keybindings nil + "Default bindings for regular windmove commands." + :set (lambda (sym val) + (windmove-install-defaults + (car val) (cdr val) + '((windmove-left left) + (windmove-right right) + (windmove-up up) + (windmove-down down)) + (null val)) + (set-default sym val)) + :type windmove--default-keybindings-type + :version "28.1" + :group 'windmove) + +(defcustom windmove-display-default-keybindings nil + "Default bindings for display windmove commands." + :set (lambda (sym val) + (windmove-install-defaults + (car val) (cdr val) + '((windmove-display-left left) + (windmove-display-right right) + (windmove-display-up up) + (windmove-display-down down) + (windmove-display-same-window ?0) + (windmove-display-new-frame ?f) + (windmove-display-new-tab ?t)) + (null val)) + (set-default sym val)) + :type windmove--default-keybindings-type + :version "28.1" + :group 'windmove) + +(defcustom windmove-delete-default-keybindings nil + "Default bindings for delete windmove commands." + :set (lambda (sym val) + (windmove-install-defaults + (car val) (cdr val) + '((windmove-delete-left left) + (windmove-delete-right right) + (windmove-delete-up up) + (windmove-delete-down down)) + (null val)) + (set-default sym val)) + :type windmove--default-keybindings-type + :version "28.1" + :group 'windmove) + +(defcustom windmove-swap-states-default-keybindings nil + "Default bindings for swap-state windmove commands." + :set (lambda (sym val) + (windmove-install-defaults + (car val) (cdr val) + '((windmove-swap-states-left left) + (windmove-swap-states-right right) + (windmove-swap-states-up up) + (windmove-swap-states-down down)) + (null val)) + (set-default sym val)) + :type windmove--default-keybindings-type + :version "28.1" + :group 'windmove) + \f (provide 'windmove) -- 2.30.2 ^ permalink raw reply related [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2021-05-31 8:50 ` Philip Kaludercic @ 2021-05-31 20:15 ` Juri Linkov 2021-05-31 21:27 ` Philip Kaludercic 0 siblings, 1 reply; 838+ messages in thread From: Juri Linkov @ 2021-05-31 20:15 UTC (permalink / raw) To: Philip Kaludercic; +Cc: 41438, Lars Ingebrigtsen > I was under the impression that this was fixed, but it turns out I did > not read the lookup-key doc string carefully enough: > > A number as value means KEY is "too long"; > that is, characters or symbols in it except for the last one > fail to be a valid sequence of prefix characters in KEYMAP. > The number is how many characters at the front of KEY > it takes to reach a non-prefix key. > > But this case can be safely ignored, as define-key will take care of the > prefix. To solve this, the warning is only trigged when a function is > over-riden. Did you intend to send a new patch? (the patches attached were the same as previous) ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2021-05-31 20:15 ` Juri Linkov @ 2021-05-31 21:27 ` Philip Kaludercic 2021-06-03 20:36 ` Juri Linkov 0 siblings, 1 reply; 838+ messages in thread From: Philip Kaludercic @ 2021-05-31 21:27 UTC (permalink / raw) To: Juri Linkov; +Cc: 41438, Lars Ingebrigtsen [-- Attachment #1: Type: text/plain, Size: 998 bytes --] Juri Linkov <juri@linkov.net> writes: >> I was under the impression that this was fixed, but it turns out I did >> not read the lookup-key doc string carefully enough: >> >> A number as value means KEY is "too long"; >> that is, characters or symbols in it except for the last one >> fail to be a valid sequence of prefix characters in KEYMAP. >> The number is how many characters at the front of KEY >> it takes to reach a non-prefix key. >> >> But this case can be safely ignored, as define-key will take care of the >> prefix. To solve this, the warning is only trigged when a function is >> over-riden. > > Did you intend to send a new patch? (the patches attached were the same as previous) Oops, I must have forgotten to regenerate patches. The important difference was + (let ((old-fn (lookup-key windmove-mode-map key))) + (when (functionp old-fn) + (warn "Overriding %S with %S" old-fn (car bind)))) -- Philip K. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-Improve-windmove-default-keybindings-fuctions.patch --] [-- Type: text/x-diff, Size: 8256 bytes --] From 7e31b789da74655e931adc937b5a22a48d4f676e Mon Sep 17 00:00:00 2001 From: Philip Kaludercic <philipk@posteo.net> Date: Tue, 25 May 2021 11:47:51 +0200 Subject: [PATCH 1/2] Improve windmove-*-default-keybindings fuctions * windmove.el (windmove-mode-map): Add special map for windmove commands (windmove-mode): Add minor mode for activating windmove-mode-map (windmove-install-defaults): Add general function for manipulating windmove-mode-map (windmove-default-keybindings): Use windmove-install-defaults (windmove-display-default-keybindings): Use windmove-install-defaults (windmove-delete-default-keybindings): Use windmove-install-defaults (windmove-swap-states-default-keybindings): Use windmove-install-defaults --- lisp/windmove.el | 92 +++++++++++++++++++++++++++++++++++++----------- 1 file changed, 71 insertions(+), 21 deletions(-) diff --git a/lisp/windmove.el b/lisp/windmove.el index e4ea8e0f69..ba59e95624 100644 --- a/lisp/windmove.el +++ b/lisp/windmove.el @@ -426,19 +426,53 @@ windmove-down ;; I don't think these bindings will work on non-X terminals; you ;; probably want to use different bindings in that case. +(defvar windmove-mode-map (make-sparse-keymap) + "Map used by `windmove-install-defaults'.") + +(define-minor-mode windmove-mode + "Global minor mode for default windmove commands." + :keymap windmove-mode-map + :init-value t + :global t) + +(defun windmove-install-defaults (prefix modifiers alist &optional uninstall) + "Install keys as specified by ALIST. +Every element of ALIST has the form (FN KEY), where KEY is +appended to MODIFIERS, adding PREFIX to the beginning, before +installing the key. Previous bindings of FN are unbound. +If UNINSTALL is non-nil, just remove the keys from ALIST." + (dolist (bind alist) + (dolist (old (where-is-internal (car bind) windmove-mode-map)) + (define-key windmove-mode-map old nil)) + (unless uninstall + (let ((key (vconcat (if (or (equal prefix [ignore]) + (eq prefix 'none)) + nil prefix) + (list (append modifiers (cdr bind)))))) + (when (eq (key-binding key) #'self-insert-command) + (warn "Command %S is shadowing self-insert-key" (car bind))) + (let ((old-fn (lookup-key windmove-mode-map key))) + (when (functionp old-fn) + (warn "Overriding %S with %S" old-fn (car bind)))) + (define-key windmove-mode-map key (car bind)))))) + ;;;###autoload (defun windmove-default-keybindings (&optional modifiers) "Set up keybindings for `windmove'. Keybindings are of the form MODIFIERS-{left,right,up,down}, where MODIFIERS is either a list of modifiers or a single modifier. +If MODIFIERS is `none', the keybindings will be directly bound to +the arrow keys. Default value of MODIFIERS is `shift'." (interactive) (unless modifiers (setq modifiers 'shift)) + (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) - (global-set-key (vector (append modifiers '(left))) 'windmove-left) - (global-set-key (vector (append modifiers '(right))) 'windmove-right) - (global-set-key (vector (append modifiers '(up))) 'windmove-up) - (global-set-key (vector (append modifiers '(down))) 'windmove-down)) + (windmove-install-defaults nil modifiers + '((windmove-left left) + (windmove-right right) + (windmove-up up) + (windmove-down down)))) \f ;;; Directional window display and selection @@ -546,17 +581,21 @@ windmove-display-default-keybindings Keys are bound to commands that display the next buffer in the specified direction. Keybindings are of the form MODIFIERS-{left,right,up,down}, where MODIFIERS is either a list of modifiers or a single modifier. +If MODIFIERS is `none', the keybindings will be directly bound to +the arrow keys. Default value of MODIFIERS is `shift-meta'." (interactive) (unless modifiers (setq modifiers '(shift meta))) + (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) - (global-set-key (vector (append modifiers '(left))) 'windmove-display-left) - (global-set-key (vector (append modifiers '(right))) 'windmove-display-right) - (global-set-key (vector (append modifiers '(up))) 'windmove-display-up) - (global-set-key (vector (append modifiers '(down))) 'windmove-display-down) - (global-set-key (vector (append modifiers '(?0))) 'windmove-display-same-window) - (global-set-key (vector (append modifiers '(?f))) 'windmove-display-new-frame) - (global-set-key (vector (append modifiers '(?t))) 'windmove-display-new-tab)) + (windmove-install-defaults nil modifiers + '((windmove-display-left left) + (windmove-display-right right) + (windmove-display-up up) + (windmove-display-down down) + (windmove-display-same-window ?0) + (windmove-display-new-frame ?f) + (windmove-display-new-tab ?t)))) \f ;;; Directional window deletion @@ -618,16 +657,22 @@ windmove-delete-default-keybindings Keys are bound to commands that delete windows in the specified direction. Keybindings are of the form PREFIX MODIFIERS-{left,right,up,down}, where PREFIX is a prefix key and MODIFIERS is either a list of modifiers or -a single modifier. Default value of PREFIX is `C-x' and MODIFIERS is `shift'." +a single modifier. +If PREFIX is `none', no prefix is used. If MODIFIERS is `none', the keybindings +are directly bound to the arrow keys. +Default value of PREFIX is `C-x' and MODIFIERS is `shift'." (interactive) (unless prefix (setq prefix '(?\C-x))) + (when (eq prefix 'none) (setq prefix nil)) (unless (listp prefix) (setq prefix (list prefix))) (unless modifiers (setq modifiers '(shift))) + (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) - (global-set-key (vector prefix (append modifiers '(left))) 'windmove-delete-left) - (global-set-key (vector prefix (append modifiers '(right))) 'windmove-delete-right) - (global-set-key (vector prefix (append modifiers '(up))) 'windmove-delete-up) - (global-set-key (vector prefix (append modifiers '(down))) 'windmove-delete-down)) + (windmove-install-defaults prefix modifiers + '((windmove-delete-left left) + (windmove-delete-right right) + (windmove-delete-up up) + (windmove-delete-down down)))) \f ;;; Directional window swap states @@ -673,14 +718,19 @@ windmove-swap-states-default-keybindings Keys are bound to commands that swap the states of the selected window with the window in the specified direction. Keybindings are of the form MODIFIERS-{left,right,up,down}, where MODIFIERS is either a list of modifiers -or a single modifier. Default value of MODIFIERS is `shift-super'." +or a single modifier. +If MODIFIERS is `none', the keybindings will be directly bound to the +arrow keys. +Default value of MODIFIERS is `shift-super'." (interactive) (unless modifiers (setq modifiers '(shift super))) + (when (eq modifiers 'none) (setq modifiers nil)) (unless (listp modifiers) (setq modifiers (list modifiers))) - (global-set-key (vector (append modifiers '(left))) 'windmove-swap-states-left) - (global-set-key (vector (append modifiers '(right))) 'windmove-swap-states-right) - (global-set-key (vector (append modifiers '(up))) 'windmove-swap-states-up) - (global-set-key (vector (append modifiers '(down))) 'windmove-swap-states-down)) + (windmove-install-defaults nil modifiers + '((windmove-swap-states-left left) + (windmove-swap-states-right right) + (windmove-swap-states-up up) + (windmove-swap-states-down down)))) \f (provide 'windmove) -- 2.30.2 ^ permalink raw reply related [flat|nested] 838+ messages in thread
* bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers 2021-05-31 21:27 ` Philip Kaludercic @ 2021-06-03 20:36 ` Juri Linkov 0 siblings, 0 replies; 838+ messages in thread From: Juri Linkov @ 2021-06-03 20:36 UTC (permalink / raw) To: Philip Kaludercic; +Cc: 41438, Lars Ingebrigtsen tags 41438 fixed close 41438 28.0.50 thanks >> Did you intend to send a new patch? (the patches attached were the same as previous) > > Oops, I must have forgotten to regenerate patches. The important > difference was > > + (let ((old-fn (lookup-key windmove-mode-map key))) > + (when (functionp old-fn) > + (warn "Overriding %S with %S" old-fn (car bind)))) Thanks, I've tested your patches, and everything work nicely. So pushed now. ^ permalink raw reply [flat|nested] 838+ messages in thread
[parent not found: <20200515175844.18941.61355@vcs0.savannah.gnu.org>]
[parent not found: <20200515175845.997EC20999@vcs0.savannah.gnu.org>]
* Deleting old `:version` from defcustoms (was: master b76cdd0: Delete libraries obsolete since 23.1 and 23.2) [not found] ` <20200515175845.997EC20999@vcs0.savannah.gnu.org> @ 2020-05-15 18:38 ` Stefan Monnier 2020-05-15 20:58 ` Stefan Kangas ` (2 more replies) 0 siblings, 3 replies; 838+ messages in thread From: Stefan Monnier @ 2020-05-15 18:38 UTC (permalink / raw) To: emacs-devel; +Cc: Stefan Kangas > Delete libraries obsolete since 23.1 and 23.2 Thanks Stefan. I did a quick `grep` to see the functions/vars that were obsoleted in the same time frame, and I saw instead a deluge of :version "23.1" If we consider those thingies old enough to remove their obsolete functions, shouldn't we also remove the corresponding `:version` thingies from `defcustom`s? I see: - 1 defcustom with a :version of 19.29 - >200 defcustoms with a :version of 20.x - a bit less than 200 defcustoms with a :version of 21.x - >400 defcustoms with a :version of 22.x - >200 defcustoms with a :version of 23.x -- Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Deleting old `:version` from defcustoms (was: master b76cdd0: Delete libraries obsolete since 23.1 and 23.2) 2020-05-15 18:38 ` Deleting old `:version` from defcustoms (was: master b76cdd0: Delete libraries obsolete since 23.1 and 23.2) Stefan Monnier @ 2020-05-15 20:58 ` Stefan Kangas 2020-08-07 15:42 ` [PATCH] Remove obsolete fast-lock and lazy-lock libraries (was: Re: Deleting old `:version` from defcustoms) Stefan Kangas 2020-05-16 13:18 ` Delete variables obsolete since Emacs 23 Stefan Kangas 2020-05-17 3:18 ` Deleting old `:version` from defcustoms (was: master b76cdd0: Delete libraries obsolete since 23.1 and 23.2) Stefan Kangas 2 siblings, 1 reply; 838+ messages in thread From: Stefan Kangas @ 2020-05-15 20:58 UTC (permalink / raw) To: Stefan Monnier, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: > I did a quick `grep` to see the functions/vars that were obsoleted in > the same time frame, and I saw instead a deluge of > > :version "23.1" > > If we consider those thingies old enough to remove their obsolete > functions, shouldn't we also remove the corresponding `:version` > thingies from `defcustom`s? There are also these two libraries: ./lisp/obsolete/fast-lock.el9:;; Obsolete-since: 22.1 ./lisp/obsolete/lazy-lock.el9:;; Obsolete-since: 22.1 For some reason they weren't removed in 27.1, when most other libraries obsolete since 22.x were deleted. This made me wonder if there was any particular reason for their non-removal. Does anyone know? And could we delete them now? Best regards, Stefan Kangas ^ permalink raw reply [flat|nested] 838+ messages in thread
* [PATCH] Remove obsolete fast-lock and lazy-lock libraries (was: Re: Deleting old `:version` from defcustoms) 2020-05-15 20:58 ` Stefan Kangas @ 2020-08-07 15:42 ` Stefan Kangas 2020-08-08 2:19 ` [PATCH] Remove obsolete fast-lock and lazy-lock libraries Stefan Monnier 0 siblings, 1 reply; 838+ messages in thread From: Stefan Kangas @ 2020-08-07 15:42 UTC (permalink / raw) To: Stefan Monnier, Emacs developers [-- Attachment #1: Type: text/plain, Size: 1092 bytes --] Stefan Kangas <stefankangas@gmail.com> writes: > There are also these two libraries: > > ./lisp/obsolete/fast-lock.el9:;; Obsolete-since: 22.1 > ./lisp/obsolete/lazy-lock.el9:;; Obsolete-since: 22.1 > > For some reason they weren't removed in 27.1, when most other libraries > obsolete since 22.x were deleted. This made me wonder if there was any > particular reason for their non-removal. Does anyone know? And could > we delete them now? I have attached a patch to remove them below. One thing to note is that I've kept the support for 'font-lock-support-mode' set to nil since Alan Mackenzie indicated that this could be useful for debugging purposes here: https://lists.gnu.org/archive/html/emacs-devel/2011-10/msg00748.html Perhaps it should be changed into a defvar, though. Or maybe it is no longer useful. But that could in any case be done separately, I think. (In case anyone is wondering, the motivation here is that these libraries are the only reason why some variables obsolete since 23.1 can't yet be removed.) Any comments or objections? Best regards, Stefan Kangas [-- Attachment #2: 0001-Remove-obsolete-fast-lock-and-lazy-lock-libraries.patch --] [-- Type: text/x-patch, Size: 102437 bytes --] From 7ecfac4412c0f1f126681fc9c99153ab5807e106 Mon Sep 17 00:00:00 2001 From: Stefan Kangas <stefankangas@gmail.com> Date: Fri, 7 Aug 2020 17:17:08 +0200 Subject: [PATCH] Remove obsolete fast-lock and lazy-lock libraries These libraries have been obsolete since 22.1. * lisp/obsolete/fast-lock.el: * lisp/obsolete/lazy-lock.el: Remove libraries obsolete since 22.1. * lisp/font-lock.el (font-lock-turn-off-thing-lock) (font-lock-after-fontify-buffer) (font-lock-after-unfontify-buffer) (font-lock-default-fontify-buffer) (font-lock-default-unfontify-buffer, font-lock-support-mode): * lisp/mail/rmail.el (rmail-variables): * lisp/ps-print.el (ps-print-ensure-fontified): Remove support for 'fast-lock' and 'lazy-lock'. * lisp/font-core.el (font-lock-defaults): * lisp/font-lock.el (font-lock-inhibit-thing-lock) (font-lock-keywords, top-level): * lisp/progmodes/antlr-mode.el (top-level): * lisp/progmodes/cc-fonts.el (c-font-lock-declarations): * lisp/progmodes/cperl-mode.el (top-level): * src/buffer.c (Fset_buffer_modified_p): Doc fixes to remove references to 'fast-lock' and 'lazy-lock'. * etc/NEWS: Announce that they have been removed. --- etc/NEWS | 5 + lisp/font-core.el | 2 +- lisp/font-lock.el | 83 +-- lisp/mail/rmail.el | 3 +- lisp/obsolete/fast-lock.el | 841 --------------------------- lisp/obsolete/lazy-lock.el | 1053 ---------------------------------- lisp/progmodes/antlr-mode.el | 3 - lisp/progmodes/cc-fonts.el | 2 +- lisp/progmodes/cperl-mode.el | 2 - lisp/ps-print.el | 5 +- src/buffer.c | 14 +- 11 files changed, 41 insertions(+), 1972 deletions(-) delete mode 100644 lisp/obsolete/fast-lock.el delete mode 100644 lisp/obsolete/lazy-lock.el diff --git a/etc/NEWS b/etc/NEWS index 850b166069..d80ef6865e 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -771,6 +771,11 @@ have now been removed. ** Some libraries obsolete since Emacs 23 have been removed: 'ledit.el', 'lmenu.el', 'lucid.el and 'old-whitespace.el'. +--- +** The 'lazy-lock' and 'fast-lock' libraries have been removed. +They have been obsolete since 22.1. Use 'jit-lock' instead (the +default). + \f * Lisp Changes in Emacs 28.1 diff --git a/lisp/font-core.el b/lisp/font-core.el index 098253eb16..344d7ee2ad 100644 --- a/lisp/font-core.el +++ b/lisp/font-core.el @@ -63,7 +63,7 @@ font-lock-defaults `font-lock-syntactic-keywords' and those for buffer-specialized fontification functions, `font-lock-fontify-buffer-function', `font-lock-unfontify-buffer-function', `font-lock-fontify-region-function', -`font-lock-unfontify-region-function', and `font-lock-inhibit-thing-lock'.") +`font-lock-unfontify-region-function'.") ;;;###autoload (put 'font-lock-defaults 'risky-local-variable t) (make-variable-buffer-local 'font-lock-defaults) diff --git a/lisp/font-lock.el b/lisp/font-lock.el index 5cda4a693d..f5adc5b768 100644 --- a/lisp/font-lock.el +++ b/lisp/font-lock.el @@ -47,9 +47,7 @@ ;; ;; Fontification for a particular mode may be available in a number of levels ;; of decoration. The higher the level, the more decoration, but the more time -;; it takes to fontify. See the variable `font-lock-maximum-decoration', and -;; also the variable `font-lock-maximum-size'. Support modes for Font Lock -;; mode can be used to speed up Font Lock mode. See `font-lock-support-mode'. +;; it takes to fontify. See the variable `font-lock-maximum-decoration'. \f ;;; How Font Lock mode fontifies: @@ -471,8 +469,7 @@ font-lock-keywords These regular expressions can match text which spans lines, although it is better to avoid it if possible since updating them while editing text is slower, and it is not guaranteed to be -always correct when using support modes like jit-lock or -lazy-lock. +always correct when using jit-lock. This variable is set by major modes via the variable `font-lock-defaults'. Be careful when composing regexps for this @@ -608,8 +605,7 @@ font-lock-unfontify-region-function (defvar font-lock-inhibit-thing-lock nil "List of Font Lock mode related modes that should not be turned on. -Currently, valid mode names are `fast-lock-mode', `jit-lock-mode' and -`lazy-lock-mode'. This is normally set via `font-lock-defaults'.") +This variable is now unused.") (make-obsolete-variable 'font-lock-inhibit-thing-lock nil "25.1") (defvar-local font-lock-multiline nil @@ -879,25 +875,19 @@ font-lock-remove-keywords (defcustom font-lock-support-mode 'jit-lock-mode "Support mode for Font Lock mode. Support modes speed up Font Lock mode by being choosy about when fontification -occurs. The default support mode, Just-in-time Lock mode (symbol -`jit-lock-mode'), is recommended. - -Other, older support modes are Fast Lock mode (symbol `fast-lock-mode') and -Lazy Lock mode (symbol `lazy-lock-mode'). See those modes for more info. -However, they are no longer recommended, as Just-in-time Lock mode is better. +occurs. The only supported mode is Just-in-time Lock mode (symbol +`jit-lock-mode'). If nil, means support for Font Lock mode is never performed. If a symbol, use that support mode. If a list, each element should be of the form (MAJOR-MODE . SUPPORT-MODE), where MAJOR-MODE is a symbol or t (meaning the default). For example: - ((c-mode . fast-lock-mode) (c++-mode . fast-lock-mode) (t . lazy-lock-mode)) -means that Fast Lock mode is used to support Font Lock mode for buffers in C or -C++ modes, and Lazy Lock mode is used to support Font Lock mode otherwise. + ((c-mode . nil) (t . jit-lock-mode)) +means that no font locking is used for buffers in C or, and Jit +Lock mode is used to support Font Lock mode otherwise. The value of this variable is used when Font Lock mode is turned on." :type '(choice (const :tag "none" nil) - (const :tag "fast lock" fast-lock-mode) - (const :tag "lazy lock" lazy-lock-mode) (const :tag "jit lock" jit-lock-mode) (repeat :menu-tag "mode specific" :tag "mode specific" :value ((t . jit-lock-mode)) @@ -907,28 +897,15 @@ font-lock-support-mode (symbol :tag "name")) (radio :tag "Support" (const :tag "none" nil) - (const :tag "fast lock" fast-lock-mode) - (const :tag "lazy lock" lazy-lock-mode) (const :tag "JIT lock" jit-lock-mode))) )) :version "21.1" :group 'font-lock) -(defvar fast-lock-mode) -(defvar lazy-lock-mode) (defvar jit-lock-mode) -(declare-function fast-lock-after-fontify-buffer "fast-lock") -(declare-function fast-lock-after-unfontify-buffer "fast-lock") -(declare-function fast-lock-mode "fast-lock") -(declare-function lazy-lock-after-fontify-buffer "lazy-lock") -(declare-function lazy-lock-after-unfontify-buffer "lazy-lock") -(declare-function lazy-lock-mode "lazy-lock") - (defun font-lock-turn-on-thing-lock () (pcase (font-lock-value-in-major-mode font-lock-support-mode) - ('fast-lock-mode (fast-lock-mode t)) - ('lazy-lock-mode (lazy-lock-mode t)) ('jit-lock-mode ;; Prepare for jit-lock (remove-hook 'after-change-functions @@ -954,37 +931,29 @@ font-lock-turn-on-thing-lock nil t)))) (defun font-lock-turn-off-thing-lock () - (cond ((bound-and-true-p fast-lock-mode) - (fast-lock-mode -1)) - ((bound-and-true-p jit-lock-mode) + (cond ((bound-and-true-p jit-lock-mode) (jit-lock-unregister 'font-lock-fontify-region) ;; Reset local vars to the non-jit-lock case. - (kill-local-variable 'font-lock-fontify-buffer-function)) - ((bound-and-true-p lazy-lock-mode) - (lazy-lock-mode -1)))) + (kill-local-variable 'font-lock-fontify-buffer-function)))) (defun font-lock-after-fontify-buffer () - (cond ((bound-and-true-p fast-lock-mode) - (fast-lock-after-fontify-buffer)) - ;; Useless now that jit-lock intercepts font-lock-fontify-buffer. -sm - ;; (jit-lock-mode - ;; (jit-lock-after-fontify-buffer)) - ((bound-and-true-p lazy-lock-mode) - (lazy-lock-after-fontify-buffer)))) + (declare (obsolete "does nothing." "28.1")) + ;; Useless now that jit-lock intercepts font-lock-fontify-buffer. -sm + ;; (jit-lock-mode + ;; (jit-lock-after-fontify-buffer)) + ) (defun font-lock-after-unfontify-buffer () - (cond ((bound-and-true-p fast-lock-mode) - (fast-lock-after-unfontify-buffer)) - ;; Useless as well. It's only called when: - ;; - turning off font-lock: it does not matter if we leave spurious - ;; `fontified' text props around since jit-lock-mode is also off. - ;; - font-lock-default-fontify-buffer fails: this is not run - ;; any more anyway. -sm - ;; - ;; (jit-lock-mode - ;; (jit-lock-after-unfontify-buffer)) - ((bound-and-true-p lazy-lock-mode) - (lazy-lock-after-unfontify-buffer)))) + (declare (obsolete "does nothing." "28.1")) + ;; Useless as well. It's only called when: + ;; - turning off font-lock: it does not matter if we leave spurious + ;; `fontified' text props around since jit-lock-mode is also off. + ;; - font-lock-default-fontify-buffer fails: this is not run + ;; any more anyway. -sm + ;; + ;; (jit-lock-mode + ;; (jit-lock-after-unfontify-buffer)) + ) ;;; End of Font Lock Support mode. \f @@ -1141,7 +1110,6 @@ font-lock-default-fontify-buffer (save-excursion (save-match-data (font-lock-fontify-region (point-min) (point-max) verbose) - (font-lock-after-fontify-buffer) (setq font-lock-fontified t))) ;; We don't restore the old fontification, so it's best to unfontify. (quit (font-lock-unfontify-buffer))))))) @@ -1152,7 +1120,6 @@ font-lock-default-unfontify-buffer (save-restriction (widen) (font-lock-unfontify-region (point-min) (point-max)) - (font-lock-after-unfontify-buffer) (setq font-lock-fontified nil))) (defvar font-lock-dont-widen nil diff --git a/lisp/mail/rmail.el b/lisp/mail/rmail.el index 44cde7cb5a..bbc220cfd1 100644 --- a/lisp/mail/rmail.el +++ b/lisp/mail/rmail.el @@ -1518,8 +1518,7 @@ rmail-variables '(rmail-font-lock-keywords t t nil nil (font-lock-maximum-size . nil) - (font-lock-dont-widen . t) - (font-lock-inhibit-thing-lock . (lazy-lock-mode fast-lock-mode)))) + (font-lock-dont-widen . t))) (make-local-variable 'require-final-newline) (setq require-final-newline nil) (make-local-variable 'version-control) diff --git a/lisp/obsolete/fast-lock.el b/lisp/obsolete/fast-lock.el deleted file mode 100644 index 9e0198dd59..0000000000 --- a/lisp/obsolete/fast-lock.el +++ /dev/null @@ -1,841 +0,0 @@ -;;; fast-lock.el --- automagic text properties caching for fast Font Lock mode - -;; Copyright (C) 1994-1998, 2001-2020 Free Software Foundation, Inc. - -;; Author: Simon Marshall <simon@gnu.org> -;; Maintainer: emacs-devel@gnu.org -;; Keywords: faces files -;; Version: 3.14 -;; Obsolete-since: 22.1 - -;; This file is part of GNU Emacs. - -;; GNU Emacs is free software: you can redistribute it and/or modify -;; it under the terms of the GNU General Public License as published by -;; the Free Software Foundation, either version 3 of the License, or -;; (at your option) any later version. - -;; GNU Emacs is distributed in the hope that it will be useful, -;; but WITHOUT ANY WARRANTY; without even the implied warranty of -;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -;; GNU General Public License for more details. - -;; You should have received a copy of the GNU General Public License -;; along with GNU Emacs. If not, see <https://www.gnu.org/licenses/>. - -;;; Commentary: - -;; Fast Lock mode is a Font Lock support mode. -;; It makes visiting a file in Font Lock mode faster by restoring its face text -;; properties from automatically saved associated Font Lock cache files. -;; -;; See caveats and feedback below. -;; See also the lazy-lock package. (But don't use the two at the same time!) - -;; Installation: -;; -;; Put in your ~/.emacs: -;; -;; (setq font-lock-support-mode 'fast-lock-mode) -;; -;; Start up a new Emacs and use font-lock as usual (except that you can use the -;; so-called "gaudier" fontification regexps on big files without frustration). -;; -;; When you visit a file (which has `font-lock-mode' enabled) that has a -;; corresponding Font Lock cache file associated with it, the Font Lock cache -;; will be loaded from that file instead of being generated by Font Lock code. - -;; Caveats: -;; -;; A cache will be saved when visiting a compressed file using crypt++, but not -;; be read. This is a "feature"/"consequence"/"bug" of crypt++. -;; -;; Version control packages are likely to stamp all over file modification -;; times. Therefore the act of checking out may invalidate a cache. -\f -;; History: -;; -;; 0.02--1.00: -;; - Changed name from turbo-prop to fast-lock. Automagic for font-lock only -;; - Made `fast-lock-mode' a minor mode, like G. Dinesh Dutt's fss-mode -;; 1.00--1.01: -;; - Turn on `fast-lock-mode' only if `buffer-file-name' or `interactive-p' -;; - Made `fast-lock-file-name' use `buffer-name' if `buffer-file-name' is nil -;; - Moved save-all conditions to `fast-lock-save-cache' -;; - Added `fast-lock-save-text-properties' to `kill-buffer-hook' -;; 1.01--2.00: complete rewrite---not worth the space to document -;; - Changed structure of text properties cache and threw out file mod checks -;; 2.00--2.01: -;; - Made `condition-case' forms understand `quit'. -;; - Made `fast-lock' require `font-lock' -;; - Made `fast-lock-cache-name' chase links (from Ben Liblit) -;; 2.01--3.00: -;; - Changed structure of cache to include `font-lock-keywords' (from rms) -;; - Changed `fast-lock-cache-mechanisms' to `fast-lock-cache-directories' -;; - Removed `fast-lock-read-others' -;; - Made `fast-lock-read-cache' ignore cache owner -;; - Made `fast-lock-save-cache-external' create cache directory -;; - Made `fast-lock-save-cache-external' save `font-lock-keywords' -;; - Made `fast-lock-cache-data' check `font-lock-keywords' -;; 3.00--3.01: incorporated port of 2.00 to Lucid, made by Barry Warsaw -;; - Package now provides itself -;; - Lucid: Use `font-lock-any-extents-p' for `font-lock-any-properties-p' -;; - Lucid: Use `list-faces' for `face-list' -;; - Lucid: Added `set-text-properties' -;; - Lucid: Made `turn-on-fast-lock' pass 1 not t to `fast-lock-mode' -;; - Removed test for `fast-lock-mode' from `fast-lock-read-cache' -;; - Lucid: Added Lucid-specific `fast-lock-get-face-properties' -;; 3.01--3.02: now works with Lucid Emacs, thanks to Barry Warsaw -;; - Made `fast-lock-cache-name' map ":" to ";" for OS/2 (from Serganova Vera) -;; - Made `fast-lock-cache-name' use abbreviated file name (from Barry Warsaw) -;; - Lucid: Separated handlers for `error' and `quit' for `condition-case' -;; 3.02--3.03: -;; - Changed `fast-lock-save-cache-external' to `fast-lock-save-cache-data' -;; - Lucid: Added Lucid-specific `fast-lock-set-face-properties' -;; 3.03--3.04: -;; - Corrected `subrp' test of Lucid code -;; - Replaced `font-lock-any-properties-p' with `text-property-not-all' -;; - Lucid: Made `fast-lock-set-face-properties' put `text-prop' on extents -;; - Made `fast-lock-cache-directories' a regexp alist (from Colin Rafferty) -;; - Made `fast-lock-cache-directory' to return a usable cache file directory -;; 3.04--3.05: -;; - Lucid: Fix for XEmacs 19.11 `text-property-not-all' -;; - Replaced `subrp' test of Lucid code with `emacs-version' `string-match' -;; - Made `byte-compile-warnings' omit `unresolved' on compilation -;; - Made `fast-lock-save-cache-data' use a buffer (from Rick Sladkey) -;; - Reverted to old `fast-lock-get-face-properties' (from Rick Sladkey) -;; 3.05--3.06: incorporated hack of 3.03, made by Jonathan Stigelman (Stig) -;; - Reverted to 3.04 version of `fast-lock-get-face-properties' -;; - XEmacs: Removed `list-faces' `defalias' -;; - Made `fast-lock-mode' and `turn-on-fast-lock' succeed `autoload' cookies -;; - Added `fast-lock-submit-bug-report' -;; - Renamed `fast-lock-save-size' to `fast-lock-minimum-size' -;; - Made `fast-lock-save-cache' output a message if no save ever attempted -;; - Made `fast-lock-save-cache-data' output a message if save attempted -;; - Made `fast-lock-cache-data' output a message if load attempted -;; - Made `fast-lock-save-cache-data' do `condition-case' not `unwind-protect' -;; - Made `fast-lock-save-cache' and `fast-lock-read-cache' return nothing -;; - Made `fast-lock-save-cache' check `buffer-modified-p' (Stig) -;; - Added `fast-lock-save-events' -;; - Added `fast-lock-after-save-hook' to `after-save-hook' (Stig) -;; - Added `fast-lock-kill-buffer-hook' to `kill-buffer-hook' -;; - Changed `fast-lock-save-caches' to `fast-lock-kill-emacs-hook' -;; - Added `fast-lock-kill-emacs-hook' to `kill-emacs-hook' -;; - Made `fast-lock-save-cache' check `verify-visited-file-modtime' (Stig) -;; - Made `visited-file-modtime' be the basis of the timestamp (Stig) -;; - Made `fast-lock-save-cache-1' and `fast-lock-cache-data' use/reformat it -;; - Added `fast-lock-cache-filename' to keep track of the cache file name -;; - Added `fast-lock-after-fontify-buffer' -;; - Added `fast-lock-save-faces' list of faces to save (idea from Stig/Tibor) -;; - Made `fast-lock-get-face-properties' functions use it -;; - XEmacs: Made `fast-lock-set-face-properties' do extents the Font Lock way -;; - XEmacs: Removed fix for `text-property-not-all' (19.11 support dropped) -;; - Made `fast-lock-mode' ensure `font-lock-mode' is on -;; - Made `fast-lock-save-cache' do `cdr-safe' not `cdr' (from Dave Foster) -;; - Made `fast-lock-save-cache' do `set-buffer' first (from Dave Foster) -;; - Made `fast-lock-save-cache' loop until saved or quit (from Georg Nikodym) -;; - Made `fast-lock-cache-data' check `buffer-modified-p' -;; - Made `fast-lock-cache-data' do `font-lock-compile-keywords' if necessary -;; - XEmacs: Made `font-lock-compile-keywords' `defalias' -;; 3.06--3.07: -;; - XEmacs: Add `fast-lock-after-fontify-buffer' to the Font Lock hook -;; - Made `fast-lock-cache-name' explain the use of `directory-abbrev-alist' -;; - Made `fast-lock-mode' use `buffer-file-truename' not `buffer-file-name' -;; 3.07--3.08: -;; - Made `fast-lock-read-cache' set `fast-lock-cache-filename' -;; 3.08--3.09: -;; - Made `fast-lock-save-cache' cope if `fast-lock-minimum-size' is a list -;; - Made `fast-lock-mode' respect the value of `font-lock-inhibit-thing-lock' -;; - Added `fast-lock-after-unfontify-buffer' -;; 3.09--3.10: -;; - Rewrite for Common Lisp macros -;; - Made fast-lock.el barf on a crap 8+3 pseudo-OS (Eli Zaretskii help) -;; - XEmacs: Made `add-minor-mode' succeed `autoload' cookie -;; - XEmacs: Made `fast-lock-save-faces' default to `font-lock-face-list' -;; - Made `fast-lock-save-cache' use `font-lock-value-in-major-mode' -;; - Wrap with `save-buffer-state' (Ray Van Tassle report) -;; - Made `fast-lock-mode' wrap `font-lock-support-mode' -;; 3.10--3.11: -;; - Made `fast-lock-get-face-properties' cope with face lists -;; - Added `fast-lock-verbose' -;; - XEmacs: Add `font-lock-value-in-major-mode' if necessary -;; - Removed `fast-lock-submit-bug-report' and bade farewell -;; 3.11--3.12: -;; - Added Custom support (Hrvoje Nikšić help) -;; - Made `save-buffer-state' wrap `inhibit-point-motion-hooks' -;; - Made `fast-lock-cache-data' simplify calls of `font-lock-compile-keywords' -;; 3.12--3.13: -;; - Removed `byte-*' variables from `eval-when-compile' (Erik Naggum hint) -;; - Changed structure of cache to include `font-lock-syntactic-keywords' -;; - Made `fast-lock-save-cache-1' save syntactic fontification data -;; - Made `fast-lock-cache-data' take syntactic fontification data -;; - Added `fast-lock-get-syntactic-properties' -;; - Renamed `fast-lock-set-face-properties' to `fast-lock-add-properties' -;; - Made `fast-lock-add-properties' add syntactic and face fontification data -;; 3.13--3.14: -;; - Made `fast-lock-cache-name' cope with `windowsnt' (Geoff Voelker fix) -;; - Made `fast-lock-verbose' use `other' widget (Andreas Schwab fix) -;; - Used `with-temp-message' where possible to make messages temporary. -\f -;;; Code: - -(require 'font-lock) - -(declare-function msdos-long-file-names "msdos.c") - -;; Make sure fast-lock.el is supported. -(if (and (eq system-type 'ms-dos) (not (msdos-long-file-names))) - (error "`fast-lock' was written for long file name systems")) - -(defvar font-lock-face-list) - -(eval-when-compile - ;; We use this to preserve or protect things when modifying text properties. - (defmacro save-buffer-state (varlist &rest body) - "Bind variables according to VARLIST and eval BODY restoring buffer state." - `(let* (,@(append varlist - '((modified (buffer-modified-p)) (buffer-undo-list t) - (inhibit-read-only t) (inhibit-point-motion-hooks t) - (inhibit-modification-hooks t) - deactivate-mark buffer-file-name buffer-file-truename))) - ,@body - (when (and (not modified) (buffer-modified-p)) - (set-buffer-modified-p nil)))) - (put 'save-buffer-state 'lisp-indent-function 1) - ;; - ;; We use this to verify that a face should be saved. - (defmacro fast-lock-save-facep (face) - "Return non-nil if FACE is one of `fast-lock-save-faces'." - `(or (null fast-lock-save-faces) - (if (symbolp ,face) - (memq ,face fast-lock-save-faces) - (let ((faces ,face)) - (while (unless (memq (car faces) fast-lock-save-faces) - (setq faces (cdr faces)))) - faces))))) - -(defgroup fast-lock nil - "Font Lock support mode to cache fontification." - :load 'fast-lock - :group 'font-lock) - -(defvar fast-lock-mode nil) ; Whether we are turned on. -(defvar fast-lock-cache-timestamp nil) ; For saving/reading. -(defvar fast-lock-cache-filename nil) ; For deleting. -\f -;; User Variables: - -(defcustom fast-lock-minimum-size 25600 - "Minimum size of a buffer for cached fontification. -Only buffers more than this can have associated Font Lock cache files saved. -If nil, means cache files are never created. -If a list, each element should be a cons pair of the form (MAJOR-MODE . SIZE), -where MAJOR-MODE is a symbol or t (meaning the default). For example: - ((c-mode . 25600) (c++-mode . 25600) (rmail-mode . 1048576)) -means that the minimum size is 25K for buffers in C or C++ modes, one megabyte -for buffers in Rmail mode, and size is irrelevant otherwise." - :type '(choice (const :tag "none" nil) - (integer :tag "size") - (repeat :menu-tag "mode specific" :tag "mode specific" - :value ((t . nil)) - (cons :tag "Instance" - (radio :tag "Mode" - (const :tag "all" t) - (symbol :tag "name")) - (radio :tag "Size" - (const :tag "none" nil) - (integer :tag "size"))))) - :group 'fast-lock) - -(defcustom fast-lock-cache-directories '("~/.emacs-flc") -; - `internal', keep each file's Font Lock cache file in the same file. -; - `external', keep each file's Font Lock cache file in the same directory. - "Directories in which Font Lock cache files are saved and read. -Each item should be either DIR or a cons pair of the form (REGEXP . DIR) where -DIR is a directory name (relative or absolute) and REGEXP is a regexp. - -An attempt will be made to save or read Font Lock cache files using these items -until one succeeds (i.e., until a readable or writable one is found). If an -item contains REGEXP, DIR is used only if the buffer file name matches REGEXP. -For example: - - (let ((home (expand-file-name (abbreviate-file-name (file-truename \"~/\"))))) - (list (cons (concat \"^\" (regexp-quote home)) \".\") \"~/.emacs-flc\")) - => - ((\"^/your/true/home/directory/\" . \".\") \"~/.emacs-flc\") - -would cause a file's current directory to be used if the file is under your -home directory hierarchy, or otherwise the absolute directory `~/.emacs-flc'. -For security reasons, it is not advisable to use the file's current directory -to avoid the possibility of using the cache of another user." - :type '(repeat (radio (directory :tag "directory") - (cons :tag "Matching" - (regexp :tag "regexp") - (directory :tag "directory")))) - :group 'fast-lock) -(put 'fast-lock-cache-directories 'risky-local-variable t) - -(defcustom fast-lock-save-events '(kill-buffer kill-emacs) - "Events under which caches will be saved. -Valid events are `save-buffer', `kill-buffer' and `kill-emacs'. -If concurrent editing sessions use the same associated cache file for a file's -buffer, then you should add `save-buffer' to this list." - :type '(set (const :tag "buffer saving" save-buffer) - (const :tag "buffer killing" kill-buffer) - (const :tag "emacs killing" kill-emacs)) - :group 'fast-lock) - -(defcustom fast-lock-save-others t - "If non-nil, save Font Lock cache files irrespective of file owner. -If nil, means only buffer files known to be owned by you can have associated -Font Lock cache files saved. Ownership may be unknown for networked files." - :type 'boolean - :group 'fast-lock) - -(defcustom fast-lock-verbose font-lock-verbose - "If non-nil, means show status messages for cache processing. -If a number, only buffers greater than this size have processing messages." - :type '(choice (const :tag "never" nil) - (other :tag "always" t) - (integer :tag "size")) - :group 'fast-lock) - -(defvar fast-lock-save-faces - (when (featurep 'xemacs) - ;; XEmacs uses extents for everything, so we have to pick the right ones. - font-lock-face-list) - "Faces that will be saved in a Font Lock cache file. -If nil, means information for all faces will be saved.") -\f -;; User Functions: - -;;;###autoload -(defun fast-lock-mode (&optional arg) - "Toggle Fast Lock mode. -With arg, turn Fast Lock mode on if and only if arg is positive and the buffer -is associated with a file. Enable it automatically in your `~/.emacs' by: - - (setq font-lock-support-mode \\='fast-lock-mode) - -If Fast Lock mode is enabled, and the current buffer does not contain any text -properties, any associated Font Lock cache is used if its timestamp matches the -buffer's file, and its `font-lock-keywords' match those that you are using. - -Font Lock caches may be saved: -- When you save the file's buffer. -- When you kill an unmodified file's buffer. -- When you exit Emacs, for all unmodified or saved buffers. -Depending on the value of `fast-lock-save-events'. -See also the commands `fast-lock-read-cache' and `fast-lock-save-cache'. - -Use \\[font-lock-fontify-buffer] to fontify the buffer if the cache is bad. - -Various methods of control are provided for the Font Lock cache. In general, -see variable `fast-lock-cache-directories' and function `fast-lock-cache-name'. -For saving, see variables `fast-lock-minimum-size', `fast-lock-save-events', -`fast-lock-save-others' and `fast-lock-save-faces'." - (interactive "P") - ;; Only turn on if we are visiting a file. We could use `buffer-file-name', - ;; but many packages temporarily wrap that to nil when doing their own thing. - (set (make-local-variable 'fast-lock-mode) - (and buffer-file-truename - (not (memq 'fast-lock-mode font-lock-inhibit-thing-lock)) - (if arg (> (prefix-numeric-value arg) 0) (not fast-lock-mode)))) - (if (and fast-lock-mode (not font-lock-mode)) - ;; Turned on `fast-lock-mode' rather than `font-lock-mode'. - (progn - (message "Use font-lock-support-mode rather than calling fast-lock-mode") - (sit-for 2)) - ;; Let's get down to business. - (set (make-local-variable 'fast-lock-cache-timestamp) nil) - (set (make-local-variable 'fast-lock-cache-filename) nil) - (when (and fast-lock-mode (not font-lock-fontified)) - (fast-lock-read-cache)))) - -(defun fast-lock-read-cache () - "Read the Font Lock cache for the current buffer. - -The following criteria must be met for a Font Lock cache file to be read: -- Fast Lock mode must be turned on in the buffer. -- The buffer must not be modified. -- The buffer's `font-lock-keywords' must match the cache's. -- The buffer file's timestamp must match the cache's. -- Criteria imposed by `fast-lock-cache-directories'. - -See `fast-lock-mode'." - (interactive) - (let ((directories fast-lock-cache-directories) - (modified (buffer-modified-p)) (inhibit-read-only t) - (fontified font-lock-fontified)) - (set (make-local-variable 'font-lock-fontified) nil) - ;; Keep trying directories until fontification is turned off. - (while (and directories (not font-lock-fontified)) - (let ((directory (fast-lock-cache-directory (car directories) nil))) - (condition-case nil - (when directory - (setq fast-lock-cache-filename (fast-lock-cache-name directory)) - (when (file-readable-p fast-lock-cache-filename) - (load fast-lock-cache-filename t t t))) - (error nil) (quit nil)) - (setq directories (cdr directories)))) - ;; Unset `fast-lock-cache-filename', and restore `font-lock-fontified', if - ;; we don't use a cache. (Note that `fast-lock-cache-data' sets the value - ;; of `fast-lock-cache-timestamp'.) - (set-buffer-modified-p modified) - (unless font-lock-fontified - (setq fast-lock-cache-filename nil font-lock-fontified fontified)))) - -(defun fast-lock-save-cache (&optional buffer) - "Save the Font Lock cache of BUFFER or the current buffer. - -The following criteria must be met for a Font Lock cache file to be saved: -- Fast Lock mode must be turned on in the buffer. -- The event must be one of `fast-lock-save-events'. -- The buffer must be at least `fast-lock-minimum-size' bytes long. -- The buffer file must be owned by you, or `fast-lock-save-others' must be t. -- The buffer must contain at least one `face' text property. -- The buffer must not be modified. -- The buffer file's timestamp must be the same as the file's on disk. -- The on disk file's timestamp must be different than the buffer's cache. -- Criteria imposed by `fast-lock-cache-directories'. - -See `fast-lock-mode'." - (interactive) - (save-excursion - (when buffer - (set-buffer buffer)) - (let ((min-size (font-lock-value-in-major-mode fast-lock-minimum-size)) - (file-timestamp (visited-file-modtime)) (saved nil)) - (when (and fast-lock-mode - ;; - ;; "Only save if the buffer matches the file, the file has - ;; changed, and it was changed by the current emacs session." - ;; - ;; Only save if the buffer is not modified, - ;; (i.e., so we don't save for something not on disk) - (not (buffer-modified-p)) - ;; and the file's timestamp is the same as the buffer's, - ;; (i.e., someone else hasn't written the file in the meantime) - (verify-visited-file-modtime (current-buffer)) - ;; and the file's timestamp is different from the cache's. - ;; (i.e., a save has occurred since the cache was read) - (not (equal fast-lock-cache-timestamp file-timestamp)) - ;; - ;; Only save if user's restrictions are satisfied. - (and min-size (>= (buffer-size) min-size)) - (or fast-lock-save-others - (eq (user-uid) (file-attribute-user-id - (file-attributes buffer-file-name)))) - ;; - ;; Only save if there are `face' properties to save. - (text-property-not-all (point-min) (point-max) 'face nil)) - ;; - ;; Try each directory until we manage to save or the user quits. - (let ((directories fast-lock-cache-directories)) - (while (and directories (memq saved '(nil error))) - (let* ((dir (fast-lock-cache-directory (car directories) t)) - (file (and dir (fast-lock-cache-name dir)))) - (when (and file (file-writable-p file)) - (setq saved (fast-lock-save-cache-1 file file-timestamp))) - (setq directories (cdr directories))))))))) - -;;;###autoload -(defun turn-on-fast-lock () - "Unconditionally turn on Fast Lock mode." - (fast-lock-mode t)) -\f -;;; API Functions: - -(defun fast-lock-after-fontify-buffer () - ;; Delete the Font Lock cache file used to restore fontification, if any. - (when fast-lock-cache-filename - (if (file-writable-p fast-lock-cache-filename) - (delete-file fast-lock-cache-filename) - (message "File %s font lock cache cannot be deleted" (buffer-name)))) - ;; Flag so that a cache will be saved later even if the file is never saved. - (setq fast-lock-cache-timestamp nil)) - -(defalias 'fast-lock-after-unfontify-buffer - 'ignore) -\f -;; Miscellaneous Functions: - -(defun fast-lock-save-cache-after-save-file () - ;; Do `fast-lock-save-cache' if `save-buffer' is on `fast-lock-save-events'. - (when (memq 'save-buffer fast-lock-save-events) - (fast-lock-save-cache))) - -(defun fast-lock-save-cache-before-kill-buffer () - ;; Do `fast-lock-save-cache' if `kill-buffer' is on `fast-lock-save-events'. - (when (memq 'kill-buffer fast-lock-save-events) - (fast-lock-save-cache))) - -(defun fast-lock-save-caches-before-kill-emacs () - ;; Do `fast-lock-save-cache's if `kill-emacs' is on `fast-lock-save-events'. - (when (memq 'kill-emacs fast-lock-save-events) - (mapcar 'fast-lock-save-cache (buffer-list)))) - -(defun fast-lock-cache-directory (directory create) - "Return usable directory based on DIRECTORY. -Returns nil if the directory does not exist, or, if CREATE non-nil, cannot be -created. DIRECTORY may be a string or a cons pair of the form (REGEXP . DIR). -See `fast-lock-cache-directories'." - (let ((dir - (cond ((not buffer-file-name) - ;; Should never be nil, but `crypt++' screws it up. - nil) - ((stringp directory) - ;; Just a directory. - directory) - (t - ;; A directory if the file name matches the regexp. - (let ((bufile (expand-file-name buffer-file-truename)) - (case-fold-search nil)) - (when (save-match-data (string-match (car directory) bufile)) - (cdr directory))))))) - (cond ((not dir) - nil) - ((file-accessible-directory-p dir) - dir) - (create - (condition-case nil - (progn (make-directory dir t) dir) - (error nil)))))) - -;; If you are wondering why we only hash if the directory is not ".", rather -;; than if `file-name-absolute-p', it is because if we just appended ".flc" for -;; relative cache directories (that are not ".") then it is possible that more -;; than one file would have the same cache name in that directory, if the luser -;; made a link from one relative cache directory to another. (Phew!) -(defun fast-lock-cache-name (directory) - "Return full cache file name using caching DIRECTORY. -If DIRECTORY is `.', the file name is the buffer file name appended with `.flc'. -Otherwise, the file name is constructed from DIRECTORY and the buffer's true -abbreviated file name, with all `/' characters in the name replaced with `#' -characters, and appended with `.flc'. - -If the same file has different cache file names when edited on different -machines, e.g., on one machine the cache file name has the prefix `#home', -perhaps due to automount, try putting in your `~/.emacs' something like: - - (setq directory-abbrev-alist (cons \\='(\"^/home/\" . \"/\") directory-abbrev-alist)) - -Emacs automagically removes the common `/tmp_mnt' automount prefix by default. - -See `fast-lock-cache-directory'." - (if (string-equal directory ".") - (concat buffer-file-name ".flc") - (let* ((bufile (expand-file-name buffer-file-truename)) - (chars-alist - (if (memq system-type '(windows-nt cygwin)) - '((?/ . (?#)) (?# . (?# ?#)) (?: . (?\;)) (?\; . (?\; ?\;))) - '((?/ . (?#)) (?# . (?# ?#))))) - (mapchars - (function (lambda (c) (or (cdr (assq c chars-alist)) (list c)))))) - (concat - (file-name-as-directory (expand-file-name directory)) - (mapconcat 'char-to-string (apply 'append (mapcar mapchars bufile)) "") - ".flc")))) -\f -;; Font Lock Cache Processing Functions: - -;; The version 3 format of the cache is: -;; -;; (fast-lock-cache-data VERSION TIMESTAMP -;; font-lock-syntactic-keywords SYNTACTIC-PROPERTIES -;; font-lock-keywords FACE-PROPERTIES) - -(defun fast-lock-save-cache-1 (file timestamp) - ;; Save the FILE with the TIMESTAMP plus fontification data. - ;; Returns non-nil if a save was attempted to a writable cache file. - (let ((tpbuf (generate-new-buffer " *fast-lock*")) - (verbose (if (numberp fast-lock-verbose) - (> (buffer-size) fast-lock-verbose) - fast-lock-verbose)) - (saved t)) - (with-temp-message - (when verbose - (format "Saving %s font lock cache..." (buffer-name))) - (condition-case nil - (save-excursion - (print (list 'fast-lock-cache-data 3 - (list 'quote timestamp) - (list 'quote font-lock-syntactic-keywords) - (list 'quote (fast-lock-get-syntactic-properties)) - (list 'quote font-lock-keywords) - (list 'quote (fast-lock-get-face-properties))) - tpbuf) - (set-buffer tpbuf) - (write-region (point-min) (point-max) file nil 'quietly) - (setq fast-lock-cache-timestamp timestamp - fast-lock-cache-filename file)) - (error (setq saved 'error)) (quit (setq saved 'quit))) - (kill-buffer tpbuf)) - (cond ((eq saved 'quit) - (message "Saving %s font lock cache...quit" (buffer-name))) - ((eq saved 'error) - (message "Saving %s font lock cache...failed" (buffer-name)))) - ;; We return non-nil regardless of whether a failure occurred. - saved)) - -(defun fast-lock-cache-data (version timestamp - syntactic-keywords syntactic-properties - keywords face-properties - &rest ignored) - ;; Find value of syntactic keywords in case it is a symbol. - (setq font-lock-syntactic-keywords (font-lock-eval-keywords - font-lock-syntactic-keywords)) - ;; Compile all keywords in case some are and some aren't. - (when font-lock-syntactic-keywords - (setq font-lock-syntactic-keywords (font-lock-compile-keywords - font-lock-syntactic-keywords t))) - (when syntactic-keywords - (setq syntactic-keywords (font-lock-compile-keywords syntactic-keywords t))) - (setq font-lock-keywords (font-lock-compile-keywords font-lock-keywords) - keywords (font-lock-compile-keywords keywords)) - ;; Use the Font Lock cache SYNTACTIC-PROPERTIES and FACE-PROPERTIES if we're - ;; using cache VERSION format 3, the current buffer's file timestamp matches - ;; the TIMESTAMP, the current buffer's `font-lock-syntactic-keywords' are the - ;; same as SYNTACTIC-KEYWORDS, and the current buffer's `font-lock-keywords' - ;; are the same as KEYWORDS. - (let ((buf-timestamp (visited-file-modtime)) - (verbose (if (numberp fast-lock-verbose) - (> (buffer-size) fast-lock-verbose) - fast-lock-verbose)) - (loaded t)) - (if (or (/= version 3) - (buffer-modified-p) - (not (equal timestamp buf-timestamp)) - (not (equal syntactic-keywords font-lock-syntactic-keywords)) - (not (equal keywords font-lock-keywords))) - (setq loaded nil) - (with-temp-message - (when verbose - (format "Loading %s font lock cache..." (buffer-name))) - (condition-case nil - (fast-lock-add-properties syntactic-properties face-properties) - (error (setq loaded 'error)) (quit (setq loaded 'quit)))) - (cond ((eq loaded 'quit) - (message "Loading %s font lock cache...quit" (buffer-name))) - ((eq loaded 'error) - (message "Loading %s font lock cache...failed" (buffer-name))))) - (setq font-lock-fontified (eq loaded t) - fast-lock-cache-timestamp (and (eq loaded t) timestamp)))) -\f -;; Text Properties Processing Functions: - -;; This is fast, but fails if adjacent characters have different `face' text -;; properties. Maybe that's why I dropped it in the first place? -;(defun fast-lock-get-face-properties () -; "Return a list of `face' text properties in the current buffer. -;Each element of the list is of the form (VALUE START1 END1 START2 END2 ...) -;where VALUE is a `face' property value and STARTx and ENDx are positions." -; (save-restriction -; (widen) -; (let ((start (text-property-not-all (point-min) (point-max) 'face nil)) -; (limit (point-max)) end properties value cell) -; (while start -; (setq end (next-single-property-change start 'face nil limit) -; value (get-text-property start 'face)) -; ;; Make, or add to existing, list of regions with same `face'. -; (if (setq cell (assq value properties)) -; (setcdr cell (cons start (cons end (cdr cell)))) -; (setq properties (cons (list value start end) properties))) -; (setq start (next-single-property-change end 'face))) -; properties))) - -;; This is slow, but copes if adjacent characters have different `face' text -;; properties, but fails if they are lists. -;(defun fast-lock-get-face-properties () -; "Return a list of `face' text properties in the current buffer. -;Each element of the list is of the form (VALUE START1 END1 START2 END2 ...) -;where VALUE is a `face' property value and STARTx and ENDx are positions. -;Only those `face' VALUEs in `fast-lock-save-faces' are returned." -; (save-restriction -; (widen) -; (let ((faces (or fast-lock-save-faces (face-list))) (limit (point-max)) -; properties regions face start end) -; (while faces -; (setq face (car faces) faces (cdr faces) regions () end (point-min)) -; ;; Make a list of start/end regions with `face' property face. -; (while (setq start (text-property-any end limit 'face face)) -; (setq end (or (text-property-not-all start limit 'face face) limit) -; regions (cons start (cons end regions)))) -; ;; Add `face' face's regions, if any, to properties. -; (when regions -; (push (cons face regions) properties))) -; properties))) - -(defun fast-lock-get-face-properties () - "Return a list of `face' text properties in the current buffer. -Each element of the list is of the form (VALUE START1 END1 START2 END2 ...) -where VALUE is a `face' property value and STARTx and ENDx are positions." - (save-restriction - (widen) - (let ((start (text-property-not-all (point-min) (point-max) 'face nil)) - end properties value cell) - (while start - (setq end (next-single-property-change start 'face nil (point-max)) - value (get-text-property start 'face)) - ;; Make, or add to existing, list of regions with same `face'. - (cond ((setq cell (assoc value properties)) - (setcdr cell (cons start (cons end (cdr cell))))) - ((fast-lock-save-facep value) - (push (list value start end) properties))) - (setq start (text-property-not-all end (point-max) 'face nil))) - properties))) - -(defun fast-lock-get-syntactic-properties () - "Return a list of `syntax-table' text properties in the current buffer. -See `fast-lock-get-face-properties'." - (save-restriction - (widen) - (let ((start (text-property-not-all (point-min) (point-max) 'syntax-table - nil)) - end properties value cell) - (while start - (setq end (next-single-property-change start 'syntax-table nil - (point-max)) - value (get-text-property start 'syntax-table)) - ;; Make, or add to existing, list of regions with same `syntax-table'. - (if (setq cell (assoc value properties)) - (setcdr cell (cons start (cons end (cdr cell)))) - (push (list value start end) properties)) - (setq start (text-property-not-all end (point-max) 'syntax-table nil))) - properties))) - -(defun fast-lock-add-properties (syntactic-properties face-properties) - "Add `syntax-table' and `face' text properties to the current buffer. -Any existing `syntax-table' and `face' text properties are removed first. -See `fast-lock-get-face-properties'." - (save-buffer-state (plist regions) - (save-restriction - (widen) - (font-lock-unfontify-region (point-min) (point-max)) - ;; - ;; Set the `syntax-table' property for each start/end region. - (while syntactic-properties - (setq plist (list 'syntax-table (car (car syntactic-properties))) - regions (cdr (car syntactic-properties)) - syntactic-properties (cdr syntactic-properties)) - (while regions - (add-text-properties (nth 0 regions) (nth 1 regions) plist) - (setq regions (nthcdr 2 regions)))) - ;; - ;; Set the `face' property for each start/end region. - (while face-properties - (setq plist (list 'face (car (car face-properties))) - regions (cdr (car face-properties)) - face-properties (cdr face-properties)) - (while regions - (add-text-properties (nth 0 regions) (nth 1 regions) plist) - (setq regions (nthcdr 2 regions))))))) -\f -;; Functions for XEmacs: - -(when (featurep 'xemacs) - ;; - ;; It would be better to use XEmacs' `map-extents' over extents with a - ;; `font-lock' property, but `face' properties are on different extents. - (defun fast-lock-get-face-properties () - "Return a list of `face' text properties in the current buffer. -Each element of the list is of the form (VALUE START1 END1 START2 END2 ...) -where VALUE is a `face' property value and STARTx and ENDx are positions. -Only those `face' VALUEs in `fast-lock-save-faces' are returned." - (save-restriction - (widen) - (let ((properties ()) cell) - (map-extents - (function (lambda (extent ignore) - (let ((value (extent-face extent))) - ;; We're only interested if it's one of `fast-lock-save-faces'. - (when (and value (fast-lock-save-facep value)) - (let ((start (extent-start-position extent)) - (end (extent-end-position extent))) - ;; Make or add to existing list of regions with the same - ;; `face' property value. - (if (setq cell (assoc value properties)) - (setcdr cell (cons start (cons end (cdr cell)))) - (push (list value start end) properties)))) - ;; Return nil to keep `map-extents' going. - nil)))) - properties))) - ;; - ;; XEmacs does not support the `syntax-table' text property. - (defalias 'fast-lock-get-syntactic-properties - 'ignore) - ;; - ;; Make extents just like XEmacs' font-lock.el does. - (defun fast-lock-add-properties (syntactic-properties face-properties) - "Set `face' text properties in the current buffer. -Any existing `face' text properties are removed first. -See `fast-lock-get-face-properties'." - (save-restriction - (widen) - (font-lock-unfontify-region (point-min) (point-max)) - ;; Set the `face' property, etc., for each start/end region. - (while face-properties - (let ((face (car (car face-properties))) - (regions (cdr (car face-properties)))) - (while regions - (font-lock-set-face (nth 0 regions) (nth 1 regions) face) - (setq regions (nthcdr 2 regions))) - (setq face-properties (cdr face-properties)))) - ;; XEmacs does not support the `syntax-table' text property. - )) - ;; - ;; XEmacs 19.12 font-lock.el's `font-lock-fontify-buffer' runs a hook. - (add-hook 'font-lock-after-fontify-buffer-hook - 'fast-lock-after-fontify-buffer)) - -(unless (boundp 'font-lock-syntactic-keywords) - (defvar font-lock-syntactic-keywords nil)) - -(unless (boundp 'font-lock-inhibit-thing-lock) - (defvar font-lock-inhibit-thing-lock nil)) - -(unless (fboundp 'font-lock-compile-keywords) - (defalias 'font-lock-compile-keywords 'identity)) - -(unless (fboundp 'font-lock-eval-keywords) - (defun font-lock-eval-keywords (keywords) - (if (symbolp keywords) - (font-lock-eval-keywords (if (fboundp keywords) - (funcall keywords) - (eval keywords))) - keywords))) - -(unless (fboundp 'font-lock-value-in-major-mode) - (defun font-lock-value-in-major-mode (alist) - (if (consp alist) - (cdr (or (assq major-mode alist) (assq t alist))) - alist))) - -(unless (fboundp 'current-message) - (defun current-message () - "")) -\f -;; Install ourselves: - -(add-hook 'after-save-hook 'fast-lock-save-cache-after-save-file) -(add-hook 'kill-buffer-hook 'fast-lock-save-cache-before-kill-buffer) -(unless noninteractive - (add-hook 'kill-emacs-hook 'fast-lock-save-caches-before-kill-emacs)) - -;;;###autoload -(when (fboundp 'add-minor-mode) - (defvar fast-lock-mode nil) - (add-minor-mode 'fast-lock-mode nil)) -;;;###dont-autoload -(unless (assq 'fast-lock-mode minor-mode-alist) - (setq minor-mode-alist (append minor-mode-alist '((fast-lock-mode nil))))) - -;; Provide ourselves: - -(provide 'fast-lock) - -;;; fast-lock.el ends here - -;; Local Variables: -;; byte-compile-warnings: (not obsolete) -;; End: diff --git a/lisp/obsolete/lazy-lock.el b/lisp/obsolete/lazy-lock.el deleted file mode 100644 index 694188ff23..0000000000 --- a/lisp/obsolete/lazy-lock.el +++ /dev/null @@ -1,1053 +0,0 @@ -;;; lazy-lock.el --- lazy demand-driven fontification for fast Font Lock mode - -;; Copyright (C) 1994-1998, 2001-2020 Free Software Foundation, Inc. - -;; Author: Simon Marshall <simon@gnu.org> -;; Maintainer: emacs-devel@gnu.org -;; Keywords: faces files -;; Version: 2.11 -;; Obsolete-since: 22.1 - -;; This file is part of GNU Emacs. - -;; GNU Emacs is free software: you can redistribute it and/or modify -;; it under the terms of the GNU General Public License as published by -;; the Free Software Foundation, either version 3 of the License, or -;; (at your option) any later version. - -;; GNU Emacs is distributed in the hope that it will be useful, -;; but WITHOUT ANY WARRANTY; without even the implied warranty of -;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -;; GNU General Public License for more details. - -;; You should have received a copy of the GNU General Public License -;; along with GNU Emacs. If not, see <https://www.gnu.org/licenses/>. - -;;; Commentary: - -;; Purpose: -;; -;; Lazy Lock mode is a Font Lock support mode. -;; It makes visiting buffers in Font Lock mode faster by making fontification -;; be demand-driven, deferred and stealthy, so that fontification only occurs -;; when, and where, necessary. -;; -;; See caveats and feedback below. -;; See also the fast-lock package. (But don't use them at the same time!) - -;; Installation: -;; -;; Put in your ~/.emacs: -;; -;; (setq font-lock-support-mode 'lazy-lock-mode) -;; -;; Start up a new Emacs and use font-lock as usual (except that you can use the -;; so-called "gaudier" fontification regexps on big files without frustration). -;; -;; In a buffer (which has `font-lock-mode' enabled) which is at least -;; `lazy-lock-minimum-size' characters long, buffer fontification will not -;; occur and only the visible portion of the buffer will be fontified. Motion -;; around the buffer will fontify those visible portions not previously -;; fontified. If stealth fontification is enabled, buffer fontification will -;; occur in invisible parts of the buffer after `lazy-lock-stealth-time' -;; seconds of idle time. If on-the-fly fontification is deferred, on-the-fly -;; fontification will occur after `lazy-lock-defer-time' seconds of idle time. - -;; User-visible differences with version 1: -;; -;; - Version 2 can defer on-the-fly fontification. Therefore you need not, and -;; should not, use defer-lock.el with this version of lazy-lock.el. -;; -;; A number of variables have changed meaning: -;; -;; - A value of nil for the variable `lazy-lock-minimum-size' means never turn -;; on demand-driven fontification. In version 1 this meant always turn on -;; demand-driven fontification. If you really want demand-driven fontification -;; regardless of buffer size, set this variable to 0. -;; -;; - The variable `lazy-lock-stealth-lines' cannot have a nil value. In -;; version 1 this meant use `window-height' as the maximum number of lines to -;; fontify as a stealth chunk. This makes no sense; stealth fontification is -;; of a buffer, not a window. - -;; Implementation differences with version 1: -;; -;; - Version 1 of lazy-lock.el is a bit of a hack. Version 1 demand-driven -;; fontification, the core feature of lazy-lock.el, is implemented by placing a -;; function on `post-command-hook'. This function fontifies where necessary, -;; i.e., where a window scroll has occurred. However, there are a number of -;; problems with using `post-command-hook': -;; -;; (a) As the name suggests, `post-command-hook' is run after every command, -;; i.e., frequently and regardless of whether scrolling has occurred. -;; (b) Scrolling can occur during a command, when `post-command-hook' is not -;; run, i.e., it is not necessarily run after scrolling has occurred. -;; (c) When `post-command-hook' is run, there is nothing to suggest where -;; scrolling might have occurred, i.e., which windows have scrolled. -;; -;; Thus lazy-lock.el's function is called almost as often as possible, usually -;; when it need not be called, yet it is not always called when it is needed. -;; Also, lazy-lock.el's function must check each window to see if a scroll has -;; occurred there. Worse still, lazy-lock.el's function must fontify a region -;; twice as large as necessary to make sure the window is completely fontified. -;; Basically, `post-command-hook' is completely inappropriate for lazy-lock.el. -;; -;; Ideally, we want to attach lazy-lock.el's function to a hook that is run -;; only when scrolling occurs, e.g., `window-start' has changed, and tells us -;; as much information as we need, i.e., the window and its new buffer region. -;; Richard Stallman implemented a `window-scroll-functions' for Emacs 19.30. -;; Functions on it are run when `window-start' has changed, and are supplied -;; with the window and the window's new `window-start' position. (It would be -;; better if it also supplied the window's new `window-end' position, but that -;; is calculated as part of the redisplay process, and the functions on -;; `window-scroll-functions' are run before redisplay has finished.) Thus, the -;; hook deals with the above problems (a), (b) and (c). -;; -;; If only life was that easy. Version 2 demand-driven fontification is mostly -;; implemented by placing a function on `window-scroll-functions'. However, -;; not all scrolling occurs when `window-start' has changed. A change in -;; window size, e.g., via C-x 1, or a significant deletion, e.g., of a number -;; of lines, causes text previously invisible (i.e., after `window-end') to -;; become visible without changing `window-start'. Arguably, these events are -;; not scrolling events, but fontification must occur for lazy-lock.el to work. -;; Hooks `window-size-change-functions' and `redisplay-end-trigger-functions' -;; were added for these circumstances. -;; -;; (Ben Wing thinks these hooks are "horribly horribly kludgy", and implemented -;; a `pre-idle-hook', a `mother-of-all-post-command-hooks', for XEmacs 19.14. -;; He then hacked up a version 1 lazy-lock.el to use `pre-idle-hook' rather -;; than `post-command-hook'. Whereas functions on `post-command-hook' are -;; called almost as often as possible, functions on `pre-idle-hook' really are -;; called as often as possible, even when the mouse moves and, on some systems, -;; while XEmacs is idle. Thus, the hook deals with the above problem (b), but -;; unfortunately it makes (a) worse and does not address (c) at all. -;; -;; I freely admit that `redisplay-end-trigger-functions' and, to a much lesser -;; extent, `window-size-change-functions' are not pretty. However, I feel that -;; a `window-scroll-functions' feature is cleaner than a `pre-idle-hook', and -;; the result is faster and smaller, less intrusive and more targeted, code. -;; Since `pre-idle-hook' is pretty much like `post-command-hook', there is no -;; point in making this version of lazy-lock.el work with it. Anyway, that's -;; Lit 30 of my humble opinion. -;; -;; - Version 1 stealth fontification is also implemented by placing a function -;; on `post-command-hook'. This function waits for a given amount of time, -;; and, if Emacs remains idle, fontifies where necessary. Again, there are a -;; number of problems with using `post-command-hook': -;; -;; (a) Functions on `post-command-hook' are run sequentially, so this function -;; can interfere with other functions on the hook, and vice versa. -;; (b) This function waits for a given amount of time, so it can interfere with -;; various features that are dealt with by Emacs after a command, e.g., -;; region highlighting, asynchronous updating and keystroke echoing. -;; (c) Fontification may be required during a command, when `post-command-hook' -;; is not run. (Version 2 deferred fontification only.) -;; -;; Again, `post-command-hook' is completely inappropriate for lazy-lock.el. -;; Richard Stallman and Morten Welinder implemented internal Timers and Idle -;; Timers for Emacs 19.31. Functions can be run independently at given times -;; or after given amounts of idle time. Thus, the feature deals with the above -;; problems (a), (b) and (c). Version 2 deferral and stealth are implemented -;; by functions on Idle Timers. (A function on XEmacs' `pre-idle-hook' is -;; similar to an Emacs Idle Timer function with a fixed zero second timeout.) - -;; - Version 1 has the following problems (relative to version 2): -;; -;; (a) It is slow when it does its job. -;; (b) It does not always do its job when it should. -;; (c) It slows all interaction (when it doesn't need to do its job). -;; (d) It interferes with other package functions on `post-command-hook'. -;; (e) It interferes with Emacs things within the read-eval loop. -;; -;; Ben's hacked-up lazy-lock.el 1.14 almost solved (b) but made (c) worse. -;; -;; - Version 2 has the following additional features (relative to version 1): -;; -;; (a) It can defer fontification (both on-the-fly and on-scrolling). -;; (b) It can fontify contextually (syntactically true on-the-fly). - -;; Caveats: -;; -;; Lazy Lock mode does not work efficiently with Outline mode. -;; This is because when in Outline mode, although text may be not visible to -;; you in the window, the text is visible to Emacs Lisp code (not surprisingly) -;; and Lazy Lock fontifies it mercilessly. Maybe it will be fixed one day. -;; -;; Because buffer text is not necessarily fontified, other packages that expect -;; buffer text to be fontified in Font Lock mode either might not work as -;; expected, or might not display buffer text as expected. An example of the -;; latter is `occur', which copies lines of buffer text into another buffer. -;; -;; In Emacs 19.30, Lazy Lock mode does not ensure that an existing buffer is -;; fontified if it is made visible via a minibuffer-less command that replaces -;; an existing window's buffer (e.g., via the Buffers menu). Upgrade! -;; -;; In Emacs 19.30, Lazy Lock mode does not work well with Transient Mark mode -;; or modes based on Comint mode (e.g., Shell mode), and also interferes with -;; the echoing of keystrokes in the minibuffer. This is because of the way -;; deferral and stealth have to be implemented for Emacs 19.30. Upgrade! -;; -;; Currently XEmacs does not have the features to support this version of -;; lazy-lock.el. Maybe it will one day. -\f -;; History: -;; -;; 1.15--2.00: -;; - Rewrite for Emacs 19.30 and the features rms added to support lazy-lock.el -;; so that it could work correctly and efficiently. -;; - Many thanks to those who reported bugs, fixed bugs, made suggestions or -;; otherwise contributed in the version 1 cycle; Jari Aalto, Kevin Broadey, -;; Ulrik Dickow, Bill Dubuque, Bob Glickstein, Boris Goldowsky, -;; Jonas Jarnestrom, David Karr, Michael Kifer, Erik Naggum, Rick Sladkey, -;; Jim Thompson, Ben Wing, Ilya Zakharevich, and Richard Stallman. -;; 2.00--2.01: -;; - Made `lazy-lock-fontify-after-command' always `sit-for' and so redisplay -;; - Use `buffer-name' not `buffer-live-p' (Bill Dubuque hint) -;; - Made `lazy-lock-install' do `add-to-list' not `setq' of `current-buffer' -;; - Made `lazy-lock-fontify-after-install' loop over buffer list -;; - Made `lazy-lock-arrange-before-change' to arrange `window-end' triggering -;; - Made `lazy-lock-let-buffer-state' wrap both `befter-change-functions' -;; - Made `lazy-lock-fontify-region' do `condition-case' (Hyman Rosen report) -;; 2.01--2.02: -;; - Use `buffer-live-p' as `buffer-name' can barf (Richard Stanton report) -;; - Made `lazy-lock-install' set `font-lock-fontified' (Kevin Davidson report) -;; - Made `lazy-lock-install' add hooks only if needed -;; - Made `lazy-lock-unstall' add `font-lock-after-change-function' if needed -;; 2.02--2.03: -;; - Made `lazy-lock-fontify-region' do `condition-case' for `quit' too -;; - Made `lazy-lock-mode' respect the value of `font-lock-inhibit-thing-lock' -;; - Added `lazy-lock-after-unfontify-buffer' -;; - Removed `lazy-lock-fontify-after-install' hack -;; - Made `lazy-lock-fontify-after-scroll' not `set-buffer' to `window-buffer' -;; - Made `lazy-lock-fontify-after-trigger' not `set-buffer' to `window-buffer' -;; - Made `lazy-lock-fontify-after-idle' be interruptible (Scott Burson hint) -;; 2.03--2.04: -;; - Rewrite for Emacs 19.31 idle timers -;; - Renamed `buffer-windows' to `get-buffer-window-list' -;; - Removed `buffer-live-p' -;; - Made `lazy-lock-defer-after-change' always save `current-buffer' -;; - Made `lazy-lock-fontify-after-defer' just process buffers -;; - Made `lazy-lock-install-hooks' add hooks correctly (Kevin Broadey report) -;; - Made `lazy-lock-install' cope if `lazy-lock-defer-time' is a list -;; 2.04--2.05: -;; - Rewrite for Common Lisp macros -;; - Added `do-while' macro -;; - Renamed `lazy-lock-let-buffer-state' macro to `save-buffer-state' -;; - Returned `lazy-lock-fontify-after-install' hack (Darren Hall hint) -;; - Added `lazy-lock-defer-on-scrolling' functionality (Scott Byer hint) -;; - Made `lazy-lock-mode' wrap `font-lock-support-mode' -;; 2.05--2.06: -;; - Made `lazy-lock-fontify-after-defer' swap correctly (Scott Byer report) -;; 2.06--2.07: -;; - Added `lazy-lock-stealth-load' functionality (Rob Hooft hint) -;; - Made `lazy-lock-unstall' call `lazy-lock-fontify-region' if needed -;; - Made `lazy-lock-mode' call `lazy-lock-unstall' only if needed -;; - Made `lazy-lock-defer-after-scroll' do `set-window-redisplay-end-trigger' -;; - Added `lazy-lock-defer-contextually' functionality -;; - Added `lazy-lock-defer-on-the-fly' from `lazy-lock-defer-time' -;; - Renamed `lazy-lock-defer-driven' to `lazy-lock-defer-on-scrolling' -;; - Removed `lazy-lock-submit-bug-report' and bade farewell -;; 2.07--2.08: -;; - Made `lazy-lock-fontify-conservatively' fontify around `window-point' -;; - Made `save-buffer-state' wrap `inhibit-point-motion-hooks' -;; - Added Custom support -;; 2.08--2.09: -;; - Removed `byte-*' variables from `eval-when-compile' (Erik Naggum hint) -;; - Made various wrapping `inhibit-point-motion-hooks' (Vinicius Latorre hint) -;; - Made `lazy-lock-fontify-after-idle' wrap `minibuffer-auto-raise' -;; - Made `lazy-lock-fontify-after-defer' paranoid about deferred buffers -;; 2.09--2.10: -;; - Use `window-end' UPDATE arg for Emacs 20.4 and later. -;; - Made deferral `widen' before unfontifying (Dan Nicolaescu report) -;; - Use `lazy-lock-fontify-after-visage' for hideshow.el (Dan Nicolaescu hint) -;; - Use `other' widget where possible (Andreas Schwab fix) -;; 2.10--2.11: -;; - Used `with-temp-message' where possible to make messages temporary. -\f -;;; Code: - -(require 'font-lock) -(eval-when-compile (require 'cl-lib)) - -(eval-when-compile - ;; We use this to preserve or protect things when modifying text properties. - (defmacro save-buffer-state (varlist &rest body) - "Bind variables according to VARLIST and eval BODY restoring buffer state." - `(let* (,@(append varlist - '((modified (buffer-modified-p)) - (buffer-undo-list t) - (inhibit-read-only t) - (inhibit-point-motion-hooks t) - (inhibit-modification-hooks t) - deactivate-mark - buffer-file-name - buffer-file-truename))) - ,@body - (when (and (not modified) (buffer-modified-p)) - (restore-buffer-modified-p nil)))) - (put 'save-buffer-state 'lisp-indent-function 1) - ;; - ;; We use this for clarity and speed. Naughty but nice. - (defmacro do-while (test &rest body) - "(do-while TEST BODY...): eval BODY... and repeat if TEST yields non-nil. -The order of execution is thus BODY, TEST, BODY, TEST and so on -until TEST returns nil." - `(while (progn ,@body ,test))) - (put 'do-while 'lisp-indent-function (get 'while 'lisp-indent-function))) - -(defgroup lazy-lock nil - "Font Lock support mode to fontify lazily." - :group 'font-lock) - -(defvar lazy-lock-mode nil) ; Whether we are turned on. -(defvar lazy-lock-buffers nil) ; For deferral. -(defvar lazy-lock-timers (cons nil nil)) ; For deferral and stealth. -\f -;; User Variables: - -(defcustom lazy-lock-minimum-size 25600 - "Minimum size of a buffer for demand-driven fontification. -On-demand fontification occurs if the buffer size is greater than this value. -If nil, means demand-driven fontification is never performed. -If a list, each element should be a cons pair of the form (MAJOR-MODE . SIZE), -where MAJOR-MODE is a symbol or t (meaning the default). For example: - ((c-mode . 25600) (c++-mode . 25600) (rmail-mode . 1048576)) -means that the minimum size is 25K for buffers in C or C++ modes, one megabyte -for buffers in Rmail mode, and size is irrelevant otherwise. - -The value of this variable is used when Lazy Lock mode is turned on." - :type '(choice (const :tag "none" nil) - (integer :tag "size") - (repeat :menu-tag "mode specific" :tag "mode specific" - :value ((t . nil)) - (cons :tag "Instance" - (radio :tag "Mode" - (const :tag "all" t) - (symbol :tag "name")) - (radio :tag "Size" - (const :tag "none" nil) - (integer :tag "size"))))) - :group 'lazy-lock) - -(defcustom lazy-lock-defer-on-the-fly t - "If non-nil, means fontification after a change should be deferred. -If nil, means on-the-fly fontification is performed. This means when changes -occur in the buffer, those areas are immediately fontified. -If a list, it should be a list of `major-mode' symbol names for which deferred -fontification should occur. The sense of the list is negated if it begins with -`not'. For example: - (c-mode c++-mode) -means that on-the-fly fontification is deferred for buffers in C and C++ modes -only, and deferral does not occur otherwise. - -The value of this variable is used when Lazy Lock mode is turned on." - :type '(choice (const :tag "never" nil) - (const :tag "always" t) - (set :menu-tag "mode specific" :tag "modes" - :value (not) - (const :tag "Except" not) - (repeat :inline t (symbol :tag "mode")))) - :group 'lazy-lock) - -(defcustom lazy-lock-defer-on-scrolling nil - "If non-nil, means fontification after a scroll should be deferred. -If nil, means demand-driven fontification is performed. This means when -scrolling into unfontified areas of the buffer, those areas are immediately -fontified. Thus scrolling never presents unfontified areas. However, since -fontification occurs during scrolling, scrolling may be slow. -If t, means defer-driven fontification is performed. This means fontification -of those areas is deferred. Thus scrolling may present momentarily unfontified -areas. However, since fontification does not occur during scrolling, scrolling -will be faster than demand-driven fontification. -If any other value, e.g., `eventually', means demand-driven fontification is -performed until the buffer is fontified, then buffer fontification becomes -defer-driven. Thus scrolling never presents unfontified areas until the buffer -is first fontified, after which subsequent scrolling may present future buffer -insertions momentarily unfontified. However, since fontification does not -occur during scrolling after the buffer is first fontified, scrolling will -become faster. (But, since contextual changes continually occur, such a value -makes little sense if `lazy-lock-defer-contextually' is non-nil.) - -The value of this variable is used when Lazy Lock mode is turned on." - :type '(choice (const :tag "never" nil) - (const :tag "always" t) - (other :tag "eventually" eventually)) - :group 'lazy-lock) - -(defcustom lazy-lock-defer-contextually 'syntax-driven - "If non-nil, means deferred fontification should be syntactically true. -If nil, means deferred fontification occurs only on those lines modified. This -means where modification on a line causes syntactic change on subsequent lines, -those subsequent lines are not refontified to reflect their new context. -If t, means deferred fontification occurs on those lines modified and all -subsequent lines. This means those subsequent lines are refontified to reflect -their new syntactic context, either immediately or when scrolling into them. -If any other value, e.g., `syntax-driven', means deferred syntactically true -fontification occurs only if syntactic fontification is performed using the -buffer mode's syntax table, i.e., only if `font-lock-keywords-only' is nil. - -The value of this variable is used when Lazy Lock mode is turned on." - :type '(choice (const :tag "never" nil) - (const :tag "always" t) - (other :tag "syntax-driven" syntax-driven)) - :group 'lazy-lock) - -(defcustom lazy-lock-defer-time 0.25 - "Time in seconds to delay before beginning deferred fontification. -Deferred fontification occurs if there is no input within this time. -If nil, means fontification is never deferred, regardless of the values of the -variables `lazy-lock-defer-on-the-fly', `lazy-lock-defer-on-scrolling' and -`lazy-lock-defer-contextually'. - -The value of this variable is used when Lazy Lock mode is turned on." - :type '(choice (const :tag "never" nil) - (number :tag "seconds")) - :group 'lazy-lock) - -(defcustom lazy-lock-stealth-time 30 - "Time in seconds to delay before beginning stealth fontification. -Stealth fontification occurs if there is no input within this time. -If nil, means stealth fontification is never performed. - -The value of this variable is used when Lazy Lock mode is turned on." - :type '(choice (const :tag "never" nil) - (number :tag "seconds")) - :group 'lazy-lock) - -(defcustom lazy-lock-stealth-lines (if font-lock-maximum-decoration 100 250) - "Maximum size of a chunk of stealth fontification. -Each iteration of stealth fontification can fontify this number of lines. -To speed up input response during stealth fontification, at the cost of stealth -taking longer to fontify, you could reduce the value of this variable." - :type '(integer :tag "lines") - :group 'lazy-lock) - -(defcustom lazy-lock-stealth-load - (if (condition-case nil (load-average) (error)) 200) - "Load in percentage above which stealth fontification is suspended. -Stealth fontification pauses when the system short-term load average (as -returned by the function `load-average' if supported) goes above this level, -thus reducing the demand that stealth fontification makes on the system. -If nil, means stealth fontification is never suspended. -To reduce machine load during stealth fontification, at the cost of stealth -taking longer to fontify, you could reduce the value of this variable. -See also `lazy-lock-stealth-nice'." - :type (if (condition-case nil (load-average) (error)) - '(choice (const :tag "never" nil) - (integer :tag "load")) - '(const :format "%t: unsupported\n" nil)) - :group 'lazy-lock) - -(defcustom lazy-lock-stealth-nice 0.125 - "Time in seconds to pause between chunks of stealth fontification. -Each iteration of stealth fontification is separated by this amount of time, -thus reducing the demand that stealth fontification makes on the system. -If nil, means stealth fontification is never paused. -To reduce machine load during stealth fontification, at the cost of stealth -taking longer to fontify, you could increase the value of this variable. -See also `lazy-lock-stealth-load'." - :type '(choice (const :tag "never" nil) - (number :tag "seconds")) - :group 'lazy-lock) - -(defcustom lazy-lock-stealth-verbose - (and (not lazy-lock-defer-contextually) (not (null font-lock-verbose))) - "If non-nil, means stealth fontification should show status messages." - :type 'boolean - :group 'lazy-lock) -\f -;; User Functions: - -;;;###autoload -(defun lazy-lock-mode (&optional arg) - "Toggle Lazy Lock mode. -With arg, turn Lazy Lock mode on if and only if arg is positive. Enable it -automatically in your `~/.emacs' by: - - (setq font-lock-support-mode \\='lazy-lock-mode) - -For a newer font-lock support mode with similar functionality, see -`jit-lock-mode'. Eventually, Lazy Lock mode will be deprecated in -JIT Lock's favor. - -When Lazy Lock mode is enabled, fontification can be lazy in a number of ways: - -- Demand-driven buffer fontification if `lazy-lock-minimum-size' is non-nil. - This means initial fontification does not occur if the buffer is greater than - `lazy-lock-minimum-size' characters in length. Instead, fontification occurs - when necessary, such as when scrolling through the buffer would otherwise - reveal unfontified areas. This is useful if buffer fontification is too slow - for large buffers. - -- Deferred scroll fontification if `lazy-lock-defer-on-scrolling' is non-nil. - This means demand-driven fontification does not occur as you scroll. - Instead, fontification is deferred until after `lazy-lock-defer-time' seconds - of Emacs idle time, while Emacs remains idle. This is useful if - fontification is too slow to keep up with scrolling. - -- Deferred on-the-fly fontification if `lazy-lock-defer-on-the-fly' is non-nil. - This means on-the-fly fontification does not occur as you type. Instead, - fontification is deferred until after `lazy-lock-defer-time' seconds of Emacs - idle time, while Emacs remains idle. This is useful if fontification is too - slow to keep up with your typing. - -- Deferred context fontification if `lazy-lock-defer-contextually' is non-nil. - This means fontification updates the buffer corresponding to true syntactic - context, after `lazy-lock-defer-time' seconds of Emacs idle time, while Emacs - remains idle. Otherwise, fontification occurs on modified lines only, and - subsequent lines can remain fontified corresponding to previous syntactic - contexts. This is useful where strings or comments span lines. - -- Stealthy buffer fontification if `lazy-lock-stealth-time' is non-nil. - This means remaining unfontified areas of buffers are fontified if Emacs has - been idle for `lazy-lock-stealth-time' seconds, while Emacs remains idle. - This is useful if any buffer has any deferred fontification. - -Basic Font Lock mode on-the-fly fontification behavior fontifies modified -lines only. Thus, if `lazy-lock-defer-contextually' is non-nil, Lazy Lock mode -on-the-fly fontification may fontify differently, albeit correctly. In any -event, to refontify some lines you can use \\[font-lock-fontify-block]. - -Stealth fontification only occurs while the system remains unloaded. -If the system load rises above `lazy-lock-stealth-load' percent, stealth -fontification is suspended. Stealth fontification intensity is controlled via -the variable `lazy-lock-stealth-nice' and `lazy-lock-stealth-lines', and -verbosity is controlled via the variable `lazy-lock-stealth-verbose'." - (interactive "P") - (let* ((was-on lazy-lock-mode) - (now-on (unless (memq 'lazy-lock-mode font-lock-inhibit-thing-lock) - (if arg (> (prefix-numeric-value arg) 0) (not was-on))))) - (cond ((and now-on (not font-lock-mode)) - ;; Turned on `lazy-lock-mode' rather than `font-lock-mode'. - (message "Use font-lock-support-mode rather than calling lazy-lock-mode") - (sit-for 2)) - (now-on - ;; Turn ourselves on. - (set (make-local-variable 'lazy-lock-mode) t) - (lazy-lock-install)) - (was-on - ;; Turn ourselves off. - (set (make-local-variable 'lazy-lock-mode) nil) - (lazy-lock-unstall))))) - -;;;###autoload -(defun turn-on-lazy-lock () - "Unconditionally turn on Lazy Lock mode." - (lazy-lock-mode t)) - -(defun lazy-lock-install () - (let ((min-size (font-lock-value-in-major-mode lazy-lock-minimum-size)) - (defer-change (and lazy-lock-defer-time lazy-lock-defer-on-the-fly)) - (defer-scroll (and lazy-lock-defer-time lazy-lock-defer-on-scrolling)) - (defer-context (and lazy-lock-defer-time lazy-lock-defer-contextually - (or (eq lazy-lock-defer-contextually t) - (null font-lock-keywords-only))))) - ;; - ;; Tell Font Lock whether Lazy Lock will do fontification. - (make-local-variable 'font-lock-fontified) - (setq font-lock-fontified (and min-size (>= (buffer-size) min-size))) - ;; - ;; Add the text properties and fontify. - (if (not font-lock-fontified) - (lazy-lock-after-fontify-buffer) - ;; Make sure we fontify in any existing windows showing the buffer. - (let ((windows (get-buffer-window-list (current-buffer) 'nomini t))) - (lazy-lock-after-unfontify-buffer) - (while windows - (lazy-lock-fontify-conservatively (car windows)) - (setq windows (cdr windows))))) - ;; - ;; Add the fontification hooks. - (lazy-lock-install-hooks - font-lock-fontified - (cond ((eq (car-safe defer-change) 'not) - (not (memq major-mode (cdr defer-change)))) - ((listp defer-change) - (memq major-mode defer-change)) - (t - defer-change)) - (eq defer-scroll t) - defer-context) - ;; - ;; Add the fontification timers. - (lazy-lock-install-timers - (if (or defer-change defer-scroll defer-context) lazy-lock-defer-time) - lazy-lock-stealth-time))) - -(defun lazy-lock-install-hooks (fontifying - defer-change defer-scroll defer-context) - ;; - ;; Add hook if lazy-lock.el is fontifying on scrolling or is deferring. - (when (or fontifying defer-change defer-scroll defer-context) - (add-hook 'window-scroll-functions (if defer-scroll - 'lazy-lock-defer-after-scroll - 'lazy-lock-fontify-after-scroll) - nil t)) - ;; - ;; Add hook if lazy-lock.el is fontifying and is not deferring changes. - (when (and fontifying (not defer-change) (not defer-context)) - (add-hook 'before-change-functions 'lazy-lock-arrange-before-change nil t)) - ;; - ;; Replace Font Lock mode hook. - (remove-hook 'after-change-functions 'font-lock-after-change-function t) - (add-hook 'after-change-functions - (cond ((and defer-change defer-context) - 'lazy-lock-defer-rest-after-change) - (defer-change - 'lazy-lock-defer-line-after-change) - (defer-context - 'lazy-lock-fontify-rest-after-change) - (t - 'lazy-lock-fontify-line-after-change)) - nil t) - ;; - ;; Add package-specific hook. - (add-hook 'outline-view-change-hook 'lazy-lock-fontify-after-visage nil t) - (add-hook 'hs-hide-hook 'lazy-lock-fontify-after-visage nil t)) - -(defun lazy-lock-install-timers (dtime stime) - ;; Schedule or re-schedule the deferral and stealth timers. - ;; The layout of `lazy-lock-timers' is: - ;; ((DEFER-TIME . DEFER-TIMER) (STEALTH-TIME . STEALTH-TIMER) - ;; If an idle timeout has changed, cancel the existing idle timer (if there - ;; is one) and schedule a new one (if the new idle timeout is non-nil). - (unless (eq dtime (car (car lazy-lock-timers))) - (let ((defer (car lazy-lock-timers))) - (when (cdr defer) - (cancel-timer (cdr defer))) - (setcar lazy-lock-timers (cons dtime (and dtime - (run-with-idle-timer dtime t 'lazy-lock-fontify-after-defer)))))) - (unless (eq stime (car (cdr lazy-lock-timers))) - (let ((stealth (cdr lazy-lock-timers))) - (when (cdr stealth) - (cancel-timer (cdr stealth))) - (setcdr lazy-lock-timers (cons stime (and stime - (run-with-idle-timer stime t 'lazy-lock-fontify-after-idle))))))) - -(defun lazy-lock-unstall () - ;; - ;; If Font Lock mode is still enabled, make sure that the buffer is - ;; fontified, and reinstall its hook. We must do this first. - (when font-lock-mode - (when (lazy-lock-unfontified-p) - (let ((verbose (if (numberp font-lock-verbose) - (> (buffer-size) font-lock-verbose) - font-lock-verbose))) - (with-temp-message - (when verbose - (format "Fontifying %s..." (buffer-name))) - ;; Make sure we fontify etc. in the whole buffer. - (save-restriction - (widen) - (lazy-lock-fontify-region (point-min) (point-max)))))) - (add-hook 'after-change-functions 'font-lock-after-change-function nil t)) - ;; - ;; Remove the text properties. - (lazy-lock-after-unfontify-buffer) - ;; - ;; Remove the fontification hooks. - (remove-hook 'window-scroll-functions 'lazy-lock-fontify-after-scroll t) - (remove-hook 'window-scroll-functions 'lazy-lock-defer-after-scroll t) - (remove-hook 'before-change-functions 'lazy-lock-arrange-before-change t) - (remove-hook 'after-change-functions 'lazy-lock-fontify-line-after-change t) - (remove-hook 'after-change-functions 'lazy-lock-fontify-rest-after-change t) - (remove-hook 'after-change-functions 'lazy-lock-defer-line-after-change t) - (remove-hook 'after-change-functions 'lazy-lock-defer-rest-after-change t) - (remove-hook 'outline-view-change-hook 'lazy-lock-fontify-after-visage t) - (remove-hook 'hs-hide-hook 'lazy-lock-fontify-after-visage t)) -\f -;; Hook functions. - -;; Lazy Lock mode intervenes when (1) a previously invisible buffer region -;; becomes visible, i.e., for demand- or defer-driven on-the-scroll -;; fontification, (2) a buffer modification occurs, i.e., for defer-driven -;; on-the-fly fontification, (3) Emacs becomes idle, i.e., for fontification of -;; deferred fontification and stealth fontification, and (4) other special -;; occasions. - -;; 1. There are three ways whereby this can happen. -;; -;; (a) Scrolling the window, either explicitly (e.g., `scroll-up') or -;; implicitly (e.g., `search-forward'). Here, `window-start' changes. -;; Fontification occurs by adding `lazy-lock-fontify-after-scroll' (for -;; demand-driven fontification) or `lazy-lock-defer-after-scroll' (for -;; defer-driven fontification) to the hook `window-scroll-functions'. - -(defun lazy-lock-fontify-after-scroll (window window-start) - ;; Called from `window-scroll-functions'. - ;; Fontify WINDOW from WINDOW-START following the scroll. - (let ((inhibit-point-motion-hooks t)) - (lazy-lock-fontify-region window-start (window-end window t))) - ;; A prior deletion that did not cause scrolling, followed by a scroll, would - ;; result in an unnecessary trigger after this if we did not cancel it now. - (set-window-redisplay-end-trigger window nil)) - -(defun lazy-lock-defer-after-scroll (window window-start) - ;; Called from `window-scroll-functions'. - ;; Defer fontification following the scroll. Save the current buffer so that - ;; we subsequently fontify in all windows showing the buffer. - (unless (memq (current-buffer) lazy-lock-buffers) - (push (current-buffer) lazy-lock-buffers)) - ;; A prior deletion that did not cause scrolling, followed by a scroll, would - ;; result in an unnecessary trigger after this if we did not cancel it now. - (set-window-redisplay-end-trigger window nil)) - -;; (b) Resizing the window, either explicitly (e.g., `enlarge-window') or -;; implicitly (e.g., `delete-other-windows'). Here, `window-end' changes. -;; Fontification occurs by adding `lazy-lock-fontify-after-resize' to the -;; hook `window-size-change-functions'. - -(defun lazy-lock-fontify-after-resize (frame) - ;; Called from `window-size-change-functions'. - ;; Fontify windows in FRAME following the resize. We cannot use - ;; `window-start' or `window-end' so we fontify conservatively. - (save-excursion - (save-selected-window - (select-frame frame) - (walk-windows (function (lambda (window) - (set-buffer (window-buffer window)) - (when lazy-lock-mode - (lazy-lock-fontify-conservatively window)) - (set-window-redisplay-end-trigger window nil))) - 'nomini frame)))) - -;; (c) Deletion in the buffer. Here, a `window-end' marker can become visible. -;; Fontification occurs by adding `lazy-lock-arrange-before-change' to -;; `before-change-functions' and `lazy-lock-fontify-after-trigger' to the -;; hook `redisplay-end-trigger-functions'. Before every deletion, the -;; marker `window-redisplay-end-trigger' position is set to the soon-to-be -;; changed `window-end' position. If the marker becomes visible, -;; `lazy-lock-fontify-after-trigger' gets called. Ouch. Note that we only -;; have to deal with this eventuality if there is no on-the-fly deferral. - -(defun lazy-lock-arrange-before-change (beg end) - ;; Called from `before-change-functions'. - ;; Arrange that if text becomes visible it will be fontified (if a deletion - ;; is pending, text might become visible at the bottom). - (unless (eq beg end) - (let ((windows (get-buffer-window-list (current-buffer) 'nomini t)) window) - (while windows - (setq window (car windows)) - (unless (markerp (window-redisplay-end-trigger window)) - (set-window-redisplay-end-trigger window (make-marker))) - (set-marker (window-redisplay-end-trigger window) (window-end window)) - (setq windows (cdr windows)))))) - -(defun lazy-lock-fontify-after-trigger (window trigger-point) - ;; Called from `redisplay-end-trigger-functions'. - ;; Fontify WINDOW from TRIGGER-POINT following the redisplay. - ;; We could probably just use `lazy-lock-fontify-after-scroll' without loss: - ;; (inline (lazy-lock-fontify-after-scroll window (window-start window))) - (let ((inhibit-point-motion-hooks t)) - (lazy-lock-fontify-region trigger-point (window-end window t)))) - -;; 2. Modified text must be marked as unfontified so it can be identified and -;; fontified later when Emacs is idle. Deferral occurs by adding one of -;; `lazy-lock-fontify-*-after-change' (for on-the-fly fontification) or -;; `lazy-lock-defer-*-after-change' (for deferred fontification) to the -;; hook `after-change-functions'. - -(defalias 'lazy-lock-fontify-line-after-change - ;; Called from `after-change-functions'. - ;; Fontify the current change. - 'font-lock-after-change-function) - -(defun lazy-lock-fontify-rest-after-change (beg end old-len) - ;; Called from `after-change-functions'. - ;; Fontify the current change and defer fontification of the rest of the - ;; buffer. Save the current buffer so that we subsequently fontify in all - ;; windows showing the buffer. - (lazy-lock-fontify-line-after-change beg end old-len) - (save-buffer-state nil - (unless (memq (current-buffer) lazy-lock-buffers) - (push (current-buffer) lazy-lock-buffers)) - (save-restriction - (widen) - (remove-text-properties end (point-max) '(lazy-lock nil))))) - -(defun lazy-lock-defer-line-after-change (beg end old-len) - ;; Called from `after-change-functions'. - ;; Defer fontification of the current change. Save the current buffer so - ;; that we subsequently fontify in all windows showing the buffer. - (save-buffer-state nil - (unless (memq (current-buffer) lazy-lock-buffers) - (push (current-buffer) lazy-lock-buffers)) - (remove-text-properties (max (1- beg) (point-min)) - (min (1+ end) (point-max)) - '(lazy-lock nil)))) - -(defun lazy-lock-defer-rest-after-change (beg end old-len) - ;; Called from `after-change-functions'. - ;; Defer fontification of the rest of the buffer. Save the current buffer so - ;; that we subsequently fontify in all windows showing the buffer. - (save-buffer-state nil - (unless (memq (current-buffer) lazy-lock-buffers) - (push (current-buffer) lazy-lock-buffers)) - (save-restriction - (widen) - (remove-text-properties (max (1- beg) (point-min)) - (point-max) - '(lazy-lock nil))))) - -;; 3. Deferred fontification and stealth fontification are done from these two -;; functions. They are set up as Idle Timers. - -(defun lazy-lock-fontify-after-defer () - ;; Called from `timer-idle-list'. - ;; Fontify all windows where deferral has occurred for its buffer. - (save-excursion - (while (and lazy-lock-buffers (not (input-pending-p))) - (let ((buffer (car lazy-lock-buffers)) windows) - ;; Paranoia: check that the buffer is still live and Lazy Lock mode on. - (when (buffer-live-p buffer) - (set-buffer buffer) - (when lazy-lock-mode - (setq windows (get-buffer-window-list buffer 'nomini t)) - (while windows - (lazy-lock-fontify-window (car windows)) - (setq windows (cdr windows))))) - (setq lazy-lock-buffers (cdr lazy-lock-buffers))))) - ;; Add hook if fontification should now be defer-driven in this buffer. - (when (and lazy-lock-mode lazy-lock-defer-on-scrolling - (memq 'lazy-lock-fontify-after-scroll window-scroll-functions) - (not (or (input-pending-p) (lazy-lock-unfontified-p)))) - (remove-hook 'window-scroll-functions 'lazy-lock-fontify-after-scroll t) - (add-hook 'window-scroll-functions 'lazy-lock-defer-after-scroll nil t))) - -(defun lazy-lock-fontify-after-idle () - ;; Called from `timer-idle-list'. - ;; Fontify all buffers that need it, stealthily while idle. - (unless (or executing-kbd-macro (window-minibuffer-p (selected-window))) - ;; Loop over all buffers, fontify stealthily for each if necessary. - (let ((buffers (buffer-list)) (continue t) - message message-log-max minibuffer-auto-raise) - (save-excursion - (do-while (and buffers continue) - (set-buffer (car buffers)) - (if (not (and lazy-lock-mode (lazy-lock-unfontified-p))) - (setq continue (not (input-pending-p))) - ;; Fontify regions in this buffer while there is no input. - (with-temp-message - (when lazy-lock-stealth-verbose - "Fontifying stealthily...") - (do-while (and (lazy-lock-unfontified-p) continue) - (if (and lazy-lock-stealth-load - (> (car (load-average)) lazy-lock-stealth-load)) - ;; Wait a while before continuing with the loop. - (progn - (when message - (message "Fontifying stealthily...suspended") - (setq message nil)) - (setq continue (sit-for (or lazy-lock-stealth-time 30)))) - ;; Fontify a chunk. - (when lazy-lock-stealth-verbose - (if message - (message "Fontifying stealthily... %2d%% of %s" - (lazy-lock-percent-fontified) (buffer-name)) - (message "Fontifying stealthily...") - (setq message t))) - ;; Current buffer may have changed during `sit-for'. - (set-buffer (car buffers)) - (lazy-lock-fontify-chunk) - (setq continue (sit-for (or lazy-lock-stealth-nice 0))))))) - (setq buffers (cdr buffers))))))) - -;; 4. Special circumstances. - -(defun lazy-lock-fontify-after-visage () - ;; Called from `outline-view-change-hook' and `hs-hide-hook'. - ;; Fontify windows showing the current buffer, as its visibility has changed. - ;; This is a conspiracy hack between lazy-lock.el, outline.el and - ;; hideshow.el. - (let ((windows (get-buffer-window-list (current-buffer) 'nomini t))) - (while windows - (lazy-lock-fontify-conservatively (car windows)) - (setq windows (cdr windows))))) - -(defun lazy-lock-after-fontify-buffer () - ;; Called from `font-lock-after-fontify-buffer'. - ;; Mark the current buffer as fontified. - ;; This is a conspiracy hack between lazy-lock.el and font-lock.el. - (save-buffer-state nil - (add-text-properties (point-min) (point-max) '(lazy-lock t)))) - -(defun lazy-lock-after-unfontify-buffer () - ;; Called from `font-lock-after-unfontify-buffer'. - ;; Mark the current buffer as unfontified. - ;; This is a conspiracy hack between lazy-lock.el and font-lock.el. - (save-buffer-state nil - (remove-text-properties (point-min) (point-max) '(lazy-lock nil)))) -\f -;; Fontification functions. - -;; If packages want to ensure that some region of the buffer is fontified, they -;; should use this function. For an example, see ps-print.el. -(defun lazy-lock-fontify-region (beg end) - ;; Fontify between BEG and END, where necessary, in the current buffer. - (save-restriction - (widen) - (when (setq beg (text-property-any beg end 'lazy-lock nil)) - (save-excursion - (save-match-data - (save-buffer-state - (next) - ;; Find successive unfontified regions between BEG and END. - (condition-case data - (do-while beg - (setq next (or (text-property-any beg end 'lazy-lock t) end)) - ;; Make sure the region end points are at beginning of line. - (goto-char beg) - (unless (bolp) - (beginning-of-line) - (setq beg (point))) - (goto-char next) - (unless (bolp) - (forward-line) - (setq next (point))) - ;; Fontify the region, then flag it as fontified. - (font-lock-fontify-region beg next) - (add-text-properties beg next '(lazy-lock t)) - (setq beg (text-property-any next end 'lazy-lock nil))) - ((error quit) (message "Fontifying region...%s" data))))))))) - -(defun lazy-lock-fontify-chunk () - ;; Fontify the nearest chunk, for stealth, in the current buffer. - (let ((inhibit-point-motion-hooks t)) - (save-excursion - (save-restriction - (widen) - ;; Move to end of line in case the character at point is not fontified. - (end-of-line) - ;; Find where the previous (next) unfontified regions end (begin). - (let ((prev (previous-single-property-change (point) 'lazy-lock)) - (next (text-property-any (point) (point-max) 'lazy-lock nil))) - ;; Fontify from the nearest unfontified position. - (if (or (null prev) (and next (< (- next (point)) (- (point) prev)))) - ;; The next, or neither, region is the nearest not fontified. - (lazy-lock-fontify-region - (progn (goto-char (or next (point-min))) - (beginning-of-line) - (point)) - (progn (goto-char (or next (point-min))) - (forward-line lazy-lock-stealth-lines) - (point))) - ;; The previous region is the nearest not fontified. - (lazy-lock-fontify-region - (progn (goto-char prev) - (forward-line (- lazy-lock-stealth-lines)) - (point)) - (progn (goto-char prev) - (forward-line) - (point))))))))) - -(defun lazy-lock-fontify-window (window) - ;; Fontify in WINDOW between `window-start' and `window-end'. - ;; We can only do this when we can use `window-start' and `window-end'. - (with-current-buffer (window-buffer window) - (lazy-lock-fontify-region (window-start window) (window-end window)))) - -(defun lazy-lock-fontify-conservatively (window) - ;; Fontify in WINDOW conservatively around point. - ;; Where we cannot use `window-start' and `window-end' we do `window-height' - ;; lines around point. That way we guarantee to have done enough. - (with-current-buffer (window-buffer window) - (let ((inhibit-point-motion-hooks t)) - (lazy-lock-fontify-region - (save-excursion - (goto-char (window-point window)) - (vertical-motion (- (window-height window)) window) (point)) - (save-excursion - (goto-char (window-point window)) - (vertical-motion (window-height window) window) (point)))))) - -(defun lazy-lock-unfontified-p () - ;; Return non-nil if there is anywhere still to be fontified. - (save-restriction - (widen) - (text-property-any (point-min) (point-max) 'lazy-lock nil))) - -(defun lazy-lock-percent-fontified () - ;; Return the percentage (of characters) of the buffer that are fontified. - (save-restriction - (widen) - (let ((beg (point-min)) (size 0) next) - ;; Find where the next fontified region begins. - (while (setq beg (text-property-any beg (point-max) 'lazy-lock t)) - (setq next (or (text-property-any beg (point-max) 'lazy-lock nil) - (point-max))) - (cl-incf size (- next beg)) - (setq beg next)) - ;; Float because using integer multiplication will frequently overflow. - (truncate (* (/ (float size) (point-max)) 100))))) -\f -;; Version dependent workarounds and fixes. - -(when (consp lazy-lock-defer-time) - ;; - ;; In 2.06.04 and below, `lazy-lock-defer-time' could specify modes and time. - (with-output-to-temp-buffer "*Help*" - (princ "The value of the variable `lazy-lock-defer-time' was\n ") - (princ lazy-lock-defer-time) - (princ "\n") - (princ "This variable cannot now be a list of modes and time,\n") - (princ "so instead use ") - (princ (substitute-command-keys "\\[customize-option]")) - (princ " to modify the variables, or put the forms:\n") - (princ " (setq lazy-lock-defer-time ") - (princ (cdr lazy-lock-defer-time)) - (princ ")\n") - (princ " (setq lazy-lock-defer-on-the-fly '") - (princ (car lazy-lock-defer-time)) - (princ ")\n") - (princ "in your ~/.emacs. ") - (princ "The above forms have been evaluated for this editor session,\n") - (princ "but you should use ") - (princ (substitute-command-keys "\\[customize-option]")) - (princ " or change your ~/.emacs now.")) - (setq lazy-lock-defer-on-the-fly (car lazy-lock-defer-time) - lazy-lock-defer-time (cdr lazy-lock-defer-time))) - -(when (boundp 'lazy-lock-defer-driven) - ;; - ;; In 2.06.04 and below, `lazy-lock-defer-driven' was the variable name. - (with-output-to-temp-buffer "*Help*" - (princ "The value of the variable `lazy-lock-defer-driven' is set to ") - (if (memq lazy-lock-defer-driven '(nil t)) - (princ lazy-lock-defer-driven) - (princ "`") - (princ lazy-lock-defer-driven) - (princ "'")) - (princ ".\n") - (princ "This variable is now called `lazy-lock-defer-on-scrolling',\n") - (princ "so instead use ") - (princ (substitute-command-keys "\\[customize-option]")) - (princ " to modify the variable, or put the form:\n") - (princ " (setq lazy-lock-defer-on-scrolling ") - (unless (memq lazy-lock-defer-driven '(nil t)) - (princ "'")) - (princ lazy-lock-defer-driven) - (princ ")\n") - (princ "in your ~/.emacs. ") - (princ "The above form has been evaluated for this editor session,\n") - (princ "but you should use ") - (princ (substitute-command-keys "\\[customize-option]")) - (princ " or change your ~/.emacs now.")) - (setq lazy-lock-defer-on-scrolling lazy-lock-defer-driven)) -\f -;; Install ourselves: - -(add-hook 'window-size-change-functions 'lazy-lock-fontify-after-resize) -(add-hook 'redisplay-end-trigger-functions 'lazy-lock-fontify-after-trigger) - -(unless (assq 'lazy-lock-mode minor-mode-alist) - (setq minor-mode-alist (append minor-mode-alist '((lazy-lock-mode nil))))) - -;; Provide ourselves: - -(provide 'lazy-lock) - -;; Local Variables: -;; byte-compile-warnings: (not obsolete) -;; End: - -;;; lazy-lock.el ends here diff --git a/lisp/progmodes/antlr-mode.el b/lisp/progmodes/antlr-mode.el index bf56a7ee49..7864485895 100644 --- a/lisp/progmodes/antlr-mode.el +++ b/lisp/progmodes/antlr-mode.el @@ -75,9 +75,6 @@ ;; (add-hook 'speedbar-load-hook ; would be too late in antlr-mode.el ;; (lambda () (speedbar-add-supported-extension ".g"))) -;; I strongly recommend to use font-lock with a support mode like fast-lock, -;; lazy-lock or better jit-lock (Emacs-21.1+) / lazy-shot (XEmacs). - ;; To customize, use menu item "Antlr" -> "Customize Antlr". ;;; Code: diff --git a/lisp/progmodes/cc-fonts.el b/lisp/progmodes/cc-fonts.el index 386cc2f16f..15f303c756 100644 --- a/lisp/progmodes/cc-fonts.el +++ b/lisp/progmodes/cc-fonts.el @@ -1430,7 +1430,7 @@ c-font-lock-declarations )) ;; Below we fontify a whole declaration even when it crosses the limit, - ;; to avoid gaps when jit/lazy-lock fontifies the file a block at a + ;; to avoid gaps when jit-lock fontifies the file a block at a ;; time. That is however annoying during editing, e.g. the following is ;; a common situation while the first line is being written: ;; diff --git a/lisp/progmodes/cperl-mode.el b/lisp/progmodes/cperl-mode.el index 6122caf518..648fbf43c3 100644 --- a/lisp/progmodes/cperl-mode.el +++ b/lisp/progmodes/cperl-mode.el @@ -49,8 +49,6 @@ ;; `cperl-praise', `cperl-speed'. <<<<<< ;; The mode information (on C-h m) provides some customization help. -;; If you use font-lock feature of this mode, it is advisable to use -;; either lazy-lock-mode or fast-lock-mode. I prefer lazy-lock. ;; Faces used now: three faces for first-class and second-class keywords ;; and control flow words, one for each: comments, string, labels, diff --git a/lisp/ps-print.el b/lisp/ps-print.el index ace3001781..367495f5bd 100644 --- a/lisp/ps-print.el +++ b/lisp/ps-print.el @@ -6331,14 +6331,11 @@ ps-screen-to-bit-face (declare-function jit-lock-fontify-now "jit-lock" (&optional start end)) -(declare-function lazy-lock-fontify-region "lazy-lock" (beg end)) ;; to avoid compilation gripes (defun ps-print-ensure-fontified (start end) (cond ((and (boundp 'jit-lock-mode) (symbol-value 'jit-lock-mode)) - (jit-lock-fontify-now start end)) - ((and (boundp 'lazy-lock-mode) (symbol-value 'lazy-lock-mode)) - (lazy-lock-fontify-region start end)))) + (jit-lock-fontify-now start end)))) (defun ps-generate-postscript-with-faces (from to) diff --git a/src/buffer.c b/src/buffer.c index 241f2d43a9..e4eb6d6741 100644 --- a/src/buffer.c +++ b/src/buffer.c @@ -1398,13 +1398,13 @@ DEFUN ("set-buffer-modified-p", Fset_buffer_modified_p, Sset_buffer_modified_p, { Frestore_buffer_modified_p (flag); - /* Set update_mode_lines only if buffer is displayed in some window. - Packages like jit-lock or lazy-lock preserve a buffer's modified - state by recording/restoring the state around blocks of code. - Setting update_mode_lines makes redisplay consider all windows - (on all frames). Stealth fontification of buffers not displayed - would incur additional redisplay costs if we'd set - update_modes_lines unconditionally. + /* Set update_mode_lines only if buffer is displayed in some + window. Packages like jit-lock preserve a buffer's modified state + by recording/restoring the state around blocks of code. Setting + update_mode_lines makes redisplay consider all windows (on all + frames). Stealth fontification of buffers not displayed would + incur additional redisplay costs if we'd set update_modes_lines + unconditionally. Ideally, I think there should be another mechanism for fontifying buffers without "modifying" buffers, or redisplay should be -- 2.27.0 ^ permalink raw reply related [flat|nested] 838+ messages in thread
* Re: [PATCH] Remove obsolete fast-lock and lazy-lock libraries 2020-08-07 15:42 ` [PATCH] Remove obsolete fast-lock and lazy-lock libraries (was: Re: Deleting old `:version` from defcustoms) Stefan Kangas @ 2020-08-08 2:19 ` Stefan Monnier 0 siblings, 0 replies; 838+ messages in thread From: Stefan Monnier @ 2020-08-08 2:19 UTC (permalink / raw) To: Stefan Kangas; +Cc: Emacs developers >> There are also these two libraries: >> ./lisp/obsolete/fast-lock.el9:;; Obsolete-since: 22.1 >> ./lisp/obsolete/lazy-lock.el9:;; Obsolete-since: 22.1 > I have attached a patch to remove them below. LGTM. > ;; to avoid compilation gripes > (defun ps-print-ensure-fontified (start end) > (cond ((and (boundp 'jit-lock-mode) (symbol-value 'jit-lock-mode)) > - (jit-lock-fontify-now start end)) > - ((and (boundp 'lazy-lock-mode) (symbol-value 'lazy-lock-mode)) > - (lazy-lock-fontify-region start end)))) > + (jit-lock-fontify-now start end)))) I think this can be replaced by `font-lock-ensure`, but it probably requires additional tests to be sure, so maybe keep the code as is and just add a FIXME. Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Delete variables obsolete since Emacs 23 2020-05-15 18:38 ` Deleting old `:version` from defcustoms (was: master b76cdd0: Delete libraries obsolete since 23.1 and 23.2) Stefan Monnier 2020-05-15 20:58 ` Stefan Kangas @ 2020-05-16 13:18 ` Stefan Kangas 2020-05-16 15:49 ` Paul Eggert ` (2 more replies) 2020-05-17 3:18 ` Deleting old `:version` from defcustoms (was: master b76cdd0: Delete libraries obsolete since 23.1 and 23.2) Stefan Kangas 2 siblings, 3 replies; 838+ messages in thread From: Stefan Kangas @ 2020-05-16 13:18 UTC (permalink / raw) To: Stefan Monnier, emacs-devel [-- Attachment #1: Type: text/plain, Size: 1144 bytes --] I've attached a patch which removes most variables declared obsolete in Emacs 23.1. I tried following the style in Glenn's commit f1c48b0ec5 which does the same for Emacs 22.1. 1. There is a small number of variables declared obsolete in 23.2, 23.3 and 23.4. I think we can remove them in a subsequent patch. 2. I was not able to untangle how to remove this, and so left it alone for now: * lisp/net/newst-backend.el (newsticker-cache-filename) 3. Note the added FIXME in `vc-default-working-revision', where I'm not sure if it should be declared obsolete or not. See Stefan M's commit 6e5d0e9e73. 4. The variable `translation-table-for-input' was declared obsolete with in Emacs 23.1 and has the following comment. I'm not sure what to do about it, if anything. ;; This was introduced in 21.4 for pre-unicode unification. That ;; usage was rendered obsolete in 23.1, which uses Unicode internally. ;; Other uses are possible, so this variable is not _really_ obsolete, ;; but Stefan insists to mark it so. Other than that, does the attached patch look okay for master? Best regards, Stefan Kangas [-- Attachment #2: 0001-Remove-many-items-obsolete-since-Emacs-23.1.patch --] [-- Type: text/x-diff, Size: 50121 bytes --] From 993fd6697972f99d503385aec1f5012a573af41c Mon Sep 17 00:00:00 2001 From: Stefan Kangas <stefankangas@gmail.com> Date: Sat, 16 May 2020 14:16:24 +0200 Subject: [PATCH] Remove many items obsolete since Emacs 23.1 Emacs 23.1 was five major releases and over a decade ago. This list can be reviewed before to the next release, but for now hopefully this motivates any needed external updates. * lisp/abbrev.el (pre-abbrev-expand-hook): * lisp/bookmark.el (bookmark-read-annotation-text-func) (bookmark-jump-noselect): * lisp/buff-menu.el (buffer-menu-mode-hook): * lisp/cus-edit.el (custom-mode-hook, custom-mode): * lisp/dirtrack.el (dirtrack-debug-toggle, dirtrack-debug): * lisp/emacs-lisp/crm.el (crm-minibuffer-complete) (crm-minibuffer-completion-help) (crm-minibuffer-complete-and-exit): * lisp/emacs-lisp/easymenu.el (easy-menu-precalculate-equivalent-keybindings): * lisp/emacs-lisp/lisp-mode.el (lisp-mode-auto-fill): * lisp/epa.el (epa-display-verify-result): * lisp/epg.el (epg-passphrase-callback-function): * lisp/eshell/eshell.el (eshell-report-bug): * lisp/ffap.el (ffap-bug, ffap-submit-bug): * lisp/files.el (locate-file-completion): * lisp/hi-lock.el (hi-lock-face-history, hi-lock-regexp-history): * lisp/hilit-chg.el (highlight-changes-initial-state) (highlight-changes-active-string) (highlight-changes-passive-string, global-highlight-changes): * lisp/international/mule-cmds.el (nonascii-insert-offset) (nonascii-translation-table): * lisp/international/mule-diag.el (non-iso-charset-alist): * lisp/international/mule-util.el (detect-coding-with-priority): * lisp/international/mule.el (charset-id, charset-bytes) (charset-list, char-valid-p, generic-char-p) (char-coding-system-table, make-coding-system) (set-coding-priority) * lisp/mail/rmail.el (rmail-message-filter): * lisp/minibuffer.el (complete-in-turn, dynamic-completion-table) (completion-common-substring) (minibuffer-local-must-match-filename-map): * lisp/mouse.el (mouse-major-mode-menu, mouse-popup-menubar) (mouse-popup-menubar-stuff): * lisp/net/newst-treeview.el (newsticker-groups-filename): * lisp/obsolete/tpu-edt.el (tpu-have-ispell, GOLD-map): * lisp/obsolete/vc-arch.el (vc-arch-command): * lisp/password-cache.el (password-read-and-add): * lisp/shell.el (shell-dirtrack-toggle): * lisp/subr.el (forward-point, define-key-rebound-commands) (redisplay-end-trigger-functions, window-redisplay-end-trigger) (set-window-redisplay-end-trigger, process-filter-multibyte-p) (set-process-filter-multibyte): * lisp/t-mouse.el (t-mouse-mode): * lisp/term/w32-win.el (w32-focus-frame, w32-select-font): * lisp/textmodes/ispell.el (ispell-aspell-supports-utf8): * lisp/textmodes/remember.el (remember-buffer): * lisp/tooltip.el (tooltip-hook): * lisp/url/url-util.el (url-generate-unique-filename): * lisp/url/url-vars.el (url-temporary-directory): * lisp/vc/vc-hooks.el (vc-workfile-version): * lisp/vc/vc-mtn.el (vc-mtn-command): * lisp/vc/vc.el (vc-revert-buffer): * lisp/vcursor.el (vcursor-toggle-vcursor-map): Remove items, obsolete since Emacs 23.1. * lisp/abbrev.el (expand-abbrev): Don't run removed hook 'pre-abbrev-expand-hook'. * lisp/cedet/semantic/wisent/wisent.el: * lisp/progmodes/idlwave.el: Update reference to removed function 'char-valid-p'. * lisp/gnus/mml2015.el (epg-encrypt-string): * lisp/gnus/mml1991.el (epg-make-context): * lisp/gnus/mml-smime.el (autoload): Remove autoload of removed 'epg-passphrase-callback-function'. * lisp/minibuffer.el (completion-extra-properties): Remove support for `completion-common-substring'. * lisp/obsolete/tpu-edt.el (tpu-toggle-overwrite-mode) Remove support for removed `spell' package. ; * etc/NEWS: List removed items. --- etc/NEWS | 34 +++++++ lisp/abbrev.el | 10 -- lisp/bookmark.el | 13 --- lisp/buff-menu.el | 3 - lisp/cedet/semantic/wisent/wisent.el | 6 +- lisp/cus-edit.el | 4 - lisp/dirtrack.el | 3 - lisp/emacs-lisp/crm.el | 6 -- lisp/emacs-lisp/easymenu.el | 10 -- lisp/emacs-lisp/lisp-mode.el | 2 - lisp/epa.el | 4 - lisp/epg.el | 13 --- lisp/eshell/eshell.el | 9 -- lisp/ffap.el | 6 -- lisp/files.el | 8 -- lisp/gnus/mml-smime.el | 1 - lisp/gnus/mml1991.el | 1 - lisp/gnus/mml2015.el | 1 - lisp/hi-lock.el | 6 -- lisp/hilit-chg.el | 16 ---- lisp/international/mule-cmds.el | 5 - lisp/international/mule-diag.el | 4 - lisp/international/mule-util.el | 9 -- lisp/international/mule.el | 134 --------------------------- lisp/mail/rmail.el | 19 ---- lisp/minibuffer.el | 18 +--- lisp/mouse.el | 28 ------ lisp/net/newst-treeview.el | 30 +----- lisp/obsolete/tpu-edt.el | 12 +-- lisp/obsolete/vc-arch.el | 2 - lisp/password-cache.el | 16 ---- lisp/progmodes/idlwave.el | 2 - lisp/shell.el | 3 - lisp/subr.el | 11 --- lisp/t-mouse.el | 2 - lisp/term/w32-win.el | 4 - lisp/textmodes/ispell.el | 9 -- lisp/textmodes/remember.el | 3 - lisp/tooltip.el | 2 - lisp/url/url-util.el | 25 ----- lisp/url/url-vars.el | 7 -- lisp/vc/vc-hooks.el | 3 +- lisp/vc/vc-mtn.el | 1 - lisp/vc/vc.el | 3 - lisp/vcursor.el | 3 - 45 files changed, 41 insertions(+), 470 deletions(-) diff --git a/etc/NEWS b/etc/NEWS index b93199f362..0e3791e13a 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -401,6 +401,40 @@ Use macro 'with-current-buffer-window' with action alist entry 'body-function'. ** Some libraries obsolete since Emacs 23 have been removed: 'ledit.el', 'lmenu.el', 'lucid.el and 'old-whitespace.el'. +--- +** Some functions and variables obsolete since Emacs 23 have been removed: +'GOLD-map', 'bookmark-jump-noselect', +'bookmark-read-annotation-text-func', 'buffer-menu-mode-hook', +'char-coding-system-table', 'char-valid-p', 'charset-bytes', +'charset-id', 'charset-list', 'complete-in-turn', +'completion-common-substring', 'crm-minibuffer-complete', +'crm-minibuffer-complete-and-exit', 'crm-minibuffer-completion-help', +'custom-mode', 'custom-mode-hook', 'define-key-rebound-commands', +'detect-coding-with-priority', 'dirtrack-debug', +'dirtrack-debug-toggle', 'dynamic-completion-table', +'easy-menu-precalculate-equivalent-keybindings', +'epa-display-verify-result', 'epg-passphrase-callback-function', +'eshell-report-bug', 'ffap-bug', 'ffap-submit-bug', 'forward-point', +'generic-char-p', 'global-highlight-changes', 'hi-lock-face-history', +'hi-lock-regexp-history', 'highlight-changes-active-string', +'highlight-changes-initial-state', 'highlight-changes-passive-string', +'ispell-aspell-supports-utf8', 'lisp-mode-auto-fill', +'locate-file-completion', 'make-coding-system', +'minibuffer-local-must-match-filename-map', 'mouse-major-mode-menu', +'mouse-popup-menubar', 'mouse-popup-menubar-stuff', +'newsticker-groups-filename', 'non-iso-charset-alist', +'nonascii-insert-offset', 'nonascii-translation-table', +'password-read-and-add', 'pre-abbrev-expand-hook', +'process-filter-multibyte-p', 'redisplay-end-trigger-functions', +'remember-buffer', 'rmail-message-filter', 'set-coding-priority', +'set-process-filter-multibyte', 'set-window-redisplay-end-trigger', +'shell-dirtrack-toggle', 't-mouse-mode', 'tooltip-hook', +'tpu-have-ispell', 'url-generate-unique-filename', +'url-temporary-directory', 'vc-arch-command', 'vc-mtn-command', +'vc-revert-buffer', 'vc-workfile-version', +'vcursor-toggle-vcursor-map', 'w32-focus-frame', 'w32-select-font', +'window-redisplay-end-trigger'. + \f * Lisp Changes in Emacs 28.1 diff --git a/lisp/abbrev.el b/lisp/abbrev.el index 190b3504fa..6fcaa52d46 100644 --- a/lisp/abbrev.el +++ b/lisp/abbrev.el @@ -521,14 +521,6 @@ last-abbrev-location ;; "Local (mode-specific) abbrev table of current buffer.") ;; (make-variable-buffer-local 'local-abbrev-table) -(defcustom pre-abbrev-expand-hook nil - "Function or functions to be called before abbrev expansion is done. -This is the first thing that `expand-abbrev' does, and so this may change -the current abbrev table before abbrev lookup happens." - :type 'hook - :group 'abbrev-mode) -(make-obsolete-variable 'pre-abbrev-expand-hook 'abbrev-expand-function "23.1") - (defun clear-abbrev-table (table) "Undefine all abbrevs in abbrev table TABLE, leaving it empty." (setq abbrevs-changed t) @@ -840,12 +832,10 @@ abbrev-expand-function (defun expand-abbrev () "Expand the abbrev before point, if there is an abbrev there. Effective when explicitly called even when `abbrev-mode' is nil. -Before doing anything else, runs `pre-abbrev-expand-hook'. Calls the value of `abbrev-expand-function' with no argument to do the work, and returns whatever it does. (That return value should be the abbrev symbol if expansion occurred, else nil.)" (interactive) - (run-hooks 'pre-abbrev-expand-hook) (funcall abbrev-expand-function)) (defun abbrev--default-expand () diff --git a/lisp/bookmark.el b/lisp/bookmark.el index 0fa77ed322..f4580cd36e 100644 --- a/lisp/bookmark.el +++ b/lisp/bookmark.el @@ -922,8 +922,6 @@ bookmark-default-annotation-text "# Date: " (current-time-string) "\n")) -(define-obsolete-variable-alias 'bookmark-read-annotation-text-func - 'bookmark-edit-annotation-text-func "23.1") (defvar bookmark-edit-annotation-text-func 'bookmark-default-annotation-text "Function to return default text to use for a bookmark annotation. It takes one argument, the name of the bookmark, as a string.") @@ -1142,17 +1140,6 @@ bookmark-jump-other-frame (let ((pop-up-frames t)) (bookmark-jump-other-window bookmark))) -(defun bookmark-jump-noselect (bookmark) - "Return the location pointed to by BOOKMARK (see `bookmark-jump'). -The return value has the form (BUFFER . POINT). - -Note: this function is deprecated and is present for Emacs 22 -compatibility only." - (declare (obsolete bookmark-handle-bookmark "23.1")) - (save-excursion - (bookmark-handle-bookmark bookmark) - (cons (current-buffer) (point)))) - (defun bookmark-handle-bookmark (bookmark-name-or-record) "Call BOOKMARK-NAME-OR-RECORD's handler or `bookmark-default-handler' if it has none. This changes current buffer and point and returns nil, diff --git a/lisp/buff-menu.el b/lisp/buff-menu.el index 655a76a713..9f8cdce4a2 100644 --- a/lisp/buff-menu.el +++ b/lisp/buff-menu.el @@ -214,9 +214,6 @@ Buffer-menu-mode-map map) "Local keymap for `Buffer-menu-mode' buffers.") -(define-obsolete-variable-alias 'buffer-menu-mode-hook - 'Buffer-menu-mode-hook "23.1") - (define-derived-mode Buffer-menu-mode tabulated-list-mode "Buffer Menu" "Major mode for Buffer Menu buffers. The Buffer Menu is invoked by the commands \\[list-buffers], diff --git a/lisp/cedet/semantic/wisent/wisent.el b/lisp/cedet/semantic/wisent/wisent.el index d8a35d3e7d..3ec1cae020 100644 --- a/lisp/cedet/semantic/wisent/wisent.el +++ b/lisp/cedet/semantic/wisent/wisent.el @@ -55,10 +55,10 @@ wisent ;;;; Runtime stuff ;;;; ------------- -;;; Compatibility +;;; XEmacs Compatibility (eval-and-compile - (if (fboundp 'char-valid-p) - (defalias 'wisent-char-p 'char-valid-p) + (if (fboundp 'characterp) + (defalias 'wisent-char-p 'characterp) (defalias 'wisent-char-p 'char-or-char-int-p))) ;;; Printed representation of terminals and nonterminals diff --git a/lisp/cus-edit.el b/lisp/cus-edit.el index 1ec2708550..171c27c945 100644 --- a/lisp/cus-edit.el +++ b/lisp/cus-edit.el @@ -4864,8 +4864,6 @@ Custom-goto-parent (parent (downcase (widget-get button :tag)))) (customize-group parent))))) -(define-obsolete-variable-alias 'custom-mode-hook 'Custom-mode-hook "23.1") - (defcustom Custom-mode-hook nil "Hook called when entering Custom mode." :type 'hook @@ -4936,8 +4934,6 @@ Custom-mode (put 'Custom-mode 'mode-class 'special) -(define-obsolete-function-alias 'custom-mode 'Custom-mode "23.1") - ;;; The End. (provide 'cus-edit) diff --git a/lisp/dirtrack.el b/lisp/dirtrack.el index 3a0bbd2c9c..ad0c18d1b3 100644 --- a/lisp/dirtrack.el +++ b/lisp/dirtrack.el @@ -196,9 +196,6 @@ dirtrack-mode (remove-hook 'comint-preoutput-filter-functions 'dirtrack t))) -(define-obsolete-function-alias 'dirtrack-debug-toggle 'dirtrack-debug-mode - "23.1") -(define-obsolete-variable-alias 'dirtrack-debug 'dirtrack-debug-mode "23.1") (define-minor-mode dirtrack-debug-mode "Toggle Dirtrack debugging." nil nil nil diff --git a/lisp/emacs-lisp/crm.el b/lisp/emacs-lisp/crm.el index 65483d0813..89d106ee48 100644 --- a/lisp/emacs-lisp/crm.el +++ b/lisp/emacs-lisp/crm.el @@ -270,12 +270,6 @@ completing-read-multiple (remove-hook 'choose-completion-string-functions 'crm--choose-completion-string))) -(define-obsolete-function-alias 'crm-minibuffer-complete 'crm-complete "23.1") -(define-obsolete-function-alias - 'crm-minibuffer-completion-help 'crm-completion-help "23.1") -(define-obsolete-function-alias - 'crm-minibuffer-complete-and-exit 'crm-complete-and-exit "23.1") - ;; testing and debugging ;; (defun crm-init-test-environ () ;; "Set up some variables for testing." diff --git a/lisp/emacs-lisp/easymenu.el b/lisp/emacs-lisp/easymenu.el index 6ba8b997f8..73dabef3fa 100644 --- a/lisp/emacs-lisp/easymenu.el +++ b/lisp/emacs-lisp/easymenu.el @@ -29,16 +29,6 @@ ;;; Code: -(defvar easy-menu-precalculate-equivalent-keybindings nil - "Determine when equivalent key bindings are computed for easy-menu menus. -It can take some time to calculate the equivalent key bindings that are shown -in a menu. If the variable is on, then this calculation gives a (maybe -noticeable) delay when a mode is first entered. If the variable is off, then -this delay will come when a menu is displayed the first time. If you never use -menus, turn this variable off, otherwise it is probably better to keep it on.") -(make-obsolete-variable - 'easy-menu-precalculate-equivalent-keybindings nil "23.1") - (defsubst easy-menu-intern (s) (if (stringp s) (intern s) s)) diff --git a/lisp/emacs-lisp/lisp-mode.el b/lisp/emacs-lisp/lisp-mode.el index 7098a41f27..8d3b357a7f 100644 --- a/lisp/emacs-lisp/lisp-mode.el +++ b/lisp/emacs-lisp/lisp-mode.el @@ -785,8 +785,6 @@ lisp-comment-indent nil))) (comment-indent-default))) -(define-obsolete-function-alias 'lisp-mode-auto-fill 'do-auto-fill "23.1") - (defcustom lisp-indent-offset nil "If non-nil, indent second line of expressions that many more columns." :group 'lisp diff --git a/lisp/epa.el b/lisp/epa.el index 8ec4218735..68c472f3f5 100644 --- a/lisp/epa.el +++ b/lisp/epa.el @@ -631,10 +631,6 @@ epa-display-error (goto-char (point-min))) (display-buffer buffer))))) -(defun epa-display-verify-result (verify-result) - (declare (obsolete epa-display-info "23.1")) - (epa-display-info (epg-verify-result-to-string verify-result))) - (defun epa-passphrase-callback-function (context key-id handback) (if (eq key-id 'SYM) (read-passwd diff --git a/lisp/epg.el b/lisp/epg.el index 222fd913e1..603415f0ec 100644 --- a/lisp/epg.el +++ b/lisp/epg.el @@ -1234,19 +1234,6 @@ epg--status-IMPORT_RES (epg-context-result-for context 'import-status))) (epg-context-set-result-for context 'import-status nil))) -(defun epg-passphrase-callback-function (context key-id _handback) - (declare (obsolete epa-passphrase-callback-function "23.1")) - (if (eq key-id 'SYM) - (read-passwd "Passphrase for symmetric encryption: " - (eq (epg-context-operation context) 'encrypt)) - (read-passwd - (if (eq key-id 'PIN) - "Passphrase for PIN: " - (let ((entry (assoc key-id epg-user-id-alist))) - (if entry - (format "Passphrase for %s %s: " key-id (cdr entry)) - (format "Passphrase for %s: " key-id))))))) - (defun epg--list-keys-1 (context name mode) (let ((args (append (if (epg-context-home-directory context) (list "--homedir" diff --git a/lisp/eshell/eshell.el b/lisp/eshell/eshell.el index 2a63882ff0..7f94c9ba63 100644 --- a/lisp/eshell/eshell.el +++ b/lisp/eshell/eshell.el @@ -380,15 +380,6 @@ eshell-command-result (set status-var eshell-last-command-status)) (cadr result)))))) -;;;_* Reporting bugs -;; -;; If you do encounter a bug, on any system, please report -;; it -- in addition to any particular oddities in your configuration -;; -- so that the problem may be corrected for the benefit of others. - -;;;###autoload -(define-obsolete-function-alias 'eshell-report-bug 'report-emacs-bug "23.1") - ;;; Code: (defun eshell-unload-all-modules () diff --git a/lisp/ffap.el b/lisp/ffap.el index d656b37372..c26fb5420b 100644 --- a/lisp/ffap.el +++ b/lisp/ffap.el @@ -1814,12 +1814,6 @@ ffap-literally (defalias 'find-file-literally-at-point 'ffap-literally) -\f -;;; Bug Reporter: - -(define-obsolete-function-alias 'ffap-bug 'report-emacs-bug "23.1") -(define-obsolete-function-alias 'ffap-submit-bug 'report-emacs-bug "23.1") - \f ;;; Hooks for Gnus, VM, Rmail: ;; diff --git a/lisp/files.el b/lisp/files.el index dba704f7a4..c2f37c178d 100644 --- a/lisp/files.el +++ b/lisp/files.el @@ -972,14 +972,6 @@ locate-file-completion-table (completion-table-with-context string-dir names string-file pred action))))) -(defun locate-file-completion (string path-and-suffixes action) - "Do completion for file names passed to `locate-file'. -PATH-AND-SUFFIXES is a pair of lists, (DIRECTORIES . SUFFIXES)." - (declare (obsolete locate-file-completion-table "23.1")) - (locate-file-completion-table (car path-and-suffixes) - (cdr path-and-suffixes) - string nil action)) - (defvar locate-dominating-stop-dir-regexp (purecopy "\\`\\(?:[\\/][\\/][^\\/]+[\\/]\\|/\\(?:net\\|afs\\|\\.\\.\\.\\)/\\)\\'") "Regexp of directory names that stop the search in `locate-dominating-file'. diff --git a/lisp/gnus/mml-smime.el b/lisp/gnus/mml-smime.el index 4754f37a2d..acddb30033 100644 --- a/lisp/gnus/mml-smime.el +++ b/lisp/gnus/mml-smime.el @@ -329,7 +329,6 @@ password-cache-expiry (autoload 'epg-verify-string "epg") (autoload 'epg-sign-string "epg") (autoload 'epg-encrypt-string "epg") - (autoload 'epg-passphrase-callback-function "epg") (autoload 'epg-context-set-passphrase-callback "epg") (autoload 'epg-sub-key-fingerprint "epg") (autoload 'epg-configuration "epg-config") diff --git a/lisp/gnus/mml1991.el b/lisp/gnus/mml1991.el index 8be1b84e52..88864ea357 100644 --- a/lisp/gnus/mml1991.el +++ b/lisp/gnus/mml1991.el @@ -242,7 +242,6 @@ mml1991-pgg-encrypt (defvar epg-user-id-alist) (autoload 'epg-make-context "epg") -(autoload 'epg-passphrase-callback-function "epg") (autoload 'epa-select-keys "epa") (autoload 'epg-list-keys "epg") (autoload 'epg-context-set-armor "epg") diff --git a/lisp/gnus/mml2015.el b/lisp/gnus/mml2015.el index d1d150ad2e..45c9bbfe90 100644 --- a/lisp/gnus/mml2015.el +++ b/lisp/gnus/mml2015.el @@ -712,7 +712,6 @@ inhibit-redisplay (autoload 'epg-verify-string "epg") (autoload 'epg-sign-string "epg") (autoload 'epg-encrypt-string "epg") -(autoload 'epg-passphrase-callback-function "epg") (autoload 'epg-context-set-passphrase-callback "epg") (autoload 'epg-key-sub-key-list "epg") (autoload 'epg-sub-key-capability "epg") diff --git a/lisp/hi-lock.el b/lisp/hi-lock.el index a18310322a..27bd316621 100644 --- a/lisp/hi-lock.el +++ b/lisp/hi-lock.el @@ -237,17 +237,11 @@ hi-lock-interactive-lighters "Human-readable lighters for `hi-lock-interactive-patterns'.") (put 'hi-lock-interactive-lighters 'permanent-local t) -(define-obsolete-variable-alias 'hi-lock-face-history - 'hi-lock-face-defaults "23.1") (defvar hi-lock-face-defaults '("hi-yellow" "hi-pink" "hi-green" "hi-blue" "hi-salmon" "hi-aquamarine" "hi-black-b" "hi-blue-b" "hi-red-b" "hi-green-b" "hi-black-hb") "Default faces for hi-lock interactive functions.") -(define-obsolete-variable-alias 'hi-lock-regexp-history - 'regexp-history - "23.1") - (defvar hi-lock-file-patterns-prefix "Hi-lock" "String used to identify hi-lock patterns at the start of files.") diff --git a/lisp/hilit-chg.el b/lisp/hilit-chg.el index 04a5ccd8d5..ae97bb008a 100644 --- a/lisp/hilit-chg.el +++ b/lisp/hilit-chg.el @@ -224,9 +224,6 @@ highlight-changes-colors ;; When you invoke highlight-changes-mode, should highlight-changes-visible-mode ;; be on or off? -(define-obsolete-variable-alias 'highlight-changes-initial-state - 'highlight-changes-visibility-initial-state "23.1") - (defcustom highlight-changes-visibility-initial-state t "Controls whether changes are initially visible in Highlight Changes mode. @@ -236,13 +233,7 @@ highlight-changes-visibility-initial-state :type 'boolean :group 'highlight-changes) -;; highlight-changes-global-initial-state has been removed - - - ;; These are the strings displayed in the mode-line for the minor mode: -(define-obsolete-variable-alias 'highlight-changes-active-string - 'highlight-changes-visible-string "23.1") (defcustom highlight-changes-visible-string " +Chg" "The string used when in Highlight Changes mode and changes are visible. @@ -252,9 +243,6 @@ highlight-changes-visible-string (const :tag "None" nil)) :group 'highlight-changes) -(define-obsolete-variable-alias 'highlight-changes-passive-string - 'highlight-changes-invisible-string "23.1") - (defcustom highlight-changes-invisible-string " -Chg" "The string used when in Highlight Changes mode and changes are hidden. This should be set to nil if no indication is desired, or to @@ -957,10 +945,6 @@ hilit-chg-get-diff-list-hk (define-globalized-minor-mode global-highlight-changes-mode highlight-changes-mode highlight-changes-mode-turn-on) -(define-obsolete-function-alias - 'global-highlight-changes - 'global-highlight-changes-mode "23.1") - (defun highlight-changes-mode-turn-on () "See if Highlight Changes mode should be turned on for this buffer. This is called when `global-highlight-changes-mode' is turned on." diff --git a/lisp/international/mule-cmds.el b/lisp/international/mule-cmds.el index 7714a778fc..5fe931dd9b 100644 --- a/lisp/international/mule-cmds.el +++ b/lisp/international/mule-cmds.el @@ -2968,11 +2968,6 @@ unify-8859-on-decoding-mode ;; Doc said "obsolete" in 23.1, this statement only added in 24.1. (make-obsolete 'unify-8859-on-decoding-mode "don't use it." "23.1") -(defvar nonascii-insert-offset 0) -(make-obsolete-variable 'nonascii-insert-offset "do not use it." "23.1") -(defvar nonascii-translation-table nil) -(make-obsolete-variable 'nonascii-translation-table "do not use it." "23.1") - (defvar ucs-names nil "Hash table of cached CHAR-NAME keys to CHAR-CODE values.") diff --git a/lisp/international/mule-diag.el b/lisp/international/mule-diag.el index 80e78ef787..b13bde58ca 100644 --- a/lisp/international/mule-diag.el +++ b/lisp/international/mule-diag.el @@ -200,10 +200,6 @@ list-character-sets-2 ;;; (charset-iso-graphic-plane charset) (charset-description charset))))) -(defvar non-iso-charset-alist nil - "Obsolete.") -(make-obsolete-variable 'non-iso-charset-alist "no longer relevant." "23.1") - ;; A variable to hold charset input history. (defvar charset-history nil) diff --git a/lisp/international/mule-util.el b/lisp/international/mule-util.el index 5cc10b1315..660ac58e02 100644 --- a/lisp/international/mule-util.el +++ b/lisp/international/mule-util.el @@ -274,15 +274,6 @@ with-coding-priority ;;;###autoload(put 'with-coding-priority 'lisp-indent-function 1) (put 'with-coding-priority 'edebug-form-spec t) -;;;###autoload -(defmacro detect-coding-with-priority (from to priority-list) - "Detect a coding system of the text between FROM and TO with PRIORITY-LIST. -PRIORITY-LIST is an alist of coding categories vs the corresponding -coding systems ordered by priority." - (declare (obsolete with-coding-priority "23.1")) - `(with-coding-priority (mapcar #'cdr ,priority-list) - (detect-coding-region ,from ,to))) - ;;;###autoload (defun detect-coding-with-language-environment (from to lang-env) "Detect a coding system for the text between FROM and TO with LANG-ENV. diff --git a/lisp/international/mule.el b/lisp/international/mule.el index 72e8cad9d6..411cc6f41d 100644 --- a/lisp/international/mule.el +++ b/lisp/international/mule.el @@ -408,16 +408,6 @@ charset-info ;; because that makes a bootstrapping problem ;; if you need to recompile all the Lisp files using interpreted code. -(defun charset-id (_charset) - "Always return 0. This is provided for backward compatibility." - (declare (obsolete nil "23.1")) - 0) - -(defmacro charset-bytes (_charset) - "Always return 0. This is provided for backward compatibility." - (declare (obsolete nil "23.1")) - 0) - (defun get-charset-property (charset propname) "Return the value of CHARSET's PROPNAME property. This is the last value stored with @@ -463,19 +453,8 @@ charset-long-name "Return long name of CHARSET." (plist-get (charset-plist charset) :long-name)) -(defun charset-list () - "Return list of all charsets ever defined." - (declare (obsolete charset-list "23.1")) - charset-list) - \f ;;; CHARACTER -(define-obsolete-function-alias 'char-valid-p 'characterp "23.1") - -(defun generic-char-p (_char) - "Always return nil. This is provided for backward compatibility." - (declare (obsolete nil "23.1")) - nil) (defun make-char-internal (charset-id &optional code1 code2) (let ((charset (aref emacs-mule-charset-table charset-id))) @@ -1084,10 +1063,6 @@ coding-system-list (setq codings (cons alias codings)))))) codings)) -(defconst char-coding-system-table nil - "It exists just for backward compatibility, and the value is always nil.") -(make-obsolete-variable 'char-coding-system-table nil "23.1") - (defun transform-make-coding-system-args (name type &optional doc-string props) "For internal use only. Transform XEmacs style args for `make-coding-system' to Emacs style. @@ -1169,106 +1144,6 @@ transform-make-coding-system-args (error "unsupported XEmacs style make-coding-style arguments: %S" `(,name ,type ,doc-string ,props)))))) -(defun make-coding-system (coding-system type mnemonic doc-string - &optional - flags - properties - eol-type) - "Define a new coding system CODING-SYSTEM (symbol). -This function is provided for backward compatibility." - (declare (obsolete define-coding-system "23.1")) - ;; For compatibility with XEmacs, we check the type of TYPE. If it - ;; is a symbol, perhaps, this function is called with XEmacs-style - ;; arguments. Here, try to transform that kind of arguments to - ;; Emacs style. - (if (symbolp type) - (let ((args (transform-make-coding-system-args coding-system type - mnemonic doc-string))) - (setq coding-system (car args) - type (nth 1 args) - mnemonic (nth 2 args) - doc-string (nth 3 args) - flags (nth 4 args) - properties (nth 5 args) - eol-type (nth 6 args)))) - - (setq type - (cond ((eq type 0) 'emacs-mule) - ((eq type 1) 'shift-jis) - ((eq type 2) 'iso2022) - ((eq type 3) 'big5) - ((eq type 4) 'ccl) - ((eq type 5) 'raw-text) - (t - (error "Invalid coding system type: %s" type)))) - - (setq properties - (let ((plist nil) key) - (dolist (elt properties) - (setq key (car elt)) - (cond ((eq key 'post-read-conversion) - (setq key :post-read-conversion)) - ((eq key 'pre-write-conversion) - (setq key :pre-write-conversion)) - ((eq key 'translation-table-for-decode) - (setq key :decode-translation-table)) - ((eq key 'translation-table-for-encode) - (setq key :encode-translation-table)) - ((eq key 'safe-charsets) - (setq key :charset-list)) - ((eq key 'mime-charset) - (setq key :mime-charset)) - ((eq key 'valid-codes) - (setq key :valids))) - (setq plist (plist-put plist key (cdr elt)))) - plist)) - (setq properties (plist-put properties :mnemonic mnemonic)) - (plist-put properties :coding-type type) - (cond ((eq eol-type 0) (setq eol-type 'unix)) - ((eq eol-type 1) (setq eol-type 'dos)) - ((eq eol-type 2) (setq eol-type 'mac)) - ((vectorp eol-type) (setq eol-type nil))) - (plist-put properties :eol-type eol-type) - - (cond - ((eq type 'iso2022) - (plist-put properties :flags - (list (and (or (consp (nth 0 flags)) - (consp (nth 1 flags)) - (consp (nth 2 flags)) - (consp (nth 3 flags))) 'designation) - (or (nth 4 flags) 'long-form) - (and (nth 5 flags) 'ascii-at-eol) - (and (nth 6 flags) 'ascii-at-cntl) - (and (nth 7 flags) '7-bit) - (and (nth 8 flags) 'locking-shift) - (and (nth 9 flags) 'single-shift) - (and (nth 10 flags) 'use-roman) - (and (nth 11 flags) 'use-oldjis) - (or (nth 12 flags) 'direction) - (and (nth 13 flags) 'init-at-bol) - (and (nth 14 flags) 'designate-at-bol) - (and (nth 15 flags) 'safe) - (and (nth 16 flags) 'latin-extra))) - (plist-put properties :designation - (let ((vec (make-vector 4 nil))) - (dotimes (i 4) - (let ((spec (nth i flags))) - (if (eq spec t) - (aset vec i '(94 96)) - (if (consp spec) - (progn - (if (memq t spec) - (setq spec (append (delq t spec) '(94 96)))) - (aset vec i spec)))))) - vec))) - - ((eq type 'ccl) - (plist-put properties :ccl-decoder (car flags)) - (plist-put properties :ccl-encoder (cdr flags)))) - - (apply 'define-coding-system coding-system doc-string properties)) - (defun merge-coding-systems (first second) "Fill in any unspecified aspects of coding system FIRST from SECOND. Return the resulting coding system." @@ -1615,15 +1490,6 @@ set-next-selection-coding-system (setq next-selection-coding-system coding-system)) -(defun set-coding-priority (arg) - "Set priority of coding categories according to ARG. -ARG is a list of coding categories ordered by priority. - -This function is provided for backward compatibility." - (declare (obsolete set-coding-system-priority "23.1")) - (apply 'set-coding-system-priority - (mapcar #'(lambda (x) (symbol-value x)) arg))) - ;;; X selections (defvar ctext-non-standard-encodings-alist diff --git a/lisp/mail/rmail.el b/lisp/mail/rmail.el index 44cde7cb5a..312baffb90 100644 --- a/lisp/mail/rmail.el +++ b/lisp/mail/rmail.el @@ -521,25 +521,6 @@ rmail-mmdf-delim1 (defvar rmail-mmdf-delim2 "^\001\001\001\001\n" "Regexp marking the end of an mmdf message.") -;; FIXME Post-mbox, this is now unused. -;; In Emacs-22, this was called: -;; i) the very first time a message was shown. -;; ii) when toggling the headers to the normal state, every time. -;; It's not clear what it should do now, since there is nothing that -;; records when a message is shown for the first time (unseen is not -;; necessarily the same thing). -;; See https://lists.gnu.org/r/emacs-devel/2009-03/msg00013.html -(defcustom rmail-message-filter nil - "If non-nil, a filter function for new messages in RMAIL. -Called with region narrowed to the message, including headers, -before obeying `rmail-ignored-headers'." - :group 'rmail-headers - :type '(choice (const nil) function)) - -(make-obsolete-variable 'rmail-message-filter - "it is not used (try `rmail-show-message-hook')." - "23.1") - (defcustom rmail-automatic-folder-directives nil "List of directives specifying how to automatically file messages. Whenever Rmail shows a message in the folder that `rmail-file-name' diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index d2c3f9045e..0d99f4687c 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -685,13 +685,6 @@ completion--twq-all completions) qboundary)))) -;; (defmacro complete-in-turn (a b) `(completion-table-in-turn ,a ,b)) -;; (defmacro dynamic-completion-table (fun) `(completion-table-dynamic ,fun)) -(define-obsolete-function-alias - 'complete-in-turn #'completion-table-in-turn "23.1") -(define-obsolete-function-alias - 'dynamic-completion-table #'completion-table-dynamic "23.1") - ;;; Minibuffer completion (defgroup minibuffer nil @@ -1770,9 +1763,6 @@ completion--insert-strings ;; Round up to a whole number of columns. (* colwidth (ceiling length colwidth)))))))))))) -(defvar completion-common-substring nil) -(make-obsolete-variable 'completion-common-substring nil "23.1") - (defvar completion-setup-hook nil "Normal hook run at the end of setting up a completion list buffer. When this hook is run, the current buffer is the one in which the @@ -1864,11 +1854,7 @@ display-completion-list (insert "Possible completions are:\n") (completion--insert-strings completions)))) - ;; The hilit used to be applied via completion-setup-hook, so there - ;; may still be some code that uses completion-common-substring. - (with-no-warnings - (let ((completion-common-substring common-substring)) - (run-hooks 'completion-setup-hook))) + (run-hooks 'completion-setup-hook) nil) (defvar completion-extra-properties nil @@ -2374,8 +2360,6 @@ minibuffer-local-filename-completion-map Gets combined either with `minibuffer-local-completion-map' or with `minibuffer-local-must-match-map'.") -(define-obsolete-variable-alias 'minibuffer-local-must-match-filename-map - 'minibuffer-local-filename-must-match-map "23.1") (defvar minibuffer-local-filename-must-match-map (make-sparse-keymap)) (make-obsolete-variable 'minibuffer-local-filename-must-match-map nil "24.1") diff --git a/lisp/mouse.el b/lisp/mouse.el index 795b4da19e..ae6ebf4dfc 100644 --- a/lisp/mouse.el +++ b/lisp/mouse.el @@ -271,34 +271,6 @@ mouse-menu-bar-map local-menu minor-mode-menus))) -(defun mouse-major-mode-menu (event &optional prefix) - "Pop up a mode-specific menu of mouse commands. -Default to the Edit menu if the major mode doesn't define a menu." - (declare (obsolete mouse-menu-major-mode-map "23.1")) - (interactive "@e\nP") - (run-hooks 'activate-menubar-hook 'menu-bar-update-hook) - (popup-menu (mouse-menu-major-mode-map) event prefix)) - -(defun mouse-popup-menubar (event prefix) - "Pop up a menu equivalent to the menu bar for keyboard EVENT with PREFIX. -The contents are the items that would be in the menu bar whether or -not it is actually displayed." - (declare (obsolete mouse-menu-bar-map "23.1")) - (interactive "@e \nP") - (run-hooks 'activate-menubar-hook 'menu-bar-update-hook) - (popup-menu (mouse-menu-bar-map) (unless (integerp event) event) prefix)) - -(defun mouse-popup-menubar-stuff (event prefix) - "Popup a menu like either `mouse-major-mode-menu' or `mouse-popup-menubar'. -Use the former if the menu bar is showing, otherwise the latter." - (declare (obsolete nil "23.1")) - (interactive "@e\nP") - (run-hooks 'activate-menubar-hook 'menu-bar-update-hook) - (popup-menu - (if (zerop (or (frame-parameter nil 'menu-bar-lines) 0)) - (mouse-menu-bar-map) - (mouse-menu-major-mode-map)) - event prefix)) \f ;; Commands that operate on windows. diff --git a/lisp/net/newst-treeview.el b/lisp/net/newst-treeview.el index 1bed61f3e7..ff8a447c7c 100644 --- a/lisp/net/newst-treeview.el +++ b/lisp/net/newst-treeview.el @@ -131,14 +131,6 @@ newsticker-groups Example: (\"Topmost group\" \"feed1\" (\"subgroup1\" \"feed 2\") \"feed3\")") -(defcustom newsticker-groups-filename - nil - "Name of the newsticker groups settings file." - :version "25.1" ; changed default value to nil - :type '(choice (const nil) string) - :group 'newsticker-treeview) -(make-obsolete-variable 'newsticker-groups-filename 'newsticker-dir "23.1") - ;; ====================================================================== ;;; internal variables ;; ====================================================================== @@ -1265,29 +1257,9 @@ newsticker-treeview-save (defun newsticker--treeview-load () "Load treeview settings." (let* ((coding-system-for-read 'utf-8) - (filename - (or (and newsticker-groups-filename - (not (string= - (expand-file-name newsticker-groups-filename) - (expand-file-name (concat newsticker-dir "/groups")))) - (file-exists-p newsticker-groups-filename) - (y-or-n-p - (format-message - (concat "Obsolete variable `newsticker-groups-filename' " - "points to existing file \"%s\".\n" - "Read it? ") - newsticker-groups-filename)) - newsticker-groups-filename) - (concat newsticker-dir "/groups"))) + (filename (concat newsticker-dir "/groups")) (buf (and (file-exists-p filename) (find-file-noselect filename)))) - (and newsticker-groups-filename - (file-exists-p newsticker-groups-filename) - (y-or-n-p (format-message - (concat "Delete the file \"%s\",\nto which the obsolete " - "variable `newsticker-groups-filename' points ? ") - newsticker-groups-filename)) - (delete-file newsticker-groups-filename)) (when buf (set-buffer buf) (goto-char (point-min)) diff --git a/lisp/obsolete/tpu-edt.el b/lisp/obsolete/tpu-edt.el index d71f79c87b..0de7aa096d 100644 --- a/lisp/obsolete/tpu-edt.el +++ b/lisp/obsolete/tpu-edt.el @@ -287,14 +287,6 @@ tpu-version ;;; ;;; User Configurable Variables ;;; -(defcustom tpu-have-ispell t - "Non-nil means `tpu-spell-check' uses `ispell-region' for spell checking. -Otherwise, use `spell-region'." - :type 'boolean - :group 'tpu) -(make-obsolete-variable 'tpu-have-ispell "the `spell' package is obsolete." - "23.1") - (defcustom tpu-kill-buffers-silently nil "If non-nil, TPU-edt kills modified buffers without asking." :type 'boolean @@ -315,7 +307,6 @@ tpu-pan-columns ;;; Global Keymaps ;;; -(define-obsolete-variable-alias 'GOLD-map 'tpu-gold-map "23.1") (defvar tpu-gold-map (let ((map (make-keymap))) ;; Previously we used escape sequences here. We now instead presume @@ -892,8 +883,7 @@ tpu-spell-check if no region is selected." (interactive) (let ((m (tpu-mark))) - (apply (if tpu-have-ispell 'ispell-region - 'spell-region) + (apply 'ispell-region (if m (if (> m (point)) (list (point) m) (list m (point))) diff --git a/lisp/obsolete/vc-arch.el b/lisp/obsolete/vc-arch.el index 93bd991eb3..6b34b31fcd 100644 --- a/lisp/obsolete/vc-arch.el +++ b/lisp/obsolete/vc-arch.el @@ -84,8 +84,6 @@ vc-arch-diff-switches :version "23.1" :group 'vc-arch) -(define-obsolete-variable-alias 'vc-arch-command 'vc-arch-program "23.1") - (defcustom vc-arch-program (let ((candidates '("tla" "baz"))) (while (and candidates (not (executable-find (car candidates)))) diff --git a/lisp/password-cache.el b/lisp/password-cache.el index 5e5f3240bc..5aed4e4049 100644 --- a/lisp/password-cache.el +++ b/lisp/password-cache.el @@ -93,22 +93,6 @@ password-read (or (password-read-from-cache key) (read-passwd prompt))) -(defun password-read-and-add (prompt &optional key) - "Read password, for use with KEY, from user, or from cache if wanted. -Then store the password in the cache. Uses `password-read' and -`password-cache-add'. Custom variables `password-cache' and -`password-cache-expiry' regulate cache behavior. - -Warning: the password is cached without checking that it is -correct. It is better to check the password before caching. If -you must use this function, take care to check passwords and -remove incorrect ones from the cache." - (declare (obsolete password-read "23.1")) - (let ((password (password-read prompt key))) - (when (and password key) - (password-cache-add key password)) - password)) - (defun password-cache-remove (key) "Remove password indexed by KEY from password cache. This is typically run by a timer setup from `password-cache-add', diff --git a/lisp/progmodes/idlwave.el b/lisp/progmodes/idlwave.el index 3092d4c45b..55acb77425 100644 --- a/lisp/progmodes/idlwave.el +++ b/lisp/progmodes/idlwave.el @@ -159,8 +159,6 @@ (defalias 'line-beginning-position 'point-at-bol)) (unless (fboundp 'line-end-position) (defalias 'line-end-position 'point-at-eol)) -(unless (fboundp 'char-valid-p) - (defalias 'char-valid-p 'characterp)) (unless (fboundp 'match-string-no-properties) (defalias 'match-string-no-properties 'match-string)) diff --git a/lisp/shell.el b/lisp/shell.el index 1e2679f723..3461ce71ef 100644 --- a/lisp/shell.el +++ b/lisp/shell.el @@ -988,9 +988,6 @@ shell-dirtrack-mode (add-hook 'comint-input-filter-functions #'shell-directory-tracker nil t) (remove-hook 'comint-input-filter-functions #'shell-directory-tracker t))) -(define-obsolete-function-alias 'shell-dirtrack-toggle #'shell-dirtrack-mode - "23.1") - (defun shell-cd (dir) "Do normal `cd' to DIR, and set `list-buffers-directory'." (cd dir) diff --git a/lisp/subr.el b/lisp/subr.el index 324c59f13f..b7ef32d5d5 100644 --- a/lisp/subr.el +++ b/lisp/subr.el @@ -1578,11 +1578,6 @@ posn-object-width-height (make-obsolete 'string-as-multibyte "use `decode-coding-string'." "26.1") (make-obsolete 'string-make-multibyte "use `decode-coding-string'." "26.1") -(defun forward-point (n) - "Return buffer position N characters after (before if N negative) point." - (declare (obsolete "use (+ (point) N) instead." "23.1")) - (+ (point) n)) - (defun log10 (x) "Return (log X 10), the log base 10 of X." (declare (obsolete log "24.4")) @@ -1598,17 +1593,11 @@ log10 \f ;;;; Obsolescence declarations for variables, and aliases. -(make-obsolete-variable 'define-key-rebound-commands nil "23.2") -(make-obsolete-variable 'redisplay-end-trigger-functions 'jit-lock-register "23.1") (make-obsolete-variable 'deferred-action-list 'post-command-hook "24.1") (make-obsolete-variable 'deferred-action-function 'post-command-hook "24.1") (make-obsolete-variable 'redisplay-dont-pause nil "24.5") -(make-obsolete 'window-redisplay-end-trigger nil "23.1") -(make-obsolete 'set-window-redisplay-end-trigger nil "23.1") (make-obsolete 'run-window-configuration-change-hook nil "27.1") -(make-obsolete 'process-filter-multibyte-p nil "23.1") -(make-obsolete 'set-process-filter-multibyte nil "23.1") (make-obsolete-variable 'command-debug-status "expect it to be removed in a future version." "25.2") diff --git a/lisp/t-mouse.el b/lisp/t-mouse.el index a1af53d8c4..4feab71401 100644 --- a/lisp/t-mouse.el +++ b/lisp/t-mouse.el @@ -62,8 +62,6 @@ gpm-mouse-disable (gpm-mouse-stop)) (set-terminal-parameter nil 'gpm-mouse-active nil)) -;;;###autoload -(define-obsolete-function-alias 't-mouse-mode 'gpm-mouse-mode "23.1") ;;;###autoload (define-minor-mode gpm-mouse-mode "Toggle mouse support in GNU/Linux consoles (GPM Mouse mode). diff --git a/lisp/term/w32-win.el b/lisp/term/w32-win.el index 5901e0295e..e866fdc36c 100644 --- a/lisp/term/w32-win.el +++ b/lisp/term/w32-win.el @@ -78,12 +78,8 @@ (require 'dnd) (require 'w32-vars) -;; Keep an obsolete alias for w32-focus-frame and w32-select-font in case -;; they are used by code outside Emacs. -(define-obsolete-function-alias 'w32-focus-frame 'x-focus-frame "23.1") (declare-function x-select-font "w32font.c" (&optional frame exclude-proportional)) -(define-obsolete-function-alias 'w32-select-font 'x-select-font "23.1") (defvar w32-color-map) ;; defined in w32fns.c (make-obsolete 'w32-default-color-map nil "24.1") diff --git a/lisp/textmodes/ispell.el b/lisp/textmodes/ispell.el index 65f61644b6..ffcdb9bd16 100644 --- a/lisp/textmodes/ispell.el +++ b/lisp/textmodes/ispell.el @@ -621,15 +621,6 @@ ispell-encoding8-command Earlier Aspell versions do not consistently support charset encoding. Handling this would require some extra guessing in `ispell-aspell-find-dictionary'.") -(defvar ispell-aspell-supports-utf8 nil - "Non-nil if Aspell has consistent command line UTF-8 support. Obsolete. -ispell.el and flyspell.el will use for this purpose the more generic -variable `ispell-encoding8-command' for both Aspell and Hunspell. Is left -here just for backwards compatibility.") - -(make-obsolete-variable 'ispell-aspell-supports-utf8 - 'ispell-encoding8-command "23.1") - (defvar ispell-dicts-name2locale-equivs-alist '(("american" "en_US") ("brasileiro" "pt_BR") diff --git a/lisp/textmodes/remember.el b/lisp/textmodes/remember.el index 279dbb4450..7bc7dc1762 100644 --- a/lisp/textmodes/remember.el +++ b/lisp/textmodes/remember.el @@ -487,9 +487,6 @@ remember-finalize (interactive) (remember-region (point-min) (point-max))) -;; Org needs this -(define-obsolete-function-alias 'remember-buffer 'remember-finalize "23.1") - (defun remember-destroy () "Destroy the current *Remember* buffer." (interactive) diff --git a/lisp/tooltip.el b/lisp/tooltip.el index f35f6b9a03..5f5a4788b2 100644 --- a/lisp/tooltip.el +++ b/lisp/tooltip.el @@ -167,8 +167,6 @@ tooltip-resize-echo-area \f ;;; Variables that are not customizable. -(define-obsolete-variable-alias 'tooltip-hook 'tooltip-functions "23.1") - (defvar tooltip-functions nil "Functions to call to display tooltips. Each function is called with one argument EVENT which is a copy diff --git a/lisp/url/url-util.el b/lisp/url/url-util.el index 6dd7a9c2aa..0a7e7e205e 100644 --- a/lisp/url/url-util.el +++ b/lisp/url/url-util.el @@ -569,31 +569,6 @@ url-get-url-at-point (setq url nil)) url))) -(defun url-generate-unique-filename (&optional fmt) - "Generate a unique filename in `url-temporary-directory'." - (declare (obsolete make-temp-file "23.1")) - ;; This variable is obsolete, but so is this function. - (let ((tempdir (with-no-warnings url-temporary-directory))) - (if (not fmt) - (let ((base (format "url-tmp.%d" (user-real-uid))) - (fname "") - (x 0)) - (setq fname (format "%s%d" base x)) - (while (file-exists-p - (expand-file-name fname tempdir)) - (setq x (1+ x) - fname (concat base (int-to-string x)))) - (expand-file-name fname tempdir)) - (let ((base (concat "url" (int-to-string (user-real-uid)))) - (fname "") - (x 0)) - (setq fname (format fmt (concat base (int-to-string x)))) - (while (file-exists-p - (expand-file-name fname tempdir)) - (setq x (1+ x) - fname (format fmt (concat base (int-to-string x))))) - (expand-file-name fname tempdir))))) - (defun url-extract-mime-headers () "Set `url-current-mime-headers' in current buffer." (save-excursion diff --git a/lisp/url/url-vars.el b/lisp/url/url-vars.el index d9277cf6f4..e35823ab9a 100644 --- a/lisp/url/url-vars.el +++ b/lisp/url/url-vars.el @@ -312,13 +312,6 @@ url-max-password-attempts :type 'integer :group 'url) -(defcustom url-temporary-directory (or (getenv "TMPDIR") "/tmp") - "Where temporary files go." - :type 'directory - :group 'url-file) -(make-obsolete-variable 'url-temporary-directory - 'temporary-file-directory "23.1") - (defcustom url-show-status t "Whether to show a running total of bytes transferred. Can cause a large hit if using a remote X display over a slow link, or diff --git a/lisp/vc/vc-hooks.el b/lisp/vc/vc-hooks.el index 2ca9d3e620..20002c4f59 100644 --- a/lisp/vc/vc-hooks.el +++ b/lisp/vc/vc-hooks.el @@ -506,9 +506,8 @@ vc-working-revision backend 'working-revision file)))))) ;; Backward compatibility. -(define-obsolete-function-alias - 'vc-workfile-version 'vc-working-revision "23.1") (defun vc-default-working-revision (backend file) + ;; FIXME: Should this be declared obsolete? (message "`working-revision' not found: using the old `workfile-version' instead") (vc-call-backend backend 'workfile-version file)) diff --git a/lisp/vc/vc-mtn.el b/lisp/vc/vc-mtn.el index 092d8b5396..3c26ffc0e5 100644 --- a/lisp/vc/vc-mtn.el +++ b/lisp/vc/vc-mtn.el @@ -60,7 +60,6 @@ vc-mtn-annotate-switches :version "25.1" :group 'vc-mtn) -(define-obsolete-variable-alias 'vc-mtn-command 'vc-mtn-program "23.1") (defcustom vc-mtn-program "mtn" "Name of the monotone executable." :type 'string diff --git a/lisp/vc/vc.el b/lisp/vc/vc.el index c640ba0420..2128f0edc1 100644 --- a/lisp/vc/vc.el +++ b/lisp/vc/vc.el @@ -2700,9 +2700,6 @@ vc-revert (vc-revert-file file) (message "Reverting %s...done" (vc-delistify files))))) -;;;###autoload -(define-obsolete-function-alias 'vc-revert-buffer 'vc-revert "23.1") - ;;;###autoload (defun vc-pull (&optional arg) "Update the current fileset or branch. diff --git a/lisp/vcursor.el b/lisp/vcursor.el index fa0cbb74b0..3601abcd6e 100644 --- a/lisp/vcursor.el +++ b/lisp/vcursor.el @@ -1132,9 +1132,6 @@ vcursor-copy-line (vcursor-copy (if (or (= count 0) arg) (1+ count) count))) ) -(define-obsolete-function-alias - 'vcursor-toggle-vcursor-map 'vcursor-use-vcursor-map "23.1") - (defun vcursor-post-command () (and vcursor-auto-disable (not vcursor-last-command) vcursor-overlay -- 2.26.2 ^ permalink raw reply related [flat|nested] 838+ messages in thread
* Re: Delete variables obsolete since Emacs 23 2020-05-16 13:18 ` Delete variables obsolete since Emacs 23 Stefan Kangas @ 2020-05-16 15:49 ` Paul Eggert 2020-05-17 2:52 ` Stefan Monnier 2020-08-08 0:28 ` Stefan Kangas 2 siblings, 0 replies; 838+ messages in thread From: Paul Eggert @ 2020-05-16 15:49 UTC (permalink / raw) To: Stefan Kangas; +Cc: Stefan Monnier, emacs-devel On 5/16/20 6:18 AM, Stefan Kangas wrote: > Other than that, does the attached patch look okay for master? Yes, it looks good to me, thanks. Though Glenn is the real expert here.... ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Delete variables obsolete since Emacs 23 2020-05-16 13:18 ` Delete variables obsolete since Emacs 23 Stefan Kangas 2020-05-16 15:49 ` Paul Eggert @ 2020-05-17 2:52 ` Stefan Monnier 2020-05-17 11:39 ` Dmitry Gutov 2020-08-08 0:28 ` Stefan Kangas 2 siblings, 1 reply; 838+ messages in thread From: Stefan Monnier @ 2020-05-17 2:52 UTC (permalink / raw) To: Stefan Kangas; +Cc: emacs-devel > 3. Note the added FIXME in `vc-default-working-revision', where I'm not > sure if it should be declared obsolete or not. See Stefan M's commit > 6e5d0e9e73. This function is never called directly (the only way it could be called was via (vc-call-backend .. 'working-revision) for backends that defined `vc-<backend>-workfile-revision` instead of `vc-<backend>-working-revision`. So a `make-obsolete` would have been ineffective (since it's never called directly, the byte-compiler would never emit an obsolescence warning) and I replaced it with a more annoying "message". Since noone complained about that message, I think it's definitely safe to remove the function. > 4. The variable `translation-table-for-input' was declared obsolete with > in Emacs 23.1 and has the following comment. I'm not sure what to do > about it, if anything. > > ;; This was introduced in 21.4 for pre-unicode unification. That > ;; usage was rendered obsolete in 23.1, which uses Unicode internally. > ;; Other uses are possible, so this variable is not _really_ obsolete, > ;; but Stefan insists to mark it so. It's not obsolete in the sense that there's nothing to replace it, indeed. But it's been completely unused since Emacs-23.1 so it's complexity that's not pulling its weight. Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Delete variables obsolete since Emacs 23 2020-05-17 2:52 ` Stefan Monnier @ 2020-05-17 11:39 ` Dmitry Gutov 0 siblings, 0 replies; 838+ messages in thread From: Dmitry Gutov @ 2020-05-17 11:39 UTC (permalink / raw) To: Stefan Monnier, Stefan Kangas; +Cc: emacs-devel On 17.05.2020 05:52, Stefan Monnier wrote: >> 3. Note the added FIXME in `vc-default-working-revision', where I'm not >> sure if it should be declared obsolete or not. See Stefan M's commit >> 6e5d0e9e73. > This function is never called directly (the only way it could be called > was via (vc-call-backend .. 'working-revision) for backends that > defined `vc-<backend>-workfile-revision` instead of > `vc-<backend>-working-revision`. > > So a `make-obsolete` would have been ineffective (since it's never > called directly, the byte-compiler would never emit an obsolescence > warning) and I replaced it with a more annoying "message". Since noone > complained about that message, I think it's definitely safe to remove > the function. > Agree. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Delete variables obsolete since Emacs 23 2020-05-16 13:18 ` Delete variables obsolete since Emacs 23 Stefan Kangas 2020-05-16 15:49 ` Paul Eggert 2020-05-17 2:52 ` Stefan Monnier @ 2020-08-08 0:28 ` Stefan Kangas 2020-08-14 11:11 ` Stefan Kangas 2020-08-14 15:42 ` Stefan Kangas 2 siblings, 2 replies; 838+ messages in thread From: Stefan Kangas @ 2020-08-08 0:28 UTC (permalink / raw) To: Stefan Monnier, emacs-devel [-- Attachment #1: Type: text/plain, Size: 1111 bytes --] Stefan Kangas <stefankangas@gmail.com> writes: > Other than that, does the attached patch look okay for master? I have looked this all over again, and I'm attaching a (hopefully) final patch here. I found some places where the documentation needed updating, and one or two uses that I had missed previously. There have been relatively minor changes since last time, but I want to give everyone a chance to comment before pushing. If someone wants to take a stab at it, we still have to remove the below items. I left them alone for now simply because they were a bit tricky to untangle: * lisp/net/newst-backend.el (newsticker-cache-filename) * lisp/subr.el (translation-table-for-input) * lisp/subr.el (define-key-rebound-commands) * lisp/subr.el (redisplay-end-trigger-functions) * lisp/subr.el (window-redisplay-end-trigger) * lisp/subr.el (set-window-redisplay-end-trigger) (The last four above should be easier to remove when the fast-lock and lazy-lock libraries are removed.) Besides that, the next step here would be to remove variables obsoleted in 23.{2,3,4}. Best regards, Stefan Kangas [-- Attachment #2: 0001-Remove-many-items-obsolete-since-Emacs-23.1.patch --] [-- Type: text/x-diff, Size: 54202 bytes --] From e8ac1ab0495684bec64c5a18226d9f61299523b2 Mon Sep 17 00:00:00 2001 From: Stefan Kangas <stefankangas@gmail.com> Date: Sat, 16 May 2020 14:16:24 +0200 Subject: [PATCH] Remove many items obsolete since Emacs 23.1 Emacs 23.1 was five major releases and over a decade ago. This list can be reviewed before to the next release, but for now hopefully this motivates any needed external updates. Ref: https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg02198.html * lisp/abbrev.el (pre-abbrev-expand-hook): * lisp/bookmark.el (bookmark-read-annotation-text-func) (bookmark-jump-noselect): * lisp/buff-menu.el (buffer-menu-mode-hook): * lisp/cus-edit.el (custom-mode-hook, custom-mode): * lisp/dirtrack.el (dirtrack-debug-toggle, dirtrack-debug): * lisp/emacs-lisp/crm.el (crm-minibuffer-complete) (crm-minibuffer-completion-help) (crm-minibuffer-complete-and-exit): * lisp/emacs-lisp/easymenu.el (easy-menu-precalculate-equivalent-keybindings): * lisp/emacs-lisp/lisp-mode.el (lisp-mode-auto-fill): * lisp/epa.el (epa-display-verify-result): * lisp/epg.el (epg-passphrase-callback-function): * lisp/eshell/eshell.el (eshell-report-bug): * lisp/ffap.el (ffap-bug, ffap-submit-bug): * lisp/files.el (locate-file-completion): * lisp/hi-lock.el (hi-lock-face-history, hi-lock-regexp-history): * lisp/hilit-chg.el (highlight-changes-initial-state) (highlight-changes-active-string) (highlight-changes-passive-string, global-highlight-changes): * lisp/international/mule-cmds.el (nonascii-insert-offset) (nonascii-translation-table): * lisp/international/mule-diag.el (non-iso-charset-alist): * lisp/international/mule-util.el (detect-coding-with-priority): * lisp/international/mule.el (charset-id, charset-bytes) (charset-list, char-valid-p, generic-char-p) (char-coding-system-table, make-coding-system) (set-coding-priority) * lisp/mail/rmail.el (rmail-message-filter): * lisp/minibuffer.el (complete-in-turn, dynamic-completion-table) (completion-common-substring) (minibuffer-local-must-match-filename-map): * lisp/mouse.el (mouse-major-mode-menu, mouse-popup-menubar) (mouse-popup-menubar-stuff): * lisp/net/newst-treeview.el (newsticker-groups-filename): * lisp/obsolete/tpu-edt.el (tpu-have-ispell, GOLD-map): * lisp/password-cache.el (password-read-and-add): * lisp/shell.el (shell-dirtrack-toggle): * lisp/subr.el (forward-point, redisplay-end-trigger-functions) (process-filter-multibyte-p, set-process-filter-multibyte): * lisp/t-mouse.el (t-mouse-mode): * lisp/term/w32-win.el (w32-focus-frame, w32-select-font): * lisp/textmodes/ispell.el (ispell-aspell-supports-utf8): * lisp/textmodes/remember.el (remember-buffer): * lisp/tooltip.el (tooltip-hook): * lisp/url/url-util.el (url-generate-unique-filename): * lisp/url/url-vars.el (url-temporary-directory): * lisp/vc/vc-hooks.el (vc-workfile-version) (vc-default-working-revision): * lisp/vc/vc-mtn.el (vc-mtn-command): * lisp/vc/vc.el (vc-revert-buffer): * lisp/vcursor.el (vcursor-toggle-vcursor-map): Remove items, obsolete since Emacs 23.1. * lisp/abbrev.el (expand-abbrev): * lisp/epg.el (epg-context): Change 'epg-passphrase-callback-function' call to 'epa-' alternative. * lisp/eshell/em-rebind.el (eshell-cannot-leave-input-list): Don't refer to removed function 'forward-point'. * test/manual/etags/c-src/abbrev.c (Fexpand_abbrev): (syms_of_abbrev): Don't run removed hook 'pre-abbrev-expand-hook'. * lisp/international/mule.el (transform-make-coding-system-args): Declare obsolete. * lisp/progmodes/idlwave.el: Update reference to removed function 'char-valid-p'. * lisp/gnus/mml2015.el (epg-encrypt-string): * lisp/gnus/mml1991.el (epg-make-context): * lisp/gnus/mml-smime.el (autoload): Remove autoload of removed 'epg-passphrase-callback-function'. * lisp/minibuffer.el (completion-extra-properties): Remove support for `completion-common-substring'. * lisp/obsolete/tpu-edt.el (tpu-toggle-overwrite-mode) Remove support for removed `spell' package. * src/coding.c (syms_of_coding): * doc/misc/efaq.texi: * doc/emacs/frames.texi (Menu Mouse Clicks): * doc/misc/url.texi (Customization): Doc fixes. ; * etc/NEWS: List removed items. --- doc/emacs/custom.texi | 1 + doc/emacs/frames.texi | 8 +- doc/misc/efaq.texi | 2 +- doc/misc/url.texi | 2 - etc/NEWS | 34 ++++++++ lisp/abbrev.el | 10 --- lisp/bookmark.el | 13 --- lisp/buff-menu.el | 3 - lisp/cus-edit.el | 4 - lisp/dirtrack.el | 3 - lisp/emacs-lisp/crm.el | 6 -- lisp/emacs-lisp/easymenu.el | 10 --- lisp/emacs-lisp/lisp-mode.el | 2 - lisp/epa.el | 4 - lisp/epg.el | 17 +--- lisp/eshell/em-rebind.el | 1 - lisp/eshell/eshell.el | 9 --- lisp/ffap.el | 6 -- lisp/files.el | 8 -- lisp/gnus/mml-smime.el | 1 - lisp/gnus/mml1991.el | 1 - lisp/gnus/mml2015.el | 1 - lisp/hi-lock.el | 6 -- lisp/hilit-chg.el | 16 ---- lisp/international/mule-cmds.el | 5 -- lisp/international/mule-diag.el | 4 - lisp/international/mule-util.el | 9 --- lisp/international/mule.el | 135 +------------------------------ lisp/mail/rmail.el | 19 ----- lisp/minibuffer.el | 18 +---- lisp/mouse.el | 28 ------- lisp/net/newst-treeview.el | 30 +------ lisp/obsolete/tpu-edt.el | 12 +-- lisp/password-cache.el | 16 ---- lisp/progmodes/idlwave.el | 2 - lisp/shell.el | 3 - lisp/subr.el | 7 -- lisp/t-mouse.el | 2 - lisp/term/w32-win.el | 4 - lisp/textmodes/ispell.el | 9 --- lisp/textmodes/remember.el | 3 - lisp/tooltip.el | 2 - lisp/url/url-util.el | 25 ------ lisp/url/url-vars.el | 7 -- lisp/vc/vc-hooks.el | 8 -- lisp/vc/vc-mtn.el | 1 - lisp/vc/vc.el | 3 - lisp/vcursor.el | 3 - src/coding.c | 3 +- test/manual/etags/c-src/abbrev.c | 14 ---- 50 files changed, 50 insertions(+), 490 deletions(-) diff --git a/doc/emacs/custom.texi b/doc/emacs/custom.texi index acd7fb13ae..a512fd14c8 100644 --- a/doc/emacs/custom.texi +++ b/doc/emacs/custom.texi @@ -2605,6 +2605,7 @@ Init Examples (if (fboundp 'blink-cursor-mode) (blink-cursor-mode 0)) +@c FIXME: Find better example since `set-coding-priority' is removed. (if (boundp 'coding-category-utf-8) (set-coding-priority '(coding-category-utf-8))) @end example diff --git a/doc/emacs/frames.texi b/doc/emacs/frames.texi index b99d8ab145..b74887612b 100644 --- a/doc/emacs/frames.texi +++ b/doc/emacs/frames.texi @@ -366,9 +366,13 @@ Menu Mouse Clicks @kbd{mouse-3} by adding the following line to your init file (@pxref{Init Rebinding}): -@c FIXME: `mouse-popup-menubar-stuff' is obsolete since 23.1. @smallexample -(global-set-key [mouse-3] 'mouse-popup-menubar-stuff) +(global-set-key [mouse-3] + '(menu-item "Menu Bar" ignore + :filter (lambda (_) + (if (zerop (or (frame-parameter nil 'menu-bar-lines) 0)) + (mouse-menu-bar-map) + (mouse-menu-major-mode-map))))) @end smallexample @node Mode Line Mouse diff --git a/doc/misc/efaq.texi b/doc/misc/efaq.texi index 82467048a0..62dcc0b753 100644 --- a/doc/misc/efaq.texi +++ b/doc/misc/efaq.texi @@ -4192,7 +4192,7 @@ SPC no longer completes file names (define-key minibuffer-local-filename-completion-map (kbd "SPC") 'minibuffer-complete-word) -(define-key minibuffer-local-must-match-filename-map (kbd "SPC") +(define-key minibuffer-local-filename-must-match-map (kbd "SPC") 'minibuffer-complete-word) @end lisp diff --git a/doc/misc/url.texi b/doc/misc/url.texi index 8d9b102407..0304ff4b9f 100644 --- a/doc/misc/url.texi +++ b/doc/misc/url.texi @@ -1312,8 +1312,6 @@ Customization @end defopt @defopt url-max-password-attempts @end defopt -@defopt url-temporary-directory -@end defopt @defopt url-show-status @end defopt @defopt url-confirmation-func diff --git a/etc/NEWS b/etc/NEWS index 850b166069..68fffef197 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -771,6 +771,40 @@ have now been removed. ** Some libraries obsolete since Emacs 23 have been removed: 'ledit.el', 'lmenu.el', 'lucid.el and 'old-whitespace.el'. +--- +** Some functions and variables obsolete since Emacs 23 have been removed: + +'GOLD-map', 'bookmark-jump-noselect', +'bookmark-read-annotation-text-func', 'buffer-menu-mode-hook', +'char-coding-system-table', 'char-valid-p', 'charset-bytes', +'charset-id', 'charset-list' (function), 'complete-in-turn', +'completion-common-substring', 'crm-minibuffer-complete', +'crm-minibuffer-complete-and-exit', 'crm-minibuffer-completion-help', +'custom-mode', 'custom-mode-hook', 'detect-coding-with-priority', +'dirtrack-debug' (function), 'dirtrack-debug-toggle', +'dynamic-completion-table', +'easy-menu-precalculate-equivalent-keybindings', +'epa-display-verify-result', 'epg-passphrase-callback-function', +'eshell-report-bug', 'ffap-bug', 'ffap-submit-bug', 'forward-point', +'generic-char-p', 'global-highlight-changes', 'hi-lock-face-history', +'hi-lock-regexp-history', 'highlight-changes-active-string', +'highlight-changes-initial-state', 'highlight-changes-passive-string', +'ispell-aspell-supports-utf8', 'lisp-mode-auto-fill', +'locate-file-completion', 'make-coding-system', +'minibuffer-local-must-match-filename-map', 'mouse-major-mode-menu', +'mouse-popup-menubar', 'mouse-popup-menubar-stuff', +'newsticker-groups-filename', 'non-iso-charset-alist', +'nonascii-insert-offset', 'nonascii-translation-table', +'password-read-and-add', 'pre-abbrev-expand-hook', +'process-filter-multibyte-p', 'remember-buffer' (function), +'rmail-message-filter', 'set-coding-priority', +'set-process-filter-multibyte', 'shell-dirtrack-toggle', +'t-mouse-mode', 'tooltip-hook', 'tpu-have-ispell', +'url-generate-unique-filename', 'url-temporary-directory', +'vc-arch-command', 'vc-default-working-revision' (variable), +'vc-mtn-command', 'vc-revert-buffer', 'vc-workfile-version', +'vcursor-toggle-vcursor-map', 'w32-focus-frame', 'w32-select-font'. + \f * Lisp Changes in Emacs 28.1 diff --git a/lisp/abbrev.el b/lisp/abbrev.el index 2d61a96010..468b0d995b 100644 --- a/lisp/abbrev.el +++ b/lisp/abbrev.el @@ -517,14 +517,6 @@ last-abbrev-location ;; "Local (mode-specific) abbrev table of current buffer.") ;; (make-variable-buffer-local 'local-abbrev-table) -(defcustom pre-abbrev-expand-hook nil - "Function or functions to be called before abbrev expansion is done. -This is the first thing that `expand-abbrev' does, and so this may change -the current abbrev table before abbrev lookup happens." - :type 'hook - :group 'abbrev-mode) -(make-obsolete-variable 'pre-abbrev-expand-hook 'abbrev-expand-function "23.1") - (defun clear-abbrev-table (table) "Undefine all abbrevs in abbrev table TABLE, leaving it empty." (setq abbrevs-changed t) @@ -836,12 +828,10 @@ abbrev-expand-function (defun expand-abbrev () "Expand the abbrev before point, if there is an abbrev there. Effective when explicitly called even when `abbrev-mode' is nil. -Before doing anything else, runs `pre-abbrev-expand-hook'. Calls the value of `abbrev-expand-function' with no argument to do the work, and returns whatever it does. (That return value should be the abbrev symbol if expansion occurred, else nil.)" (interactive) - (run-hooks 'pre-abbrev-expand-hook) (funcall abbrev-expand-function)) (defun abbrev--default-expand () diff --git a/lisp/bookmark.el b/lisp/bookmark.el index de7d60f97e..12b8c145fe 100644 --- a/lisp/bookmark.el +++ b/lisp/bookmark.el @@ -922,8 +922,6 @@ bookmark-default-annotation-text "# Date: " (current-time-string) "\n")) -(define-obsolete-variable-alias 'bookmark-read-annotation-text-func - 'bookmark-edit-annotation-text-func "23.1") (defvar bookmark-edit-annotation-text-func 'bookmark-default-annotation-text "Function to return default text to use for a bookmark annotation. It takes one argument, the name of the bookmark, as a string.") @@ -1142,17 +1140,6 @@ bookmark-jump-other-frame (let ((pop-up-frames t)) (bookmark-jump-other-window bookmark))) -(defun bookmark-jump-noselect (bookmark) - "Return the location pointed to by BOOKMARK (see `bookmark-jump'). -The return value has the form (BUFFER . POINT). - -Note: this function is deprecated and is present for Emacs 22 -compatibility only." - (declare (obsolete bookmark-handle-bookmark "23.1")) - (save-excursion - (bookmark-handle-bookmark bookmark) - (cons (current-buffer) (point)))) - (defun bookmark-handle-bookmark (bookmark-name-or-record) "Call BOOKMARK-NAME-OR-RECORD's handler or `bookmark-default-handler' if it has none. This changes current buffer and point and returns nil, diff --git a/lisp/buff-menu.el b/lisp/buff-menu.el index 9fe0dbae38..324646dc3c 100644 --- a/lisp/buff-menu.el +++ b/lisp/buff-menu.el @@ -214,9 +214,6 @@ Buffer-menu-mode-map map) "Local keymap for `Buffer-menu-mode' buffers.") -(define-obsolete-variable-alias 'buffer-menu-mode-hook - 'Buffer-menu-mode-hook "23.1") - (define-derived-mode Buffer-menu-mode tabulated-list-mode "Buffer Menu" "Major mode for Buffer Menu buffers. The Buffer Menu is invoked by the commands \\[list-buffers], diff --git a/lisp/cus-edit.el b/lisp/cus-edit.el index 16695967df..5ec5799f80 100644 --- a/lisp/cus-edit.el +++ b/lisp/cus-edit.el @@ -4868,8 +4868,6 @@ Custom-goto-parent (parent (downcase (widget-get button :tag)))) (customize-group parent))))) -(define-obsolete-variable-alias 'custom-mode-hook 'Custom-mode-hook "23.1") - (defcustom Custom-mode-hook nil "Hook called when entering Custom mode." :type 'hook @@ -4940,8 +4938,6 @@ Custom-mode (put 'Custom-mode 'mode-class 'special) -(define-obsolete-function-alias 'custom-mode 'Custom-mode "23.1") - ;;; The End. (provide 'cus-edit) diff --git a/lisp/dirtrack.el b/lisp/dirtrack.el index 3a0bbd2c9c..ad0c18d1b3 100644 --- a/lisp/dirtrack.el +++ b/lisp/dirtrack.el @@ -196,9 +196,6 @@ dirtrack-mode (remove-hook 'comint-preoutput-filter-functions 'dirtrack t))) -(define-obsolete-function-alias 'dirtrack-debug-toggle 'dirtrack-debug-mode - "23.1") -(define-obsolete-variable-alias 'dirtrack-debug 'dirtrack-debug-mode "23.1") (define-minor-mode dirtrack-debug-mode "Toggle Dirtrack debugging." nil nil nil diff --git a/lisp/emacs-lisp/crm.el b/lisp/emacs-lisp/crm.el index 65483d0813..89d106ee48 100644 --- a/lisp/emacs-lisp/crm.el +++ b/lisp/emacs-lisp/crm.el @@ -270,12 +270,6 @@ completing-read-multiple (remove-hook 'choose-completion-string-functions 'crm--choose-completion-string))) -(define-obsolete-function-alias 'crm-minibuffer-complete 'crm-complete "23.1") -(define-obsolete-function-alias - 'crm-minibuffer-completion-help 'crm-completion-help "23.1") -(define-obsolete-function-alias - 'crm-minibuffer-complete-and-exit 'crm-complete-and-exit "23.1") - ;; testing and debugging ;; (defun crm-init-test-environ () ;; "Set up some variables for testing." diff --git a/lisp/emacs-lisp/easymenu.el b/lisp/emacs-lisp/easymenu.el index 6ba8b997f8..73dabef3fa 100644 --- a/lisp/emacs-lisp/easymenu.el +++ b/lisp/emacs-lisp/easymenu.el @@ -29,16 +29,6 @@ ;;; Code: -(defvar easy-menu-precalculate-equivalent-keybindings nil - "Determine when equivalent key bindings are computed for easy-menu menus. -It can take some time to calculate the equivalent key bindings that are shown -in a menu. If the variable is on, then this calculation gives a (maybe -noticeable) delay when a mode is first entered. If the variable is off, then -this delay will come when a menu is displayed the first time. If you never use -menus, turn this variable off, otherwise it is probably better to keep it on.") -(make-obsolete-variable - 'easy-menu-precalculate-equivalent-keybindings nil "23.1") - (defsubst easy-menu-intern (s) (if (stringp s) (intern s) s)) diff --git a/lisp/emacs-lisp/lisp-mode.el b/lisp/emacs-lisp/lisp-mode.el index 1311d94cb0..d0c28ec5dc 100644 --- a/lisp/emacs-lisp/lisp-mode.el +++ b/lisp/emacs-lisp/lisp-mode.el @@ -785,8 +785,6 @@ lisp-comment-indent nil))) (comment-indent-default))) -(define-obsolete-function-alias 'lisp-mode-auto-fill 'do-auto-fill "23.1") - (defcustom lisp-indent-offset nil "If non-nil, indent second line of expressions that many more columns." :group 'lisp diff --git a/lisp/epa.el b/lisp/epa.el index 3c7dd8309a..beefc71ddf 100644 --- a/lisp/epa.el +++ b/lisp/epa.el @@ -644,10 +644,6 @@ epa-display-error (goto-char (point-min))) (display-buffer buffer))))) -(defun epa-display-verify-result (verify-result) - (declare (obsolete epa-display-info "23.1")) - (epa-display-info (epg-verify-result-to-string verify-result))) - (defun epa-passphrase-callback-function (context key-id handback) (if (eq key-id 'SYM) (read-passwd diff --git a/lisp/epg.el b/lisp/epg.el index 5b90bc290a..dd19f73eb1 100644 --- a/lisp/epg.el +++ b/lisp/epg.el @@ -180,6 +180,8 @@ 'epg-error (file nil :read-only t) (string nil :read-only t)) +(declare-function epa-passphrase-callback-function "epa.el") + (cl-defstruct (epg-context (:constructor nil) (:constructor epg-context--make @@ -204,7 +206,7 @@ 'epg-error cipher-algorithm digest-algorithm compress-algorithm - (passphrase-callback (list #'epg-passphrase-callback-function)) + (passphrase-callback (list #'epa-passphrase-callback-function)) progress-callback edit-callback signers @@ -1234,19 +1236,6 @@ epg--status-IMPORT_RES (epg-context-result-for context 'import-status))) (epg-context-set-result-for context 'import-status nil))) -(defun epg-passphrase-callback-function (context key-id _handback) - (declare (obsolete epa-passphrase-callback-function "23.1")) - (if (eq key-id 'SYM) - (read-passwd "Passphrase for symmetric encryption: " - (eq (epg-context-operation context) 'encrypt)) - (read-passwd - (if (eq key-id 'PIN) - "Passphrase for PIN: " - (let ((entry (assoc key-id epg-user-id-alist))) - (if entry - (format "Passphrase for %s %s: " key-id (cdr entry)) - (format "Passphrase for %s: " key-id))))))) - (defun epg--list-keys-1 (context name mode) (let ((args (append (if (epg-context-home-directory context) (list "--homedir" diff --git a/lisp/eshell/em-rebind.el b/lisp/eshell/em-rebind.el index bf5a4bf1af..7991c63177 100644 --- a/lisp/eshell/em-rebind.el +++ b/lisp/eshell/em-rebind.el @@ -114,7 +114,6 @@ eshell-cannot-leave-input-list backward-list forward-page backward-page - forward-point forward-paragraph backward-paragraph backward-prefix-chars diff --git a/lisp/eshell/eshell.el b/lisp/eshell/eshell.el index 5ffb159b57..6698ca45de 100644 --- a/lisp/eshell/eshell.el +++ b/lisp/eshell/eshell.el @@ -384,15 +384,6 @@ eshell-command-result (set status-var eshell-last-command-status)) (cadr result)))))) -;;;_* Reporting bugs -;; -;; If you do encounter a bug, on any system, please report -;; it -- in addition to any particular oddities in your configuration -;; -- so that the problem may be corrected for the benefit of others. - -;;;###autoload -(define-obsolete-function-alias 'eshell-report-bug 'report-emacs-bug "23.1") - ;;; Code: (defun eshell-unload-all-modules () diff --git a/lisp/ffap.el b/lisp/ffap.el index ceba9d2622..4a506207d5 100644 --- a/lisp/ffap.el +++ b/lisp/ffap.el @@ -1824,12 +1824,6 @@ ffap-literally (defalias 'find-file-literally-at-point 'ffap-literally) -\f -;;; Bug Reporter: - -(define-obsolete-function-alias 'ffap-bug 'report-emacs-bug "23.1") -(define-obsolete-function-alias 'ffap-submit-bug 'report-emacs-bug "23.1") - \f ;;; Hooks for Gnus, VM, Rmail: ;; diff --git a/lisp/files.el b/lisp/files.el index 1909669346..dd48c151e3 100644 --- a/lisp/files.el +++ b/lisp/files.el @@ -979,14 +979,6 @@ locate-file-completion-table (completion-table-with-context string-dir names string-file pred action))))) -(defun locate-file-completion (string path-and-suffixes action) - "Do completion for file names passed to `locate-file'. -PATH-AND-SUFFIXES is a pair of lists, (DIRECTORIES . SUFFIXES)." - (declare (obsolete locate-file-completion-table "23.1")) - (locate-file-completion-table (car path-and-suffixes) - (cdr path-and-suffixes) - string nil action)) - (defvar locate-dominating-stop-dir-regexp (purecopy "\\`\\(?:[\\/][\\/][^\\/]+[\\/]\\|/\\(?:net\\|afs\\|\\.\\.\\.\\)/\\)\\'") "Regexp of directory names that stop the search in `locate-dominating-file'. diff --git a/lisp/gnus/mml-smime.el b/lisp/gnus/mml-smime.el index 4754f37a2d..acddb30033 100644 --- a/lisp/gnus/mml-smime.el +++ b/lisp/gnus/mml-smime.el @@ -329,7 +329,6 @@ password-cache-expiry (autoload 'epg-verify-string "epg") (autoload 'epg-sign-string "epg") (autoload 'epg-encrypt-string "epg") - (autoload 'epg-passphrase-callback-function "epg") (autoload 'epg-context-set-passphrase-callback "epg") (autoload 'epg-sub-key-fingerprint "epg") (autoload 'epg-configuration "epg-config") diff --git a/lisp/gnus/mml1991.el b/lisp/gnus/mml1991.el index 8be1b84e52..88864ea357 100644 --- a/lisp/gnus/mml1991.el +++ b/lisp/gnus/mml1991.el @@ -242,7 +242,6 @@ mml1991-pgg-encrypt (defvar epg-user-id-alist) (autoload 'epg-make-context "epg") -(autoload 'epg-passphrase-callback-function "epg") (autoload 'epa-select-keys "epa") (autoload 'epg-list-keys "epg") (autoload 'epg-context-set-armor "epg") diff --git a/lisp/gnus/mml2015.el b/lisp/gnus/mml2015.el index d1d150ad2e..45c9bbfe90 100644 --- a/lisp/gnus/mml2015.el +++ b/lisp/gnus/mml2015.el @@ -712,7 +712,6 @@ inhibit-redisplay (autoload 'epg-verify-string "epg") (autoload 'epg-sign-string "epg") (autoload 'epg-encrypt-string "epg") -(autoload 'epg-passphrase-callback-function "epg") (autoload 'epg-context-set-passphrase-callback "epg") (autoload 'epg-key-sub-key-list "epg") (autoload 'epg-sub-key-capability "epg") diff --git a/lisp/hi-lock.el b/lisp/hi-lock.el index 33ca40f8de..0ffe77d276 100644 --- a/lisp/hi-lock.el +++ b/lisp/hi-lock.el @@ -237,17 +237,11 @@ hi-lock-interactive-lighters "Human-readable lighters for `hi-lock-interactive-patterns'.") (put 'hi-lock-interactive-lighters 'permanent-local t) -(define-obsolete-variable-alias 'hi-lock-face-history - 'hi-lock-face-defaults "23.1") (defvar hi-lock-face-defaults '("hi-yellow" "hi-pink" "hi-green" "hi-blue" "hi-salmon" "hi-aquamarine" "hi-black-b" "hi-blue-b" "hi-red-b" "hi-green-b" "hi-black-hb") "Default faces for hi-lock interactive functions.") -(define-obsolete-variable-alias 'hi-lock-regexp-history - 'regexp-history - "23.1") - (defvar hi-lock-file-patterns-prefix "Hi-lock" "String used to identify hi-lock patterns at the start of files.") diff --git a/lisp/hilit-chg.el b/lisp/hilit-chg.el index 04a5ccd8d5..ae97bb008a 100644 --- a/lisp/hilit-chg.el +++ b/lisp/hilit-chg.el @@ -224,9 +224,6 @@ highlight-changes-colors ;; When you invoke highlight-changes-mode, should highlight-changes-visible-mode ;; be on or off? -(define-obsolete-variable-alias 'highlight-changes-initial-state - 'highlight-changes-visibility-initial-state "23.1") - (defcustom highlight-changes-visibility-initial-state t "Controls whether changes are initially visible in Highlight Changes mode. @@ -236,13 +233,7 @@ highlight-changes-visibility-initial-state :type 'boolean :group 'highlight-changes) -;; highlight-changes-global-initial-state has been removed - - - ;; These are the strings displayed in the mode-line for the minor mode: -(define-obsolete-variable-alias 'highlight-changes-active-string - 'highlight-changes-visible-string "23.1") (defcustom highlight-changes-visible-string " +Chg" "The string used when in Highlight Changes mode and changes are visible. @@ -252,9 +243,6 @@ highlight-changes-visible-string (const :tag "None" nil)) :group 'highlight-changes) -(define-obsolete-variable-alias 'highlight-changes-passive-string - 'highlight-changes-invisible-string "23.1") - (defcustom highlight-changes-invisible-string " -Chg" "The string used when in Highlight Changes mode and changes are hidden. This should be set to nil if no indication is desired, or to @@ -957,10 +945,6 @@ hilit-chg-get-diff-list-hk (define-globalized-minor-mode global-highlight-changes-mode highlight-changes-mode highlight-changes-mode-turn-on) -(define-obsolete-function-alias - 'global-highlight-changes - 'global-highlight-changes-mode "23.1") - (defun highlight-changes-mode-turn-on () "See if Highlight Changes mode should be turned on for this buffer. This is called when `global-highlight-changes-mode' is turned on." diff --git a/lisp/international/mule-cmds.el b/lisp/international/mule-cmds.el index 7714a778fc..5fe931dd9b 100644 --- a/lisp/international/mule-cmds.el +++ b/lisp/international/mule-cmds.el @@ -2968,11 +2968,6 @@ unify-8859-on-decoding-mode ;; Doc said "obsolete" in 23.1, this statement only added in 24.1. (make-obsolete 'unify-8859-on-decoding-mode "don't use it." "23.1") -(defvar nonascii-insert-offset 0) -(make-obsolete-variable 'nonascii-insert-offset "do not use it." "23.1") -(defvar nonascii-translation-table nil) -(make-obsolete-variable 'nonascii-translation-table "do not use it." "23.1") - (defvar ucs-names nil "Hash table of cached CHAR-NAME keys to CHAR-CODE values.") diff --git a/lisp/international/mule-diag.el b/lisp/international/mule-diag.el index 80e78ef787..b13bde58ca 100644 --- a/lisp/international/mule-diag.el +++ b/lisp/international/mule-diag.el @@ -200,10 +200,6 @@ list-character-sets-2 ;;; (charset-iso-graphic-plane charset) (charset-description charset))))) -(defvar non-iso-charset-alist nil - "Obsolete.") -(make-obsolete-variable 'non-iso-charset-alist "no longer relevant." "23.1") - ;; A variable to hold charset input history. (defvar charset-history nil) diff --git a/lisp/international/mule-util.el b/lisp/international/mule-util.el index 5cc10b1315..660ac58e02 100644 --- a/lisp/international/mule-util.el +++ b/lisp/international/mule-util.el @@ -274,15 +274,6 @@ with-coding-priority ;;;###autoload(put 'with-coding-priority 'lisp-indent-function 1) (put 'with-coding-priority 'edebug-form-spec t) -;;;###autoload -(defmacro detect-coding-with-priority (from to priority-list) - "Detect a coding system of the text between FROM and TO with PRIORITY-LIST. -PRIORITY-LIST is an alist of coding categories vs the corresponding -coding systems ordered by priority." - (declare (obsolete with-coding-priority "23.1")) - `(with-coding-priority (mapcar #'cdr ,priority-list) - (detect-coding-region ,from ,to))) - ;;;###autoload (defun detect-coding-with-language-environment (from to lang-env) "Detect a coding system for the text between FROM and TO with LANG-ENV. diff --git a/lisp/international/mule.el b/lisp/international/mule.el index df71205d51..092abc09b0 100644 --- a/lisp/international/mule.el +++ b/lisp/international/mule.el @@ -408,16 +408,6 @@ charset-info ;; because that makes a bootstrapping problem ;; if you need to recompile all the Lisp files using interpreted code. -(defun charset-id (_charset) - "Always return 0. This is provided for backward compatibility." - (declare (obsolete nil "23.1")) - 0) - -(defmacro charset-bytes (_charset) - "Always return 0. This is provided for backward compatibility." - (declare (obsolete nil "23.1")) - 0) - (defun get-charset-property (charset propname) "Return the value of CHARSET's PROPNAME property. This is the last value stored with @@ -463,19 +453,8 @@ charset-long-name "Return long name of CHARSET." (plist-get (charset-plist charset) :long-name)) -(defun charset-list () - "Return list of all charsets ever defined." - (declare (obsolete charset-list "23.1")) - charset-list) - \f ;;; CHARACTER -(define-obsolete-function-alias 'char-valid-p 'characterp "23.1") - -(defun generic-char-p (_char) - "Always return nil. This is provided for backward compatibility." - (declare (obsolete nil "23.1")) - nil) (defun make-char-internal (charset-id &optional code1 code2) (let ((charset (aref emacs-mule-charset-table charset-id))) @@ -1085,14 +1064,11 @@ coding-system-list (setq codings (cons alias codings)))))) codings)) -(defconst char-coding-system-table nil - "It exists just for backward compatibility, and the value is always nil.") -(make-obsolete-variable 'char-coding-system-table nil "23.1") - (defun transform-make-coding-system-args (name type &optional doc-string props) "For internal use only. Transform XEmacs style args for `make-coding-system' to Emacs style. Value is a list of transformed arguments." + (declare (obsolete nil "28.1")) (let ((mnemonic (string-to-char (or (plist-get props 'mnemonic) "?"))) (eol-type (plist-get props 'eol-type)) properties tmp) @@ -1170,106 +1146,6 @@ transform-make-coding-system-args (error "unsupported XEmacs style make-coding-style arguments: %S" `(,name ,type ,doc-string ,props)))))) -(defun make-coding-system (coding-system type mnemonic doc-string - &optional - flags - properties - eol-type) - "Define a new coding system CODING-SYSTEM (symbol). -This function is provided for backward compatibility." - (declare (obsolete define-coding-system "23.1")) - ;; For compatibility with XEmacs, we check the type of TYPE. If it - ;; is a symbol, perhaps, this function is called with XEmacs-style - ;; arguments. Here, try to transform that kind of arguments to - ;; Emacs style. - (if (symbolp type) - (let ((args (transform-make-coding-system-args coding-system type - mnemonic doc-string))) - (setq coding-system (car args) - type (nth 1 args) - mnemonic (nth 2 args) - doc-string (nth 3 args) - flags (nth 4 args) - properties (nth 5 args) - eol-type (nth 6 args)))) - - (setq type - (cond ((eq type 0) 'emacs-mule) - ((eq type 1) 'shift-jis) - ((eq type 2) 'iso2022) - ((eq type 3) 'big5) - ((eq type 4) 'ccl) - ((eq type 5) 'raw-text) - (t - (error "Invalid coding system type: %s" type)))) - - (setq properties - (let ((plist nil) key) - (dolist (elt properties) - (setq key (car elt)) - (cond ((eq key 'post-read-conversion) - (setq key :post-read-conversion)) - ((eq key 'pre-write-conversion) - (setq key :pre-write-conversion)) - ((eq key 'translation-table-for-decode) - (setq key :decode-translation-table)) - ((eq key 'translation-table-for-encode) - (setq key :encode-translation-table)) - ((eq key 'safe-charsets) - (setq key :charset-list)) - ((eq key 'mime-charset) - (setq key :mime-charset)) - ((eq key 'valid-codes) - (setq key :valids))) - (setq plist (plist-put plist key (cdr elt)))) - plist)) - (setq properties (plist-put properties :mnemonic mnemonic)) - (plist-put properties :coding-type type) - (cond ((eq eol-type 0) (setq eol-type 'unix)) - ((eq eol-type 1) (setq eol-type 'dos)) - ((eq eol-type 2) (setq eol-type 'mac)) - ((vectorp eol-type) (setq eol-type nil))) - (plist-put properties :eol-type eol-type) - - (cond - ((eq type 'iso2022) - (plist-put properties :flags - (list (and (or (consp (nth 0 flags)) - (consp (nth 1 flags)) - (consp (nth 2 flags)) - (consp (nth 3 flags))) 'designation) - (or (nth 4 flags) 'long-form) - (and (nth 5 flags) 'ascii-at-eol) - (and (nth 6 flags) 'ascii-at-cntl) - (and (nth 7 flags) '7-bit) - (and (nth 8 flags) 'locking-shift) - (and (nth 9 flags) 'single-shift) - (and (nth 10 flags) 'use-roman) - (and (nth 11 flags) 'use-oldjis) - (or (nth 12 flags) 'direction) - (and (nth 13 flags) 'init-at-bol) - (and (nth 14 flags) 'designate-at-bol) - (and (nth 15 flags) 'safe) - (and (nth 16 flags) 'latin-extra))) - (plist-put properties :designation - (let ((vec (make-vector 4 nil))) - (dotimes (i 4) - (let ((spec (nth i flags))) - (if (eq spec t) - (aset vec i '(94 96)) - (if (consp spec) - (progn - (if (memq t spec) - (setq spec (append (delq t spec) '(94 96)))) - (aset vec i spec)))))) - vec))) - - ((eq type 'ccl) - (plist-put properties :ccl-decoder (car flags)) - (plist-put properties :ccl-encoder (cdr flags)))) - - (apply 'define-coding-system coding-system doc-string properties)) - (defun merge-coding-systems (first second) "Fill in any unspecified aspects of coding system FIRST from SECOND. Return the resulting coding system." @@ -1616,15 +1492,6 @@ set-next-selection-coding-system (setq next-selection-coding-system coding-system)) -(defun set-coding-priority (arg) - "Set priority of coding categories according to ARG. -ARG is a list of coding categories ordered by priority. - -This function is provided for backward compatibility." - (declare (obsolete set-coding-system-priority "23.1")) - (apply 'set-coding-system-priority - (mapcar #'(lambda (x) (symbol-value x)) arg))) - ;;; X selections (defvar ctext-non-standard-encodings-alist diff --git a/lisp/mail/rmail.el b/lisp/mail/rmail.el index 44cde7cb5a..312baffb90 100644 --- a/lisp/mail/rmail.el +++ b/lisp/mail/rmail.el @@ -521,25 +521,6 @@ rmail-mmdf-delim1 (defvar rmail-mmdf-delim2 "^\001\001\001\001\n" "Regexp marking the end of an mmdf message.") -;; FIXME Post-mbox, this is now unused. -;; In Emacs-22, this was called: -;; i) the very first time a message was shown. -;; ii) when toggling the headers to the normal state, every time. -;; It's not clear what it should do now, since there is nothing that -;; records when a message is shown for the first time (unseen is not -;; necessarily the same thing). -;; See https://lists.gnu.org/r/emacs-devel/2009-03/msg00013.html -(defcustom rmail-message-filter nil - "If non-nil, a filter function for new messages in RMAIL. -Called with region narrowed to the message, including headers, -before obeying `rmail-ignored-headers'." - :group 'rmail-headers - :type '(choice (const nil) function)) - -(make-obsolete-variable 'rmail-message-filter - "it is not used (try `rmail-show-message-hook')." - "23.1") - (defcustom rmail-automatic-folder-directives nil "List of directives specifying how to automatically file messages. Whenever Rmail shows a message in the folder that `rmail-file-name' diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index d2c3f9045e..0d99f4687c 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -685,13 +685,6 @@ completion--twq-all completions) qboundary)))) -;; (defmacro complete-in-turn (a b) `(completion-table-in-turn ,a ,b)) -;; (defmacro dynamic-completion-table (fun) `(completion-table-dynamic ,fun)) -(define-obsolete-function-alias - 'complete-in-turn #'completion-table-in-turn "23.1") -(define-obsolete-function-alias - 'dynamic-completion-table #'completion-table-dynamic "23.1") - ;;; Minibuffer completion (defgroup minibuffer nil @@ -1770,9 +1763,6 @@ completion--insert-strings ;; Round up to a whole number of columns. (* colwidth (ceiling length colwidth)))))))))))) -(defvar completion-common-substring nil) -(make-obsolete-variable 'completion-common-substring nil "23.1") - (defvar completion-setup-hook nil "Normal hook run at the end of setting up a completion list buffer. When this hook is run, the current buffer is the one in which the @@ -1864,11 +1854,7 @@ display-completion-list (insert "Possible completions are:\n") (completion--insert-strings completions)))) - ;; The hilit used to be applied via completion-setup-hook, so there - ;; may still be some code that uses completion-common-substring. - (with-no-warnings - (let ((completion-common-substring common-substring)) - (run-hooks 'completion-setup-hook))) + (run-hooks 'completion-setup-hook) nil) (defvar completion-extra-properties nil @@ -2374,8 +2360,6 @@ minibuffer-local-filename-completion-map Gets combined either with `minibuffer-local-completion-map' or with `minibuffer-local-must-match-map'.") -(define-obsolete-variable-alias 'minibuffer-local-must-match-filename-map - 'minibuffer-local-filename-must-match-map "23.1") (defvar minibuffer-local-filename-must-match-map (make-sparse-keymap)) (make-obsolete-variable 'minibuffer-local-filename-must-match-map nil "24.1") diff --git a/lisp/mouse.el b/lisp/mouse.el index d369545f18..a06ca2a56c 100644 --- a/lisp/mouse.el +++ b/lisp/mouse.el @@ -274,34 +274,6 @@ mouse-menu-bar-map local-menu minor-mode-menus))) -(defun mouse-major-mode-menu (event &optional prefix) - "Pop up a mode-specific menu of mouse commands. -Default to the Edit menu if the major mode doesn't define a menu." - (declare (obsolete mouse-menu-major-mode-map "23.1")) - (interactive "@e\nP") - (run-hooks 'activate-menubar-hook 'menu-bar-update-hook) - (popup-menu (mouse-menu-major-mode-map) event prefix)) - -(defun mouse-popup-menubar (event prefix) - "Pop up a menu equivalent to the menu bar for keyboard EVENT with PREFIX. -The contents are the items that would be in the menu bar whether or -not it is actually displayed." - (declare (obsolete mouse-menu-bar-map "23.1")) - (interactive "@e \nP") - (run-hooks 'activate-menubar-hook 'menu-bar-update-hook) - (popup-menu (mouse-menu-bar-map) (unless (integerp event) event) prefix)) - -(defun mouse-popup-menubar-stuff (event prefix) - "Popup a menu like either `mouse-major-mode-menu' or `mouse-popup-menubar'. -Use the former if the menu bar is showing, otherwise the latter." - (declare (obsolete nil "23.1")) - (interactive "@e\nP") - (run-hooks 'activate-menubar-hook 'menu-bar-update-hook) - (popup-menu - (if (zerop (or (frame-parameter nil 'menu-bar-lines) 0)) - (mouse-menu-bar-map) - (mouse-menu-major-mode-map)) - event prefix)) \f ;; Commands that operate on windows. diff --git a/lisp/net/newst-treeview.el b/lisp/net/newst-treeview.el index 1bed61f3e7..ff8a447c7c 100644 --- a/lisp/net/newst-treeview.el +++ b/lisp/net/newst-treeview.el @@ -131,14 +131,6 @@ newsticker-groups Example: (\"Topmost group\" \"feed1\" (\"subgroup1\" \"feed 2\") \"feed3\")") -(defcustom newsticker-groups-filename - nil - "Name of the newsticker groups settings file." - :version "25.1" ; changed default value to nil - :type '(choice (const nil) string) - :group 'newsticker-treeview) -(make-obsolete-variable 'newsticker-groups-filename 'newsticker-dir "23.1") - ;; ====================================================================== ;;; internal variables ;; ====================================================================== @@ -1265,29 +1257,9 @@ newsticker-treeview-save (defun newsticker--treeview-load () "Load treeview settings." (let* ((coding-system-for-read 'utf-8) - (filename - (or (and newsticker-groups-filename - (not (string= - (expand-file-name newsticker-groups-filename) - (expand-file-name (concat newsticker-dir "/groups")))) - (file-exists-p newsticker-groups-filename) - (y-or-n-p - (format-message - (concat "Obsolete variable `newsticker-groups-filename' " - "points to existing file \"%s\".\n" - "Read it? ") - newsticker-groups-filename)) - newsticker-groups-filename) - (concat newsticker-dir "/groups"))) + (filename (concat newsticker-dir "/groups")) (buf (and (file-exists-p filename) (find-file-noselect filename)))) - (and newsticker-groups-filename - (file-exists-p newsticker-groups-filename) - (y-or-n-p (format-message - (concat "Delete the file \"%s\",\nto which the obsolete " - "variable `newsticker-groups-filename' points ? ") - newsticker-groups-filename)) - (delete-file newsticker-groups-filename)) (when buf (set-buffer buf) (goto-char (point-min)) diff --git a/lisp/obsolete/tpu-edt.el b/lisp/obsolete/tpu-edt.el index d71f79c87b..0de7aa096d 100644 --- a/lisp/obsolete/tpu-edt.el +++ b/lisp/obsolete/tpu-edt.el @@ -287,14 +287,6 @@ tpu-version ;;; ;;; User Configurable Variables ;;; -(defcustom tpu-have-ispell t - "Non-nil means `tpu-spell-check' uses `ispell-region' for spell checking. -Otherwise, use `spell-region'." - :type 'boolean - :group 'tpu) -(make-obsolete-variable 'tpu-have-ispell "the `spell' package is obsolete." - "23.1") - (defcustom tpu-kill-buffers-silently nil "If non-nil, TPU-edt kills modified buffers without asking." :type 'boolean @@ -315,7 +307,6 @@ tpu-pan-columns ;;; Global Keymaps ;;; -(define-obsolete-variable-alias 'GOLD-map 'tpu-gold-map "23.1") (defvar tpu-gold-map (let ((map (make-keymap))) ;; Previously we used escape sequences here. We now instead presume @@ -892,8 +883,7 @@ tpu-spell-check if no region is selected." (interactive) (let ((m (tpu-mark))) - (apply (if tpu-have-ispell 'ispell-region - 'spell-region) + (apply 'ispell-region (if m (if (> m (point)) (list (point) m) (list m (point))) diff --git a/lisp/password-cache.el b/lisp/password-cache.el index f5007579a8..2443f374a8 100644 --- a/lisp/password-cache.el +++ b/lisp/password-cache.el @@ -94,22 +94,6 @@ password-read (or (password-read-from-cache key) (read-passwd prompt))) -(defun password-read-and-add (prompt &optional key) - "Read password, for use with KEY, from user, or from cache if wanted. -Then store the password in the cache. Uses `password-read' and -`password-cache-add'. Custom variables `password-cache' and -`password-cache-expiry' regulate cache behavior. - -Warning: the password is cached without checking that it is -correct. It is better to check the password before caching. If -you must use this function, take care to check passwords and -remove incorrect ones from the cache." - (declare (obsolete password-read "23.1")) - (let ((password (password-read prompt key))) - (when (and password key) - (password-cache-add key password)) - password)) - (defun password-cache-remove (key) "Remove password indexed by KEY from password cache. This is typically run by a timer setup from `password-cache-add', diff --git a/lisp/progmodes/idlwave.el b/lisp/progmodes/idlwave.el index 3092d4c45b..55acb77425 100644 --- a/lisp/progmodes/idlwave.el +++ b/lisp/progmodes/idlwave.el @@ -159,8 +159,6 @@ (defalias 'line-beginning-position 'point-at-bol)) (unless (fboundp 'line-end-position) (defalias 'line-end-position 'point-at-eol)) -(unless (fboundp 'char-valid-p) - (defalias 'char-valid-p 'characterp)) (unless (fboundp 'match-string-no-properties) (defalias 'match-string-no-properties 'match-string)) diff --git a/lisp/shell.el b/lisp/shell.el index dc528412a6..39f2b4ce0f 100644 --- a/lisp/shell.el +++ b/lisp/shell.el @@ -985,9 +985,6 @@ shell-dirtrack-mode (add-hook 'comint-input-filter-functions #'shell-directory-tracker nil t) (remove-hook 'comint-input-filter-functions #'shell-directory-tracker t))) -(define-obsolete-function-alias 'shell-dirtrack-toggle #'shell-dirtrack-mode - "23.1") - (defun shell-cd (dir) "Do normal `cd' to DIR, and set `list-buffers-directory'." (cd dir) diff --git a/lisp/subr.el b/lisp/subr.el index 6bd06a0b82..8eb4cf452d 100644 --- a/lisp/subr.el +++ b/lisp/subr.el @@ -1583,11 +1583,6 @@ posn-object-width-height (make-obsolete 'string-as-multibyte "use `decode-coding-string'." "26.1") (make-obsolete 'string-make-multibyte "use `decode-coding-string'." "26.1") -(defun forward-point (n) - "Return buffer position N characters after (before if N negative) point." - (declare (obsolete "use (+ (point) N) instead." "23.1")) - (+ (point) n)) - (defun log10 (x) "Return (log X 10), the log base 10 of X." (declare (obsolete log "24.4")) @@ -1612,8 +1607,6 @@ log10 (make-obsolete 'set-window-redisplay-end-trigger nil "23.1") (make-obsolete 'run-window-configuration-change-hook nil "27.1") -(make-obsolete 'process-filter-multibyte-p nil "23.1") -(make-obsolete 'set-process-filter-multibyte nil "23.1") (make-obsolete-variable 'command-debug-status "expect it to be removed in a future version." "25.2") diff --git a/lisp/t-mouse.el b/lisp/t-mouse.el index a1af53d8c4..4feab71401 100644 --- a/lisp/t-mouse.el +++ b/lisp/t-mouse.el @@ -62,8 +62,6 @@ gpm-mouse-disable (gpm-mouse-stop)) (set-terminal-parameter nil 'gpm-mouse-active nil)) -;;;###autoload -(define-obsolete-function-alias 't-mouse-mode 'gpm-mouse-mode "23.1") ;;;###autoload (define-minor-mode gpm-mouse-mode "Toggle mouse support in GNU/Linux consoles (GPM Mouse mode). diff --git a/lisp/term/w32-win.el b/lisp/term/w32-win.el index 5901e0295e..e866fdc36c 100644 --- a/lisp/term/w32-win.el +++ b/lisp/term/w32-win.el @@ -78,12 +78,8 @@ (require 'dnd) (require 'w32-vars) -;; Keep an obsolete alias for w32-focus-frame and w32-select-font in case -;; they are used by code outside Emacs. -(define-obsolete-function-alias 'w32-focus-frame 'x-focus-frame "23.1") (declare-function x-select-font "w32font.c" (&optional frame exclude-proportional)) -(define-obsolete-function-alias 'w32-select-font 'x-select-font "23.1") (defvar w32-color-map) ;; defined in w32fns.c (make-obsolete 'w32-default-color-map nil "24.1") diff --git a/lisp/textmodes/ispell.el b/lisp/textmodes/ispell.el index 65f61644b6..ffcdb9bd16 100644 --- a/lisp/textmodes/ispell.el +++ b/lisp/textmodes/ispell.el @@ -621,15 +621,6 @@ ispell-encoding8-command Earlier Aspell versions do not consistently support charset encoding. Handling this would require some extra guessing in `ispell-aspell-find-dictionary'.") -(defvar ispell-aspell-supports-utf8 nil - "Non-nil if Aspell has consistent command line UTF-8 support. Obsolete. -ispell.el and flyspell.el will use for this purpose the more generic -variable `ispell-encoding8-command' for both Aspell and Hunspell. Is left -here just for backwards compatibility.") - -(make-obsolete-variable 'ispell-aspell-supports-utf8 - 'ispell-encoding8-command "23.1") - (defvar ispell-dicts-name2locale-equivs-alist '(("american" "en_US") ("brasileiro" "pt_BR") diff --git a/lisp/textmodes/remember.el b/lisp/textmodes/remember.el index 279dbb4450..7bc7dc1762 100644 --- a/lisp/textmodes/remember.el +++ b/lisp/textmodes/remember.el @@ -487,9 +487,6 @@ remember-finalize (interactive) (remember-region (point-min) (point-max))) -;; Org needs this -(define-obsolete-function-alias 'remember-buffer 'remember-finalize "23.1") - (defun remember-destroy () "Destroy the current *Remember* buffer." (interactive) diff --git a/lisp/tooltip.el b/lisp/tooltip.el index f35f6b9a03..5f5a4788b2 100644 --- a/lisp/tooltip.el +++ b/lisp/tooltip.el @@ -167,8 +167,6 @@ tooltip-resize-echo-area \f ;;; Variables that are not customizable. -(define-obsolete-variable-alias 'tooltip-hook 'tooltip-functions "23.1") - (defvar tooltip-functions nil "Functions to call to display tooltips. Each function is called with one argument EVENT which is a copy diff --git a/lisp/url/url-util.el b/lisp/url/url-util.el index 6dd7a9c2aa..0a7e7e205e 100644 --- a/lisp/url/url-util.el +++ b/lisp/url/url-util.el @@ -569,31 +569,6 @@ url-get-url-at-point (setq url nil)) url))) -(defun url-generate-unique-filename (&optional fmt) - "Generate a unique filename in `url-temporary-directory'." - (declare (obsolete make-temp-file "23.1")) - ;; This variable is obsolete, but so is this function. - (let ((tempdir (with-no-warnings url-temporary-directory))) - (if (not fmt) - (let ((base (format "url-tmp.%d" (user-real-uid))) - (fname "") - (x 0)) - (setq fname (format "%s%d" base x)) - (while (file-exists-p - (expand-file-name fname tempdir)) - (setq x (1+ x) - fname (concat base (int-to-string x)))) - (expand-file-name fname tempdir)) - (let ((base (concat "url" (int-to-string (user-real-uid)))) - (fname "") - (x 0)) - (setq fname (format fmt (concat base (int-to-string x)))) - (while (file-exists-p - (expand-file-name fname tempdir)) - (setq x (1+ x) - fname (format fmt (concat base (int-to-string x))))) - (expand-file-name fname tempdir))))) - (defun url-extract-mime-headers () "Set `url-current-mime-headers' in current buffer." (save-excursion diff --git a/lisp/url/url-vars.el b/lisp/url/url-vars.el index d9277cf6f4..e35823ab9a 100644 --- a/lisp/url/url-vars.el +++ b/lisp/url/url-vars.el @@ -312,13 +312,6 @@ url-max-password-attempts :type 'integer :group 'url) -(defcustom url-temporary-directory (or (getenv "TMPDIR") "/tmp") - "Where temporary files go." - :type 'directory - :group 'url-file) -(make-obsolete-variable 'url-temporary-directory - 'temporary-file-directory "23.1") - (defcustom url-show-status t "Whether to show a running total of bytes transferred. Can cause a large hit if using a remote X display over a slow link, or diff --git a/lisp/vc/vc-hooks.el b/lisp/vc/vc-hooks.el index ce72a49b95..f09ceddcb3 100644 --- a/lisp/vc/vc-hooks.el +++ b/lisp/vc/vc-hooks.el @@ -505,14 +505,6 @@ vc-working-revision (vc-call-backend backend 'working-revision file)))))) -;; Backward compatibility. -(define-obsolete-function-alias - 'vc-workfile-version 'vc-working-revision "23.1") -(defun vc-default-working-revision (backend file) - (message - "`working-revision' not found: using the old `workfile-version' instead") - (vc-call-backend backend 'workfile-version file)) - (defun vc-default-registered (backend file) "Check if FILE is registered in BACKEND using vc-BACKEND-master-templates." (let ((sym (vc-make-backend-sym backend 'master-templates))) diff --git a/lisp/vc/vc-mtn.el b/lisp/vc/vc-mtn.el index 092d8b5396..3c26ffc0e5 100644 --- a/lisp/vc/vc-mtn.el +++ b/lisp/vc/vc-mtn.el @@ -60,7 +60,6 @@ vc-mtn-annotate-switches :version "25.1" :group 'vc-mtn) -(define-obsolete-variable-alias 'vc-mtn-command 'vc-mtn-program "23.1") (defcustom vc-mtn-program "mtn" "Name of the monotone executable." :type 'string diff --git a/lisp/vc/vc.el b/lisp/vc/vc.el index 65775f8e46..5561292d8c 100644 --- a/lisp/vc/vc.el +++ b/lisp/vc/vc.el @@ -2709,9 +2709,6 @@ vc-revert (vc-revert-file file) (message "Reverting %s...done" (vc-delistify files))))) -;;;###autoload -(define-obsolete-function-alias 'vc-revert-buffer 'vc-revert "23.1") - ;;;###autoload (defun vc-pull (&optional arg) "Update the current fileset or branch. diff --git a/lisp/vcursor.el b/lisp/vcursor.el index fa0cbb74b0..3601abcd6e 100644 --- a/lisp/vcursor.el +++ b/lisp/vcursor.el @@ -1132,9 +1132,6 @@ vcursor-copy-line (vcursor-copy (if (or (= count 0) arg) (1+ count) count))) ) -(define-obsolete-function-alias - 'vcursor-toggle-vcursor-map 'vcursor-use-vcursor-map "23.1") - (defun vcursor-post-command () (and vcursor-auto-disable (not vcursor-last-command) vcursor-overlay diff --git a/src/coding.c b/src/coding.c index 071124b4ef..1d79c703a3 100644 --- a/src/coding.c +++ b/src/coding.c @@ -11829,8 +11829,7 @@ syms_of_coding (void) This variable is given to `completing-read' as COLLECTION argument. Do not alter the value of this variable manually. This variable should be -updated by the functions `make-coding-system' and -`define-coding-system-alias'. */); +updated by `define-coding-system-alias'. */); Vcoding_system_alist = Qnil; DEFVAR_LISP ("coding-category-list", Vcoding_category_list, diff --git a/test/manual/etags/c-src/abbrev.c b/test/manual/etags/c-src/abbrev.c index 03b9f0e65b..44563d6046 100644 --- a/test/manual/etags/c-src/abbrev.c +++ b/test/manual/etags/c-src/abbrev.c @@ -78,9 +78,6 @@ int last_abbrev_point; -/* Hook to run before expanding any abbrev. */ - -Lisp_Object Vpre_abbrev_expand_hook, Qpre_abbrev_expand_hook; \f DEFUN ("make-abbrev-table", Fmake_abbrev_table, Smake_abbrev_table, 0, 0, 0, "Create a new, empty abbrev table object.") @@ -232,9 +229,6 @@ DEFUN ("expand-abbrev", Fexpand_abbrev, Sexpand_abbrev, 0, 0, "", value = Qnil; - if (!NILP (Vrun_hooks)) - call1 (Vrun_hooks, Qpre_abbrev_expand_hook); - wordstart = 0; if (!(BUFFERP (Vabbrev_start_location_buffer) && XBUFFER (Vabbrev_start_location_buffer) == current_buffer)) @@ -595,14 +589,6 @@ syms_of_abbrev () "*Set non-nil means expand multi-word abbrevs all caps if abbrev was so."); abbrev_all_caps = 0; - DEFVAR_LISP ("pre-abbrev-expand-hook", &Vpre_abbrev_expand_hook, - "Function or functions to be called before abbrev expansion is done.\n\ -This is the first thing that `expand-abbrev' does, and so this may change\n\ -the current abbrev table before abbrev lookup happens."); - Vpre_abbrev_expand_hook = Qnil; - Qpre_abbrev_expand_hook = intern ("pre-abbrev-expand-hook"); - staticpro (&Qpre_abbrev_expand_hook); - defsubr (&Smake_abbrev_table); defsubr (&Sclear_abbrev_table); defsubr (&Sdefine_abbrev); -- 2.27.0 ^ permalink raw reply related [flat|nested] 838+ messages in thread
* Re: Delete variables obsolete since Emacs 23 2020-08-08 0:28 ` Stefan Kangas @ 2020-08-14 11:11 ` Stefan Kangas 2020-08-14 15:42 ` Stefan Kangas 1 sibling, 0 replies; 838+ messages in thread From: Stefan Kangas @ 2020-08-14 11:11 UTC (permalink / raw) To: Stefan Monnier, emacs-devel Stefan Kangas <stefankangas@gmail.com> writes: > I have looked this all over again, and I'm attaching a (hopefully) final > patch here. I found some places where the documentation needed updating, > and one or two uses that I had missed previously. There have been > relatively minor changes since last time, but I want to give everyone a > chance to comment before pushing. No further comments within a week. Pushed to master as commit 874ba85363e. Best regards, Stefan Kangas ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Delete variables obsolete since Emacs 23 2020-08-08 0:28 ` Stefan Kangas 2020-08-14 11:11 ` Stefan Kangas @ 2020-08-14 15:42 ` Stefan Kangas 2020-08-14 18:56 ` Drew Adams 1 sibling, 1 reply; 838+ messages in thread From: Stefan Kangas @ 2020-08-14 15:42 UTC (permalink / raw) To: Stefan Monnier, emacs-devel [-- Attachment #1: Type: text/plain, Size: 432 bytes --] Stefan Kangas <stefankangas@gmail.com> writes: > Besides that, the next step here would be to remove variables obsoleted > in 23.{2,3,4}. I'm attaching a patch to remove most things declared obsolete in 23.2 and 23.3. (Nothing was declared obsolete in 23.4 AFAICT.) There are still some items obsoleted in 23.x left to delete in Semantic. I intend to do that in a separate patch. Comments welcome. Best regards, Stefan Kangas [-- Attachment #2: 0001-Remove-many-items-obsolete-since-Emacs-23.2-and-23.3.patch --] [-- Type: text/x-diff, Size: 36276 bytes --] From 7f3f615b3547ee902461f752ba420ffc705c20d1 Mon Sep 17 00:00:00 2001 From: Stefan Kangas <stefankangas@gmail.com> Date: Sat, 8 Aug 2020 05:32:37 +0200 Subject: [PATCH] Remove many items obsolete since Emacs 23.2 and 23.3 * lisp/allout.el (allout-init): * lisp/emacs-lisp/shadow.el (shadows-compare-text-p): * lisp/ffap.el (ffap-version): * lisp/filecache.el (file-cache-choose-completion): * lisp/help.el (print-help-return-message): * lisp/image-mode.el (image-mode-maybe): * lisp/imenu.el (imenu-example--name-and-position): * lisp/international/mule-cmds.el (princ-list): * lisp/mail/rmail.el (rmail-highlight-face): * lisp/minibuffer.el (read-file-name-predicate): * lisp/mouse.el (mouse-choose-completion): * lisp/progmodes/cc-cmds.el (c-forward-into-nomenclature): * lisp/progmodes/xscheme.el (advertised-xscheme-send-previous-expression): * lisp/simple.el (completion-base-size) (choose-completion-delete-max-match, exchange-dot-and-mark): * lisp/subr.el (eval-next-after-load, interactive-p): * lisp/term.el (term-dynamic-simple-complete): Remove items, obsolete since Emacs 23.2 and 23.3. * doc/misc/cc-mode.texi (Movement Commands): Doc fix. * doc/lispref/help.texi (Accessing Documentation): * lisp/emacs-lisp/edebug.el (edebug-wrap-def-body): * lisp/cedet/data-debug.el: * lisp/simple.el (append-next-kill): * test/manual/cedet/cedet-utests.el (cedet-utest, pulse-test): * test/manual/cedet/semantic-tests.el (semantic-symref-test-count-hits-in-tag) (semantic-lex-spp-write-utest): Use 'called-interactively-p' instead of 'interactive-p'. * lisp/comint.el (comint-dynamic-list-completions): * lisp/progmodes/idlwave.el (idlwave-make-modified-completion-map-xemacs) (idlwave-make-modified-completion-map-emacs): * lisp/progmodes/vhdl-mode.el: * lisp/term.el (term-dynamic-list-completions): Remove references to 'mouse-choose-completion'. * lisp/image-mode.el (image-mode-to-text): Remove reference to 'image-mode-maybe'. * lisp/mail/rmail.el (rmail-highlight-headers): Use 'rmail-highlight' face instead of 'rmail-highlight-face'. * lisp/progmodes/antlr-mode.el (antlr-mode-map, antlr-mode-menu): Remove reference to 'c-forward-into-nomenclature'. * lisp/simple.el (choose-completion, choose-completion-string) (completion-list-mode, completion-setup-function): Don't use 'completion-base-size'. ; * etc/NEWS: List removed items. --- doc/lispref/help.texi | 3 +- doc/misc/cc-mode.texi | 2 -- etc/NEWS | 49 ++++++++++++++++------------- lisp/allout.el | 15 +-------- lisp/cedet/data-debug.el | 2 +- lisp/comint.el | 2 +- lisp/emacs-lisp/edebug.el | 2 +- lisp/emacs-lisp/shadow.el | 3 -- lisp/ffap.el | 2 -- lisp/filecache.el | 3 -- lisp/help.el | 1 - lisp/image-mode.el | 4 +-- lisp/imenu.el | 22 ------------- lisp/international/mule-cmds.el | 6 ---- lisp/mail/rmail.el | 22 ++----------- lisp/minibuffer.el | 5 --- lisp/mouse.el | 3 -- lisp/progmodes/antlr-mode.el | 4 +-- lisp/progmodes/cc-cmds.el | 13 -------- lisp/progmodes/idlwave.el | 11 ++----- lisp/progmodes/vhdl-mode.el | 4 --- lisp/progmodes/xscheme.el | 2 -- lisp/simple.el | 43 +++---------------------- lisp/subr.el | 30 ------------------ lisp/term.el | 49 +---------------------------- test/manual/cedet/cedet-utests.el | 12 +++---- test/manual/cedet/semantic-tests.el | 4 +-- 27 files changed, 55 insertions(+), 263 deletions(-) diff --git a/doc/lispref/help.texi b/doc/lispref/help.texi index 9b3c4fcb23..d4505d5c3f 100644 --- a/doc/lispref/help.texi +++ b/doc/lispref/help.texi @@ -220,7 +220,8 @@ Accessing Documentation @group ;; @r{Display the data.} - (help-setup-xref (list 'describe-symbols pattern) (interactive-p)) + (help-setup-xref (list 'describe-symbols pattern) + (called-interactively-p 'interactive)) (with-help-window (help-buffer) (mapcar describe-func (sort sym-list 'string<))))) @end group diff --git a/doc/misc/cc-mode.texi b/doc/misc/cc-mode.texi index 10bbf8ff09..adc233d99d 100644 --- a/doc/misc/cc-mode.texi +++ b/doc/misc/cc-mode.texi @@ -1024,9 +1024,7 @@ Movement Commands preprocessor statements. @item @kbd{M-x c-backward-into-nomenclature} -@itemx @kbd{M-x c-forward-into-nomenclature} @findex c-backward-into-nomenclature -@findex c-forward-into-nomenclature @findex backward-into-nomenclature @r{(c-)} @findex forward-into-nomenclature @r{(c-)} A popular programming style, especially for object-oriented languages diff --git a/etc/NEWS b/etc/NEWS index 91add027e4..ef9a11c521 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -910,35 +910,42 @@ have now been removed. --- ** Some functions and variables obsolete since Emacs 23 have been removed: - -'GOLD-map', 'bookmark-jump-noselect', +'GOLD-map', 'advertised-xscheme-send-previous-expression', +'allout-init', 'bookmark-jump-noselect', 'bookmark-read-annotation-text-func', 'buffer-menu-mode-hook', -'char-coding-system-table', 'char-valid-p', 'charset-bytes', -'charset-id', 'charset-list' (function), 'complete-in-turn', -'completion-common-substring', 'crm-minibuffer-complete', -'crm-minibuffer-complete-and-exit', 'crm-minibuffer-completion-help', -'custom-mode', 'custom-mode-hook', 'detect-coding-with-priority', -'dirtrack-debug' (function), 'dirtrack-debug-toggle', -'dynamic-completion-table', +'c-forward-into-nomenclature', 'char-coding-system-table', +'char-valid-p', 'charset-bytes', 'charset-id', 'charset-list' +(function), 'choose-completion-delete-max-match', 'complete-in-turn', +'completion-base-size', 'completion-common-substring', +'crm-minibuffer-complete', 'crm-minibuffer-complete-and-exit', +'crm-minibuffer-completion-help', 'custom-mode', 'custom-mode-hook', +'detect-coding-with-priority', 'dirtrack-debug' (function), +'dirtrack-debug-toggle', 'dynamic-completion-table', 'easy-menu-precalculate-equivalent-keybindings', 'epa-display-verify-result', 'epg-passphrase-callback-function', -'eshell-report-bug', 'ffap-bug', 'ffap-submit-bug', 'forward-point', -'generic-char-p', 'global-highlight-changes', 'hi-lock-face-history', +'eshell-report-bug', 'eval-next-after-load', 'exchange-dot-and-mark', +'ffap-bug', 'ffap-submit-bug', 'ffap-version', +'file-cache-choose-completion', 'forward-point', 'generic-char-p', +'global-highlight-changes', 'hi-lock-face-history', 'hi-lock-regexp-history', 'highlight-changes-active-string', 'highlight-changes-initial-state', 'highlight-changes-passive-string', -'ispell-aspell-supports-utf8', 'lisp-mode-auto-fill', +'image-mode-maybe', 'imenu-example--name-and-position', +'interactive-p', 'ispell-aspell-supports-utf8', 'lisp-mode-auto-fill', 'locate-file-completion', 'make-coding-system', -'minibuffer-local-must-match-filename-map', 'mouse-major-mode-menu', -'mouse-popup-menubar', 'mouse-popup-menubar-stuff', -'newsticker-groups-filename', 'non-iso-charset-alist', -'nonascii-insert-offset', 'nonascii-translation-table', -'password-read-and-add', 'pre-abbrev-expand-hook', -'process-filter-multibyte-p', 'remember-buffer' (function), +'minibuffer-local-must-match-filename-map', 'mouse-choose-completion', +'mouse-major-mode-menu', 'mouse-popup-menubar', +'mouse-popup-menubar-stuff', 'newsticker-groups-filename', +'non-iso-charset-alist', 'nonascii-insert-offset', +'nonascii-translation-table', 'password-read-and-add', +'pre-abbrev-expand-hook', 'princ-list', 'print-help-return-message', +'process-filter-multibyte-p', 'read-file-name-predicate', +'remember-buffer' (function), 'rmail-highlight-face', 'rmail-message-filter', 'set-coding-priority', -'set-process-filter-multibyte', 'shell-dirtrack-toggle', -'t-mouse-mode', 'tooltip-hook', 'tpu-have-ispell', +'set-process-filter-multibyte', 'shadows-compare-text-p', +'shell-dirtrack-toggle', 't-mouse-mode', +'term-dynamic-simple-complete', 'tooltip-hook', 'tpu-have-ispell', 'url-generate-unique-filename', 'url-temporary-directory', -'vc-arch-command', 'vc-default-working-revision' (variable), +'vc-arch-command', 'vc-default-working-revision (variable)', 'vc-mtn-command', 'vc-revert-buffer', 'vc-workfile-version', 'vcursor-toggle-vcursor-map', 'w32-focus-frame', 'w32-select-font'. diff --git a/lisp/allout.el b/lisp/allout.el index 05d9153a31..955b7000cb 100644 --- a/lisp/allout.el +++ b/lisp/allout.el @@ -62,8 +62,7 @@ ;; The outline menubar additions provide quick reference to many of the ;; features. See the docstring of the variables `allout-layout' and ;; `allout-auto-activation' for details on automatic activation of -;; `allout-mode' as a minor mode. (`allout-init' is deprecated in favor of -;; a purely customization-based method.) +;; `allout-mode' as a minor mode. ;; ;; Note -- the lines beginning with `;;;_' are outline topic headers. ;; Customize `allout-auto-activation' to enable, then revisit this @@ -1627,18 +1626,6 @@ allout-explicitly-deactivated "If t, `allout-mode's last deactivation was deliberate. So `allout-post-command-business' should not reactivate it...") (make-variable-buffer-local 'allout-explicitly-deactivated) -;;;_ > allout-init (mode) -(defun allout-init (mode) - "DEPRECATED - configure allout activation by customizing -`allout-auto-activation'. This function remains around, limited -from what it did before, for backwards compatibility. - -MODE is the activation mode - see `allout-auto-activation' for -valid values." - (declare (obsolete allout-auto-activation "23.3")) - (customize-set-variable 'allout-auto-activation (format "%s" mode)) - (format "%s" mode)) - ;;;_ > allout-setup-menubar () (defun allout-setup-menubar () "Populate the current buffer's menubar with `allout-mode' stuff." diff --git a/lisp/cedet/data-debug.el b/lisp/cedet/data-debug.el index 604fc40926..44cce389cb 100644 --- a/lisp/cedet/data-debug.el +++ b/lisp/cedet/data-debug.el @@ -38,7 +38,7 @@ ;; "Calculate something complicated at point, and return it." ;; (interactive) ;; function not normally interactive ;; (let ((stuff (do-stuff))) -;; (when (interactive-p) +;; (when (called-interactively-p 'interactive) ;; (data-debug-show-stuff stuff "myStuff")) ;; stuff)) diff --git a/lisp/comint.el b/lisp/comint.el index df4937a7d6..9460009bf4 100644 --- a/lisp/comint.el +++ b/lisp/comint.el @@ -3442,7 +3442,7 @@ comint-dynamic-list-completions (eq (window-buffer (posn-window (event-start first))) (get-buffer "*Completions*")) (memq (key-binding key) - '(mouse-choose-completion choose-completion)))) + '(choose-completion)))) ;; If the user does choose-completion with the mouse, ;; execute the command, then delete the completion window. (progn diff --git a/lisp/emacs-lisp/edebug.el b/lisp/emacs-lisp/edebug.el index d9bbf6129c..7ff6d68c3e 100644 --- a/lisp/emacs-lisp/edebug.el +++ b/lisp/emacs-lisp/edebug.el @@ -1229,7 +1229,7 @@ edebug-wrap-def-body "Wrap the FORMS of a definition body." (if edebug-def-interactive `(let ((,(edebug-interactive-p-name) - (interactive-p))) + (called-interactively-p 'interactive))) ,(edebug-make-enter-wrapper forms)) (edebug-make-enter-wrapper forms))) diff --git a/lisp/emacs-lisp/shadow.el b/lisp/emacs-lisp/shadow.el index 4ff129e367..dd614dd792 100644 --- a/lisp/emacs-lisp/shadow.el +++ b/lisp/emacs-lisp/shadow.el @@ -55,9 +55,6 @@ lisp-shadow :prefix "load-path-shadows-" :group 'lisp) -(define-obsolete-variable-alias 'shadows-compare-text-p - 'load-path-shadows-compare-text "23.3") - (defcustom load-path-shadows-compare-text nil "If non-nil, then shadowing files are reported only if their text differs. This is slower, but filters out some innocuous shadowing." diff --git a/lisp/ffap.el b/lisp/ffap.el index 4a506207d5..97e55df65c 100644 --- a/lisp/ffap.el +++ b/lisp/ffap.el @@ -110,8 +110,6 @@ (require 'url-parse) (require 'thingatpt) -(define-obsolete-variable-alias 'ffap-version 'emacs-version "23.2") - (defgroup ffap nil "Find file or URL at point." :group 'matching diff --git a/lisp/filecache.el b/lisp/filecache.el index 3c07a49420..113d28cf75 100644 --- a/lisp/filecache.el +++ b/lisp/filecache.el @@ -614,9 +614,6 @@ file-cache-choose-completion (select-window (active-minibuffer-window)) (file-cache-minibuffer-complete nil))) -(define-obsolete-function-alias 'file-cache-mouse-choose-completion - #'file-cache-choose-completion "23.2") - (defun file-cache-complete () "Complete the word at point, using the filecache." (interactive) diff --git a/lisp/help.el b/lisp/help.el index b7d867eb70..1b0149616f 100644 --- a/lisp/help.el +++ b/lisp/help.el @@ -131,7 +131,6 @@ help-return-method (WINDOW . quit-window) do quit-window, then select WINDOW. (WINDOW BUF START POINT) display BUF at START, POINT, then select WINDOW.") -(define-obsolete-function-alias 'print-help-return-message 'help-print-return-message "23.2") (defun help-print-return-message (&optional function) "Display or return message saying how to restore windows after help command. This function assumes that `standard-output' is the help buffer. diff --git a/lisp/image-mode.el b/lisp/image-mode.el index 948e62e10d..534609932c 100644 --- a/lisp/image-mode.el +++ b/lisp/image-mode.el @@ -709,7 +709,7 @@ image-mode-to-text displays an image file as text." ;; image-mode-as-text = normal-mode + image-minor-mode (let ((previous-image-type image-type)) ; preserve `image-type' - (major-mode-restore '(image-mode image-mode-maybe image-mode-as-text)) + (major-mode-restore '(image-mode image-mode-as-text)) ;; Restore `image-type' after `kill-all-local-variables' in `normal-mode'. (setq image-type previous-image-type) ;; Enable image minor mode with `C-c C-c'. @@ -759,8 +759,6 @@ image-mode-as-text (if (image-get-display-property) "text" "an image or hex") "."))) -(define-obsolete-function-alias 'image-mode-maybe 'image-mode "23.2") - (defun image-toggle-display-text () "Show the image file as text. Remove text properties that display the image." diff --git a/lisp/imenu.el b/lisp/imenu.el index 1949f2f48f..3a16dcb9ac 100644 --- a/lisp/imenu.el +++ b/lisp/imenu.el @@ -316,28 +316,6 @@ imenu-progress-message ) -;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; -;;;; -;;;; Some examples of functions utilizing the framework of this -;;;; package. -;;;; -;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; - -;; FIXME: This was the only imenu-example-* definition actually used, -;; by cperl-mode.el. Now cperl-mode has its own copy, so these can -;; all be removed. -(defun imenu-example--name-and-position () - "Return the current/previous sexp and its (beginning) location. -Don't move point." - (declare (obsolete "use your own function instead." "23.2")) - (save-excursion - (forward-sexp -1) - ;; [ydi] modified for imenu-use-markers - (let ((beg (if imenu-use-markers (point-marker) (point))) - (end (progn (forward-sexp) (point)))) - (cons (buffer-substring beg end) - beg)))) - ;;; ;;; Lisp ;;; diff --git a/lisp/international/mule-cmds.el b/lisp/international/mule-cmds.el index 5fe931dd9b..02dacaf0a2 100644 --- a/lisp/international/mule-cmds.el +++ b/lisp/international/mule-cmds.el @@ -2070,12 +2070,6 @@ set-language-environment-unibyte "Do various unibyte-mode setups for language environment LANGUAGE-NAME." (set-display-table-and-terminal-coding-system language-name)) -(defun princ-list (&rest args) - "Print all arguments with `princ', then print \"\\n\"." - (declare (obsolete "use mapc and princ instead." "23.3")) - (mapc #'princ args) - (princ "\n")) - (put 'describe-specified-language-support 'apropos-inhibit t) ;; Print language-specific information such as input methods, diff --git a/lisp/mail/rmail.el b/lisp/mail/rmail.el index 312baffb90..f14025a93a 100644 --- a/lisp/mail/rmail.el +++ b/lisp/mail/rmail.el @@ -417,20 +417,6 @@ rmail-highlight :group 'rmail-headers :version "22.1") -;; This was removed in Emacs 23.1 with no notification, an unnecessary -;; incompatible change. -(defcustom rmail-highlight-face 'rmail-highlight - "Face used by Rmail for highlighting headers." - ;; Note that nil doesn't actually mean use the default face, it - ;; means use either bold or highlight. It's not worth fixing this - ;; now that this is obsolete. - :type '(choice (const :tag "Default" nil) - face) - :group 'rmail-headers) -(make-obsolete-variable 'rmail-highlight-face - "customize the face `rmail-highlight' instead." - "23.2") - (defface rmail-header-name '((t (:inherit font-lock-function-name-face))) "Face to use for highlighting the header names. @@ -3012,7 +2998,7 @@ rmail-redecode-body (defun rmail-highlight-headers () "Highlight the headers specified by `rmail-highlighted-headers'. -Uses the face specified by `rmail-highlight-face'." +Uses the face `rmail-highlight'." (if rmail-highlighted-headers (save-excursion (search-forward "\n\n" nil 'move) @@ -3020,11 +3006,7 @@ rmail-highlight-headers (narrow-to-region (point-min) (point)) (let ((case-fold-search t) (inhibit-read-only t) - ;; When rmail-highlight-face is removed, just - ;; use 'rmail-highlight here. - (face (or rmail-highlight-face - (if (face-differs-from-default-p 'bold) - 'bold 'highlight))) + (face 'rmail-highlight) ;; List of overlays to reuse. (overlays rmail-overlay-list)) (goto-char (point-min)) diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index 641a2e5315..1f2dcc4755 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -2539,11 +2539,6 @@ completion-file-name-table all)))))) (file-error nil))) ;PCM often calls with invalid directories. -(defvar read-file-name-predicate nil - "Current predicate used by `read-file-name-internal'.") -(make-obsolete-variable 'read-file-name-predicate - "use the regular PRED argument" "23.2") - (defun completion--sifn-requote (upos qstr) ;; We're looking for `qpos' such that: ;; (equal (substring (substitute-in-file-name qstr) 0 upos) diff --git a/lisp/mouse.el b/lisp/mouse.el index a06ca2a56c..06fdca12b9 100644 --- a/lisp/mouse.el +++ b/lisp/mouse.el @@ -2303,9 +2303,6 @@ mouse-buffer-menu-split ;; Few buffers--put them all in one pane. (list (cons title alist)))) \f -(define-obsolete-function-alias - 'mouse-choose-completion 'choose-completion "23.2") - ;; Font selection. (defun font-menu-add-default () diff --git a/lisp/progmodes/antlr-mode.el b/lisp/progmodes/antlr-mode.el index bf56a7ee49..24e1f8831a 100644 --- a/lisp/progmodes/antlr-mode.el +++ b/lisp/progmodes/antlr-mode.el @@ -695,7 +695,7 @@ antlr-mode-map (define-key map "\e\C-e" 'antlr-end-of-rule) (define-key map "\C-c\C-a" 'antlr-beginning-of-body) (define-key map "\C-c\C-e" 'antlr-end-of-body) - (define-key map "\C-c\C-f" 'c-forward-into-nomenclature) + (define-key map "\C-c\C-f" 'subword-forward) (define-key map "\C-c\C-b" 'c-backward-into-nomenclature) (define-key map "\C-c\C-c" 'comment-region) (define-key map "\C-c\C-v" 'antlr-hide-actions) @@ -745,7 +745,7 @@ antlr-mode-menu ["Backward Statement" c-beginning-of-statement t] ["Forward Statement" c-end-of-statement t] ["Backward Into Nomencl." c-backward-into-nomenclature t] - ["Forward Into Nomencl." c-forward-into-nomenclature t]) + ["Forward Into Nomencl." subword-forward t]) ["Indent Region" indent-region :active (and (not buffer-read-only) (c-region-is-active-p))] ["Comment Out Region" comment-region diff --git a/lisp/progmodes/cc-cmds.el b/lisp/progmodes/cc-cmds.el index 1b557c41a5..4425e275ac 100644 --- a/lisp/progmodes/cc-cmds.el +++ b/lisp/progmodes/cc-cmds.el @@ -1554,19 +1554,6 @@ c-toggle-cpp-indent-to-body (declare-function c-backward-subword "ext:cc-subword" (&optional arg)) ;; "nomenclature" functions + c-scope-operator. -(defun c-forward-into-nomenclature (&optional arg) - "Compatibility alias for `c-forward-subword'." - (interactive "p") - (if (fboundp 'subword-mode) - (progn - (require 'subword) - (subword-forward arg)) - (require 'cc-subword) - (c-forward-subword arg))) -(make-obsolete 'c-forward-into-nomenclature - (if (fboundp 'subword-mode) 'subword-forward 'c-forward-subword) - "23.2") - (defun c-backward-into-nomenclature (&optional arg) "Compatibility alias for `c-backward-subword'." (interactive "p") diff --git a/lisp/progmodes/idlwave.el b/lisp/progmodes/idlwave.el index f7e53ec02d..2d591dd91d 100644 --- a/lisp/progmodes/idlwave.el +++ b/lisp/progmodes/idlwave.el @@ -7118,7 +7118,7 @@ idlwave-default-choose-completion (apply 'idlwave-choose 'default-choose-completion args)) (defun idlwave-make-modified-completion-map-xemacs (old-map) - "Replace `choose-completion' and `mouse-choose-completion' in OLD-MAP." + "Replace `choose-completion' in OLD-MAP." (let ((new-map (copy-keymap old-map))) (define-key new-map [button3up] 'idlwave-mouse-completion-help) (define-key new-map [button3] (lambda () @@ -7141,12 +7141,10 @@ idlwave-display-completion-list-emacs (current-local-map))))))) (defun idlwave-make-modified-completion-map-emacs (old-map) - "Replace `choose-completion' and `mouse-choose-completion' in OLD-MAP." + "Replace `choose-completion' in OLD-MAP." (let ((new-map (copy-keymap old-map))) (substitute-key-definition 'choose-completion 'idlwave-choose-completion new-map) - (substitute-key-definition - 'mouse-choose-completion 'idlwave-mouse-choose-completion new-map) (define-key new-map [mouse-3] 'idlwave-mouse-completion-help) new-map)) @@ -7155,11 +7153,6 @@ idlwave-choose-completion (interactive (list last-nonmenu-event)) (apply 'idlwave-choose 'choose-completion args)) -(defun idlwave-mouse-choose-completion (&rest args) - "Click on an alternative in the `*Completions*' buffer to choose it." - (interactive "e") - (apply 'idlwave-choose 'mouse-choose-completion args)) - ;;---------------------------------------------------------------------- ;;---------------------------------------------------------------------- diff --git a/lisp/progmodes/vhdl-mode.el b/lisp/progmodes/vhdl-mode.el index 9cd84cf713..3d66483b83 100644 --- a/lisp/progmodes/vhdl-mode.el +++ b/lisp/progmodes/vhdl-mode.el @@ -2304,10 +2304,6 @@ vhdl-last-input-event (defvaralias 'vhdl-last-input-event 'last-input-char) (defvaralias 'vhdl-last-input-event 'last-input-event)) -;; `help-print-return-message' changed to `print-help-return-message' in Emacs -;;;(unless (fboundp 'help-print-return-message) -;;; (defalias 'help-print-return-message 'print-help-return-message)) - ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; Compatibility with older VHDL Mode versions diff --git a/lisp/progmodes/xscheme.el b/lisp/progmodes/xscheme.el index 8dfb3a40dd..c6997862f7 100644 --- a/lisp/progmodes/xscheme.el +++ b/lisp/progmodes/xscheme.el @@ -446,8 +446,6 @@ xscheme-enter-interaction-mode (scheme-interaction-mode-initialize) (scheme-interaction-mode t))))) -(define-obsolete-function-alias 'advertised-xscheme-send-previous-expression - 'xscheme-send-previous-expression "23.2") \f ;;;; Debugger Mode diff --git a/lisp/simple.el b/lisp/simple.el index 1cb93c5722..5a8816c8d6 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -5052,7 +5052,8 @@ append-next-kill The argument is used for internal purposes; do not supply one." (interactive "p") - ;; We don't use (interactive-p), since that breaks kbd macros. + ;; We don't use (called-interactively-p 'interactive), since that + ;; breaks kbd macros. (if interactive (progn (setq this-command 'kill-region) @@ -6114,8 +6115,6 @@ pop-mark (pop mark-ring)) (deactivate-mark)) -(define-obsolete-function-alias - 'exchange-dot-and-mark 'exchange-point-and-mark "23.3") (defun exchange-point-and-mark (&optional arg) "Put the mark where point is now, and point where the mark is now. This command works even when the mark is not active, @@ -8400,18 +8399,6 @@ completion-list-insert-choice-function between BEG and END with TEXT. Expected to be set buffer-locally in the *Completions* buffer.") -(defvar completion-base-size nil - "Number of chars before point not involved in completion. -This is a local variable in the completion list buffer. -It refers to the chars in the minibuffer if completing in the -minibuffer, or in `completion-reference-buffer' otherwise. -Only characters in the field at point are included. - -If nil, Emacs determines which part of the tail end of the -buffer's text is involved in completion by comparing the text -directly.") -(make-obsolete-variable 'completion-base-size 'completion-base-position "23.2") - (defun delete-completion-window () "Delete the completion list window. Go to the window from which completion was requested." @@ -8465,7 +8452,6 @@ choose-completion (run-hooks 'mouse-leave-buffer-hook) (with-current-buffer (window-buffer (posn-window (event-start event))) (let ((buffer completion-reference-buffer) - (base-size completion-base-size) (base-position completion-base-position) (insert-function completion-list-insert-choice-function) (choice @@ -8492,10 +8478,6 @@ choose-completion (choose-completion-string choice buffer (or base-position - (when base-size - ;; Someone's using old completion code that doesn't know - ;; about base-position yet. - (list (+ base-size (field-beginning)))) ;; If all else fails, just guess. (list (choose-completion-guess-base-position choice))) insert-function))))) @@ -8523,10 +8505,6 @@ choose-completion-guess-base-position (forward-char 1)) (point)))) -(defun choose-completion-delete-max-match (string) - (declare (obsolete choose-completion-guess-base-position "23.2")) - (delete-region (choose-completion-guess-base-position string) (point))) - (defvar choose-completion-string-functions nil "Functions that may override the normal insertion of a completion choice. These functions are called in order with three arguments: @@ -8555,13 +8533,6 @@ choose-completion-string ;; unless it is reading a file name and CHOICE is a directory, ;; or completion-no-auto-exit is non-nil. - ;; Some older code may call us passing `base-size' instead of - ;; `base-position'. It's difficult to make any use of `base-size', - ;; so we just ignore it. - (unless (consp base-position) - (message "Obsolete `base-size' passed to choose-completion-string") - (setq base-position nil)) - (let* ((buffer (or buffer completion-reference-buffer)) (mini-p (minibufferp buffer))) ;; If BUFFER is a minibuffer, barf unless it's the currently @@ -8617,8 +8588,7 @@ completion-list-mode to select the completion near point. Or click to select one with the mouse. -\\{completion-list-mode-map}" - (set (make-local-variable 'completion-base-size) nil)) +\\{completion-list-mode-map}") (defun completion-list-mode-finish () "Finish setup of the completions buffer. @@ -8655,14 +8625,11 @@ completion-setup-function (if minibuffer-completing-file-name (file-name-as-directory (expand-file-name - (buffer-substring (minibuffer-prompt-end) - (- (point) (or completion-base-size 0)))))))) + (buffer-substring (minibuffer-prompt-end) (point))))))) (with-current-buffer standard-output - (let ((base-size completion-base-size) ;Read before killing localvars. - (base-position completion-base-position) + (let ((base-position completion-base-position) (insert-fun completion-list-insert-choice-function)) (completion-list-mode) - (set (make-local-variable 'completion-base-size) base-size) (set (make-local-variable 'completion-base-position) base-position) (set (make-local-variable 'completion-list-insert-choice-function) insert-fun)) diff --git a/lisp/subr.el b/lisp/subr.el index 8eb4cf452d..f86d0e00f4 100644 --- a/lisp/subr.el +++ b/lisp/subr.el @@ -4669,13 +4669,6 @@ do-after-load-evaluation ;; Finally, run any other hook. (run-hook-with-args 'after-load-functions abs-file)) -(defun eval-next-after-load (file) - "Read the following input sexp, and run it whenever FILE is loaded. -This makes or adds to an entry on `after-load-alist'. -FILE should be the name of a library, with no directory name." - (declare (obsolete eval-after-load "23.2")) - (eval-after-load file (read))) - \f (defun display-delayed-warnings () "Display delayed warnings from `delayed-warnings-list'. @@ -5135,29 +5128,6 @@ called-interactively-p . ,_)) t))))) -(defun interactive-p () - "Return t if the containing function was run directly by user input. -This means that the function was called with `call-interactively' -\(which includes being called as the binding of a key) -and input is currently coming from the keyboard (not a keyboard macro), -and Emacs is not running in batch mode (`noninteractive' is nil). - -The only known proper use of `interactive-p' is in deciding whether to -display a helpful message, or how to display it. If you're thinking -of using it for any other purpose, it is quite likely that you're -making a mistake. Think: what do you want to do when the command is -called from a keyboard macro or in batch mode? - -To test whether your function was called with `call-interactively', -either (i) add an extra optional argument and give it an `interactive' -spec that specifies non-nil unconditionally (such as \"p\"); or (ii) -use `called-interactively-p'. - -To test whether a function can be called interactively, use -`commandp'." - (declare (obsolete called-interactively-p "23.2")) - (called-interactively-p 'interactive)) - (defun internal-push-keymap (keymap symbol) (let ((map (symbol-value symbol))) (unless (memq keymap map) diff --git a/lisp/term.el b/lisp/term.el index 149405fa41..40c8481fdf 100644 --- a/lisp/term.el +++ b/lisp/term.el @@ -4102,53 +4102,6 @@ term-replace-by-expanded-filename (term-dynamic-complete-filename)) -(defun term-dynamic-simple-complete (stub candidates) - "Dynamically complete STUB from CANDIDATES list. -This function inserts completion characters at point by completing STUB from -the strings in CANDIDATES. A completions listing may be shown in a help buffer -if completion is ambiguous. - -Returns nil if no completion was inserted. -Returns `sole' if completed with the only completion match. -Returns `shortest' if completed with the shortest of the completion matches. -Returns `partial' if completed as far as possible with the completion matches. -Returns `listed' if a completion listing was shown. - -See also `term-dynamic-complete-filename'." - (declare (obsolete completion-in-region "23.2")) - (let* ((completion-ignore-case nil) - (completions (all-completions stub candidates))) - (cond ((null completions) - (message "No completions of %s" stub) - nil) - ((= 1 (length completions)) ; Gotcha! - (let ((completion (car completions))) - (if (string-equal completion stub) - (message "Sole completion") - (insert (substring completion (length stub))) - (message "Completed")) - (when term-completion-addsuffix (insert " ")) - 'sole)) - (t ; There's no unique completion. - (let ((completion (try-completion stub candidates))) - ;; Insert the longest substring. - (insert (substring completion (length stub))) - (cond ((and term-completion-recexact term-completion-addsuffix - (string-equal stub completion) - (member completion completions)) - ;; It's not unique, but user wants shortest match. - (insert " ") - (message "Completed shortest") - 'shortest) - ((or term-completion-autolist - (string-equal stub completion)) - ;; It's not unique, list possible completions. - (term-dynamic-list-completions completions) - 'listed) - (t - (message "Partially completed") - 'partial))))))) - (defun term-dynamic-list-filename-completions () "List in help buffer possible completions of the filename at point." (interactive) @@ -4178,7 +4131,7 @@ term-dynamic-list-completions (eq (window-buffer (posn-window (event-start first))) (get-buffer "*Completions*")) (memq (key-binding key) - '(mouse-choose-completion choose-completion)))) + '(choose-completion)))) ;; If the user does choose-completion with the mouse, ;; execute the command, then delete the completion window. (progn diff --git a/test/manual/cedet/cedet-utests.el b/test/manual/cedet/cedet-utests.el index 124b49907d..ee6be438dd 100644 --- a/test/manual/cedet/cedet-utests.el +++ b/test/manual/cedet/cedet-utests.el @@ -150,7 +150,7 @@ cedet-utest ;; Cleanup stray input and events that are in the way. ;; Not doing this causes sit-for to not refresh the screen. ;; Doing this causes the user to need to press keys more frequently. - (when (and (interactive-p) (input-pending-p)) + (when (and (called-interactively-p 'interactive) (input-pending-p)) (if (fboundp 'read-event) (read-event) (read-char))) @@ -497,11 +497,11 @@ pulse-test (error (concat "Pulse test only works on versions of Emacs" " that support pulsing"))) ;; Run the tests - (when (interactive-p) + (when (called-interactively-p 'interactive) (message "<Press a key> Pulse one line.") (read-char)) (pulse-momentary-highlight-one-line (point)) - (when (interactive-p) + (when (called-interactively-p 'interactive) (message "<Press a key> Pulse a region.") (read-char)) (pulse-momentary-highlight-region (point) @@ -510,11 +510,11 @@ pulse-test (forward-char 30) (error nil)) (point))) - (when (interactive-p) + (when (called-interactively-p 'interactive) (message "<Press a key> Pulse line a specific color.") (read-char)) (pulse-momentary-highlight-one-line (point) 'mode-line) - (when (interactive-p) + (when (called-interactively-p 'interactive) (message "<Press a key> Pulse a pre-existing overlay.") (read-char)) (let* ((start (point-at-bol)) @@ -530,7 +530,7 @@ pulse-test (delete-overlay o) (error "Non-temporary overlay was deleted!")) ) - (when (interactive-p) + (when (called-interactively-p 'interactive) (message "Done!")))) (provide 'cedet-utests) diff --git a/test/manual/cedet/semantic-tests.el b/test/manual/cedet/semantic-tests.el index 53552be06b..a0899cb932 100644 --- a/test/manual/cedet/semantic-tests.el +++ b/test/manual/cedet/semantic-tests.el @@ -235,7 +235,7 @@ semantic-lex-spp-write-utest (set-buffer buff) (semantic-lex-spp-write-test) (kill-buffer buff) - (when (not (interactive-p)) + (when (not (called-interactively-p 'interactive)) (kill-buffer "*SPP Write Test*")) ))) @@ -276,7 +276,7 @@ semantic-symref-test-count-hits-in-tag target (lambda (start end prefix) (setq Lcount (1+ Lcount))) (semantic-tag-start tag) (semantic-tag-end tag)) - (when (interactive-p) + (when (called-interactively-p 'interactive) (message "Found %d occurrences of %s in %.2f seconds" Lcount (semantic-tag-name target) (semantic-elapsed-time start nil))) -- 2.28.0 ^ permalink raw reply related [flat|nested] 838+ messages in thread
* RE: Delete variables obsolete since Emacs 23 2020-08-14 15:42 ` Stefan Kangas @ 2020-08-14 18:56 ` Drew Adams 2020-08-14 19:00 ` Lars Ingebrigtsen ` (3 more replies) 0 siblings, 4 replies; 838+ messages in thread From: Drew Adams @ 2020-08-14 18:56 UTC (permalink / raw) To: Stefan Kangas, Stefan Monnier, emacs-devel > I'm attaching a patch to remove most things declared obsolete in 23.2 > and 23.3. (Nothing was declared obsolete in 23.4 AFAICT.) > > There are still some items obsoleted in 23.x left to delete in Semantic. > I intend to do that in a separate patch. > > Comments welcome. PLEASE do not remove `interactive-p'. I have over 2500 lines that use `interactive-p'. Is there some problem with keeping its simple definition as (called-interactively 'interactive)? ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Delete variables obsolete since Emacs 23 2020-08-14 18:56 ` Drew Adams @ 2020-08-14 19:00 ` Lars Ingebrigtsen 2020-08-14 19:14 ` Drew Adams 2020-08-14 19:55 ` Ulrich Mueller ` (2 subsequent siblings) 3 siblings, 1 reply; 838+ messages in thread From: Lars Ingebrigtsen @ 2020-08-14 19:00 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-devel, Stefan Kangas, Stefan Monnier Drew Adams <drew.adams@oracle.com> writes: > PLEASE do not remove `interactive-p'. > > I have over 2500 lines that use `interactive-p'. > > Is there some problem with keeping its simple > definition as (called-interactively 'interactive)? Is there some problem with you adding your own interactive-p if you want to use that name instead? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Delete variables obsolete since Emacs 23 2020-08-14 19:00 ` Lars Ingebrigtsen @ 2020-08-14 19:14 ` Drew Adams 0 siblings, 0 replies; 838+ messages in thread From: Drew Adams @ 2020-08-14 19:14 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: emacs-devel, Stefan Kangas, Stefan Monnier > > Is there some problem with keeping its simple > > definition as (called-interactively 'interactive)? > > Is there some problem with you adding your own interactive-p > if you want to use that name instead? Is there some problem with Emacs keeping the existing simple definition of `interactive-p'? (defun interactive-p () (called-interactively-p 'interactive)) What's the problem with that? With that longstanding definition _in Emacs_, no one needs to define it in a million files or create a file for it and require that file everywhere. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Delete variables obsolete since Emacs 23 2020-08-14 18:56 ` Drew Adams 2020-08-14 19:00 ` Lars Ingebrigtsen @ 2020-08-14 19:55 ` Ulrich Mueller 2020-08-14 23:37 ` Stefan Kangas 2020-08-18 11:17 ` Lars Ingebrigtsen 3 siblings, 0 replies; 838+ messages in thread From: Ulrich Mueller @ 2020-08-14 19:55 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-devel, Stefan Kangas, Stefan Monnier >>>>> On Fri, 14 Aug 2020, Drew Adams wrote: >> I'm attaching a patch to remove most things declared obsolete in 23.2 >> and 23.3. (Nothing was declared obsolete in 23.4 AFAICT.) >> >> There are still some items obsoleted in 23.x left to delete in Semantic. >> I intend to do that in a separate patch. >> >> Comments welcome. > PLEASE do not remove `interactive-p'. > I have over 2500 lines that use `interactive-p'. > Is there some problem with keeping its simple > definition as (called-interactively 'interactive)? I second this. Removal of interactive-p would unnecessarily break many third-party elisp libraries, while keeping the backwards compatible definition in Emacs requires only a single line. ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Delete variables obsolete since Emacs 23 2020-08-14 18:56 ` Drew Adams 2020-08-14 19:00 ` Lars Ingebrigtsen 2020-08-14 19:55 ` Ulrich Mueller @ 2020-08-14 23:37 ` Stefan Kangas 2020-08-15 1:28 ` Drew Adams 2020-08-18 11:17 ` Lars Ingebrigtsen 3 siblings, 1 reply; 838+ messages in thread From: Stefan Kangas @ 2020-08-14 23:37 UTC (permalink / raw) To: Drew Adams, Stefan Monnier, emacs-devel > PLEASE do not remove `interactive-p'. This has been declared obsolete for a decade now. Author: Stefan Monnier <monnier@iro.umontreal.ca> Date: Thu Oct 1 17:47:38 2009 +0000 * eval.c (Fcalled_interactively_p): Add `kind' argument. * subr.el (interactive-p): Mark obsolete. It has been discussed before: https://lists.gnu.org/archive/html/emacs-devel/2015-07/msg00326.html And here: https://lists.gnu.org/archive/html/emacs-devel/2015-11/msg01740.html (I'm sure there are other threads that I couldn't find, if so please link them.) > I have over 2500 lines that use `interactive-p'. Yet once we obsolete something, there surely has to come a point when we can finally delete it. Emacs is already extremely conservative when it comes to dropping backwards support. AFAICT, we generally don't delete anything until five major releases after it was first obsoleted. Best regards, Stefan Kangas ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Delete variables obsolete since Emacs 23 2020-08-14 23:37 ` Stefan Kangas @ 2020-08-15 1:28 ` Drew Adams 2020-08-15 12:51 ` Stefan Monnier 2020-08-16 4:13 ` Richard Stallman 0 siblings, 2 replies; 838+ messages in thread From: Drew Adams @ 2020-08-15 1:28 UTC (permalink / raw) To: Stefan Kangas, Stefan Monnier, emacs-devel There's no obligation, or any good reason, to remove it. Just leave it "obsolete", please. It's not hurting anyone. You're not really helping anyone by removing it. To repeat the (unanswered) question: > > > Is there some problem with keeping its simple > > > definition as (called-interactively 'interactive)? > > > > Is there some problem with you adding your own > > interactive-p if you want to use that name instead? > > Is there some problem with Emacs keeping the > existing simple definition of `interactive-p'? > > (defun interactive-p () (called-interactively-p 'interactive)) > > What's the problem with that? ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Delete variables obsolete since Emacs 23 2020-08-15 1:28 ` Drew Adams @ 2020-08-15 12:51 ` Stefan Monnier 2020-08-15 19:54 ` Drew Adams 2020-08-16 4:13 ` Richard Stallman 1 sibling, 1 reply; 838+ messages in thread From: Stefan Monnier @ 2020-08-15 12:51 UTC (permalink / raw) To: Drew Adams; +Cc: Stefan Kangas, emacs-devel > There's no obligation, or any good reason, to remove it. Actually, `interactive-p` is harmful, so you should remove as many uses of it as you can. `called-interactive-p` is not a good replacement for it. Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Delete variables obsolete since Emacs 23 2020-08-15 12:51 ` Stefan Monnier @ 2020-08-15 19:54 ` Drew Adams 0 siblings, 0 replies; 838+ messages in thread From: Drew Adams @ 2020-08-15 19:54 UTC (permalink / raw) To: Stefan Monnier; +Cc: Stefan Kangas, emacs-devel > > There's no obligation, or any good reason, to remove it. > > Actually, `interactive-p` is harmful, so you should remove as many uses > of it as you can. `called-interactive-p` is not a good replacement > for it. It's not harming me. Removing it will. Emacs allows (called-interactively-p 'interactive). It should also allow (interactive-p) which does the same thing. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Delete variables obsolete since Emacs 23 2020-08-15 1:28 ` Drew Adams 2020-08-15 12:51 ` Stefan Monnier @ 2020-08-16 4:13 ` Richard Stallman 2020-08-16 5:30 ` Drew Adams 1 sibling, 1 reply; 838+ messages in thread From: Richard Stallman @ 2020-08-16 4:13 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-devel, stefankangas, monnier [[[ 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. ]]] ISTR that we declared interactive-p obsolete because it is an not a correct solution to the problem it is meant to solve. The correct solution is to give the function an optional argument and an interactive spec which provides a non-nil value for that argument in interactive calls. There are cases where that gives the right answer, while interactive-p gives the wrong answer. The point is, you really should change each of those functions so that it will not misbehave in those special situations. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Delete variables obsolete since Emacs 23 2020-08-16 4:13 ` Richard Stallman @ 2020-08-16 5:30 ` Drew Adams 2020-08-16 13:46 ` Stefan Monnier 2020-08-17 3:23 ` Richard Stallman 0 siblings, 2 replies; 838+ messages in thread From: Drew Adams @ 2020-08-16 5:30 UTC (permalink / raw) To: rms; +Cc: emacs-devel, stefankangas, monnier > ISTR that we declared interactive-p obsolete because it is an not a > correct solution to the problem it is meant to solve. Then neither is (called-interactively-p 'interactive). Goose ... gander. > The correct solution is to give the function an optional argument > and an interactive spec which provides a non-nil value for that argument > in interactive calls. I already do that where it makes sense (e.g. to show a message). And that lesson is given in the doc string of `called-interactively-p' (which is _not_ obsolete, let alone being removed). > There are cases where that gives the right answer, > while interactive-p gives the wrong answer. `called-interactively-p' is just as brittle as `interactive-p' - see its doc string. The main difference is for keyboard-macro use - (called-interactively-p 'any) versus (called-interactively-p 'interactive). > The point is, you really should change each of those functions > so that it will not misbehave in those special situations. My code is backward-compatible, and there's too much of it to want to change to (if (fboundp 'called-interactively-p) (called-interactively-p 'interactive) (interactive-p)) I have no objection to Emacs having declared `interactive-p' obsolete (well, I kinda do, but not much, and it's not important at all). I object to Emacs _removing_ it. I see no reason for that. And no one has given a reason, so far. Everything said against `interactive-p' so far is true also of (called-interactively-p 'interactive). Emacs allows the latter - it's not obsolete. Emacs should continue to allow (interactive-p), which is _identical_. As far as I'm concerned, Emacs can feel free to continue to call `interactive-p' names. Shout from the rooftops that it's awful, evil, stupid, obsolete, whatever. Doesn't bother me. What bothers me is removing it. Sticks & stones... I didn't complain about the other removals being made, BTW. I didn't complain that `buffer-menu-mode-hook' was deprecated in favor of the same with capital `B', or that the former is now being removed. Likewise, for deprecating (and now removing) `print-help-return-message' in favor of `help-print-return-message'. Lots of obsolete things are being removed now, with no complaint from me, although I had to make code adjustments. `interactive-p' is used much more than the others. (Mea culpa: I said I had 2500 occurrences of `interactive-p'. I actually have 406 occurrences. A first grep included extraneous test files etc.) Nothing is gained by removing `interactive-p'. No one has been able to point out any gain. Only pain, no gain. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Delete variables obsolete since Emacs 23 2020-08-16 5:30 ` Drew Adams @ 2020-08-16 13:46 ` Stefan Monnier 2020-08-17 3:23 ` Richard Stallman 1 sibling, 0 replies; 838+ messages in thread From: Stefan Monnier @ 2020-08-16 13:46 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-devel, rms, stefankangas >> The correct solution is to give the function an optional argument >> and an interactive spec which provides a non-nil value for that argument >> in interactive calls. > I already do that where it makes sense (e.g. to show a message). I think you misunderstand: it makes sense everywhere where it technically *can* be used. There are still circumstances where `called-interactively-p` is necessary (typically in cases where the arglist cannot be extended with a new argument (mostly because it already uses `&rest`), or in advice), but it's rare. > I have no objection to Emacs having declared `interactive-p' obsolete > (well, I kinda do, but not much, and it's not important at all). > > I object to Emacs _removing_ it. I see no reason for that. And no > one has given a reason, so far. You know the reason: because it's obsolete and deprecated. Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Delete variables obsolete since Emacs 23 2020-08-16 5:30 ` Drew Adams 2020-08-16 13:46 ` Stefan Monnier @ 2020-08-17 3:23 ` Richard Stallman 2020-08-17 14:20 ` Drew Adams 1 sibling, 1 reply; 838+ messages in thread From: Richard Stallman @ 2020-08-17 3:23 UTC (permalink / raw) To: Drew Adams; +Cc: stefankangas, monnier, emacs-devel [[[ 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. ]]] I think we are miscommunicating. You seem to be talking about called-interactively-p. I am talking about making your function take an optional argument. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Delete variables obsolete since Emacs 23 2020-08-17 3:23 ` Richard Stallman @ 2020-08-17 14:20 ` Drew Adams 2020-08-17 14:45 ` Gregory Heytings via Emacs development discussions. ` (2 more replies) 0 siblings, 3 replies; 838+ messages in thread From: Drew Adams @ 2020-08-17 14:20 UTC (permalink / raw) To: rms; +Cc: stefankangas, monnier, emacs-devel > I think we are miscommunicating. You seem to be talking about > called-interactively-p. I am talking about making your function take > an optional argument. What "your function" are you talking about? This is about the standard Emacs function `interactive-p'. What optional argument would you have it take, and why? And how would that solve the problem of existing calls to `(interactive-p)'? But yes, it does sound like we've perhaps miscommunicated. `interactive-p' has existed since nearly Day One. `called-interactively-p' was introduced to replace/"fix" it - presumably instead of fixing it directly by adding an optional arg and leaving the default behavior (no arg) as is. And `interactive-p' was declared obsolete. I have no problem with that declaration, even if I'd have preferred to see `interactive-p' fixed directly (previous paragraph). My only request is to not remove `interactive-p'. My request is to please leave it "obsolete". ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Delete variables obsolete since Emacs 23 2020-08-17 14:20 ` Drew Adams @ 2020-08-17 14:45 ` Gregory Heytings via Emacs development discussions. 2020-08-18 1:55 ` Jeff Norden 2020-08-18 4:06 ` Richard Stallman 2 siblings, 0 replies; 838+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-08-17 14:45 UTC (permalink / raw) To: emacs-devel Drew Adams: > > My only request is to not remove `interactive-p'. > My request is to please leave it "obsolete". > Perhaps I'm misunderstanding something, but I don't even understand why it is marked "obsolete". If (called-interactively-p 'interactive) is a common idiom (and it seems to be, the docstring of called-interactively-p indicates that "the only known proper use of 'interactive' for KIND is in deciding whether to display a helpful message, or how to display it."), it would make perfect sense to have, in subr.el: (defun interactive-p () "Shorthand for (called-interactively-p 'interactive). See `called-interactively-p'." (called-interactively-p 'interactive)) Unless of course there is a long-term goal to replace "interactive-p" with some other definition. Gregory ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Delete variables obsolete since Emacs 23 2020-08-17 14:20 ` Drew Adams 2020-08-17 14:45 ` Gregory Heytings via Emacs development discussions. @ 2020-08-18 1:55 ` Jeff Norden 2020-08-18 4:53 ` Eli Zaretskii 2020-08-18 16:14 ` Drew Adams 2020-08-18 4:06 ` Richard Stallman 2 siblings, 2 replies; 838+ messages in thread From: Jeff Norden @ 2020-08-18 1:55 UTC (permalink / raw) To: Drew Adams; +Cc: ghe, stefankangas, rms, monnier, emacs-devel Drew Adams wrote: > My only request is to not remove `interactive-p'. > My request is to please leave it "obsolete". The elisp manual says: You can mark a named function as "obsolete", meaning that it may be removed at some point in the future. This causes Emacs to warn that the function is obsolete whenever it byte-compiles code containing that function, and whenever it displays the documentation for that function. In all other respects, an obsolete function behaves like any other function. The phrase "may be removed" seems a bit vague. Would "will be removed" or "will probably be removed" be more accurate? If so, perhaps it would help for obsolete functions and variables to also include something like a 'target-expiration-date', which could be a release number rather than an actual date. A target-expiration of "31.1" would mean that the current intent is that the function/variable will no longer exist when version 31.1 is released. The chromium project does something similar for its experimental "flags" that can be used to customize the user interface. From where I sit, it seems plausible that someone might view interactive-p as just an obsolete way of writing (called-interactively-p 'interactive), which exists for backward compatibility, and would be available long term. It seems that the last part is a mis-interpretation of the intent of marking it as obsolete. The fact that emacs maintains backward compatibility so well is one of the features that I appreciate the most. But, in this case, the fact that interactive-p has been obsolete for so long may give the impression that it would continue to be available. I can see arguments on both sides of the coin for why interactive-p should or should not continue to exist. If the underlying fact is that virtually all functions marked as obsolete will eventually be removed, then this should be made clear (or more clear than it currently seems to be). Then the issue of whether or not something should be marked as obsolete would have a better focus. Also, it might be worthwhile for the elisp manual to mention one other difference that obsolete functions have. When an interactive command is obsolete, it no longer appears as a possible completion when you press [tab] while entering a command-name after M-x. Regards, -Jeff ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Delete variables obsolete since Emacs 23 2020-08-18 1:55 ` Jeff Norden @ 2020-08-18 4:53 ` Eli Zaretskii 2020-08-19 8:31 ` Gregory Heytings via Emacs development discussions. 2020-08-18 16:14 ` Drew Adams 1 sibling, 1 reply; 838+ messages in thread From: Eli Zaretskii @ 2020-08-18 4:53 UTC (permalink / raw) To: Jeff Norden; +Cc: rms, emacs-devel, monnier, ghe, drew.adams, stefankangas > From: Jeff Norden <jnorden@tntech.edu> > Date: Mon, 17 Aug 2020 20:55:56 -0500 > Cc: ghe@sdf.org, stefankangas@gmail.com, rms@gnu.org, monnier@iro.umontreal.ca, > emacs-devel@gnu.org > > The elisp manual says: > > You can mark a named function as "obsolete", meaning that it may be > removed at some point in the future. This causes Emacs to warn that the > function is obsolete whenever it byte-compiles code containing that > function, and whenever it displays the documentation for that function. > In all other respects, an obsolete function behaves like any other > function. > > The phrase "may be removed" seems a bit vague. Would "will be removed" or > "will probably be removed" be more accurate? No, it won't. Primarily because we don't really know whether we will remove it, let alone when. It depends on too many factors that we cannot predict. > The fact that emacs maintains backward compatibility so well is one of the > features that I appreciate the most. But, in this case, the fact that > interactive-p has been obsolete for so long may give the impression that it > would continue to be available. I think the gentle annoyance we have now strikes the right balance between not letting people forget the fact of obsolescence and not annoying them too much. We are talking to adults, not to children, so we can rely on them doing TRT. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Delete variables obsolete since Emacs 23 2020-08-18 4:53 ` Eli Zaretskii @ 2020-08-19 8:31 ` Gregory Heytings via Emacs development discussions. 2020-08-19 13:26 ` Drew Adams ` (2 more replies) 0 siblings, 3 replies; 838+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-08-19 8:31 UTC (permalink / raw) To: emacs-devel >>> The elisp manual says: >>> >>> You can mark a named function as "obsolete", meaning that it may be >>> removed at some point in the future. This causes Emacs to warn that >>> the function is obsolete whenever it byte-compiles code containing >>> that function, and whenever it displays the documentation for that >>> function. In all other respects, an obsolete function behaves like any >>> other function. >> >> The phrase "may be removed" seems a bit vague. Would "will be removed" >> or "will probably be removed" be more accurate? > > No, it won't. Primarily because we don't really know whether we will > remove it, let alone when. It depends on too many factors that we > cannot predict. > In that case, would a two-step process not be better? First declaring the function "obsolete", and when it is known that it will be removed declare it "pending-removal" with a target major version. Gregory ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Delete variables obsolete since Emacs 23 2020-08-19 8:31 ` Gregory Heytings via Emacs development discussions. @ 2020-08-19 13:26 ` Drew Adams 2020-08-19 13:39 ` Stefan Monnier 2020-08-19 14:36 ` Eli Zaretskii 2 siblings, 0 replies; 838+ messages in thread From: Drew Adams @ 2020-08-19 13:26 UTC (permalink / raw) To: emacs-devel, Gregory Heytings > >> The phrase "may be removed" seems a bit vague. Would "will be removed" > >> or "will probably be removed" be more accurate? > > > > No, it won't. Primarily because we don't really know whether we will > > remove it, let alone when. It depends on too many factors that we > > cannot predict. > > > > In that case, would a two-step process not be better? First declaring the > function "obsolete", and when it is known that it will be removed declare > it "pending-removal" with a target major version. In my experience, organizations typically avoid a lot of commitments to future changes. Instead, it's about _no longer_ committing to something that's currently committed to. It's about removal of commitments, not imposition of new commitments. (Sometimes there's informal/unofficial mention to some users that it's likely XYZ will be removed at a specific point. But even that is generally avoided.) Typically there are two possible stages: 1. Deprecation (sometimes calling the thing "obsolete"). The thing _remains supported_. There's no longer a _commitment_ to active development - that's all. Users are told that the thing _might_ be desupported at some time in the future. Because of the removal of a _commitment_ to actively develop AND the removal of a _commitment_ that the thing will remain forever, users are advised to start moving away from using the thing. 2. Desupport. This is _optional_. A deprecated thing need never be desupported. And typically there is some (sometimes announced, sometimes not) minimal time period or number of intermediate releases, needed between deprecation and desupport. Something that's desupported gets no support. Trying to use it typically results in a no-op or raising an error. ___ That's my experience. YMMV. And of course nothing requires GNU Emacs to follow any particular outside convention or typical behavior. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Delete variables obsolete since Emacs 23 2020-08-19 8:31 ` Gregory Heytings via Emacs development discussions. 2020-08-19 13:26 ` Drew Adams @ 2020-08-19 13:39 ` Stefan Monnier 2020-08-19 13:54 ` Gregory Heytings via Emacs development discussions. 2020-08-19 14:36 ` Eli Zaretskii 2 siblings, 1 reply; 838+ messages in thread From: Stefan Monnier @ 2020-08-19 13:39 UTC (permalink / raw) To: Gregory Heytings via Emacs development discussions.; +Cc: Gregory Heytings > In that case, would a two-step process not be better? First declaring the > function "obsolete", and when it is known that it will be removed declare > it "pending-removal" with a target major version. I'm not sure it would make much difference to the speed at which people move away from using the obsolete feature (which is really all that matters, in the end). Another approach I toyed with is to change the `make-obsolete*` functions so that they actually *remove* the obsolete feature when used in development builds (i.e. builds with version XXX.0.50). Just like that it's a bit blunt, so it'd have to come with some knobs so the user can ask to disable this for some particular funs/vars, and also so it's only applied when the fun/var has been obsolete for at least 1 (or maybe 2) versions. Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Delete variables obsolete since Emacs 23 2020-08-19 13:39 ` Stefan Monnier @ 2020-08-19 13:54 ` Gregory Heytings via Emacs development discussions. 2020-08-19 15:15 ` Eli Zaretskii 0 siblings, 1 reply; 838+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-08-19 13:54 UTC (permalink / raw) To: emacs-devel > >> In that case, would a two-step process not be better? First declaring >> the function "obsolete", and when it is known that it will be removed >> declare it "pending-removal" with a target major version. > > I'm not sure it would make much difference to the speed at which people > move away from using the obsolete feature (which is really all that > matters, in the end). > FWIW, I think it would. With the current situation there is no concrete reason to move away from such a feature. As Eli wrote "we don't really know whether we will remove [an absolete feature], let alone when", so it could very wall stay there forever, and I can understand Drew's viewpoint who did not make the effort to update the 2500 lines of his codebase in which 'interactive-p' is used. If he had been warned, when Emacs 25 was released, with: (declare (pending-removal called-interactively-p "27")) he would have known that it would be removed in a medium term, and would have had a reason to update his codebase. That being said, about this particular feature, I still don't understand why it is obsolete. It is just a way to express a common pattern in a shorter way, like say (1+ x) and (+ x 1). Gregory ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Delete variables obsolete since Emacs 23 2020-08-19 13:54 ` Gregory Heytings via Emacs development discussions. @ 2020-08-19 15:15 ` Eli Zaretskii 2020-08-20 0:33 ` Jeff Norden 0 siblings, 1 reply; 838+ messages in thread From: Eli Zaretskii @ 2020-08-19 15:15 UTC (permalink / raw) To: Gregory Heytings; +Cc: emacs-devel > Date: Wed, 19 Aug 2020 13:54:50 +0000 > From: Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org> > > > I'm not sure it would make much difference to the speed at which people > > move away from using the obsolete feature (which is really all that > > matters, in the end). > > > > FWIW, I think it would. With the current situation there is no concrete > reason to move away from such a feature. As Eli wrote "we don't really > know whether we will remove [an absolete feature], let alone when", so it > could very wall stay there forever, and I can understand Drew's viewpoint > who did not make the effort to update the 2500 lines of his codebase in > which 'interactive-p' is used. If he had been warned, when Emacs 25 was > released, with: > > (declare (pending-removal called-interactively-p "27")) > > he would have known that it would be removed in a medium term, and would > have had a reason to update his codebase. You seem to be under the impression that we have difficulty removing obsolete features when we decide it's time for that. But the reality is we do remove such obsolete features. It's the decision to do so that's difficult, not the execution of the removal once we do decide. P.S. Could you please refrain from using Reply-To in your messages? It causes emacs-devel to appear twice in the addresses of the responses, so I have to manually delete one of them. TIA. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Delete variables obsolete since Emacs 23 2020-08-19 15:15 ` Eli Zaretskii @ 2020-08-20 0:33 ` Jeff Norden 0 siblings, 0 replies; 838+ messages in thread From: Jeff Norden @ 2020-08-20 0:33 UTC (permalink / raw) To: Eli Zaretskii Cc: rms, emacs-devel, monnier, ghe, larsi, drew.adams, stefankangas Stefan Monnier wrote: > IMNSHO it doesn't: if we don't intend to remove it ever, then we don't > declare it obsolete. > > Of course, declaring it obsolete doesn't guarantee that we will remove > it: it's just a declaration of intention. Eli Zaretskii wrote: > You seem to be under the impression that we have difficulty removing > obsolete features when we decide it's time for that. But the reality > is we do remove such obsolete features. It's the decision to do so > that's difficult, not the execution of the removal once we do decide. This makes it clear, I think. Perhaps the elisp manual could say something like: When the Emacs developers mark a function or variable as obsolete, this signals the intent to remove it at some point in the future. You should refrain from using it in new code, and should work towards removing it from existing code that you plan to maintain for the long term. But maybe that is not really necessary. --- Lars Ingebrigtsen wrote: > ...this is a pretty entertaining read: > https://medium.com/@steve.yegge/dear-google-cloud-your-deprecation-policy-is-killing-you-ee7525dc05dc Thanks for this link, which I really enjoyed. In addition to characterizing Emacs as "a sort of hybrid between Windows Notepad, a monolithic-kernel operating system, and the International Space Station," Yegge says: I’m still using software that I wrote for Emacs back in 1995. ... Every once in a while it might require a minor tweak, but it’s really quite rare. I’m not aware of anything I’ve ever written for Emacs (and I’ve written a lot) that was ever forced into re-architecture. ... when they make an API obsolete, they are basically saying: "You really shouldn't use this approach, because even though it works, it suffers from various deficiencies which we enumerate here. But in the end it’s your call." Whereas in the Google world, deprecation means: "We are breaking our commitments to you." It really does. --- As far as interactive-p is concerned, I grepped thru my personal stuff and found exactly one instance of interactive-p, which dates to April 1993. It is used to make a function behave differently on the rare times that I invoke it via M-x. I changed the interactive spec and introduced an optional arg. I agree this is a better solution - but I would also argue that this use of interactive-p was harmless, since I'm the only person who uses this snippet of code, and interactive-p did a perfectly good job for my use case. I can see an argument for removing interactive-p as a way to encourage people to carefully examine where it was used, and replace it with something better when possible. But the docstrings and elisp manual already do this, and it isn't clear to me that removing the function would accomplish much more. There is nothing gained by replacing (interactive-p) with (called-interactively 'interactive) where it is really necessary. And nothing can prevent someone from just blindly doing a search-and-replace if they choose to. On the other hand, if I hadn't been reading this list this summer, it would have been a "gentle annoyance" when my old snippet of code failed to run. Or, as Yegge put it, one of the rare times that it required a minor tweak. Maybe a stronger docstring could be used instead of deletion. Perhaps: (defun interactive-p () "Equivalent to (called-interactively-p 'interactive), for backward compatibility. See the Info node `(elisp)Distinguish Interactive' for the limited situations in which this is appropriate, and suggestions for more robust alternatives." (called-interactively-p 'interactive)) But, the design of Emacs makes this a very minor issue, especially compared to other software I use. (No matter how many times I set it, tex-live seems find a new way to change my default paper size back to A4.) --- Thinking more broadly, it seems to me that the issue is more than just backward compatibility. It's about having respect for the people who will be using your software. I think of Arethra Franklin singing R-E-S-P-E-C-T in her rendition of the classic Otis Redding song. More than any other software that I know of, Emacs embodies the concept of "user-respect." One thing that's clear to me from reading this list recently is that *every* decision involves a careful consideration of the effects it will have on the people who use Emacs. That a lack of user-respect is otherwise ubiquitous today is evidenced simply by the number of times each day that you mutter "WTF, why did that just happen?" as you browse the web, interact with software, etc, etc. https://commadot.com/wtf-per-minute/ In commercial settings, this is likely due to the (perhaps misguided) perception that decisions are in their financial interest, and the people who use their products are willing to just "live with it." In other circles, I think that the ego and hubris of developers is, in large part, to blame. If I had to guess, I'd say that the respect embodied by Emacs is due, in no small part, to Richard Stallman: his apparent humility and his absolutely unwavering commitment to principles rather than self promotion. Thanks, -Jeff ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Delete variables obsolete since Emacs 23 2020-08-19 8:31 ` Gregory Heytings via Emacs development discussions. 2020-08-19 13:26 ` Drew Adams 2020-08-19 13:39 ` Stefan Monnier @ 2020-08-19 14:36 ` Eli Zaretskii 2 siblings, 0 replies; 838+ messages in thread From: Eli Zaretskii @ 2020-08-19 14:36 UTC (permalink / raw) To: Gregory Heytings; +Cc: emacs-devel > Date: Wed, 19 Aug 2020 08:31:55 +0000 > From: Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org> > > >> The phrase "may be removed" seems a bit vague. Would "will be removed" > >> or "will probably be removed" be more accurate? > > > > No, it won't. Primarily because we don't really know whether we will > > remove it, let alone when. It depends on too many factors that we > > cannot predict. > > In that case, would a two-step process not be better? First declaring the > function "obsolete", and when it is known that it will be removed declare > it "pending-removal" with a target major version. How would it help? It will definitely complicate our procedures, but I see no gains. Do you? ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Delete variables obsolete since Emacs 23 2020-08-18 1:55 ` Jeff Norden 2020-08-18 4:53 ` Eli Zaretskii @ 2020-08-18 16:14 ` Drew Adams 1 sibling, 0 replies; 838+ messages in thread From: Drew Adams @ 2020-08-18 16:14 UTC (permalink / raw) To: Jeff Norden; +Cc: ghe, stefankangas, rms, monnier, emacs-devel > > My only request is to not remove `interactive-p'. > > My request is to please leave it "obsolete". > > The elisp manual says: > > You can mark a named function as "obsolete", meaning that it may be > removed at some point in the future. This causes Emacs to warn that the > function is obsolete whenever it byte-compiles code containing that > function, and whenever it displays the documentation for that function. > In all other respects, an obsolete function behaves like any other > function. > > The phrase "may be removed" seems a bit vague. Would "will be removed" or > "will probably be removed" be more accurate? Not in my opinion. I mean that shouldn't be what we mean by "obsolete" or "deprecated". Normally it means just what the text says: there's no guarantee that it won't be removed. In general (e.g. outside Emacs), there's no obligation to ever remove something that's been deprecated (is obsolete). In general, something that's deprecated is still supported. But it is not under active development, and there may not be a lot of energy spent on fixing its bugs. > From where I sit, it seems plausible that someone might view interactive-p > as just an obsolete way of writing (called-interactively-p 'interactive), > which exists for backward compatibility, and would be available long term. > It seems that the last part is a mis-interpretation of the intent of marking > it as obsolete. That's exactly the interpretation I'm looking for. I don't care that it's deprecated, as long as it's still there. > The fact that emacs maintains backward compatibility so well is one of the > features that I appreciate the most. Indeed. https://medium.com/@steve.yegge/dear-google-cloud-your-deprecation-policy-is-killing-you-ee7525dc05dc > But, in this case, the fact that interactive-p > has been obsolete for so long may give the > impression that it would continue to be available. I don't care about either possible impression. I'm saying it makes sense to leave it alone. There's no reason to remove it. (And no reason has yet been given.) "It's obsolete" is not a reason to remove it. We're not removing (called-interactively-p 'interactive). Why not? > If the underlying fact is that virtually > all functions marked as obsolete will > eventually be removed Not a fact. Not in my book, anyway. And certainly not in the world outside Emacs. (Unless by "eventually" you include the disappearance of the planet or sun. ;-)) > Also, it might be worthwhile for the elisp manual to mention one other > difference that obsolete functions have. When an interactive command is > obsolete, it no longer appears as a possible completion when you press > [tab] while entering a command-name after M-x. That's not true either. Perhaps you're suggesting that such behavior should be implemented? (FWIW, my opinion is no.) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Delete variables obsolete since Emacs 23 2020-08-17 14:20 ` Drew Adams 2020-08-17 14:45 ` Gregory Heytings via Emacs development discussions. 2020-08-18 1:55 ` Jeff Norden @ 2020-08-18 4:06 ` Richard Stallman 2020-08-18 16:13 ` Drew Adams 2 siblings, 1 reply; 838+ messages in thread From: Richard Stallman @ 2020-08-18 4:06 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-devel, stefankangas, monnier [[[ 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. ]]] > > I think we are miscommunicating. You seem to be talking about > > called-interactively-p. I am talking about making your function take > > an optional argument. > What "your function" are you talking about? The function which calls `interactive-p'. It's in your code, right? So I refer to it as yours. You should change that function to have an additional optional argument and use `interactive' to silently supply a non-nil value for it when it gets called interactively. Then use that argument instead of calling `interactive-p'. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Delete variables obsolete since Emacs 23 2020-08-18 4:06 ` Richard Stallman @ 2020-08-18 16:13 ` Drew Adams 0 siblings, 0 replies; 838+ messages in thread From: Drew Adams @ 2020-08-18 16:13 UTC (permalink / raw) To: rms; +Cc: emacs-devel, stefankangas, monnier > You should change that function to have an additional optional > argument and use `interactive' to silently supply a non-nil value for > it when it gets called interactively. Then use that argument > instead of calling `interactive-p'. I already addressed that "should". Emacs "should" just leave `interactive-p' alone. It's not hurting anyone. It can't hurt any more than (called-interactively 'interactive) hurts, which is the exact same thing. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Delete variables obsolete since Emacs 23 2020-08-14 18:56 ` Drew Adams ` (2 preceding siblings ...) 2020-08-14 23:37 ` Stefan Kangas @ 2020-08-18 11:17 ` Lars Ingebrigtsen 2020-08-24 2:28 ` Stefan Kangas 3 siblings, 1 reply; 838+ messages in thread From: Lars Ingebrigtsen @ 2020-08-18 11:17 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-devel, Stefan Kangas, Stefan Monnier Drew Adams <drew.adams@oracle.com> writes: >> I'm attaching a patch to remove most things declared obsolete in 23.2 >> and 23.3. (Nothing was declared obsolete in 23.4 AFAICT.) >> >> There are still some items obsoleted in 23.x left to delete in Semantic. >> I intend to do that in a separate patch. >> >> Comments welcome. > > PLEASE do not remove `interactive-p'. Emacs does have to move on and eventually remove stuff that we've deprecated, and that's fine for most things. But thinking about this a bit more, I agree with Drew here -- interactive-p is used too much in the wild for us to ever delete it. It should stay marked as obsolete, but with a comment saying "never delete" or something, because removing it will break too much code out there. For a perspective on deprecation (which mentions Emacs :-)), this is a pretty entertaining read: https://medium.com/@steve.yegge/dear-google-cloud-your-deprecation-policy-is-killing-you-ee7525dc05dc -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Delete variables obsolete since Emacs 23 2020-08-18 11:17 ` Lars Ingebrigtsen @ 2020-08-24 2:28 ` Stefan Kangas 2020-08-25 3:46 ` Richard Stallman 2020-09-04 17:04 ` Stefan Kangas 0 siblings, 2 replies; 838+ messages in thread From: Stefan Kangas @ 2020-08-24 2:28 UTC (permalink / raw) To: Lars Ingebrigtsen, Drew Adams; +Cc: Stefan Monnier, emacs-devel Lars Ingebrigtsen <larsi@gnus.org> writes: > But thinking about this a bit more, I agree with Drew here -- Given the controversy here, I don't feel comfortable deleting interactive-p. So I left that part of my patch out and pushed the rest as commit 326fdb9ec0. The next step here is the obsoletions in semantic. > interactive-p is used too much in the wild for us to ever delete it. It > should stay marked as obsolete, but with a comment saying "never delete" > or something, because removing it will break too much code out there. FWIW, I also think there's merit to the argument advanced by Drew and Lars in the case of interactive-p. (But my preference would be to say: "Delete after year or version N".) Best regards, Stefan Kangas ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Delete variables obsolete since Emacs 23 2020-08-24 2:28 ` Stefan Kangas @ 2020-08-25 3:46 ` Richard Stallman 2020-08-25 4:06 ` Drew Adams 2020-09-04 17:04 ` Stefan Kangas 1 sibling, 1 reply; 838+ messages in thread From: Richard Stallman @ 2020-08-25 3:46 UTC (permalink / raw) To: Stefan Kangas; +Cc: larsi, monnier, drew.adams, emacs-devel [[[ 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. ]]] > > interactive-p is used too much in the wild for us to ever delete it. It > > should stay marked as obsolete, but with a comment saying "never delete" > > or something, because removing it will break too much code out there. I agree we should never delete it, for that good reason. But we made it obsolete for a good reason, too: any program which uses will misbehave in some unusual cases. The only way to get fully correct behavior is to eliminate the calls to interactive-p, and instead use an optional argument which gets a non-nil value in an interactive call. All the calls in the Emacs code have been replaced. Do any remain in ELPA? -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Delete variables obsolete since Emacs 23 2020-08-25 3:46 ` Richard Stallman @ 2020-08-25 4:06 ` Drew Adams 2020-08-26 1:57 ` Richard Stallman 0 siblings, 1 reply; 838+ messages in thread From: Drew Adams @ 2020-08-25 4:06 UTC (permalink / raw) To: rms, Stefan Kangas; +Cc: larsi, monnier, emacs-devel > > > interactive-p is used too much in the wild for us to ever delete it. > > > It should stay marked as obsolete, but with a comment saying "never > > > delete" or something, because removing it will break too much code > > > out there. > > I agree we should never delete it, for that good reason. Good. That was the (only) point in question. > But we made it obsolete for a good reason, too: any program which > uses will misbehave in some unusual cases. The only way to get > fully correct behavior is to eliminate the calls to interactive-p, > and instead use an optional argument which gets a non-nil value > in an interactive call. > > All the calls in the Emacs code have been replaced. Uh, no, I don't think so. (interactive-p) == (called-interactively-p 'interactive) Grepping tells me there are 258 occurrences of the latter in the Lisp code distributed with Emacs. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Delete variables obsolete since Emacs 23 2020-08-25 4:06 ` Drew Adams @ 2020-08-26 1:57 ` Richard Stallman 2020-08-26 8:59 ` Gregory Heytings via Emacs development discussions. 2020-08-26 17:39 ` Drew Adams 0 siblings, 2 replies; 838+ messages in thread From: Richard Stallman @ 2020-08-26 1:57 UTC (permalink / raw) To: Drew Adams; +Cc: larsi, emacs-devel, stefankangas, monnier [[[ 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. ]]] > Uh, no, I don't think so. > (interactive-p) == (called-interactively-p 'interactive) I do not follow you -- your words are very terse. Are you saying that people replaced calls to interactive-p with calls to called-interactively-p, rather than converting to use an optional argument? -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Delete variables obsolete since Emacs 23 2020-08-26 1:57 ` Richard Stallman @ 2020-08-26 8:59 ` Gregory Heytings via Emacs development discussions. 2020-08-26 13:22 ` Stefan Kangas 2020-08-26 17:39 ` Drew Adams 1 sibling, 1 reply; 838+ messages in thread From: Gregory Heytings via Emacs development discussions. @ 2020-08-26 8:59 UTC (permalink / raw) To: Richard Stallman; +Cc: emacs-devel, Drew Adams, larsi, stefankangas, monnier > >> Uh, no, I don't think so. >> >> (interactive-p) == (called-interactively-p 'interactive) > > I do not follow you -- your words are very terse. > > Are you saying that people replaced calls to interactive-p with calls to > called-interactively-p, rather than converting to use an optional > argument? > Yes. And that's also what Stefan Kangas did in his patch for Emacs named 0001-Remove-many-items-obsolete-since-Emacs-23.2-and-23.3.patch and sent on this list two weeks ago (on Fri, 14 Aug 2020 08:42:38 -0700). Gregory ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Delete variables obsolete since Emacs 23 2020-08-26 8:59 ` Gregory Heytings via Emacs development discussions. @ 2020-08-26 13:22 ` Stefan Kangas 2020-08-27 2:51 ` Richard Stallman 0 siblings, 1 reply; 838+ messages in thread From: Stefan Kangas @ 2020-08-26 13:22 UTC (permalink / raw) To: Gregory Heytings, Richard Stallman Cc: larsi, monnier, Drew Adams, emacs-devel Gregory Heytings <ghe@sdf.org> writes: >> Are you saying that people replaced calls to interactive-p with calls to >> called-interactively-p, rather than converting to use an optional >> argument? > > Yes. > > And that's also what Stefan Kangas did in his patch for Emacs named > 0001-Remove-many-items-obsolete-since-Emacs-23.2-and-23.3.patch and sent > on this list two weeks ago (on Fri, 14 Aug 2020 08:42:38 -0700). My commit bc5da2c3fb does basically the following: - (help-setup-xref (list 'describe-symbols pattern) (interactive-p)) + (help-setup-xref (list 'describe-symbols pattern) + (called-interactively-p 'interactive)) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Delete variables obsolete since Emacs 23 2020-08-26 13:22 ` Stefan Kangas @ 2020-08-27 2:51 ` Richard Stallman 2020-08-27 3:51 ` Stefan Kangas 0 siblings, 1 reply; 838+ messages in thread From: Richard Stallman @ 2020-08-27 2:51 UTC (permalink / raw) To: Stefan Kangas; +Cc: ghe, larsi, monnier, drew.adams, emacs-devel [[[ 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. ]]] > My commit bc5da2c3fb does basically the following: > - (help-setup-xref (list 'describe-symbols pattern) (interactive-p)) > + (help-setup-xref (list 'describe-symbols pattern) > + (called-interactively-p 'interactive)) That is not the recommend way to fix these calls. called-interactively-p does not give the correct results in all situations. The right way is to make the optional argument. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Delete variables obsolete since Emacs 23 2020-08-27 2:51 ` Richard Stallman @ 2020-08-27 3:51 ` Stefan Kangas 0 siblings, 0 replies; 838+ messages in thread From: Stefan Kangas @ 2020-08-27 3:51 UTC (permalink / raw) To: rms; +Cc: ghe, larsi, monnier, drew.adams, emacs-devel Richard Stallman <rms@gnu.org> writes: > > My commit bc5da2c3fb does basically the following: > > > - (help-setup-xref (list 'describe-symbols pattern) (interactive-p)) > > + (help-setup-xref (list 'describe-symbols pattern) > > + (called-interactively-p 'interactive)) > > That is not the recommend way to fix these calls. > called-interactively-p does not give the correct results in all > situations. The right way is to make the optional argument. This was simply to not use the old deprecated name, which AFAIU is being considered for removal. Perhaps we could also expand the section in the Manual that explains why using an optional argument is better, and make the wording stronger. Here's what I read in `(info "(elisp) Distinguish Interactive")': The above method with the additional argument is usually best, because it allows callers to say “treat this call as interactive”. But you can also do the job by testing ‘called-interactively-p’. ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Delete variables obsolete since Emacs 23 2020-08-26 1:57 ` Richard Stallman 2020-08-26 8:59 ` Gregory Heytings via Emacs development discussions. @ 2020-08-26 17:39 ` Drew Adams 2020-08-26 18:16 ` Stefan Monnier 1 sibling, 1 reply; 838+ messages in thread From: Drew Adams @ 2020-08-26 17:39 UTC (permalink / raw) To: rms; +Cc: larsi, emacs-devel, stefankangas, monnier > > Uh, no, I don't think so. > > (interactive-p) == (called-interactively-p 'interactive) > > I do not follow you -- your words are very terse. > > Are you saying that people replaced calls to interactive-p with calls > to called-interactively-p, rather than converting to use an optional > argument? Yes, apparently so. You're correct that there are now no occurrences of `interactive-p' in the source code. But there are hundreds of occurrences of what amounts to the same thing. I've said it several times in this thread already, which is why I didn't belabor it in my too-terse reply: this is the _definition_ of `interactive-p' (in `subr.el'): (defun interactive-p () "..." (declare (obsolete called-interactively-p "23.2")) (called-interactively-p 'interactive)) And the Emacs Lisp source code contains lots of occurrences of `(called-interactively-p 'interactive)'. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Delete variables obsolete since Emacs 23 2020-08-26 17:39 ` Drew Adams @ 2020-08-26 18:16 ` Stefan Monnier 0 siblings, 0 replies; 838+ messages in thread From: Stefan Monnier @ 2020-08-26 18:16 UTC (permalink / raw) To: Drew Adams; +Cc: larsi, emacs-devel, rms, stefankangas > I've said it several times in this thread already, > which is why I didn't belabor it in my too-terse > reply: this is the _definition_ of `interactive-p' > (in `subr.el'): > > (defun interactive-p () > "..." > (declare (obsolete called-interactively-p "23.2")) > (called-interactively-p 'interactive)) For completeness, I have to warn that there is a bit more than meets the eye, here: `called-interactively-p` is a big-ugly-hack and in order for the above `interactive-p` to work, it has to know that `interactive-p` is also one of those special not-really-functions. More specifically, this manifests itself in the presence of the symbol `interactive-p` inside `called-interactively-p`. After all, if taken literally, the above code would always return nil since `interactive-p` can't be called interactively. > And the Emacs Lisp source code contains lots of > occurrences of `(called-interactively-p 'interactive)'. Yes, and that still sucks, indeed. Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Delete variables obsolete since Emacs 23 2020-08-24 2:28 ` Stefan Kangas 2020-08-25 3:46 ` Richard Stallman @ 2020-09-04 17:04 ` Stefan Kangas 2020-09-05 12:39 ` Lars Ingebrigtsen 1 sibling, 1 reply; 838+ messages in thread From: Stefan Kangas @ 2020-09-04 17:04 UTC (permalink / raw) To: Lars Ingebrigtsen, Drew Adams; +Cc: Stefan Monnier, emacs-devel [-- Attachment #1: Type: text/plain, Size: 217 bytes --] Stefan Kangas <stefankangas@gmail.com> writes: > The next step here is the obsoletions in semantic. Please find attached a patch to remove obsolete items also from cedet. Any comments? Best regards, Stefan Kangas [-- Attachment #2: 0001-Remove-cedet-items-obsolete-since-23.2.patch --] [-- Type: text/x-diff, Size: 45771 bytes --] From a89738531bf9c37293d4d2fdfcf52fa660abd19c Mon Sep 17 00:00:00 2001 From: Stefan Kangas <stefankangas@gmail.com> Date: Fri, 14 Aug 2020 13:40:29 +0200 Subject: [PATCH] Remove cedet items obsolete since 23.2 * lisp/cedet/semantic.el (semantic-toplevel-bovine-table) (semantic-toplevel-bovine-cache) (semantic-before-toplevel-bovination-hook) (semantic-after-toplevel-bovinate-hook, semantic-init-hooks) (semantic-init-mode-hooks, semantic-init-db-hooks) (semantic-bovination-working-type, semantic-bovinate-toplevel) (semantic-bovinate-region-until-error) (semantic-bovinate-from-nonterminal-full): * lisp/cedet/semantic/db-mode.el (semanticdb-mode-hooks): * lisp/cedet/semantic/decorate/mode.el (semantic-decorate-pending-decoration-hooks): * lisp/cedet/semantic/edit.el (semantic-edits-incremental-reparse-failed-hooks): * lisp/cedet/semantic/fw.el (define-mode-overload-implementation): * lisp/cedet/semantic/idle.el (semantic-before-idle-scheduler-reparse-hooks) (semantic-after-idle-scheduler-reparse-hooks): (semantic-eldoc-current-symbol-info) * lisp/cedet/semantic/imenu.el (semantic-imenu-expand-type-parts) (semantic-imenu-bucketize-type-parts) (semantic-imenu-expandable-token): * lisp/cedet/semantic/java.el (semantic-java-prototype-nonterminal): * lisp/cedet/semantic/lex.el (semantic-flex-token-start) (semantic-flex-token-end, semantic-flex-token-text) (semantic-flex-make-keyword-table, semantic-flex-keyword-p) (semantic-flex-keyword-put, semantic-flex-keyword-get) (semantic-flex-map-keywords, semantic-flex-keywords) (semantic-flex-buffer, semantic-flex-list, semantic-flex): * lisp/cedet/semantic/tag-file.el (semantic-find-nonterminal) (semantic-find-dependency): * lisp/cedet/semantic/tag-ls.el (semantic-nonterminal-full-name) (semantic-nonterminal-protection, semantic-nonterminal-abstract) (semantic-nonterminal-leaf): * lisp/cedet/semantic/tag.el (semantic-token-type-parent) (semantic-tag-make-assoc-list, semantic-expand-nonterminal): * lisp/cedet/semantic/util.el (semantic-file-token-stream) (semantic-something-to-stream): * lisp/cedet/semantic/wisent.el (wisent-lex-make-token-table): Delete many items obsolete since Emacs 23.2. * lisp/cedet/semantic.el (semantic--set-buffer-cache) (semantic-fetch-tags): Don't run removed hooks 'semantic-after-toplevel-bovinate-hook' and 'semantic-before-toplevel-bovination-hook'. * lisp/cedet/semantic/bovine/el.el: Remove reference to obsolete variable 'define-mode-overload-implementation'. * lisp/cedet/semantic/doc.el (semantic-doc-snarf-comment-for-tag): Don't bind removed variable 'semantic-ignore-comments'. * lisp/cedet/semantic/fw.el (semantic-overload-symbol-from-function) (semantic-alias-obsolete, semantic-varalias-obsolete): Declare obsolete in favor of standard Emacs 'define-obsolete-*-alias'. * lisp/cedet/semantic/grammar.el (semantic-grammar-ASSOC): Don't use obsolete names. * lisp/cedet/semantic/tag-ls.el (semantic-tag-full-package) (semantic-tag-full-name): Doc fixes. * lisp/cedet/semantic/util.el (semantic-describe-buffer): Don't bind removed variable 'semantic-after-toplevel-bovinate-hook'. * lisp/cedet/semantic/lex.el (semantic-flex-tokens) (semantic-flex-unterminated-syntax-end-function) (semantic-flex-extensions, semantic-flex-syntax-modifications) (semantic-ignore-comments, semantic-flex-enable-newlines) (semantic-flex-enable-whitespace, semantic-flex-enable-bol) (semantic-number-expression, semantic-flex-depth): Make unused variables obsolete. ; * etc/NEWS: List removed items. --- etc/NEWS | 33 +++- lisp/cedet/semantic.el | 79 +-------- lisp/cedet/semantic/bovine/el.el | 1 - lisp/cedet/semantic/db-mode.el | 4 - lisp/cedet/semantic/decorate/mode.el | 3 - lisp/cedet/semantic/doc.el | 3 +- lisp/cedet/semantic/edit.el | 3 - lisp/cedet/semantic/fw.el | 13 +- lisp/cedet/semantic/grammar.el | 2 +- lisp/cedet/semantic/idle.el | 9 -- lisp/cedet/semantic/imenu.el | 6 - lisp/cedet/semantic/java.el | 3 - lisp/cedet/semantic/lex.el | 231 ++------------------------- lisp/cedet/semantic/tag-file.el | 13 -- lisp/cedet/semantic/tag-ls.el | 16 +- lisp/cedet/semantic/tag.el | 20 --- lisp/cedet/semantic/util.el | 7 - lisp/cedet/semantic/wisent.el | 5 - 18 files changed, 53 insertions(+), 398 deletions(-) diff --git a/etc/NEWS b/etc/NEWS index e0ea8f53cc..13e145cec1 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -1146,8 +1146,8 @@ ledit.el, lmenu.el, lucid.el and old-whitespace.el. 'completion-base-size', 'completion-common-substring', 'crm-minibuffer-complete', 'crm-minibuffer-complete-and-exit', 'crm-minibuffer-completion-help', 'custom-mode', 'custom-mode-hook', -'detect-coding-with-priority', 'dirtrack-debug', -'dirtrack-debug-toggle', 'dynamic-completion-table', +'define-mode-overload-implementation', 'detect-coding-with-priority', +'dirtrack-debug', 'dirtrack-debug-toggle', 'dynamic-completion-table', 'easy-menu-precalculate-equivalent-keybindings', 'epa-display-verify-result', 'epg-passphrase-callback-function', 'eshell-report-bug', 'eval-next-after-load', 'exchange-dot-and-mark', @@ -1167,13 +1167,40 @@ ledit.el, lmenu.el, lucid.el and old-whitespace.el. 'pre-abbrev-expand-hook', 'princ-list', 'print-help-return-message', 'process-filter-multibyte-p', 'read-file-name-predicate', 'remember-buffer', 'rmail-highlight-face', 'rmail-message-filter', +'semantic-after-idle-scheduler-reparse-hooks', +'semantic-after-toplevel-bovinate-hook', +'semantic-before-idle-scheduler-reparse-hooks', +'semantic-before-toplevel-bovination-hook', +'semantic-bovinate-from-nonterminal-full', +'semantic-bovinate-region-until-error', 'semantic-bovinate-toplevel', +'semantic-bovination-working-type', +'semantic-decorate-pending-decoration-hooks', +'semantic-edits-incremental-reparse-failed-hooks', +'semantic-eldoc-current-symbol-info', 'semantic-expand-nonterminal', +'semantic-file-token-stream', 'semantic-find-dependency', +'semantic-find-nonterminal', 'semantic-flex', 'semantic-flex-buffer', +'semantic-flex-keyword-get', 'semantic-flex-keyword-p', +'semantic-flex-keyword-put', 'semantic-flex-keywords', +'semantic-flex-list', 'semantic-flex-make-keyword-table', +'semantic-flex-map-keywords', 'semantic-flex-token-end', +'semantic-flex-token-start', 'semantic-flex-token-text', +'semantic-imenu-bucketize-type-parts', +'semantic-imenu-expand-type-parts', 'semantic-imenu-expandable-token', +'semantic-init-db-hooks)', 'semantic-init-hooks', +'semantic-init-mode-hooks', 'semantic-java-prototype-nonterminal', +'semantic-nonterminal-abstract', 'semantic-nonterminal-full-name', +'semantic-nonterminal-leaf', 'semantic-nonterminal-protection', +'semantic-something-to-stream', 'semantic-tag-make-assoc-list', +'semantic-token-type-parent', 'semantic-toplevel-bovine-cache', +'semantic-toplevel-bovine-table', 'semanticdb-mode-hooks', 'set-coding-priority', 'set-process-filter-multibyte', 'shadows-compare-text-p', 'shell-dirtrack-toggle', 't-mouse-mode', 'term-dynamic-simple-complete', 'tooltip-hook', 'tpu-have-ispell', 'url-generate-unique-filename', 'url-temporary-directory', 'vc-arch-command', 'vc-default-working-revision' (variable), 'vc-mtn-command', 'vc-revert-buffer', 'vc-workfile-version', -'vcursor-toggle-vcursor-map', 'w32-focus-frame', 'w32-select-font'. +'vcursor-toggle-vcursor-map', 'w32-focus-frame', 'w32-select-font', +'wisent-lex-make-token-table'. \f * Lisp Changes in Emacs 28.1 diff --git a/lisp/cedet/semantic.el b/lisp/cedet/semantic.el index 58a35d7d8a..71321e12da 100644 --- a/lisp/cedet/semantic.el +++ b/lisp/cedet/semantic.el @@ -82,8 +82,6 @@ semantic--parse-table This variable is for internal use only, and its content depends on the external parser used.") (make-variable-buffer-local 'semantic--parse-table) -(semantic-varalias-obsolete 'semantic-toplevel-bovine-table - 'semantic--parse-table "23.2") (defvar semantic-symbol->name-assoc-list '((type . "Types") @@ -112,17 +110,6 @@ semantic-case-fold "Value for `case-fold-search' when parsing.") (make-variable-buffer-local 'semantic-case-fold) -(defvar semantic-expand-nonterminal nil - "Function to call for each nonterminal production. -Return a list of non-terminals derived from the first argument, or nil -if it does not need to be expanded. -Languages with compound definitions should use this function to expand -from one compound symbol into several. For example, in C the definition - int a, b; -is easily parsed into one tag. This function should take this -compound tag and turn it into two tags, one for A, and the other for B.") -(make-variable-buffer-local 'semantic-expand-nonterminal) - (defvar semantic--buffer-cache nil "A cache of the fully parsed buffer. If no significant changes have been made (based on the state) then @@ -134,8 +121,6 @@ semantic--buffer-cache cached values for some reason, chances are you can add a hook to `semantic-after-toplevel-cache-change-hook'.") (make-variable-buffer-local 'semantic--buffer-cache) -(semantic-varalias-obsolete 'semantic-toplevel-bovine-cache - 'semantic--buffer-cache "23.2") (defvar semantic-unmatched-syntax-cache nil "A cached copy of unmatched syntax tokens.") @@ -171,18 +156,6 @@ semantic--before-fetch-tags-hook `semantic-fetch-tags' by an application. If any hook returns a nil value, the cached value is returned immediately, even if it is empty.") -(semantic-varalias-obsolete 'semantic-before-toplevel-bovination-hook - 'semantic--before-fetch-tags-hook "23.2") - -(defvar semantic-after-toplevel-bovinate-hook nil - "Hooks run after a toplevel parse. -It is not run if the toplevel parse command is called, and buffer does -not need to be fully reparsed. -For language specific hooks, make sure you define this as a local hook. - -This hook should not be used any more. -Use `semantic-after-toplevel-cache-change-hook' instead.") -(make-obsolete-variable 'semantic-after-toplevel-bovinate-hook nil "23.2") (defvar semantic-after-toplevel-cache-change-hook nil "Hooks run after the buffer tag list has changed. @@ -305,13 +278,6 @@ semantic-init-db-hook This guarantees that the DB will go before other modes that require a parse of the buffer.") -(semantic-varalias-obsolete 'semantic-init-hooks - 'semantic-init-hook "23.2") -(semantic-varalias-obsolete 'semantic-init-mode-hooks - 'semantic-init-mode-hook "23.2") -(semantic-varalias-obsolete 'semantic-init-db-hooks - 'semantic-init-db-hook "23.2") - (defsubst semantic-error-if-unparsed () "Raise an error if current buffer was not parsed by Semantic." (unless semantic-new-buffer-fcn-was-run @@ -516,8 +482,6 @@ semantic-clear-toplevel-cache (semantic-parse-tree-set-needs-rebuild) ;; Remove this hook which tracks if a buffer is up to date or not. (remove-hook 'after-change-functions 'semantic-change-function t) - ;; Old model. Delete someday. - ;;(run-hooks 'semantic-after-toplevel-bovinate-hook) (run-hook-with-args 'semantic-after-toplevel-cache-change-hook semantic--buffer-cache) @@ -540,17 +504,12 @@ semantic--set-buffer-cache (setq semantic--completion-cache nil) ;; Refresh the display of unmatched syntax tokens if enabled (run-hook-with-args 'semantic-unmatched-syntax-hook - semantic-unmatched-syntax-cache) - ;; Old Semantic 1.3 hook API. Maybe useful forever? - (run-hooks 'semantic-after-toplevel-bovinate-hook) - ) + semantic-unmatched-syntax-cache)) (defvar semantic-working-type 'percent "The type of working message to use when parsing. 'percent means we are doing a linear parse through the buffer. 'dynamic means we are reparsing specific tags.") -(semantic-varalias-obsolete 'semantic-bovination-working-type - 'semantic-working-type "23.2") (defvar semantic-minimum-working-buffer-size (* 1024 5) "The minimum size of a buffer before working messages are displayed. @@ -585,8 +544,6 @@ semantic-fetch-tags ;; Is this a semantic enabled buffer? (semantic-active-p) ;; Application hooks say the buffer is safe for parsing - (run-hook-with-args-until-failure - 'semantic-before-toplevel-bovination-hook) (run-hook-with-args-until-failure 'semantic--before-fetch-tags-hook) ;; If the buffer was previously marked unparseable, @@ -690,11 +647,6 @@ semantic-refresh-tags-safe ;; Return if we are lexically safe lexically-safe)))) -(defun semantic-bovinate-toplevel (&optional ignored) - "Backward compatibility function." - (semantic-fetch-tags)) -(make-obsolete 'semantic-bovinate-toplevel 'semantic-fetch-tags "23.2") - ;; Another approach is to let Emacs call the parser on idle time, when ;; needed, use `semantic-fetch-available-tags' to only retrieve ;; available tags, and setup the `semantic-after-*-hook' hooks to @@ -812,20 +764,6 @@ semantic-dump-parser-warnings ;; Please move away from these functions, and try using semantic 2.x ;; interfaces instead. ;; -(defsubst semantic-bovinate-region-until-error - (start end nonterm &optional depth) - "NOTE: Use `semantic-parse-region' instead. - -Bovinate between START and END starting with NONTERM. -Optional DEPTH specifies how many levels of parenthesis to enter. -This command will parse until an error is encountered, and return -the list of everything found until that moment. -This is meant for finding variable definitions at the beginning of -code blocks in methods. If `bovine-inner-scope' can also support -commands, use `semantic-bovinate-from-nonterminal-full'." - (semantic-parse-region start end nonterm depth t)) -(make-obsolete 'semantic-bovinate-region-until-error - 'semantic-parse-region "23.2") (defsubst semantic-bovinate-from-nonterminal (start end nonterm &optional depth length) @@ -840,21 +778,6 @@ semantic-bovinate-from-nonterminal (semantic-lex start end (or depth 1) length) nonterm)))) -(defsubst semantic-bovinate-from-nonterminal-full - (start end nonterm &optional depth) - "NOTE: Use `semantic-parse-region' instead. - -Bovinate from within a nonterminal lambda from START to END. -Iterates until all the space between START and END is exhausted. -Argument NONTERM is the nonterminal symbol to start with. -If NONTERM is nil, use `bovine-block-toplevel'. -Optional argument DEPTH is the depth of lists to dive into. -When used in a `lambda' of a MATCH-LIST, there is no need to include -a START and END part." - (semantic-parse-region start end nonterm (or depth 1))) -(make-obsolete 'semantic-bovinate-from-nonterminal-full - 'semantic-parse-region "23.2") - ;;; User interface (defun semantic-force-refresh () diff --git a/lisp/cedet/semantic/bovine/el.el b/lisp/cedet/semantic/bovine/el.el index 656c63b7ee..822ec176a3 100644 --- a/lisp/cedet/semantic/bovine/el.el +++ b/lisp/cedet/semantic/bovine/el.el @@ -420,7 +420,6 @@ semantic-elisp-use-read :parent (symbol-name (nth 2 form)) :documentation (semantic-elisp-do-doc (nth 4 form)) ))) - define-mode-overload-implementation ;; obsoleted define-mode-local-override ) diff --git a/lisp/cedet/semantic/db-mode.el b/lisp/cedet/semantic/db-mode.el index 0ab03ef49e..16a30b6cfb 100644 --- a/lisp/cedet/semantic/db-mode.el +++ b/lisp/cedet/semantic/db-mode.el @@ -69,10 +69,6 @@ global-semanticdb-minor-mode (dolist (elt semanticdb-hooks) (remove-hook (cadr elt) (car elt))))) -(semantic-varalias-obsolete 'semanticdb-mode-hooks - 'global-semanticdb-minor-mode-hook "23.2") - - (defun semanticdb-toggle-global-mode () "Toggle use of the Semantic Database feature. Update the environment of Semantic enabled buffers accordingly." diff --git a/lisp/cedet/semantic/decorate/mode.el b/lisp/cedet/semantic/decorate/mode.el index 8eb6a3bbd5..293692000d 100644 --- a/lisp/cedet/semantic/decorate/mode.el +++ b/lisp/cedet/semantic/decorate/mode.el @@ -204,9 +204,6 @@ semantic-decorate-add-decorations (defvar semantic-decorate-pending-decoration-hook nil "Normal hook run to perform pending decoration changes.") -(semantic-varalias-obsolete 'semantic-decorate-pending-decoration-hooks - 'semantic-decorate-pending-decoration-hook "23.2") - (defun semantic-decorate-add-pending-decoration (fcn &optional buffer) "Add a pending decoration change represented by FCN. Applies only to the current BUFFER. diff --git a/lisp/cedet/semantic/doc.el b/lisp/cedet/semantic/doc.el index 8b39e77578..896bc3bb42 100644 --- a/lisp/cedet/semantic/doc.el +++ b/lisp/cedet/semantic/doc.el @@ -93,8 +93,7 @@ semantic-doc-snarf-comment-for-tag Attempt to strip out comment syntactic sugar. Argument NOSNARF means don't modify the found text. If NOSNARF is `lex', then return the lex token." - (let* ((semantic-ignore-comments nil) - (semantic-lex-analyzer #'semantic-comment-lexer)) + (let* ((semantic-lex-analyzer #'semantic-comment-lexer)) (if (memq nosnarf '(lex flex)) ;; keep `flex' for compatibility (car (semantic-lex (point) (1+ (point)))) (let ((ct (semantic-lex-token-text diff --git a/lisp/cedet/semantic/edit.el b/lisp/cedet/semantic/edit.el index a1225dfeee..e4319c7d1b 100644 --- a/lisp/cedet/semantic/edit.el +++ b/lisp/cedet/semantic/edit.el @@ -121,9 +121,6 @@ semantic-edits-incremental-reparse-failed-hook "Hook run after the incremental parser fails. When this happens, the buffer is marked as needing a full reparse.") -(semantic-varalias-obsolete 'semantic-edits-incremental-reparse-failed-hooks - 'semantic-edits-incremental-reparse-failed-hook "23.2") - (defcustom semantic-edits-verbose-flag nil "Non-nil means the incremental parser is verbose. If nil, errors are still displayed, but informative messages are not." diff --git a/lisp/cedet/semantic/fw.el b/lisp/cedet/semantic/fw.el index e347c99f19..c86cd3abf3 100644 --- a/lisp/cedet/semantic/fw.el +++ b/lisp/cedet/semantic/fw.el @@ -173,6 +173,7 @@ semantic-test-data-cache ;; (defun semantic-overload-symbol-from-function (name) "Return the symbol for overload used by NAME, the defined symbol." + (declare (obsolete define-obsolete-function-alias "28.1")) (let ((sym-name (symbol-name name))) (if (string-match "^semantic-" sym-name) (intern (substring sym-name (match-end 0))) @@ -182,6 +183,7 @@ semantic-alias-obsolete "Make OLDFNALIAS an alias for NEWFN. Mark OLDFNALIAS as obsolete, such that the byte compiler will throw a warning when it encounters this symbol." + (declare (obsolete define-obsolete-function-alias "28.1")) (defalias oldfnalias newfn) (make-obsolete oldfnalias newfn when) (when (and (mode-local--function-overload-p newfn) @@ -196,13 +198,14 @@ semantic-alias-obsolete "%s: `%s' obsoletes overload `%s'" byte-compile-current-file newfn - (semantic-overload-symbol-from-function oldfnalias)) - )) + (with-suppressed-warnings ((obsolete semantic-overload-symbol-from-function)) + (semantic-overload-symbol-from-function oldfnalias))))) (defun semantic-varalias-obsolete (oldvaralias newvar when) "Make OLDVARALIAS an alias for variable NEWVAR. Mark OLDVARALIAS as obsolete, such that the byte compiler will throw a warning when it encounters this symbol." + (declare (obsolete define-obsolete-variable-alias "28.1")) (make-obsolete-variable oldvaralias newvar when) (condition-case nil (defvaralias oldvaralias newvar) @@ -256,9 +259,6 @@ semantic-map-buffers (defalias 'semantic-map-mode-buffers 'mode-local-map-mode-buffers) -(semantic-alias-obsolete 'define-mode-overload-implementation - 'define-mode-local-override "23.2") - (defun semantic-install-function-overrides (overrides &optional transient) "Install the function OVERRIDES in the specified environment. OVERRIDES must be an alist ((OVERLOAD . FUNCTION) ...) where OVERLOAD @@ -396,13 +396,10 @@ semanticdb-without-unloaded-file-searches ;; "define-lex-regex-type-analyzer" ;; "define-lex-string-type-analyzer" ;; "define-lex-block-type-analyzer" -;; ;;"define-mode-overload-implementation" ;; ;;"define-semantic-child-mode" ;; "define-semantic-idle-service" ;; "define-semantic-decoration-style" ;; "define-wisent-lexer" -;; "semantic-alias-obsolete" -;; "semantic-varalias-obsolete" ;; "semantic-make-obsolete-overload" ;; "defcustom-mode-local-semantic-dependency-system-include-path" ;; )) diff --git a/lisp/cedet/semantic/grammar.el b/lisp/cedet/semantic/grammar.el index 6cd4832165..f71ac6c413 100644 --- a/lisp/cedet/semantic/grammar.el +++ b/lisp/cedet/semantic/grammar.el @@ -142,7 +142,7 @@ semantic-grammar-ASSOC "Return expansion of built-in ASSOC expression. ARGS are ASSOC's key value list." (let ((key t)) - `(semantic-tag-make-assoc-list + `(semantic-tag-make-plist ,@(mapcar #'(lambda (i) (prog1 (if key diff --git a/lisp/cedet/semantic/idle.el b/lisp/cedet/semantic/idle.el index 76218249c5..8301b19530 100644 --- a/lisp/cedet/semantic/idle.el +++ b/lisp/cedet/semantic/idle.el @@ -472,11 +472,6 @@ semantic-after-idle-scheduler-reparse-hook If any hook function throws an error, this variable is reset to nil. This hook is not protected from lexical errors.") -(semantic-varalias-obsolete 'semantic-before-idle-scheduler-reparse-hooks - 'semantic-before-idle-scheduler-reparse-hook "23.2") -(semantic-varalias-obsolete 'semantic-after-idle-scheduler-reparse-hooks - 'semantic-after-idle-scheduler-reparse-hook "23.2") - (defun semantic-idle-scheduler-refresh-tags () "Refreshes the current buffer's tags. This is called by `semantic-idle-scheduler-function' to update the @@ -734,10 +729,6 @@ semantic-idle-summary-useful-context-p (define-overloadable-function semantic-idle-summary-current-symbol-info () "Return a string message describing the current context.") -(make-obsolete-overload 'semantic-eldoc-current-symbol-info - 'semantic-idle-summary-current-symbol-info - "23.2") - (defcustom semantic-idle-summary-mode-hook nil "Hook run at the end of `semantic-idle-summary'." :group 'semantic diff --git a/lisp/cedet/semantic/imenu.el b/lisp/cedet/semantic/imenu.el index cdf0a23fa0..25f7fdb842 100644 --- a/lisp/cedet/semantic/imenu.el +++ b/lisp/cedet/semantic/imenu.el @@ -88,8 +88,6 @@ semantic-imenu-expand-type-members :group 'semantic-imenu :type 'boolean) (make-variable-buffer-local 'semantic-imenu-expand-type-members) -(semantic-varalias-obsolete 'semantic-imenu-expand-type-parts - 'semantic-imenu-expand-type-members "23.2") (defcustom semantic-imenu-bucketize-type-members t "Non-nil if members of a type should be grouped into buckets. @@ -98,8 +96,6 @@ semantic-imenu-bucketize-type-members :group 'semantic-imenu :type 'boolean) (make-variable-buffer-local 'semantic-imenu-bucketize-type-members) -(semantic-varalias-obsolete 'semantic-imenu-bucketize-type-parts - 'semantic-imenu-bucketize-type-members "23.2") (defcustom semantic-imenu-sort-bucket-function nil "Function to use when sorting tags in the buckets of functions. @@ -145,8 +141,6 @@ semantic-imenu-expandable-tag-classes By default, a `type' has interesting children. In Texinfo, however, a `section' has interesting children.") (make-variable-buffer-local 'semantic-imenu-expandable-tag-classes) -(semantic-varalias-obsolete 'semantic-imenu-expandable-token - 'semantic-imenu-expandable-tag-classes "23.2") ;;; Code: (defun semantic-imenu-tag-overlay (tag) diff --git a/lisp/cedet/semantic/java.el b/lisp/cedet/semantic/java.el index 80d03dc629..2aa0ab0e3f 100644 --- a/lisp/cedet/semantic/java.el +++ b/lisp/cedet/semantic/java.el @@ -253,9 +253,6 @@ semantic-format-tag-prototype 'semantic-format-tag-prototype-default) tag parent color))) -(semantic-alias-obsolete 'semantic-java-prototype-nonterminal - 'semantic-format-tag-prototype-java-mode "23.2") - ;; Include Tag Name ;; diff --git a/lisp/cedet/semantic/lex.el b/lisp/cedet/semantic/lex.el index 500a09d492..cb17f9fd93 100644 --- a/lisp/cedet/semantic/lex.el +++ b/lisp/cedet/semantic/lex.el @@ -1754,29 +1754,11 @@ semantic-lex-catch-errors ;; ;; NOTE: DELETE THIS SOMEDAY SOON -(semantic-alias-obsolete 'semantic-flex-start 'semantic-lex-token-start "23.2") -(semantic-alias-obsolete 'semantic-flex-end 'semantic-lex-token-end "23.2") -(semantic-alias-obsolete 'semantic-flex-text 'semantic-lex-token-text "23.2") -(semantic-alias-obsolete 'semantic-flex-make-keyword-table 'semantic-lex-make-keyword-table "23.2") -(semantic-alias-obsolete 'semantic-flex-keyword-p 'semantic-lex-keyword-p "23.2") -(semantic-alias-obsolete 'semantic-flex-keyword-put 'semantic-lex-keyword-put "23.2") -(semantic-alias-obsolete 'semantic-flex-keyword-get 'semantic-lex-keyword-get "23.2") -(semantic-alias-obsolete 'semantic-flex-map-keywords 'semantic-lex-map-keywords "23.2") -(semantic-alias-obsolete 'semantic-flex-keywords 'semantic-lex-keywords "23.2") -(semantic-alias-obsolete 'semantic-flex-buffer 'semantic-lex-buffer "23.2") -(semantic-alias-obsolete 'semantic-flex-list 'semantic-lex-list "23.2") - -;; This simple scanner uses the syntax table to generate a stream of -;; simple tokens of the form: -;; -;; (SYMBOL START . END) -;; -;; Where symbol is the type of thing it is. START and END mark that -;; objects boundary. - (defvar semantic-flex-tokens semantic-lex-tokens "An alist of semantic token types. See variable `semantic-lex-tokens'.") +(make-obsolete-variable 'semantic-flex-tokens + 'semantic-lex-tokens "28.1") (defvar semantic-flex-unterminated-syntax-end-function (lambda (_syntax _syntax-start flex-end) flex-end) @@ -1788,6 +1770,8 @@ semantic-flex-unterminated-syntax-end-function This function can be used for languages that can intelligently fix up broken syntax, or the exit lexical analysis via `throw' or `signal' when finding unterminated syntax.") +(make-obsolete-variable 'semantic-flex-unterminated-syntax-end-function + nil "28.1") (defvar semantic-flex-extensions nil "Buffer local extensions to the lexical analyzer. @@ -1799,6 +1783,7 @@ semantic-flex-extensions TYPE can be any type of symbol, as long as it doesn't occur as a nonterminal in the language definition.") (make-variable-buffer-local 'semantic-flex-extensions) +(make-obsolete-variable 'semantic-flex-extensions nil "28.1") (defvar semantic-flex-syntax-modifications nil "Changes to the syntax table for this buffer. @@ -1809,237 +1794,47 @@ semantic-flex-syntax-modifications and CLASS is the string also passed to `modify-syntax-entry' to define what syntax class CHAR has.") (make-variable-buffer-local 'semantic-flex-syntax-modifications) +(make-obsolete-variable 'semantic-flex-syntax-modifications nil "28.1") (defvar semantic-ignore-comments t "Default comment handling. The value t means to strip comments when flexing; nil means to keep comments as part of the token stream.") (make-variable-buffer-local 'semantic-ignore-comments) +(make-obsolete-variable 'semantic-ignore-comments nil "28.1") (defvar semantic-flex-enable-newlines nil "When flexing, report newlines as syntactic elements. Useful for languages where the newline is a special case terminator. Only set this on a per mode basis, not globally.") (make-variable-buffer-local 'semantic-flex-enable-newlines) +(make-obsolete-variable 'semantic-flex-enable-newlines nil "28.1") (defvar semantic-flex-enable-whitespace nil "When flexing, report whitespace as syntactic elements. Useful for languages where the syntax is whitespace dependent. Only set this on a per mode basis, not globally.") (make-variable-buffer-local 'semantic-flex-enable-whitespace) +(make-obsolete-variable 'semantic-flex-enable-whitespace nil "28.1") (defvar semantic-flex-enable-bol nil "When flexing, report beginning of lines as syntactic elements. Useful for languages like python which are indentation sensitive. Only set this on a per mode basis, not globally.") (make-variable-buffer-local 'semantic-flex-enable-bol) +(make-obsolete-variable 'semantic-flex-enable-bol nil "28.1") (defvar semantic-number-expression semantic-lex-number-expression "See variable `semantic-lex-number-expression'.") (make-variable-buffer-local 'semantic-number-expression) +(make-obsolete-variable 'semantic-number-expression + 'semantic-lex-number-expression "28.1") (defvar semantic-flex-depth 0 "Default flexing depth. This specifies how many lists to create tokens in.") (make-variable-buffer-local 'semantic-flex-depth) - -(defun semantic-flex (start end &optional depth length) - "Using the syntax table, do something roughly equivalent to flex. -Semantically check between START and END. Optional argument DEPTH -indicates at what level to scan over entire lists. -The return value is a token stream. Each element is a list, such of -the form (symbol start-expression . end-expression) where SYMBOL -denotes the token type. -See `semantic-flex-tokens' variable for details on token types. -END does not mark the end of the text scanned, only the end of the -beginning of text scanned. Thus, if a string extends past END, the -end of the return token will be larger than END. To truly restrict -scanning, use `narrow-to-region'. -The last argument, LENGTH specifies that `semantic-flex' should only -return LENGTH tokens." - (declare (obsolete define-lex "23.2")) - (if (not semantic-flex-keywords-obarray) - (setq semantic-flex-keywords-obarray [ nil ])) - (let ((ts nil) - (pos (point)) - (ep nil) - (curdepth 0) - (cs (if comment-start-skip - (concat "\\(\\s<\\|" comment-start-skip "\\)") - (concat "\\(\\s<\\)"))) - (newsyntax (copy-syntax-table (syntax-table))) - (mods semantic-flex-syntax-modifications) - ;; Use the default depth if it is not specified. - (depth (or depth semantic-flex-depth))) - ;; Update the syntax table - (while mods - (modify-syntax-entry (car (car mods)) (car (cdr (car mods))) newsyntax) - (setq mods (cdr mods))) - (with-syntax-table newsyntax - (goto-char start) - (while (and (< (point) end) (or (not length) (<= (length ts) length))) - (cond - ;; catch beginning of lines when needed. - ;; Must be done before catching any other tokens! - ((and semantic-flex-enable-bol - (bolp) - ;; Just insert a (bol N . N) token in the token stream, - ;; without moving the point. N is the point at the - ;; beginning of line. - (setq ts (cons (cons 'bol (cons (point) (point))) ts)) - nil)) ;; CONTINUE - ;; special extensions, includes whitespace, nl, etc. - ((and semantic-flex-extensions - (let ((fe semantic-flex-extensions) - (r nil)) - (while fe - (if (looking-at (car (car fe))) - (setq ts (cons (funcall (cdr (car fe))) ts) - r t - fe nil - ep (point))) - (setq fe (cdr fe))) - (if (and r (not (car ts))) (setq ts (cdr ts))) - r))) - ;; catch newlines when needed - ((looking-at "\\s-*\\(\n\\|\\s>\\)") - (if semantic-flex-enable-newlines - (setq ep (match-end 1) - ts (cons (cons 'newline - (cons (match-beginning 1) ep)) - ts)))) - ;; catch whitespace when needed - ((looking-at "\\s-+") - (if semantic-flex-enable-whitespace - ;; Language wants whitespaces, link them together. - (if (eq (car (car ts)) 'whitespace) - (setcdr (cdr (car ts)) (match-end 0)) - (setq ts (cons (cons 'whitespace - (cons (match-beginning 0) - (match-end 0))) - ts))))) - ;; numbers - ((and semantic-number-expression - (looking-at semantic-number-expression)) - (setq ts (cons (cons 'number - (cons (match-beginning 0) - (match-end 0))) - ts))) - ;; symbols - ((looking-at "\\(\\sw\\|\\s_\\)+") - (setq ts (cons (cons - ;; Get info on if this is a keyword or not - (or (semantic-lex-keyword-p (match-string 0)) - 'symbol) - (cons (match-beginning 0) (match-end 0))) - ts))) - ;; Character quoting characters (ie, \n as newline) - ((looking-at "\\s\\+") - (setq ts (cons (cons 'charquote - (cons (match-beginning 0) (match-end 0))) - ts))) - ;; Open parens, or semantic-lists. - ((looking-at "\\s(") - (if (or (not depth) (< curdepth depth)) - (progn - (setq curdepth (1+ curdepth)) - (setq ts (cons (cons 'open-paren - (cons (match-beginning 0) (match-end 0))) - ts))) - (setq ts (cons - (cons 'semantic-list - (cons (match-beginning 0) - (save-excursion - (condition-case nil - (forward-list 1) - ;; This case makes flex robust - ;; to broken lists. - (error - (goto-char - (funcall - semantic-flex-unterminated-syntax-end-function - 'semantic-list - start end)))) - (setq ep (point))))) - ts)))) - ;; Close parens - ((looking-at "\\s)") - (setq ts (cons (cons 'close-paren - (cons (match-beginning 0) (match-end 0))) - ts)) - (setq curdepth (1- curdepth))) - ;; String initiators - ((looking-at "\\s\"") - ;; Zing to the end of this string. - (setq ts (cons (cons 'string - (cons (match-beginning 0) - (save-excursion - (condition-case nil - (forward-sexp 1) - ;; This case makes flex - ;; robust to broken strings. - (error - (goto-char - (funcall - semantic-flex-unterminated-syntax-end-function - 'string - start end)))) - (setq ep (point))))) - ts))) - ;; comments - ((looking-at cs) - (if (and semantic-ignore-comments - (not semantic-flex-enable-whitespace)) - ;; If the language doesn't deal with comments nor - ;; whitespaces, ignore them here. - (let ((comment-start-point (point))) - (forward-comment 1) - (if (eq (point) comment-start-point) - ;; In this case our start-skip string failed - ;; to work properly. Lets try and move over - ;; whatever white space we matched to begin - ;; with. - (skip-syntax-forward "-.'" (point-at-eol)) - ;;(forward-comment 1) - ;; Generate newline token if enabled - (if (and semantic-flex-enable-newlines - (bolp)) - (backward-char 1))) - (if (eq (point) comment-start-point) - (error "Strange comment syntax prevents lexical analysis")) - (setq ep (point))) - (let ((tk (if semantic-ignore-comments 'whitespace 'comment))) - (save-excursion - (forward-comment 1) - ;; Generate newline token if enabled - (if (and semantic-flex-enable-newlines - (bolp)) - (backward-char 1)) - (setq ep (point))) - ;; Language wants comments or want them as whitespaces, - ;; link them together. - (if (eq (car (car ts)) tk) - (setcdr (cdr (car ts)) ep) - (setq ts (cons (cons tk (cons (match-beginning 0) ep)) - ts)))))) - ;; punctuation - ((looking-at "\\(\\s.\\|\\s$\\|\\s'\\)") - (setq ts (cons (cons 'punctuation - (cons (match-beginning 0) (match-end 0))) - ts))) - ;; unknown token - (t - (error "What is that?"))) - (goto-char (or ep (match-end 0))) - (setq ep nil))) - ;; maybe catch the last beginning of line when needed - (and semantic-flex-enable-bol - (= (point) end) - (bolp) - (setq ts (cons (cons 'bol (cons (point) (point))) ts))) - (goto-char pos) - ;;(message "Flexing muscles...done") - (nreverse ts))) +(make-obsolete-variable 'semantic-flex-depth nil "28.1") (provide 'semantic/lex) diff --git a/lisp/cedet/semantic/tag-file.el b/lisp/cedet/semantic/tag-file.el index 50d43fe934..23f4b29cbd 100644 --- a/lisp/cedet/semantic/tag-file.el +++ b/lisp/cedet/semantic/tag-file.el @@ -101,9 +101,6 @@ semantic-go-to-tag ) ) -(make-obsolete-overload 'semantic-find-nonterminal - 'semantic-go-to-tag "23.2") - ;;; Dependencies ;; ;; A tag which is of type 'include specifies a dependency. @@ -175,9 +172,6 @@ semantic-dependency-tag-file nil) ))) -(make-obsolete-overload 'semantic-find-dependency - 'semantic-dependency-tag-file "23.2") - ;;; PROTOTYPE FILE ;; ;; In C, a function in the .c file often has a representation in a @@ -199,13 +193,6 @@ semantic-prototype-file (if (re-search-forward "::Header:: \\([a-zA-Z0-9.]+\\)" nil t) (match-string 1)))))) -(semantic-alias-obsolete 'semantic-find-nonterminal - 'semantic-go-to-tag "23.2") - -(semantic-alias-obsolete 'semantic-find-dependency - 'semantic-dependency-tag-file "23.2") - - (provide 'semantic/tag-file) ;; Local variables: diff --git a/lisp/cedet/semantic/tag-ls.el b/lisp/cedet/semantic/tag-ls.el index 16179a53cd..3ee11df7d8 100644 --- a/lisp/cedet/semantic/tag-ls.el +++ b/lisp/cedet/semantic/tag-ls.el @@ -190,7 +190,7 @@ semantic-tag-similar-p-default ;; will contain the info needed to determine the full name. (define-overloadable-function semantic-tag-full-package (tag &optional stream-or-buffer) "Return the fully qualified package name of TAG in a package hierarchy. -STREAM-OR-BUFFER can be anything convertible by `semantic-something-to-stream', +STREAM-OR-BUFFER can be anything convertible by `semantic-something-to-tag-table', but must be a toplevel semantic tag stream that contains TAG. A Package Hierarchy is defined in UML by the way classes and methods are organized on disk. Some languages use this concept such that a @@ -213,7 +213,7 @@ semantic-tag-full-package-default (define-overloadable-function semantic-tag-full-name (tag &optional stream-or-buffer) "Return the fully qualified name of TAG in the package hierarchy. -STREAM-OR-BUFFER can be anything convertible by `semantic-something-to-stream', +STREAM-OR-BUFFER can be anything convertible by `semantic-something-to-tag-table', but must be a toplevel semantic tag stream that contains TAG. A Package Hierarchy is defined in UML by the way classes and methods are organized on disk. Some languages use this concept such that a @@ -233,9 +233,6 @@ semantic-tag-full-name (or stream-or-buffer tag)))) (:override-with-args (tag stream)))) -(make-obsolete-overload 'semantic-nonterminal-full-name - 'semantic-tag-full-name "23.2") - (defun semantic-tag-full-name-default (tag stream) "Default method for `semantic-tag-full-name'. Return the name of TAG found in the toplevel STREAM." @@ -287,9 +284,6 @@ semantic-tag-protection (setq parent (semantic-tag-calculate-parent tag))) (:override)) -(make-obsolete-overload 'semantic-nonterminal-protection - 'semantic-tag-protection "23.2") - (defun semantic-tag-protection-default (tag &optional parent) "Return the protection of TAG as a child of PARENT default action. See `semantic-tag-protection'." @@ -377,9 +371,6 @@ semantic-tag-abstract-p The default behavior (if not overridden with `tag-abstract-p' is to return true if `abstract' is in the type modifiers.") -(make-obsolete-overload 'semantic-nonterminal-abstract - 'semantic-tag-abstract-p "23.2") - (defun semantic-tag-abstract-p-default (tag &optional parent) "Return non-nil if TAG is abstract as a child of PARENT default action. See `semantic-tag-abstract-p'." @@ -400,9 +391,6 @@ semantic-tag-leaf-p The default behavior (if not overridden with `tag-leaf-p' is to return true if `leaf' is in the type modifiers.") -(make-obsolete-overload 'semantic-nonterminal-leaf - 'semantic-tag-leaf-p "23.2") - (defun semantic-tag-leaf-p-default (tag &optional parent) "Return non-nil if TAG is leaf as a child of PARENT default action. See `semantic-tag-leaf-p'." diff --git a/lisp/cedet/semantic/tag.el b/lisp/cedet/semantic/tag.el index ca5c068d34..e677264c5a 100644 --- a/lisp/cedet/semantic/tag.el +++ b/lisp/cedet/semantic/tag.el @@ -1328,26 +1328,6 @@ semantic-token-version (defconst semantic-token-incompatible-version semantic-tag-incompatible-version) -(defsubst semantic-token-type-parent (tag) - "Return the parent of the type that TAG describes. -The return value is a list. A value of nil means no parents. -The `car' of the list is either the parent class, or a list -of parent classes. The `cdr' of the list is the list of -interfaces, or abstract classes which are parents of TAG." - (cons (semantic-tag-get-attribute tag :superclasses) - (semantic-tag-type-interfaces tag))) - -(make-obsolete 'semantic-token-type-parent - "\ -use `semantic-tag-type-superclass' \ -and `semantic-tag-type-interfaces' instead" "23.2") - -(semantic-alias-obsolete 'semantic-tag-make-assoc-list - 'semantic-tag-make-plist "23.2") - -(semantic-varalias-obsolete 'semantic-expand-nonterminal - 'semantic-tag-expand-function "23.2") - (provide 'semantic/tag) ;; Local variables: diff --git a/lisp/cedet/semantic/util.el b/lisp/cedet/semantic/util.el index c64d56b2e2..7df7dfcb75 100644 --- a/lisp/cedet/semantic/util.el +++ b/lisp/cedet/semantic/util.el @@ -79,9 +79,6 @@ semantic-file-tag-table (with-current-buffer (find-file-noselect file) (semantic-fetch-tags)))))) -(semantic-alias-obsolete 'semantic-file-token-stream - 'semantic-file-tag-table "23.2") - (declare-function semanticdb-abstract-table-child-p "semantic/db" (obj) t) (declare-function semanticdb-refresh-table "semantic/db") (declare-function semanticdb-get-tags "semantic/db" (arg &rest args) t) @@ -137,9 +134,6 @@ semantic-something-to-tag-table ;; don't know what it is (t nil))) -(semantic-alias-obsolete 'semantic-something-to-stream - 'semantic-something-to-tag-table "23.2") - ;;; Completion APIs ;; ;; These functions provide minibuffer reading/completion for lists of @@ -307,7 +301,6 @@ semantic-describe-buffer semantic-init-db-hook semantic-unmatched-syntax-hook semantic--before-fetch-tags-hook - semantic-after-toplevel-bovinate-hook semantic-after-toplevel-cache-change-hook semantic-before-toplevel-cache-flush-hook semantic-dump-parse diff --git a/lisp/cedet/semantic/wisent.el b/lisp/cedet/semantic/wisent.el index 527a35c9ae..15d1313dfa 100644 --- a/lisp/cedet/semantic/wisent.el +++ b/lisp/cedet/semantic/wisent.el @@ -43,11 +43,6 @@ wisent-lex-lookahead "Extra lookahead token. When non-nil it is directly returned by `wisent-lex-function'.") -;; Maintain this alias for compatibility until all WY grammars have -;; been translated again to Elisp code. -(semantic-alias-obsolete 'wisent-lex-make-token-table - 'semantic-lex-make-type-table "23.2") - (defmacro wisent-lex-eoi () "Return an End-Of-Input lexical token. The EOI token is like this: ($EOI \"\" POINT-MAX . POINT-MAX)." -- 2.28.0 ^ permalink raw reply related [flat|nested] 838+ messages in thread
* Re: Delete variables obsolete since Emacs 23 2020-09-04 17:04 ` Stefan Kangas @ 2020-09-05 12:39 ` Lars Ingebrigtsen 2020-09-11 20:01 ` Stefan Kangas 0 siblings, 1 reply; 838+ messages in thread From: Lars Ingebrigtsen @ 2020-09-05 12:39 UTC (permalink / raw) To: Stefan Kangas; +Cc: Stefan Monnier, Drew Adams, emacs-devel Stefan Kangas <stefankangas@gmail.com> writes: > Stefan Kangas <stefankangas@gmail.com> writes: > >> The next step here is the obsoletions in semantic. > > Please find attached a patch to remove obsolete items also from cedet. > > Any comments? I just skimmed it, but it looks good to me. Perhaps this comment should also be deleted? > ;; NOTE: DELETE THIS SOMEDAY SOON > > -(semantic-alias-obsolete 'semantic-flex-start 'semantic-lex-token-start "23.2") -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Delete variables obsolete since Emacs 23 2020-09-05 12:39 ` Lars Ingebrigtsen @ 2020-09-11 20:01 ` Stefan Kangas 0 siblings, 0 replies; 838+ messages in thread From: Stefan Kangas @ 2020-09-11 20:01 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Stefan Monnier, Drew Adams, emacs-devel Lars Ingebrigtsen <larsi@gnus.org> writes: >> Please find attached a patch to remove obsolete items also from cedet. > > I just skimmed it, but it looks good to me. Perhaps this comment should > also be deleted? > >> ;; NOTE: DELETE THIS SOMEDAY SOON >> >> -(semantic-alias-obsolete 'semantic-flex-start 'semantic-lex-token-start "23.2") Thanks for the review. I removed the above line and pushed to master as commit 91a221b279. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Deleting old `:version` from defcustoms (was: master b76cdd0: Delete libraries obsolete since 23.1 and 23.2) 2020-05-15 18:38 ` Deleting old `:version` from defcustoms (was: master b76cdd0: Delete libraries obsolete since 23.1 and 23.2) Stefan Monnier 2020-05-15 20:58 ` Stefan Kangas 2020-05-16 13:18 ` Delete variables obsolete since Emacs 23 Stefan Kangas @ 2020-05-17 3:18 ` Stefan Kangas 2020-05-17 15:18 ` Eli Zaretskii 2 siblings, 1 reply; 838+ messages in thread From: Stefan Kangas @ 2020-05-17 3:18 UTC (permalink / raw) To: Stefan Monnier, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: > I did a quick `grep` to see the functions/vars that were obsoleted in > the same time frame, and I saw instead a deluge of > > :version "23.1" > > If we consider those thingies old enough to remove their obsolete > functions, shouldn't we also remove the corresponding `:version` > thingies from `defcustom`s? > > I see: > - 1 defcustom with a :version of 19.29 > - >200 defcustoms with a :version of 20.x > - a bit less than 200 defcustoms with a :version of 21.x > - >400 defcustoms with a :version of 22.x > - >200 defcustoms with a :version of 23.x I realize I don't fully understand the purpose of the :version declarations. If it's mostly to let users know what changed, they can probably be removed for these very old versions. But are they also intended to provide a historical record? If so, maybe they should be kept indefinitely. Best regards, Stefan Kangas ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Deleting old `:version` from defcustoms (was: master b76cdd0: Delete libraries obsolete since 23.1 and 23.2) 2020-05-17 3:18 ` Deleting old `:version` from defcustoms (was: master b76cdd0: Delete libraries obsolete since 23.1 and 23.2) Stefan Kangas @ 2020-05-17 15:18 ` Eli Zaretskii 2020-05-17 16:59 ` Deleting old `:version` from defcustoms Stefan Monnier 0 siblings, 1 reply; 838+ messages in thread From: Eli Zaretskii @ 2020-05-17 15:18 UTC (permalink / raw) To: Stefan Kangas; +Cc: monnier, emacs-devel > From: Stefan Kangas <stefankangas@gmail.com> > Date: Sat, 16 May 2020 20:18:54 -0700 > > I realize I don't fully understand the purpose of the :version > declarations. If it's mostly to let users know what changed, they can > probably be removed for these very old versions. > > But are they also intended to provide a historical record? If so, maybe > they should be kept indefinitely. I think it's good to have a facility that can tell us in which Emacs version was some option introduced. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Deleting old `:version` from defcustoms 2020-05-17 15:18 ` Eli Zaretskii @ 2020-05-17 16:59 ` Stefan Monnier 0 siblings, 0 replies; 838+ messages in thread From: Stefan Monnier @ 2020-05-17 16:59 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Stefan Kangas, emacs-devel > I think it's good to have a facility that can tell us in which Emacs > version was some option introduced. The :version doesn't quite tell us that: it tells us when it was last changed. Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#35367: 26.2; `dired-copy-how-to-fn' and HOW-TO arg of `dired-create-files'
@ 2019-04-21 19:30 Drew Adams
2019-07-09 14:21 ` Lars Ingebrigtsen
0 siblings, 1 reply; 838+ messages in thread
From: Drew Adams @ 2019-04-21 19:30 UTC (permalink / raw)
To: 35367
1. I believe `dired-copy-how-to-fn' was added to Emacs quite a while ago
(1991[1]). But it's not clear to me what it's really for, and there
seem to be no uses of it in the distributed Emacs code, apart from
`dired-do-copy', which just passes it on to `dired-create-files'.
The variable's doc just says to "See HOW-TO argument for
`dired-create-files'."
So why was this variable created?
2. Apart from the variable, why was the HOW-TO arg of
`dired-do-create-files' added? I find no uses of it, apart from
`dired-do-copy' (which just passes it along).
Presumably someone thought that someone might want to pass such a
thing to `dired-do-copy', but why?
Half the doc of `dired-do-create-files' is for this parameter. And
its description, although probably correct and complete, reads like
gobbledygook, to me.
For one thing, the nil case should not be described under this
parameter; it should be described as the function's default behavior,
up above the parameter list. (That's already 4 lines of its
description.)
Beyond that:
* A value of `t' is unclear to me. What does it mean to target a
plain file - is this the same as using a `nil' value? What happens
with `t' if the target is a directory or if there are multiple
marked files? Is that where the difference lies somehow (how)?
* A unary function value is the most confusing. I can't follow it,
I'm afraid.
If HOW-TO is to stay (and I assume it is) then we really need some
kind of motivating explanation - perhaps an example of why/when/how
you would use a function here. With no existing examples in the code
this seems a bit
maybe-someone-someday-might-need-this-thing-that-somebody-dreamed.
It was apparently RMS who added this [1]. I'm surprised that it's
not more clear what good it is.
[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25075#20
In GNU Emacs 26.2 (build 1, x86_64-w64-mingw32)
of 2019-04-13
Repository revision: fd1b34bfba8f3f6298df47c8e10b61530426f749
Windowing system distributor `Microsoft Corp.', version 10.0.17134
Configured using:
`configure --without-dbus --host=x86_64-w64-mingw32
--without-compress-install 'CFLAGS=-O2 -static -g3''
^ permalink raw reply [flat|nested] 838+ messages in thread* bug#35367: 26.2; `dired-copy-how-to-fn' and HOW-TO arg of `dired-create-files' 2019-04-21 19:30 bug#35367: 26.2; `dired-copy-how-to-fn' and HOW-TO arg of `dired-create-files' Drew Adams @ 2019-07-09 14:21 ` Lars Ingebrigtsen 2019-07-11 5:51 ` Mike Kupfer 0 siblings, 1 reply; 838+ messages in thread From: Lars Ingebrigtsen @ 2019-07-09 14:21 UTC (permalink / raw) To: Drew Adams; +Cc: 35367 Drew Adams <drew.adams@oracle.com> writes: > 1. I believe `dired-copy-how-to-fn' was added to Emacs quite a while ago > (1991[1]). But it's not clear to me what it's really for, and there > seem to be no uses of it in the distributed Emacs code, apart from > `dired-do-copy', which just passes it on to `dired-create-files'. > The variable's doc just says to "See HOW-TO argument for > `dired-create-files'." > > So why was this variable created? I hoped that the code might throw some light on this variable, but: (defun dired-into-dir-with-symlinks (target) (and (file-directory-p target) (not (file-symlink-p target)))) ;; This may not always be what you want, especially if target is your ;; home directory and it happens to be a symbolic link, as is often the ;; case with NFS and automounters. Or if you want to make symlinks ;; into directories that themselves are only symlinks, also quite ;; common. ;; So we don't use this function as value for HOW-TO in ;; dired-do-symlink, which has the minor disadvantage of ;; making links *into* a symlinked-dir, when you really wanted to ;; *overwrite* that symlink. In that (rare, I guess) case, you'll ;; just have to remove that symlink by hand before making your marked ;; symlinks. (defvar dired-copy-how-to-fn nil "Either nil or a function used by `dired-do-copy' to determine target. See HOW-TO argument for `dired-do-create-files'.") It's still clear as mud to me. > 2. Apart from the variable, why was the HOW-TO arg of > `dired-do-create-files' added? I find no uses of it, apart from > `dired-do-copy' (which just passes it along). > > Presumably someone thought that someone might want to pass such a > thing to `dired-do-copy', but why? > > Half the doc of `dired-do-create-files' is for this parameter. And > its description, although probably correct and complete, reads like > gobbledygook, to me. > > For one thing, the nil case should not be described under this > parameter; it should be described as the function's default behavior, > up above the parameter list. (That's already 4 lines of its > description.) Well... I think it makes sense (in so far as this parameter makes any sense) to keep it where it is: Optional arg HOW-TO determines how to treat the target. If HOW-TO is nil, use `file-directory-p' to determine if the target is a directory. If so, the marked file(s) are created inside that directory. Otherwise, the target is a plain file; an error is raised unless there is exactly one marked file. If HOW-TO is t, target is always treated as a plain file. Otherwise, HOW-TO should be a function of one argument, TARGET. If its return value is nil, TARGET is regarded as a plain file. If it return value is a list, TARGET is a generalized directory (e.g. some sort of archive). The first element of this list must be a function with at least four arguments: operation - as OPERATION above. rfn-list - list of the relative names for the marked files. fn-list - list of the absolute names for the marked files. target - the name of the target itself. The rest of elements of the list returned by HOW-TO are optional arguments for the function that is the first element of the list. For any other return value, TARGET is treated as a directory." > Beyond that: > > * A value of `t' is unclear to me. What does it mean to target a > plain file - is this the same as using a `nil' value? What happens > with `t' if the target is a directory or if there are multiple > marked files? Is that where the difference lies somehow (how)? My interpretation of t is that all files you copy will up in the same file if it's t, which is a supremely useless thing, you'd think... > It was apparently RMS who added this [1]. I'm surprised that it's > not more clear what good it is. Does anybody know what this parameter and variable was meant to do, and whether it's used anywhere out-of-tree? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#35367: 26.2; `dired-copy-how-to-fn' and HOW-TO arg of `dired-create-files' 2019-07-09 14:21 ` Lars Ingebrigtsen @ 2019-07-11 5:51 ` Mike Kupfer 2019-07-11 14:04 ` Lars Ingebrigtsen ` (2 more replies) 0 siblings, 3 replies; 838+ messages in thread From: Mike Kupfer @ 2019-07-11 5:51 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 35367 Lars Ingebrigtsen wrote: > Drew Adams <drew.adams@oracle.com> writes: > > > 1. I believe `dired-copy-how-to-fn' was added to Emacs quite a while ago > > (1991[1]). lisp/ChangeLog.8 in the 25.3 tarball attributes the change to Inge Frick, with a date of 1999-09-14 (a couple days before the date listed in bug#25075). > > But it's not clear to me what it's really for, and there > > seem to be no uses of it in the distributed Emacs code, apart from > > `dired-do-copy', which just passes it on to `dired-create-files'. > > The variable's doc just says to "See HOW-TO argument for > > `dired-create-files'." > > > > So why was this variable created? Presumably it's so you could override dired's behavior for handling a target. If the target is a symlink to a directory, the default behavior would be to treat it as a directory, but maybe there are cases where you want to replace the link instead. The bit about If it return value is a list, TARGET is a generalized directory (e.g. some sort of archive). The first element of this list must be a function with at least four arguments: looks like it might be useful when the target is, for example, a tar file. By default, copying a single file would replace the tar file. But this could be overridden (I think) to add or replace entries in the tar file. Besides the possibility of a user setting dired-copy-how-to-fn, I can imagine a package might want to dynamically rebind dired-copy-how-to-fn, perhaps as a buffer-local variable in a dired buffer. (I'm not sure what sort of package might want to do that, but it seems like a possible reason for having a variable.) > I hoped that the code might throw some light on this variable, but: > > (defun dired-into-dir-with-symlinks (target) > (and (file-directory-p target) > (not (file-symlink-p target)))) > ;; This may not always be what you want, especially if target is your > ;; home directory and it happens to be a symbolic link, as is often the > ;; case with NFS and automounters. Or if you want to make symlinks > ;; into directories that themselves are only symlinks, also quite > ;; common. > > ;; So we don't use this function as value for HOW-TO in > ;; dired-do-symlink, which has the minor disadvantage of > ;; making links *into* a symlinked-dir, when you really wanted to > ;; *overwrite* that symlink. In that (rare, I guess) case, you'll > ;; just have to remove that symlink by hand before making your marked > ;; symlinks. > > (defvar dired-copy-how-to-fn nil > "Either nil or a function used by `dired-do-copy' to determine target. > See HOW-TO argument for `dired-do-create-files'.") > > It's still clear as mud to me. dired-into-dir-with-symlinks returns t if TARGET is a real directory. It returns nil if TARGET is a plain file or a symlink to a directory. The first generation automounter(s) mounted your home directory in a temporary directory and then created a symlink to the mounted directory. But $HOME would be the path to the symlink. > My interpretation of t is that all files you copy will up in the same > file if it's t, which is a supremely useless thing, you'd think... No, you can only copy one file if the target is a plain file. From earlier in the docstring for dired-do-create-files: The target may also be a non-directory file, if only one file is marked. Maybe this sentence should be deleted: Otherwise, the target is a plain file; an error is raised unless there is exactly one marked file. The way the docstring is currently written, it seems to imply that the error only gets raised in the case where HOW-TO is nil. I agree that this is all very complicated and confusing. It doesn't help that if HOW-TO is t, the target is treated as a plain file. But if HOW-TO is a function, it returns nil to indicate a plain file. mike ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#35367: 26.2; `dired-copy-how-to-fn' and HOW-TO arg of `dired-create-files' 2019-07-11 5:51 ` Mike Kupfer @ 2019-07-11 14:04 ` Lars Ingebrigtsen 2019-07-11 14:18 ` Drew Adams 2022-01-22 14:43 ` Lars Ingebrigtsen 2 siblings, 0 replies; 838+ messages in thread From: Lars Ingebrigtsen @ 2019-07-11 14:04 UTC (permalink / raw) To: Mike Kupfer; +Cc: 35367 Mike Kupfer <mkupfer@alum.berkeley.edu> writes: > Presumably it's so you could override dired's behavior for handling a > target. If the target is a symlink to a directory, the default behavior > would be to treat it as a directory, but maybe there are cases where you > want to replace the link instead. Ah, I see. [More useful explanation deleted; thanks for figuring it out.] >> My interpretation of t is that all files you copy will up in the same >> file if it's t, which is a supremely useless thing, you'd think... > > No, you can only copy one file if the target is a plain file. From > earlier in the docstring for dired-do-create-files: > > The target may also be a non-directory file, if only > one file is marked. > > Maybe this sentence should be deleted: > > Otherwise, the target is a plain file; > an error is raised unless there is exactly one marked file. > > The way the docstring is currently written, it seems to imply that the > error only gets raised in the case where HOW-TO is nil. > > I agree that this is all very complicated and confusing. It doesn't > help that if HOW-TO is t, the target is treated as a plain file. But if > HOW-TO is a function, it returns nil to indicate a plain file. Could you perhaps propose a rewrite of the doc string here to make it more understandable; both what it does and say when it might be useful? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#35367: 26.2; `dired-copy-how-to-fn' and HOW-TO arg of `dired-create-files' 2019-07-11 5:51 ` Mike Kupfer 2019-07-11 14:04 ` Lars Ingebrigtsen @ 2019-07-11 14:18 ` Drew Adams 2019-07-12 3:20 ` Mike Kupfer 2022-01-22 14:43 ` Lars Ingebrigtsen 2 siblings, 1 reply; 838+ messages in thread From: Drew Adams @ 2019-07-11 14:18 UTC (permalink / raw) To: Mike Kupfer, Lars Ingebrigtsen; +Cc: 35367 Thanks, Mike. I probably would never have figured out all of that. Kinda seems odd that we'd have created a variable for something that someone _might_ want to do (but probably never has done). Usually, when someone proposes something like that it gets rejected as fulfilling only a hypothetical need. Anyway, if the variable will stay then it would be great if the doc could be fixed a bit, based on some of what you said here. ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#35367: 26.2; `dired-copy-how-to-fn' and HOW-TO arg of `dired-create-files' 2019-07-11 14:18 ` Drew Adams @ 2019-07-12 3:20 ` Mike Kupfer 2019-07-12 3:33 ` Drew Adams 0 siblings, 1 reply; 838+ messages in thread From: Mike Kupfer @ 2019-07-12 3:20 UTC (permalink / raw) To: Drew Adams; +Cc: 35367, Lars Ingebrigtsen Drew Adams wrote: > Kinda seems odd that we'd have created a > variable for something that someone _might_ > want to do (but probably never has done). > > Usually, when someone proposes something > like that it gets rejected as fulfilling > only a hypothetical need. Indeed. Maybe there were consumers of dired-copy-how-to-fn back in the 1990s. While poking around in the sources I noticed a comment in vc-dir.el saying that it *used to be* based on dired. (Or maybe whoever was the Emacs maintainer at the time thought dired-copy-how-to-fn was a cool idea and didn't insist on having a consumer for it.) > Anyway, if the variable will stay then it > would be great if the doc could be fixed > a bit, based on some of what you said here. I can try proposing clearer wording for the dired-do-create-files docstring, though it'll probably be several days before I can get to it. I want to be cautious about proposing ways to use dired-copy-how-to-fn. My earlier comments were based on my reading of the documentation and a tiny bit of testing. I wasn't involved with Emacs development when the dired how-to stuff was introduced, so I don't have any special insights into what the thinking was at the time. Though the more I think about my tarfile example, the more I think it'd be a fun little hack. mike ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#35367: 26.2; `dired-copy-how-to-fn' and HOW-TO arg of `dired-create-files' 2019-07-12 3:20 ` Mike Kupfer @ 2019-07-12 3:33 ` Drew Adams 0 siblings, 0 replies; 838+ messages in thread From: Drew Adams @ 2019-07-12 3:33 UTC (permalink / raw) To: Mike Kupfer; +Cc: 35367, Lars Ingebrigtsen > > Kinda seems odd that we'd have created a > > variable for something that someone _might_ > > want to do (but probably never has done). > > > > Usually, when someone proposes something > > like that it gets rejected as fulfilling > > only a hypothetical need. > > Indeed. Maybe there were consumers of dired-copy-how-to-fn back in the > 1990s. While poking around in the sources I noticed a comment in > vc-dir.el saying that it *used to be* based on dired. (Or maybe whoever > was the Emacs maintainer at the time thought dired-copy-how-to-fn was a > cool idea and didn't insist on having a consumer for it.) > > > Anyway, if the variable will stay then it > > would be great if the doc could be fixed > > a bit, based on some of what you said here. > > I can try proposing clearer wording for the dired-do-create-files > docstring, though it'll probably be several days before I can get to it. > > I want to be cautious about proposing ways to use dired-copy-how-to-fn. > My earlier comments were based on my reading of the documentation and a > tiny bit of testing. I wasn't involved with Emacs development when the > dired how-to stuff was introduced, so I don't have any special insights > into what the thinking was at the time. Though the more I think about > my tarfile example, the more I think it'd be a fun little hack. Sounds good. I don't think you have to worry about hurrying. Instead of several days it could probably be several years (decades?) without anyone noticing. ;-) ^ permalink raw reply [flat|nested] 838+ messages in thread
* bug#35367: 26.2; `dired-copy-how-to-fn' and HOW-TO arg of `dired-create-files' 2019-07-11 5:51 ` Mike Kupfer 2019-07-11 14:04 ` Lars Ingebrigtsen 2019-07-11 14:18 ` Drew Adams @ 2022-01-22 14:43 ` Lars Ingebrigtsen 2 siblings, 0 replies; 838+ messages in thread From: Lars Ingebrigtsen @ 2022-01-22 14:43 UTC (permalink / raw) To: Mike Kupfer; +Cc: 35367 Mike Kupfer <mkupfer@alum.berkeley.edu> writes: > The bit about > > If it return value is a list, TARGET is a generalized > directory (e.g. some sort of archive). The first element of > this list must be a function with at least four arguments: > > looks like it might be useful when the target is, for example, a tar > file. By default, copying a single file would replace the tar file. > But this could be overridden (I think) to add or replace entries in the > tar file. I've now added something like this to the doc string in Emacs 29, and that should hopefully clarify the use case slightly. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 838+ messages in thread
[parent not found: <mailman.5042.1543777897.1284.help-gnu-emacs@gnu.org>]
* Re: using setq to create lists based on other lists... [not found] <mailman.5042.1543777897.1284.help-gnu-emacs@gnu.org> @ 2018-12-04 9:04 ` Barry Margolin 2018-12-04 13:56 ` Stefan Monnier ` (2 more replies) 0 siblings, 3 replies; 838+ messages in thread From: Barry Margolin @ 2018-12-04 9:04 UTC (permalink / raw) To: help-gnu-emacs In article <mailman.5042.1543777897.1284.help-gnu-emacs@gnu.org>, Robert Thorpe <rt@robertthorpeconsulting.com> wrote: > I've seen lots of beginners write programs that setq undefined symbols > and now I know why. There's nothing wrong with it in Emacs Lisp and a number of other Lisp dialects. I think Common Lisp was the first specification that made it questionable, but it was commonplace in the days of Maclisp, which is the dialect that Emacs Lisp is most directly descended from. -- Barry Margolin, barmar@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: using setq to create lists based on other lists... 2018-12-04 9:04 ` using setq to create lists based on other lists Barry Margolin @ 2018-12-04 13:56 ` Stefan Monnier 2018-12-05 1:07 ` Robert Thorpe [not found] ` <mailman.5145.1543931778.1284.help-gnu-emacs@gnu.org> 2 siblings, 0 replies; 838+ messages in thread From: Stefan Monnier @ 2018-12-04 13:56 UTC (permalink / raw) To: help-gnu-emacs > There's nothing wrong with it in Emacs Lisp Actually, there is in the sense that these are global variables and so can interfere with other Elisp packages. > and a number of other Lisp dialects. For most other Lisps what the user writes only creates havoc with its own code because each program runs in its own process. But Emacs being its own kind of OS the situation is a bit different. Of course similar situations occur with "Lisp machine" kind of systems (or Smalltalk machines, ...). Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: using setq to create lists based on other lists... 2018-12-04 9:04 ` using setq to create lists based on other lists Barry Margolin 2018-12-04 13:56 ` Stefan Monnier @ 2018-12-05 1:07 ` Robert Thorpe 2018-12-05 2:32 ` Drew Adams [not found] ` <mailman.5186.1543978155.1284.help-gnu-emacs@gnu.org> [not found] ` <mailman.5145.1543931778.1284.help-gnu-emacs@gnu.org> 2 siblings, 2 replies; 838+ messages in thread From: Robert Thorpe @ 2018-12-05 1:07 UTC (permalink / raw) To: Barry Margolin; +Cc: help-gnu-emacs Barry Margolin <barmar@alum.mit.edu> writes: > In article <mailman.5042.1543777897.1284.help-gnu-emacs@gnu.org>, > Robert Thorpe <rt@robertthorpeconsulting.com> wrote: > >> I've seen lots of beginners write programs that setq undefined symbols >> and now I know why. > > There's nothing wrong with it in Emacs Lisp and a number of other Lisp > dialects. I think Common Lisp was the first specification that made it > questionable, but it was commonplace in the days of Maclisp, which is > the dialect that Emacs Lisp is most directly descended from. Yes. But, there's still the issue of accidentally creating global variables. I think the modern learner will expect "setq" to do what "let" does unless told otherwise. BR, Robert Thorpe ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: using setq to create lists based on other lists... 2018-12-05 1:07 ` Robert Thorpe @ 2018-12-05 2:32 ` Drew Adams 2018-12-05 6:45 ` Jean-Christophe Helary [not found] ` <mailman.5186.1543978155.1284.help-gnu-emacs@gnu.org> 1 sibling, 1 reply; 838+ messages in thread From: Drew Adams @ 2018-12-05 2:32 UTC (permalink / raw) To: Robert Thorpe, Barry Margolin; +Cc: help-gnu-emacs > I think the modern learner will expect "setq" to > do what "let" does unless told otherwise. "Modern learner"... Why not just say Lisp learner? ;-) How/why is "the modern learner" different here from the learner of 2008, 1998, 1988, or 1978? (Or `68 or `58, for that matter?) Am I missing something? Lexically bound, "ordinary", local variables are as old as Fortran - nay, assembler. Nothing particularly modern about them, or about folks who are used to only them. They were even added to Lisp as long ago as the '70s (at least). Lisp is typically not a Lisp learner's first language. Gunk accumulated on eyeballs can need to be scraped off, to see more easily and clearly. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: using setq to create lists based on other lists... 2018-12-05 2:32 ` Drew Adams @ 2018-12-05 6:45 ` Jean-Christophe Helary 2018-12-05 8:00 ` Marcin Borkowski ` (2 more replies) 0 siblings, 3 replies; 838+ messages in thread From: Jean-Christophe Helary @ 2018-12-05 6:45 UTC (permalink / raw) To: help-gnu-emacs > On Dec 5, 2018, at 11:32, Drew Adams <drew.adams@oracle.com> wrote: > > Lisp is typically not a Lisp learner's first language. I'm straying off topic here but let me suggest that emacs could (and is) used by first learners and that the Introduction could be used as a Lisp manual for such people. Hence the need to clarify things and slightly bridge the gap between the Introduction and the Reference. There is nothing intrinsically difficult to emacs lisp, compared to a language (and ecosystem) like AppleScript that *is* advertised as a first learner language, even though both target the same class of people: users who need to do automation on their machine. That's exactly the spirit of what Stallman wrote when he referred to secretaries who were not conscious of doing "programming" but were still writing programs in Emacs. Jean-Christophe Helary ----------------------------------------------- http://mac4translators.blogspot.com @brandelune ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: using setq to create lists based on other lists... 2018-12-05 6:45 ` Jean-Christophe Helary @ 2018-12-05 8:00 ` Marcin Borkowski 2018-12-05 8:11 ` Jean-Christophe Helary 2018-12-05 14:57 ` Drew Adams [not found] ` <mailman.5218.1544021892.1284.help-gnu-emacs@gnu.org> 2 siblings, 1 reply; 838+ messages in thread From: Marcin Borkowski @ 2018-12-05 8:00 UTC (permalink / raw) To: Jean-Christophe Helary; +Cc: help-gnu-emacs On 2018-12-05, at 07:45, Jean-Christophe Helary <brandelune@gmail.com> wrote: >> On Dec 5, 2018, at 11:32, Drew Adams <drew.adams@oracle.com> wrote: >> >> Lisp is typically not a Lisp learner's first language. > > I'm straying off topic here but let me suggest that emacs could (and is) used by first learners and that the Introduction could be used as a Lisp manual for such people. > > Hence the need to clarify things and slightly bridge the gap between the Introduction and the Reference. > > There is nothing intrinsically difficult to emacs lisp, compared to a language (and ecosystem) like AppleScript that *is* advertised as a first learner language, even though both target the same class of people: users who need to do automation on their machine. > > That's exactly the spirit of what Stallman wrote when he referred to secretaries who were not conscious of doing "programming" but were still writing programs in Emacs. +1 to all Jean-Christophe says. And your emails make really want to get back to work on my intermediate Elisp textbook... (I have to finish another book I'm writing right now, especially that I'm a coauthor and expected to work rather hard on it.) Best, -- Marcin Borkowski http://mbork.pl ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: using setq to create lists based on other lists... 2018-12-05 8:00 ` Marcin Borkowski @ 2018-12-05 8:11 ` Jean-Christophe Helary 0 siblings, 0 replies; 838+ messages in thread From: Jean-Christophe Helary @ 2018-12-05 8:11 UTC (permalink / raw) To: help-gnu-emacs > On Dec 5, 2018, at 17:00, Marcin Borkowski <mbork@mbork.pl> wrote: > > And your emails make really want to get back to work on my intermediate > Elisp textbook... (I have to finish another book I'm writing right now, > especially that I'm a coauthor and expected to work rather hard on it.) Marcin, I'm actually working on a rewrite of the Introduction, as I progress through it. It's hard because I need to write code (and play with the kids, and work) more than I have time to read the book and write additional pages... I feel like a lot of attempts at writing introductions do not reach their objectives because they are written by people who do not remember how it was when they needed the introduction... That's my feeling when I read the Introduction, even though I have a lot of respect for what Chassell did with that book. Jean-Christophe Helary ----------------------------------------------- http://mac4translators.blogspot.com @brandelune ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: using setq to create lists based on other lists... 2018-12-05 6:45 ` Jean-Christophe Helary 2018-12-05 8:00 ` Marcin Borkowski @ 2018-12-05 14:57 ` Drew Adams [not found] ` <mailman.5218.1544021892.1284.help-gnu-emacs@gnu.org> 2 siblings, 0 replies; 838+ messages in thread From: Drew Adams @ 2018-12-05 14:57 UTC (permalink / raw) To: Jean-Christophe Helary, help-gnu-emacs > > Lisp is typically not a Lisp learner's first language. > > Emacs could (and is) used by first learners and ... > the Introduction could be used as a Lisp manual for > such people. Yes, of course. The point is that someone coming to Lisp from another language, especially (and typically) from a language where variables are essentially local & lexical, may have a harder time "getting it" than someone learning programming with Lisp as her first language. Things like list structure (including, yes, sharing structure), symbols (named objects with properties), dynamic scope/binding, `setq' (which can act on both global & local vars), and even REPL/interpretation can seem quite odd if you come to Lisp with only C or Java or ... eyes. Years ago I would have added higher-order and anonymous functions to the list. Even more years ago I would have added recursion to it. Depending on the languages you are used to, the list can vary. But Lisp is not C or Java or Haskell or ... FWIW, I came to Lisp (and to purely functional, logic-programming, and OOP languages) from Fortran. No recursion, no nothin' - nada. Another planet. But lots of variable-value/common-memory sharing. ^ permalink raw reply [flat|nested] 838+ messages in thread
[parent not found: <mailman.5218.1544021892.1284.help-gnu-emacs@gnu.org>]
* Re: using setq to create lists based on other lists... [not found] ` <mailman.5218.1544021892.1284.help-gnu-emacs@gnu.org> @ 2018-12-05 16:59 ` Barry Margolin 0 siblings, 0 replies; 838+ messages in thread From: Barry Margolin @ 2018-12-05 16:59 UTC (permalink / raw) To: help-gnu-emacs In article <mailman.5218.1544021892.1284.help-gnu-emacs@gnu.org>, Drew Adams <drew.adams@oracle.com> wrote: > > > Lisp is typically not a Lisp learner's first language. > > > > Emacs could (and is) used by first learners and ... > > the Introduction could be used as a Lisp manual for > > such people. > > Yes, of course. > > The point is that someone coming to Lisp from another > language, especially (and typically) from a language > where variables are essentially local & lexical, may > have a harder time "getting it" than someone learning > programming with Lisp as her first language. > > Things like list structure (including, yes, sharing > structure), symbols (named objects with properties), > dynamic scope/binding, `setq' (which can act on both > global & local vars), and even REPL/interpretation > can seem quite odd if you come to Lisp with only C > or Java or ... eyes. If you come to it from Java, JavaScript, or Python it actually shouldn't be that hard; they all pass data as references to structures. C and C++ are the only popular languages with explicit pointers. PHP is in between -- arrays are copied, but objects are not. -- Barry Margolin, barmar@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** ^ permalink raw reply [flat|nested] 838+ messages in thread
[parent not found: <mailman.5186.1543978155.1284.help-gnu-emacs@gnu.org>]
* Re: using setq to create lists based on other lists... [not found] ` <mailman.5186.1543978155.1284.help-gnu-emacs@gnu.org> @ 2018-12-05 16:50 ` Barry Margolin 0 siblings, 0 replies; 838+ messages in thread From: Barry Margolin @ 2018-12-05 16:50 UTC (permalink / raw) To: help-gnu-emacs In article <mailman.5186.1543978155.1284.help-gnu-emacs@gnu.org>, Drew Adams <drew.adams@oracle.com> wrote: > Lisp is typically not a Lisp learner's first language. It often was back in the days of Multics Emacs (30 years ago). It was pretty common for non-programmers to learn it so they could customize their editor. Although often they just learned enough to set a few customization variables, not write complex extensions; that's the kind of thing that's now automated with M-x customize. -- Barry Margolin, barmar@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** ^ permalink raw reply [flat|nested] 838+ messages in thread
[parent not found: <mailman.5145.1543931778.1284.help-gnu-emacs@gnu.org>]
* Re: using setq to create lists based on other lists... [not found] ` <mailman.5145.1543931778.1284.help-gnu-emacs@gnu.org> @ 2018-12-05 16:47 ` Barry Margolin 0 siblings, 0 replies; 838+ messages in thread From: Barry Margolin @ 2018-12-05 16:47 UTC (permalink / raw) To: help-gnu-emacs In article <mailman.5145.1543931778.1284.help-gnu-emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> wrote: > > There's nothing wrong with it in Emacs Lisp > > Actually, there is in the sense that these are global variables and so > can interfere with other Elisp packages. Declaring the variable with defvar won't change that. Anyway, the code we're talking about is just example snippets, not a full program. -- Barry Margolin, barmar@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** ^ permalink raw reply [flat|nested] 838+ messages in thread
[parent not found: <mailman.7307.1515801433.27995.help-gnu-emacs@gnu.org>]
* Re: info-find-source [not found] <mailman.7307.1515801433.27995.help-gnu-emacs@gnu.org> @ 2018-01-13 0:43 ` Emanuel Berg 2018-01-13 3:43 ` info-find-source Robert Thorpe ` (2 more replies) 0 siblings, 3 replies; 838+ messages in thread From: Emanuel Berg @ 2018-01-13 0:43 UTC (permalink / raw) To: help-gnu-emacs OK, there seems to be a bit of confusion here with respect to what I mean. So I'd like to clarify a few thing. That said, I'm not saying any of this to try to sway anyone. It is just my POV. First, I don't think info is bad in any way. Actually, I think it is very good! To have a uniform interface to documentation and to have people add new pieces to it, in a uniform way, which will then fit seamlessly, is great. I encourage everyone who has written a larger piece of software to do it, no doubt. Markup and interconnectivity, if that is a word, is also good. The man pages are both as well and I never felt the need to browse the groff source. That the documentation comes with Emacs, or is on-line (i.e., not on paper) - remember the terrible Sierra On-Line adventure games? - is also a good thing, even tho a web version is also good. And because of the uniformity one can easily use or write a tool that will translate info material into HTML or whatever format is desired. The issue I have with info is that it is easy to get lost when navigating all those node back and forth in the tree structure, back and forth in history, up to the parent and down to the child until you are stuck at a leaf and you still haven't found what you are looking for. And you do all this with keys that you do not use every day for editing. Compare this to the man pages where this never happens (because of less complexity), *or* a plain text files, where by definition it cannot ever happen. But doesn't this mean the files will be very long? Yes, and I don't have a problem with that as this volume is linear, not broken down into a complicated tree structure one has to traverse to get to the rainbow's end. The speed I've mentioned isn't the speed it takes to execute a command, it the the general speed of access, the human-computer interface if you will, which again per definition (unless your cognitive "humanity" differs from mine), this will be much, much faster with text because I edit text and code every day, using the same functions and finger-habits, and no matter how fluent an info user I'll ever be, it could never, ever match that. Also, how does info look to you guys? To me, it looks like this: http://user.it.uu.se/~embe8573/pics/info.png The problems getting an overview what's going on may be related to that, as well. -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: info-find-source 2018-01-13 0:43 ` info-find-source Emanuel Berg @ 2018-01-13 3:43 ` Robert Thorpe 2018-01-13 5:23 ` info-find-source Marcin Borkowski ` (2 more replies) 2018-01-13 5:17 ` info-find-source Marcin Borkowski [not found] ` <mailman.7313.1515820700.27995.help-gnu-emacs@gnu.org> 2 siblings, 3 replies; 838+ messages in thread From: Robert Thorpe @ 2018-01-13 3:43 UTC (permalink / raw) To: Emanuel Berg; +Cc: help-gnu-emacs Emanuel Berg <moasen@zoho.com> writes: > The speed I've mentioned isn't the speed it > takes to execute a command, it the the general > speed of access, the human-computer interface > if you will, which again per definition (unless > your cognitive "humanity" differs from mine), > this will be much, much faster with text > because I edit text and code every day, using > the same functions and finger-habits, and no > matter how fluent an info user I'll ever be, it > could never, ever match that. I don't understand what you mean. I usually don't understand what you mean in these type of situations. Info has it's own keybindings. That can be a little tricky, since "s" is the normal way to search rather than "C-s" or "M-s". You can rebind these functions though. > Also, how does info look to you guys? To me, it > looks like this: > > http://user.it.uu.se/~embe8573/pics/info.png If you use Emacs in a GUI environment then there is more markup. Some things are in bold and some are in larger fonts. I generally think this is useful, but opinions differ. BR, Robert Thorpe ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: info-find-source 2018-01-13 3:43 ` info-find-source Robert Thorpe @ 2018-01-13 5:23 ` Marcin Borkowski 2018-01-13 16:31 ` info-find-source Drew Adams 2018-01-13 15:50 ` info-find-source Drew Adams [not found] ` <mailman.7314.1515821013.27995.help-gnu-emacs@gnu.org> 2 siblings, 1 reply; 838+ messages in thread From: Marcin Borkowski @ 2018-01-13 5:23 UTC (permalink / raw) To: Robert Thorpe; +Cc: help-gnu-emacs, Emanuel Berg On 2018-01-13, at 04:43, Robert Thorpe <rt@robertthorpeconsulting.com> wrote: > Info has it's own keybindings. That can be a little tricky, since "s" > is the normal way to search rather than "C-s" or "M-s". You can rebind > these functions though. I didn't know that! I used to use C-s/C-r in Info all the time. They _do_ work there! Then, maybe a year or two ago, I learned about the index and the `i' keystroke, and now I can't understand how I used Info before. Also, `C-h S', by the way. I would really like it if someone set up a contest of "how fast can someone use Info to search for things and come back to other things and not get distracted by links and/or writing one's own functions to do what you can do with stock Emacs better", and made Emanuel and me the contestants. ;-) Best, -- Marcin Borkowski ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: info-find-source 2018-01-13 5:23 ` info-find-source Marcin Borkowski @ 2018-01-13 16:31 ` Drew Adams 2018-01-14 7:03 ` info-find-source Marcin Borkowski 0 siblings, 1 reply; 838+ messages in thread From: Drew Adams @ 2018-01-13 16:31 UTC (permalink / raw) To: Marcin Borkowski, Robert Thorpe; +Cc: help-gnu-emacs, Emanuel Berg > I would really like it if someone set up a contest of "how fast can > someone use Info to search for things and come back to other things and > not get distracted by links and/or writing one's own functions to do > what you can do with stock Emacs better", and made Emanuel and me the > contestants. What I find most useful for finding stuff: `i', combined with better pattern-matching for the index-entry completion candidates. I use Icicles. That means that index entries, which are what `i' completes your minibuffer contents to, can be matched with regexps, including just substrings. In Icicle mode, `i' is bound to command `icicle-Info-index'. Besides giving you better pattern-matching, you can optionally have it highlight index-entry candidates in *Completions* that correspond to already-visited nodes. That way, you don't end up trying multiple index entries in hopes of getting to some nodes you haven't already checked out. (Wrt seeing which nodes you've visited by link color, face `info-xref-visited' helps, but if you want that indication to persist across Emacs sessions you can get that (togglable anytime) with `info+.el' minor mode `Info-persist-history-mode'.) Even just substring matching makes `i' much, much more useful, IMO. (And yes, you can set vanilla Emacs to use substring matching for `i'. If you don't use Icicles or similar then this is a good workaround/substitute.) With Icicles you can incrementally match any number of simple patterns (progressive completion), which is much simpler and quicker than trying to come up with a single regexp to match what you need. (Not to mention more powerful, as a single regexp is limited in terms of what it matches.) You can also match the complements of patterns. Beyond pattern-matching and indicated previously visited nodes, `icicle-Info-index' is a multi-command, which means that you can, with a single invocation, visit any number of nodes, matching any patterns, in any order. Icicles also enhances other Info commands, in particular `g'. When you use it you can optionally match node names or node _content_, or both at once. https://www.emacswiki.org/emacs/Icicles_-_Info_Enhancements https://www.emacswiki.org/emacs/Icicles_-_Nutshell_View#ProgressiveCompletion ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: info-find-source 2018-01-13 16:31 ` info-find-source Drew Adams @ 2018-01-14 7:03 ` Marcin Borkowski 2018-01-16 23:10 ` info-find-source Drew Adams 0 siblings, 1 reply; 838+ messages in thread From: Marcin Borkowski @ 2018-01-14 7:03 UTC (permalink / raw) To: Drew Adams; +Cc: help-gnu-emacs, Emanuel Berg, Robert Thorpe On 2018-01-13, at 17:31, Drew Adams <drew.adams@oracle.com> wrote: >> I would really like it if someone set up a contest of "how fast can >> someone use Info to search for things and come back to other things and >> not get distracted by links and/or writing one's own functions to do >> what you can do with stock Emacs better", and made Emanuel and me the >> contestants. > > What I find most useful for finding stuff: `i', combined > with better pattern-matching for the index-entry > completion candidates. > > I use Icicles. That means that index entries, which > are what `i' completes your minibuffer contents to, > can be matched with regexps, including just substrings. I stopped using Icicles, since I did not use it often enough to memorize all the cool stuff in there; also, it was not as fast as I wanted. I switched to Ivy, which is definitely less powerful, but good enough for me, and much faster than Icicles. In Ivy, if you search for "abc xyz", it basically transforms it to "abc.*xyz" under the hood. Very useful, and covers 99% of my use cases. Still, I do appreciate Icicles - I just don't really need its power (or at least I haven't yet discovered that I do;-)). Best, -- Marcin Borkowski ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: info-find-source 2018-01-14 7:03 ` info-find-source Marcin Borkowski @ 2018-01-16 23:10 ` Drew Adams 0 siblings, 0 replies; 838+ messages in thread From: Drew Adams @ 2018-01-16 23:10 UTC (permalink / raw) To: Marcin Borkowski; +Cc: help-gnu-emacs, Emanuel Berg, Robert Thorpe [-- Attachment #1: Type: text/plain, Size: 5211 bytes --] >> What I find most useful for finding stuff: `i', >> combined with better pattern-matching for the >> index-entry completion candidates. Further in that post I said "Icicles or similar" to characterize such "better pattern-matching". My point was that key `i' is typically the best way (IMO) to find stuff in Info. And its power is greatly increased by libraries that provide better pattern-matching than what is offered by vanilla Emacs. Icicles is one such library. >> I use Icicles. That means that index entries, >> which are what `i' completes your minibuffer >> contents to, can be matched with regexps, >> including just substrings. > > I stopped using Icicles... I switched to Ivy, which > is definitely less powerful, but good enough... If you prefer this or that or you don't use/need this or that, that's fine. Wrt Icicles and other pattern-matching libraries, FWIW: When Icicles started exploring completion and what could be done with it there was essentially nothing besides vanilla-Emacs completion, which was itself coded only in C (no `minibuffer.el' library yet, no `completion-styles' - just basic prefix completion). And completion wasn't used much in Emacs - mainly just for file-finding, buffer-switching, and `M-x'. IswitchB was the only completion-related thing that did something interesting before Icicles. Well, there was also `icomplete.el', which incrementally showed you some input completions, but you couldn't do anything with them except use them as a guide for what to continue typing. Over time many Icicles features have been introduced into new packages (Ido, Helm/Anything, Ivy) - years later. Ivy apparently introduced `ivy-occur'/`swiper' in 2015. Icicles introduced it (as `icicle-occur') in 2006 (along with `icicle-search': same, but with regexp-defined search contexts, not just lines). That's all good, not bad. "Imitation...flattery." Icicles has introduced original ideas/features, including: incremental completion (matches updated as you type), help on individual completion candidates, multi-commands (multiple actions on multiple candidates), progressive completion (narrowing, successive search patterns), match complementing, multi-completions (matching multiple things together - e.g. file names & contents), cycling candidates, sorting candidates on the fly, saving completion matches & combining them using set operations, key completion (which also shows the keys currently available), fuzzy completion, using completion for search... Some Icicles ideas might be hare-brained or half-baked. Some that I originally thought were probably crazy have turned out to be among the most useful. Others I thought might be more useful were not so. Any or all of them could be implemented in different, some better, ways. And different UIs could be used to present them to users. And there are bugs to be fixed... If another package picks up this or that Icicles idea and implements it faster or in an easier-to-use way than what Icicles provides that's a good thing, not a bad thing. Improvement is good. One of the explicit purposes of Icicles, from the outset, has been to serve as food for thought and experiment (for me, in particular). The existence of Helm (formerly Anything) and Ivy is, among other things, a testament to the usefulness of Icicles ideas - at least some of them ;-). Other Icicles ideas have found their way to vanilla Emacs and to other of my libraries: Isearch+, Info+, Bookmark+, Dired+, LaCarte, highlight.el, mouse3.el, palette.el, synonyms.el, ucs-cmds.el. > since I did not use it often enough to memorize all > the cool stuff in there; There's really nothing to memorize. But perhaps the first thing is to know how to ask it. * `S-TAB', to see all currently available keys and their commands (navigate the key hierarchy, including menus). * `M-?' during minibuffer input for general help, with links to the complete help - in local files and on the Web - and with links to customizing the Icicles options & faces. The `M-?' help also gives you the current status of options, and (linked) key-sequences to change status on the fly. See attached, and imagine that the commands and keys shown there are links that perform their actions. If someone can't remember `M-?' then s?he can find it in menu-bar `Icicles > Icicles Help' anytime. > In Ivy, if you search for "abc xyz", it basically > transforms it to "abc.*xyz" under the hood. Very > useful, and covers 99% of my use cases. Same with Icicles, FWIW. That's one of the 7 "fuzzy" completion methods it supports, besides regexp matching and vanilla `completion-styles'. You can make it your default method or choose it or another using `M-('. > Still, I do appreciate Icicles - I just don't > really need its power (or at least I haven't yet > discovered that I do;-)). You probably don't "need" most of what Emacs or Lisp has to offer either. Few (none?) of us do. It's available on demand, for when you do. It doesn't bother you when you don't. Same for Icicles, I hope. [-- Attachment #2: general-help.txt --] [-- Type: text/plain, Size: 50349 bytes --] [Icicles Help on the Web] [Icicles Doc, Part 1] [Icicles Options & Faces] [Icicles Doc, Part 2] You are completing input for an Icicles multi-command. To show help on individual candidates: Current candidate C-M-RET, C-M-mouse-2 Next, previous candidate C-M-down, C-M-up, C-M- plus mouse wheel prefix-match candidate C-M-end, C-M-home apropos-match candidate C-M-next, C-M-prior To act on individual candidates: Current candidate C-RET, C-mouse-2 Next, previous candidate C-down, C-up, C- plus mouse wheel prefix-match candidate C-end, C-home apropos-match candidate C-next, C-prior All candidates at once C-! (each) or M-! (list) Delete object named by candidate S-delete Object-action: apply a fn to candidate M-RET For alt action, use `C-S-' instead of `C-', but use `C-|' or `M-|', instead of `C-!' or `M-!', to act on all. Icicles Minibuffer Completion ----------------------------- Completion indicators: Mode line `Icy' lighter (additive): red = Completion available (use `TAB' or `S-TAB' to complete) + = Multi-command completion (use `C-RET' to act on candidate) || = Multi-completion candidates (use `C-M-j' to separate parts) ... = `icicle-max-candidates' shown (use `C-x #' to change) Prompt prefix (exclusive): . = Simple completion + = Multi-command completion You can complete your minibuffer input in several ways. These are the main Icicles actions and their minibuffer key bindings: * Show Icicles minibuffer help (this). M-? For help on individual completion candidates, see "Show help on individual completion candidates", below. * Abandon or commit your input. Abandon input C-g Commit input to Emacs RET Complete partial input, then commit S-return * Toggle/cycle Icicles options on the fly. Key: Currently: Highlighting of past inputs C-pause yes Highlighting of saved candidates M-i s yes Showing candidates with WYSIWYG M-i w yes Removal of duplicate candidates M-i $ no Sort order C-, alphabetical Alternative sort order M-, by previous use alphabetically Swap alternative/normal sort M-i M-, Case sensitivity M-i A yes `.' matching newlines too (any char) M-i M-. no Escaping of special regexp chars C-` no Incremental completion M-i # yes, if *Completions* showing Input expansion to common match (toggle)M-i " yes Input expansion to common match (cycle) M-i M-" always Hiding common match in `*Completions*' C-x . no Hiding no-match lines in `*Completions*' C-u C-x . no Horizontal/vertical candidate layout C-M-^ horizontal Completion-mode keys M-i TAB unchanged S-TAB completion method M-( apropos TAB completion method C-( vanilla Vanilla completion style set (E23+) C-M-( nil Showing image-file thumbnails (E22+) C-x t image and name Showing candidate annotations C-x C-a yes Inclusion of proxy candidates C-M-_ no Ignoring certain file extensions M-i . yes Expansion of directory candidates C-x / no Checking for remote file names C-^ yes Considering network drives as remote C-x : yes Ignoring space prefix for buffer names M-_ yes Using `C-' for multi-command actions M-g yes Using `~' for your home directory M-~ yes `icicle-search' all-current highlights C-^ no Whole-word searching M-q no Removal of `icicle-search' highlighting M-i . yes Replacement of whole search hit M-_ yes Replacement of expanded common match M-; yes Searching complements of contexts M-i ~ no * Regexp-quote input, then apropos-complete M-% * Change the set of completion candidates. Modify your input. Edit your input (just edit in minibuffer) Erase your input (clear minibuffer) M-k Goto/kill non-matching portion of input C-M-l Retrieve previous completion inputs C-l, C-S-l Match another regexp (chaining) M-* Satisfy another predicate (chaining) M-& Remove a candidate from set of matches delete, S-mouse-2 Yank text at cursor into minibuffer M-. Insert text (string) from a variable C-= Insert `icicle-list-join-string' C-M-j Insert previously entered input(s) M-o Insert completion candidates(s) M-r Insert key description (key completion) M-q * Complete your current input in the minibuffer. Apropos (regexp) completion backtab Without displaying candidates C-M-S-TAB Complete and match another regexp S-SPC Prefix completion As much as possible TAB Without displaying candidates C-M-tab A word at a time M-SPC Complete and commit S-return Complete search string using past input backtab * Display/navigate completions for current input (in `*Completions*'). Show completion candidates Prefix completion TAB (repeat) Apropos completion backtab Move between minibuffer and list C-insert Cycle among completion candidates right, left, TAB, backtab Within a `*Completions*' column down, up Choose a completion candidate RET, M-x mouse-choose-completion * Cycle among input candidates. Completion candidates Current mode down, up, mouse wheel Prefix completion end, home Apropos completion next, prior Minibuffer history items M-n, M-p Completion history items C-l, C-S-l * Show help on individual completion candidates. Current candidate C-M-RET, C-M-mouse-2 Next, previous candidate C-M-down, C-M-up, C-M- plus mouse wheel prefix-match candidate C-M-end, C-M-home apropos-match candidate C-M-next, C-M-prior * Choose a previous input from the minibuffer history. Complete to insert a previous input M-o Complete against history items M-h, M-pause Restrict candidates to history items M-pause Change to another history C-M-pause List history items first in Completions M-i M-, Cycle among minibuffer history items M-n, M-p * Delete history entries Delete current entry (cycling) M-k Delete any or all entries M-K * Multi-commands: Act on completion candidates. For alternative action, use `C-S-' instead of `C-', but `C-|' and `M-|' are alternative action versions of `C-!' and `M-!'. Current candidate C-RET, C-mouse-2 Next, previous candidate C-down, C-up, C- with mouse wheel prefix-match candidate C-end, C-home apropos-match candidate C-next, C-prior Act on each matching candidate, in turn C-! Act on the list of matching candidates M-! Delete object named by candidate S-delete Remove candidate from set of matches delete, S-mouse-2 Save candidate (add to those saved) insert, M-S-mouse-2 Object-action: apply a fn to candidate M-RET * Act on multiple minibuffer inputs M-R * Search and replace (e.g. `C-c `'). See also `icicle-search'. Use action keys (prefix `C-') to navigate. Use alternative action keys (prefix `C-S-') to replace matches. Toggle input highlighting at all hits C-^ Toggle whole-word searching M-q Toggle `.' matching newlines too M-i M-. Toggle escaping of special regexp chars C-` Toggle removal of search highlighting M-i . Replace all M-| Redefine the replacement string M-, Toggle literal replacement M-i ` Toggle replacement of whole search hit M-_ Toggle replacement of common match M-; * Perform set operations on candidate sets. Remove candidate from current set delete, S-mouse-2 Add current candidate to saved set insert, M-S-mouse-2 Retrieve saved candidates from... `icicle-saved-completion-candidates' C-M-< another variable C-M-{ a cache file C-{ Retrieve more saved candidates C-< Save candidates in current set to... `icicle-saved-completion-candidates' C-M-> another variable C-M-} a cache file C-} Save more candidates to current set C-> Save, save more selected candidates C-M-), C-) with region Save multiple minibuffer inputs M-S Clear all saved candidates C-M-) with empty region Add new or update existing saved set M-x icicle-add/update-saved-completion-set Remove a saved completion set M-x icicle-remove-saved-completion-set Swap current and saved sets C-% Define current set by evaluating sexp C-: Restrict candidates to history items M-pause Set complement C-~ Set difference C-- Set union C-+ Set intersection C-* Set intersection using regexp M-* Set intersection using predicate M-& Save current predicate to a variable C-M-& Insert string variable as input C-= * Adjust Icicles options incrementally on the fly (uses Do Re Mi). `icicle-candidate-width-factor' C-x w `icicle-max-candidates' C-x # `icicle-swank-timeout' C-x 1 `icicle-swank-prefix-length' C-x 2 `icicle-inter-candidates-min-spaces' C-x | Zoom `*Completions*' (not an option) C-x - (Emacs 23+) Remember: You can always input any character (e.g. TAB) that is bound to a command by preceding it with C-q. Though it has no direct connection with completion, you can use `M-:' in the minibuffer at any time to evaluate an Emacs-Lisp expression. This calls `icicle-pp-eval-expression-in-minibuffer', which displays the result in the echo area or a popup buffer, *Pp Eval Output*. It also provides some of the Emacs-Lisp key bindings during expression editing. \f Customize Icicles: `M-x icicle-customize-icicles-group'. Summary of customizable options and faces (alphabetical order). Some of the options can be toggled or cycled - the keys for this are noted in parentheses. * `case-fold-search', `completion-ignore-case', (`C-u') `read-file-name-completion-ignore-case' - Case sensitivity? (`C-A') * `completion-ignored-extensions' - Ignored filenames (`C-.') * `icicle-act-before-cycle-flag' - Act then cycle or reverse? * `icicle-add-proxy-candidates-flag' - Include proxies? (`C-M-_') * `icicle-alternative-actions-alist' - Overriding alt actions * `icicle-alternative-sort-comparer' - Other sort (`M-,', `C-M-,') * `icicle-apropos-complete-keys*' - Keys to apropos-complete * `icicle-apropos-cycle-*-keys' - Keys to apropos-cycle * `icicle-bookmark-name-length-max' - Max length of bookmark name * `icicle-bookmark-refresh-cache-flag' - Refresh bookmarks cache? * `icicle-top-level-key-bindings' - Bind top-level commands * `icicle-buffer-*' - `icicle-buffer' options * `icicle-candidate-width-factor' - Width %%, candidate columns * `icicle-change-region-background-flag' - Change region color? * `icicle-change-sort-order-completion' - Control `C-,' behavior * `icicle-C-l-uses-completion-flag' - `C-l' uses completion? * `icicle-color-themes' - For `icicle-color-theme' * `icicle-comint-dynamic-complete-replacements' - Comint complete fns * `icicle-command-abbrev*' - Command abbrev behavior * `icicle-complete-key-anyway-flag' - `S-TAB' must complete keys * `icicle-complete-keys-self-insert-ranges'- `S-TAB' for self-insert? * `icicle-completing-read+insert-keys' - Keys for complete-on-demand * `icicle-completion-history-max-length' - Completion history length * `icicle-completion-key-bindings' - minibuffer completion keys * `icicle-completion-list-key-bindings' - `*Completions*' bindings * `icicle-Completions-display-min-input-chars'- Remove `*Completions*' if fewer chars input * `icicle-completions-format' - `*Completions*' layout * `icicle-move-Completions-frame' - `*Completions*' at edge? * `icicle-Completions-text-scale-decrease'- `*Completions*' shrink * `icicle-Completions-window-max-height' - Max lines, `*Completions*' * `icicle-customize-save-flag' - Save some options on quit? * `icicle-default-cycling-mode' - Default completion mode for per-mode cycling * `icicle-default-thing-insertion' - Control behavior of M-. * `icicle-default-value' - How to treat default value * `icicle-define-alias-commands-flag' - Define top-level aliases? * `icicle-deletion-action-flag' - `S-delete' deletes? * `icicle-dot-show-regexp-flag' - Show regexp for `.'? * `icicle-dot-string' - String that `.' inserts * `icicle-expand-input-to-common-match' - Expand your input? (`C-M-"') * `icicle-expand-input-to-common-match-alt' - Expand your input? (`C-"') * `icicle-file-*' - `icicle-file' options * `icicle-filesets-as-saved-completion-sets-flag'- Use filesets? * `icicle-guess-commands-in-path' - Shell commands to complete * `icicle-help-in-mode-line-delay' - Secs to show candidate help * `icicle-hide-common-match-in-Completions-flag'- Show common match? * `icicle-hide-non-matching-lines-flag' - Hide non-match lines? * `icicle-highlight-historical-candidates-flag' - Highlight past input? * `icicle-highlight-input-completion-failure*'- Input non-match sign * `icicle-highlight-input-initial-whitespace-flag' - Highlight input whitespace? * `icicle-highlight-lighter-flag' - Highlight mode-line `Icy' * `icicle-incremental-completion' - Icompletion? (`C-#') * `icicle-incremental-completion-delay' - Delay before update cands * `icicle-incremental-completion-threshold'- # of candidates for delay * `icicle-inhibit-advice-functions' - Advice-inhibited functions * `icicle-inhibit-ding-flag' - Suppress audible bell * `icicle-input-string' - String inserted by `C-=' * `icicle-inter-candidates-min-spaces' - Min spaces among candidates * `icicle-isearch-complete-keys' - Keys to complete search * `icicle-key-complete-keys' - Keys to complete keys * `icicle-key-descriptions-use-<>-flag' - Show key names with "<>"? * `icicle-keymaps-for-key-completion' - `S-TAB' = key-complete maps * `icicle-kmacro-ring-max' - Icicles `kmacro-ring-max' * `icicle-levenshtein-distance' - Levenshtein match distance * `icicle-list-join-string' - Multi-completion join * `icicle-list-nth-parts-join-string' - Join split-candidate parts * `icicle-mark-position-in-candidate' - Mark position in cycling * `icicle-menu-items-to-history-flag' - Add menus to history? * `icicle-minibuffer-key-bindings' - general minibuffer keys * `icicle-minibuffer-setup-hook' - Functions run after setup * `icicle-modal-cycle-*-keys' - Keys for modal cycling * `icicle-option-type-prefix-arg-list' - Prefix-args for `C-h C-o' * `icicle-point-position-in-candidate' - Cursor position in cycling * `icicle-populate-interactive-history-flag'- Track interactive use? * `icicle-pp-eval-expression-print-*' - Print control for `pp-*' * `icicle-prefix-complete-keys*' - Keys to prefix-complete * `icicle-prefix-cycle-*-keys' - Keys to prefix-cycle * `icicle-quote-shell-file-name-flag' - Quote file name in shell? * `icicle-read+insert-file-name-keys' - Keys for on-demand file * `icicle-regexp-quote-flag' - Escape chars? (`C-`') * `icicle-regexp-search-ring-max' - `regexp-search-ring-max' * `icicle-region-background' - Background for region * `icicle-require-match-flag' - Override REQUIRE-MATCH? * `icicle-saved-completion-sets' - Completion sets for `C-M-<' * `icicle-search-cleanup-flag' - Remove search highlighting? (`C-.') * `icicle-search-from-isearch-keys' - Isearch-to-Icicles keys * `icicle-search-highlight-all-current-flag'- In each hit (`C-^') * `icicle-search-highlight-context-levels-flag' - Highlight match subgroups? * `icicle-search-highlight-threshold' - # hits to highlight at once * `icicle-search-hook' - Functions run by `C-c `' * `icicle-search-replace-common-match-flag' - Replace ECM? (`M-;') * `icicle-search-replace-literally-flag' - Replace text literally? * `icicle-search-replace-whole-candidate-flag' - Replace input match or whole search hit?(`M-_') * `icicle-search-ring-max' - Icicles `search-ring-max' * `icicle-search-whole-word-flag' - Find whole words? (`M-q') * `icicle-show-Completions-help-flag' - Show `*Completions*' help? * `icicle-show-Completions-initially-flag'- Show `*Completions*' 1st? * `icicle-show-multi-completion-flag' - Show extra candidate info? * `icicle-sort-comparer' - Sort candidates (`C-,') * `icicle-sort-orders-alist' - Predicates for sorting * `icicle-special-candidate-regexp' - To highlight special cands * `icicle-S-TAB-completion-methods-alist'- `S-TAB' methods (`M-(') * `icicle-swank-*' - Swank completion control * `icicle-TAB-completion-methods' - `TAB' methods (`C-(') * `icicle-TAB-shows-candidates-flag' - 1st `TAB' shows candidates? * `icicle-test-for-remote-files-flag' - Check remote files? (`C-^') * `icicle-thing-at-point-functions' - Functions to yank things * `icicle-top-level-key-bindings' - Top-level key bindings * `icicle-top-level-when-sole-completion-*'- Exiting if one completion * `icicle-touche-pas-aux-menus-flag' - Add to standard menus? * `icicle-transform-function' - Remove duplicates (`C-$') * `icicle-type-actions-alist' - Objects and their types * `icicle-unpropertize-completion-result-flag'- Properties in result? * `icicle-update-input-hook' - Fns run when input changes * `icicle-use-~-for-home-dir-flag' - Use `~' for $HOME? (`M-~') * `icicle-use-C-for-actions-flag' - `C-' for actions? (`M-g') * `icicle-use-candidates-only-once-flag' - Remove used candidate? * `icicle-word-completion-keys' - Keys for word completion * `icicle-WYSIWYG-Completions-flag' - WYSIWYG `*Completions*'? * `icicle-yank-function' - Yank function to use Faces that highlight input in minibuffer. * `icicle-complete-input' - Input when it is complete * `icicle-completion' - Completing? * `icicle-input-completion-fail*' - Non-match part of input * `icicle-match-highlight-minibuffer' - Matched part of input * `icicle-multi-command-completion' - Multi-command completion? * `icicle-mustmatch-completion' - Strict completion? * `icicle-whitespace-highlight' - Initial whitespace in input Faces that highlight candidates in buffer `*Completions*'. * `icicle-candidate-part' - Part of candidate * `icicle-common-match-highlight-Completions' - Max common substring * `icicle-current-candidate-highlight' - Current candidate (cycling) * `icicle-extra-candidate' - Extra candidate * `icicle-historical-candidate' - Highlight candidates used * `icicle-match-highlight-Completions' - Matched part of input * `icicle-proxy-candidate' - Proxy candidate * `icicle-saved-candidate' - Saved candidate * `icicle-special-candidate' - Special candidate Faces that highlight information in the mode line. * `icicle-completion' - Completing? * `icicle-mode-line-help' - Candidate help * `icicle-multi-command-completion' - Multi-command completion? * `icicle-mustmatch-completion' - Strict completion? Faces that highlight for command `icicle-search'. * `icicle-search-context-level-*' - Regexp subgroup highlighting * `icicle-search-current-input' - What input matches * `icicle-search-main-regexp-current' - Current match of 1st regexp * `icicle-search-main-regexp-others' - Other matches of 1st regexp Icicle mode defines many top-level commands. For a list, see the Commentary headers of files `icicles-cmd1.el' and `icicles-cmd2.el'. \f These are all of the top-level bindings in Icicle mode: key binding --- ------- C-c Prefix Command C-h Prefix Command C-x Prefix Command ESC Prefix Command <S-f10> icicle-complete-menu-bar <S-f4> icicle-kmacro <f10> lacarte-execute-menu-command <pause> icicle-switch-to/from-minibuffer <remap> Prefix Command <remap> <abort-recursive-edit> icicle-abort-recursive-edit <remap> <apropos> icicle-apropos <remap> <apropos-command> icicle-apropos-command <remap> <apropos-user-option> icicle-apropos-option <remap> <apropos-value> icicle-apropos-value <remap> <apropos-zippy> icicle-apropos-zippy <remap> <bmkp-all-tags-jump> icicle-bookmark-all-tags <remap> <bmkp-all-tags-jump-other-window> icicle-bookmark-all-tags-other-window <remap> <bmkp-all-tags-regexp-jump> icicle-bookmark-all-tags-regexp <remap> <bmkp-all-tags-regexp-jump-other-window> icicle-bookmark-all-tags-regexp-other-window <remap> <bmkp-autofile-all-tags-jump> icicle-bookmark-autofile-all-tags <remap> <bmkp-autofile-all-tags-jump-other-window> icicle-bookmark-autofile-all-tags-other-window <remap> <bmkp-autofile-all-tags-regexp-jump> icicle-bookmark-autofile-all-tags-regexp <remap> <bmkp-autofile-all-tags-regexp-jump-other-window> icicle-bookmark-autofile-all-tags-regexp-other-window <remap> <bmkp-autofile-jump> icicle-bookmark-autofile <remap> <bmkp-autofile-jump-other-window> icicle-bookmark-autofile-other-window <remap> <bmkp-autofile-set> icicle-bookmark-a-file <remap> <bmkp-autofile-some-tags-jump> icicle-bookmark-autofile-some-tags <remap> <bmkp-autofile-some-tags-jump-other-window> icicle-bookmark-autofile-some-tags-other-window <remap> <bmkp-autofile-some-tags-regexp-jump> icicle-bookmark-autofile-some-tags-regexp <remap> <bmkp-autofile-some-tags-regexp-jump-other-window> icicle-bookmark-autofile-some-tags-regexp-other-window <remap> <bmkp-autonamed-jump> icicle-bookmark-autonamed <remap> <bmkp-autonamed-jump-other-window> icicle-bookmark-autonamed-other-window <remap> <bmkp-autonamed-this-buffer-jump> icicle-bookmark-autonamed-this-buffer <remap> <bmkp-bookmark-file-jump> icicle-bookmark-bookmark-file <remap> <bmkp-bookmark-list-jump> icicle-bookmark-bookmark-list <remap> <bmkp-bookmark-set-confirm-overwrite> icicle-bookmark-cmd <remap> <bmkp-desktop-jump> icicle-bookmark-desktop <remap> <bmkp-dired-jump> icicle-bookmark-dired <remap> <bmkp-dired-jump-other-window> icicle-bookmark-dired-other-window <remap> <bmkp-file-all-tags-jump> icicle-bookmark-file-all-tags <remap> <bmkp-file-all-tags-jump-other-window> icicle-bookmark-file-all-tags-other-window <remap> <bmkp-file-all-tags-regexp-jump> icicle-bookmark-file-all-tags-regexp <remap> <bmkp-file-all-tags-regexp-jump-other-window> icicle-bookmark-file-all-tags-regexp-other-window <remap> <bmkp-file-jump> icicle-bookmark-file <remap> <bmkp-file-jump-other-window> icicle-bookmark-file-other-window <remap> <bmkp-file-some-tags-jump> icicle-bookmark-file-some-tags <remap> <bmkp-file-some-tags-jump-other-window> icicle-bookmark-file-some-tags-other-window <remap> <bmkp-file-some-tags-regexp-jump> icicle-bookmark-file-some-tags-regexp <remap> <bmkp-file-some-tags-regexp-jump-other-window> icicle-bookmark-file-some-tags-regexp-other-window <remap> <bmkp-file-this-dir-all-tags-jump> icicle-bookmark-file-this-dir-all-tags <remap> <bmkp-file-this-dir-all-tags-jump-other-window> icicle-bookmark-file-this-dir-all-tags-other-window <remap> <bmkp-file-this-dir-all-tags-regexp-jump> icicle-bookmark-file-this-dir-all-tags-regexp <remap> <bmkp-file-this-dir-all-tags-regexp-jump-other-window> icicle-bookmark-file-this-dir-all-tags-regexp-other-window <remap> <bmkp-file-this-dir-jump> icicle-bookmark-file-this-dir <remap> <bmkp-file-this-dir-jump-other-window> icicle-bookmark-file-this-dir-other-window <remap> <bmkp-file-this-dir-some-tags-jump> icicle-bookmark-file-this-dir-some-tags <remap> <bmkp-file-this-dir-some-tags-jump-other-window> icicle-bookmark-file-this-dir-some-tags-other-window <remap> <bmkp-file-this-dir-some-tags-regexp-jump> icicle-bookmark-file-this-dir-some-tags-regexp <remap> <bmkp-file-this-dir-some-tags-regexp-jump-other-window> icicle-bookmark-file-this-dir-some-tags-regexp-other-window <remap> <bmkp-find-file> icicle-find-file-handle-bookmark <remap> <bmkp-find-file-all-tags> icicle-find-file-all-tags <remap> <bmkp-find-file-all-tags-other-window> icicle-find-file-all-tags-other-window <remap> <bmkp-find-file-all-tags-regexp> icicle-find-file-all-tags-regexp <remap> <bmkp-find-file-all-tags-regexp-other-window> icicle-find-file-all-tags-regexp-other-window <remap> <bmkp-find-file-other-window> icicle-find-file-handle-bookmark-other-window <remap> <bmkp-find-file-some-tags> icicle-find-file-some-tags <remap> <bmkp-find-file-some-tags-other-window> icicle-find-file-some-tags-other-window <remap> <bmkp-find-file-some-tags-regexp> icicle-find-file-some-tags-regexp <remap> <bmkp-find-file-some-tags-regexp-other-window> icicle-find-file-some-tags-regexp-other-window <remap> <bmkp-gnus-jump> icicle-bookmark-gnus <remap> <bmkp-gnus-jump-other-window> icicle-bookmark-gnus-other-window <remap> <bmkp-image-jump> icicle-bookmark-image <remap> <bmkp-image-jump-other-window> icicle-bookmark-image-other-window <remap> <bmkp-info-jump> icicle-bookmark-info <remap> <bmkp-info-jump-other-window> icicle-bookmark-info-other-window <remap> <bmkp-local-file-jump> icicle-bookmark-local-file <remap> <bmkp-local-file-jump-other-window> icicle-bookmark-local-file-other-window <remap> <bmkp-man-jump> icicle-bookmark-man <remap> <bmkp-man-jump-other-window> icicle-bookmark-man-other-window <remap> <bmkp-non-file-jump> icicle-bookmark-non-file <remap> <bmkp-non-file-jump-other-window> icicle-bookmark-non-file-other-window <remap> <bmkp-region-jump> icicle-bookmark-region <remap> <bmkp-region-jump-other-window> icicle-bookmark-region-other-window <remap> <bmkp-remote-file-jump> icicle-bookmark-remote-file <remap> <bmkp-remote-file-jump-other-window> icicle-bookmark-remote-file-other-window <remap> <bmkp-some-tags-jump> icicle-bookmark-some-tags <remap> <bmkp-some-tags-jump-other-window> icicle-bookmark-some-tags-other-window <remap> <bmkp-some-tags-regexp-jump> icicle-bookmark-some-tags-regexp <remap> <bmkp-some-tags-regexp-jump-other-window> icicle-bookmark-some-tags-regexp-other-window <remap> <bmkp-specific-buffers-jump> icicle-bookmark-specific-buffers <remap> <bmkp-specific-buffers-jump-other-window> icicle-bookmark-specific-buffers-other-window <remap> <bmkp-specific-files-jump> icicle-bookmark-specific-files <remap> <bmkp-specific-files-jump-other-window> icicle-bookmark-specific-files-other-window <remap> <bmkp-tag-a-file> icicle-tag-a-file <remap> <bmkp-temporary-jump> icicle-bookmark-temporary <remap> <bmkp-temporary-jump-other-window> icicle-bookmark-temporary-other-window <remap> <bmkp-this-buffer-jump> icicle-bookmark-this-buffer <remap> <bmkp-this-buffer-jump-other-window> icicle-bookmark-this-buffer-other-window <remap> <bmkp-untag-a-file> icicle-untag-a-file <remap> <bmkp-url-jump> icicle-bookmark-url <remap> <bmkp-url-jump-other-window> icicle-bookmark-url-other-window <remap> <bmkp-w3m-jump> icicle-bookmark-w3m <remap> <bmkp-w3m-jump-other-window> icicle-bookmark-w3m-other-window <remap> <bookmark-jump> icicle-bookmark <remap> <bookmark-jump-other-window> icicle-bookmark-other-window <remap> <bookmark-set> icicle-bookmark-cmd <remap> <customize-apropos> icicle-customize-apropos <remap> <customize-apropos-faces> icicle-customize-apropos-faces <remap> <customize-apropos-groups> icicle-customize-apropos-groups <remap> <customize-apropos-options> icicle-customize-apropos-options <remap> <customize-face> icicle-customize-face <remap> <customize-face-other-window> icicle-customize-face-other-window <remap> <dabbrev-completion> icicle-dabbrev-completion <remap> <delete-window> icicle-delete-window <remap> <delete-windows-for> icicle-delete-window <remap> <describe-package> icicle-describe-package <remap> <eval-expression> icicle-pp-eval-expression <remap> <exchange-point-and-mark> icicle-exchange-point-and-mark <remap> <execute-extended-command> icicle-execute-extended-command <remap> <find-file> icicle-file <remap> <find-file-other-window> icicle-file-other-window <remap> <find-file-read-only> icicle-find-file-read-only <remap> <find-file-read-only-other-window> icicle-find-file-read-only-other-window <remap> <find-tag> icicle-find-tag <remap> <find-tag-other-window> icicle-find-first-tag-other-window <remap> <insert-buffer> icicle-insert-buffer <remap> <kill-buffer> icicle-kill-buffer <remap> <kill-buffer-and-its-windows> icicle-kill-buffer <remap> <load-library> icicle-load-library <remap> <minibuffer-keyboard-quit> icicle-abort-recursive-edit <remap> <other-window> icicle-other-window-or-frame <remap> <other-window-or-frame> icicle-other-window-or-frame <remap> <pop-global-mark> icicle-goto-global-marker-or-pop-global-mark <remap> <pop-tag-mark> icicle-pop-tag-mark <remap> <pp-eval-expression> icicle-pp-eval-expression <remap> <repeat-complex-command> icicle-repeat-complex-command <remap> <set-mark-command> icicle-goto-marker-or-set-mark-command <remap> <switch-to-buffer> icicle-buffer <remap> <switch-to-buffer-other-window> icicle-buffer-other-window <remap> <where-is> icicle-where-is <remap> <yank> icicle-yank-maybe-completing <remap> <yank-pop> icicle-yank-pop-commands <remap> <yank-pop-commands> icicle-yank-pop-commands <remap> <zap-to-char> icicle-zap-to-char C-h C-o icicle-describe-option-of-type ESC ESC Prefix Command M-` lacarte-execute-menu-command M-s Prefix Command C-M-/ icicle-dispatch-C-M-/ M-ESC C-x icicle-command-abbrev M-ESC x lacarte-execute-command M-s ESC Prefix Command C-x ESC Prefix Command C-x 4 Prefix Command C-x 5 Prefix Command C-x j Prefix Command C-c " icicle-search-text-property C-c $ icicle-search-word C-c ' icicle-occur C-c / icicle-complete-thesaurus-entry C-c = icicle-imenu C-c ^ icicle-search-keywords C-c ` icicle-search-generic M-s M-s Prefix Command M-s M-s C-l icicle-search-pages M-s M-s ESC Prefix Command M-s M-s , icicle-tags-search M-s M-s D icicle-search-defs-full M-s M-s I icicle-imenu-full M-s M-s J icicle-search-bookmarks-together M-s M-s O icicle-search-overlay-property M-s M-s T icicle-search-text-property M-s M-s X icicle-search-xml-element-text-node M-s M-s b icicle-search-buffer M-s M-s c icicle-search-char-property M-s M-s d icicle-search-defs M-s M-s f icicle-search-file M-s M-s g icicle-grep-saved-file-candidates M-s M-s i icicle-imenu M-s M-s j icicle-search-bookmark M-s M-s k icicle-search-keywords M-s M-s l icicle-search-lines M-s M-s o icicle-occur M-s M-s p icicle-search-paragraphs M-s M-s s icicle-search-sentences M-s M-s t icicle-search-thing M-s M-s w icicle-search-word M-s M-s x icicle-search-xml-element C-x 4 j Prefix Command C-x j t Prefix Command C-x 5 o icicle-select-frame C-x M-e icicle-execute-named-keyboard-macro M-s M-s M-s icicle-search-generic C-x 4 j t Prefix Command C-x j t C-f Prefix Command C-x j t j icicle-bookmark-tagged C-x 4 j t C-f Prefix Command C-x 4 j t j icicle-bookmark-tagged-other-window C-x j t C-f C-f icicle-find-file-tagged C-x 4 j t C-f C-f icicle-find-file-tagged-other-window These are all of the minibuffer bindings during completion: key binding --- ------- C-a icicle-beginning-of-line+ C-e icicle-end-of-line+ C-g icicle-abort-recursive-edit TAB icicle-prefix-complete C-j icicle-insert-newline-in-minibuffer C-l icicle-retrieve-previous-input RET exit-minibuffer C-v icicle-scroll-Completions-forward C-w icicle-kill-region C-x Prefix Command ESC Prefix Command C-^ icicle-dispatch-C-^ SPC icicle-self-insert . icicle-insert-dot-command ? icicle-self-insert C-S-a icicle-toggle-case-sensitivity C-S-l icicle-retrieve-next-input S-SPC icicle-apropos-complete-and-narrow C-! icicle-all-candidates-action C-" icicle-toggle-expand-to-common-match C-# icicle-cycle-incremental-completion C-$ icicle-toggle-transforming C-% icicle-candidate-set-swap C-( icicle-next-TAB-completion-method C-) icicle-candidate-set-save-more-selected C-* icicle-candidate-set-intersection C-+ icicle-candidate-set-union C-, icicle-change-sort-order C-- icicle-candidate-set-difference C-. icicle-dispatch-C-. C-: icicle-candidate-set-define C-< icicle-candidate-set-retrieve-more C-= icicle-insert-string-from-variable C-> icicle-candidate-set-save-more C-` icicle-toggle-regexp-quote C-{ icicle-candidate-set-retrieve-persistent C-| icicle-all-candidates-alt-action C-} icicle-candidate-set-save-persistently C-~ icicle-candidate-set-complement <C-M-S-TAB> icicle-apropos-complete-no-display <C-M-S-tab> icicle-apropos-complete-no-display <C-M-down> icicle-next-candidate-per-mode-help <C-M-end> icicle-help-on-next-prefix-candidate <C-M-f1> icicle-help-on-candidate <C-M-help> icicle-help-on-candidate <C-M-home> icicle-help-on-previous-prefix-candidate <C-M-next> icicle-help-on-next-apropos-candidate <C-M-pause> icicle-other-history <C-M-prior> icicle-help-on-previous-apropos-candidate <C-M-return> icicle-help-on-candidate <C-M-tab> icicle-prefix-complete-no-display <C-M-up> icicle-previous-candidate-per-mode-help <C-M-wheel-down> icicle-next-candidate-per-mode-help <C-M-wheel-up> icicle-previous-candidate-per-mode-help <C-S-down> icicle-next-candidate-per-mode-alt-action <C-S-end> icicle-next-prefix-candidate-alt-action <C-S-home> icicle-previous-prefix-candidate-alt-action <C-S-next> icicle-next-apropos-candidate-alt-action <C-S-pause> icicle-toggle-WYSIWYG-Completions <C-S-prior> icicle-previous-apropos-candidate-alt-action <C-S-return> icicle-candidate-alt-action <C-S-tab> icicle-toggle-completion-mode-keys <C-S-up> icicle-previous-candidate-per-mode-alt-action <C-S-wheel-down> icicle-next-candidate-per-mode-alt-action <C-S-wheel-up> icicle-previous-candidate-per-mode-alt-action <C-down> icicle-next-candidate-per-mode-action <C-end> icicle-next-prefix-candidate-action <C-f1> icicle-help-on-candidate <C-help> icicle-help-on-candidate <C-home> icicle-previous-prefix-candidate-action <C-insert> icicle-switch-to-Completions-buf <C-next> icicle-next-apropos-candidate-action <C-pause> icicle-toggle-highlight-historical-candidates <C-prior> icicle-previous-apropos-candidate-action <C-return> icicle-candidate-action <C-tab> file-cache-minibuffer-complete <C-up> icicle-previous-candidate-per-mode-action <C-wheel-down> icicle-next-candidate-per-mode-action <C-wheel-up> icicle-previous-candidate-per-mode-action <M-S-backspace> icicle-erase-minibuffer <M-S-delete> icicle-erase-minibuffer <M-backtab> icicle-complete-keys <M-pause> icicle-keep-only-past-inputs <M-return> icicle-candidate-read-fn-invoke <M-up> 1on1-fit-minibuffer-frame <S-backspace> icicle-apropos-complete-and-widen <S-delete> icicle-delete-candidate-object <S-pause> icicle-toggle-highlight-saved-candidates <S-return> icicle-apropos-complete-and-exit <XF86Back> previous-history-element <XF86Forward> next-history-element <backtab> icicle-apropos-complete <delete> icicle-remove-candidate <down> icicle-next-candidate-per-mode <end> icicle-next-prefix-candidate <home> icicle-previous-prefix-candidate <icicle-is-completion-map> ignore <insert> icicle-save/unsave-candidate <next> icicle-next-apropos-candidate <nil> Prefix Command <prior> icicle-previous-apropos-candidate <remap> Prefix Command <tab> icicle-prefix-complete <up> icicle-previous-candidate-per-mode <wheel-down> icicle-next-candidate-per-mode <wheel-up> icicle-previous-candidate-per-mode C-x C-a icicle-toggle-annotation C-x ESC Prefix Command C-x # icicle-doremi-increment-max-candidates+ C-x - icicle-doremi-zoom-Completions+ C-x . icicle-dispatch-C-x. C-x / icicle-toggle-expand-directory C-x : icicle-toggle-network-drives-as-remote C-x t icicle-cycle-image-file-thumbnail C-x w icicle-doremi-candidate-width-factor+ C-x | icicle-doremi-inter-candidates-min-spaces+ C-x C-0 icicle-recomplete-from-original-domain C-x C-< bmkp-retrieve-more-icicle-search-hits <nil> <C-M-wheel-down> icicle-next-candidate-per-mode-help <nil> <C-M-wheel-up> icicle-previous-candidate-per-mode-help <nil> <C-S-wheel-down> icicle-next-candidate-per-mode-alt-action <nil> <C-S-wheel-up> icicle-previous-candidate-per-mode-alt-action <nil> <C-wheel-down> icicle-next-candidate-per-mode-action <nil> <C-wheel-up> icicle-previous-candidate-per-mode-action <nil> <wheel-down> icicle-next-candidate-per-mode <nil> <wheel-up> icicle-previous-candidate-per-mode <remap> <backward-delete-char-untabify> icicle-backward-delete-char-untabify <remap> <backward-kill-paragraph> icicle-backward-kill-paragraph <remap> <backward-kill-sentence> icicle-backward-kill-sentence <remap> <backward-kill-sexp> icicle-backward-kill-sexp <remap> <backward-kill-word> icicle-backward-kill-word <remap> <delete-backward-char> icicle-delete-backward-char <remap> <delete-char> icicle-delete-char <remap> <digit-argument> icicle-digit-argument <remap> <kill-line> icicle-kill-line <remap> <kill-paragraph> icicle-kill-paragraph <remap> <kill-sexp> icicle-kill-sexp <remap> <kill-word> icicle-kill-word <remap> <mouse-yank-secondary> icicle-mouse-yank-secondary <remap> <negative-argument> icicle-negative-argument <remap> <reposition-window> icicle-goto/kill-failed-input <remap> <self-insert-command> icicle-self-insert <remap> <transpose-chars> icicle-transpose-chars <remap> <transpose-sexps> icicle-transpose-sexps <remap> <transpose-words> icicle-transpose-words <remap> <universal-argument> icicle-universal-argument <remap> <yank-pop> icicle-yank-pop C-M-j icicle-insert-list-join-string M-RET icicle-candidate-read-fn-invoke C-M-^ icicle-toggle-completions-format C-M-_ icicle-toggle-proxy-candidates M-SPC icicle-prefix-word-complete M-! icicle-all-candidates-list-action M-$ icicle-candidate-set-truncate M-% icicle-regexp-quote-input M-& icicle-narrow-candidates-with-predicate M-( icicle-next-S-TAB-completion-method M-* icicle-narrow-candidates M-+ icicle-widen-candidates M-, icicle-dispatch-M-comma M-; icicle-toggle-search-replace-common-match M-_ icicle-dispatch-M-_ M-g icicle-toggle-C-for-actions M-h icicle-history M-i icicle-toggle-map M-m icicle-toggle-show-multi-completion M-q icicle-dispatch-M-q M-r icicle-roundup M-v icicle-scroll-Completions-backward M-| icicle-all-candidates-list-alt-action M-~ icicle-toggle-~-for-home-dir C-M-" icicle-cycle-expand-to-common-match C-M-# icicle-toggle-icomplete-mode C-M-& icicle-save-predicate-to-variable C-M-( icicle-next-completion-style-set C-M-) icicle-candidate-set-save-selected C-M-+ icicle-plus-saved-sort C-M-, icicle-toggle-alternative-sorting C-M-. icicle-toggle-dot C-M-; icicle-toggle-ignoring-comments C-M-< icicle-candidate-set-retrieve C-M-> icicle-candidate-set-save C-M-` icicle-toggle-literal-replacement C-M-{ icicle-candidate-set-retrieve-from-variable C-M-} icicle-candidate-set-save-to-variable C-M-~ icicle-toggle-search-complementing-domain M-i TAB icicle-toggle-completion-mode-keys M-i ESC Prefix Command M-i " icicle-toggle-expand-to-common-match M-i # icicle-cycle-incremental-completion M-i $ icicle-toggle-transforming M-i , icicle-toggle-sorting M-i . icicle-dispatch-C-. M-i / icicle-toggle-expand-directory M-i : icicle-toggle-network-drives-as-remote M-i ; icicle-toggle-ignoring-comments M-i < icicle-toggle-angle-brackets M-i A icicle-toggle-case-sensitivity M-i F icicle-toggle-include-cached-files M-i ^ icicle-dispatch-C-^ M-i _ icicle-dispatch-M-_ M-i ` icicle-toggle-literal-replacement M-i a icicle-toggle-annotation M-i g icicle-toggle-C-for-actions M-i h icicle-dispatch-C-x. M-i m icicle-toggle-show-multi-completion M-i p icicle-toggle-proxy-candidates M-i q icicle-dispatch-M-q M-i r icicle-toggle-include-recent-files M-i s icicle-toggle-highlight-saved-candidates M-i t icicle-cycle-image-file-thumbnail M-i w icicle-toggle-WYSIWYG-Completions M-i ~ icicle-toggle-search-complementing-domain M-i C-` icicle-toggle-regexp-quote M-i <backtab> icicle-complete-keys M-i <pause> icicle-toggle-highlight-historical-candidates C-x C-f icicle-resolve-file-name C-M-v icicle-scroll-forward C-M-y icicle-yank-secondary M-. icicle-insert-string-at-point M-: icicle-pp-eval-expression-in-minibuffer M-? icicle-minibuffer-help M-K icicle-clear-current-history M-R icicle-multi-inputs-act M-S icicle-multi-inputs-save M-k icicle-erase-minibuffer-or-history-element M-n next-history-element M-o icicle-insert-history-element M-p previous-history-element M-r previous-matching-history-element (that binding is currently shadowed by another mode) M-s next-matching-history-element C-M-S-c icicle-completing-read+insert C-M-S-f icicle-read+insert-file-name C-M-S-t icicle-top-level C-M-S-v icicle-scroll-backward ESC <M-backtab> icicle-complete-keys C-x C-M-l icicle-display-candidates-in-Completions C-x C-M-< bmkp-retrieve-icicle-search-hits C-x C-M-> bmkp-set-icicle-search-hits-bookmark M-i M-" icicle-cycle-expand-to-common-match M-i M-# icicle-toggle-icomplete-mode M-i M-, icicle-toggle-alternative-sorting M-i M-. icicle-toggle-dot M-i M-; icicle-toggle-search-replace-common-match M-i M-^ icicle-toggle-completions-format M-i M-i icicle-toggle-option M-i M-~ icicle-toggle-~-for-home-dir M-i ESC <backtab> icicle-complete-keys ______________________________________________________________________ Send an Icicles bug report: `M-x icicle-send-bug-report'. [Icicles Help on the Web] [Icicles Doc, Part 1] [Icicles Options & Faces] [Icicles Doc, Part 2] ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: info-find-source 2018-01-13 3:43 ` info-find-source Robert Thorpe 2018-01-13 5:23 ` info-find-source Marcin Borkowski @ 2018-01-13 15:50 ` Drew Adams [not found] ` <mailman.7314.1515821013.27995.help-gnu-emacs@gnu.org> 2 siblings, 0 replies; 838+ messages in thread From: Drew Adams @ 2018-01-13 15:50 UTC (permalink / raw) To: Robert Thorpe, Emanuel Berg; +Cc: help-gnu-emacs > Info has it's own keybindings. That can be a little tricky, > since "s" is the normal way to search rather than "C-s" or "M-s". `C-s' and `C-M-s' are normal ways of searching in Info. In the beginning there was only `s': `C-s' searched only the current node, but `s' searched across nodes. As of several releases ago `C-s' and `C-M-s' work fine across nodes. ^ permalink raw reply [flat|nested] 838+ messages in thread
[parent not found: <mailman.7314.1515821013.27995.help-gnu-emacs@gnu.org>]
* Re: info-find-source [not found] ` <mailman.7314.1515821013.27995.help-gnu-emacs@gnu.org> @ 2018-01-14 2:57 ` Emanuel Berg 2018-01-14 7:00 ` info-find-source Marcin Borkowski [not found] ` <mailman.7369.1515913231.27995.help-gnu-emacs@gnu.org> 0 siblings, 2 replies; 838+ messages in thread From: Emanuel Berg @ 2018-01-14 2:57 UTC (permalink / raw) To: help-gnu-emacs Marcin Borkowski wrote: >> Info has it's own keybindings. That can be >> a little tricky, since "s" is the normal way >> to search rather than "C-s" or "M-s". >> You can rebind these functions though. > > I didn't know that! To quote the late Cipher, dreaming of re-entering the Matrix without remembering anything, "ignorance is a bliss". > Then, maybe a year or two ago, I learned > about the index and the `i' keystroke, and > now I can't understand how I used > Info before. Unnecessary in text-mode, of course. > I would really like it if someone set up > a contest of "how fast can someone use Info > to search for things and come back to other > things and not get distracted by links and/or > writing one's own functions to do what you > can do with stock Emacs better", and made > Emanuel and me the contestants. If so, I will not only defeat you. I will punish you :) -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: info-find-source 2018-01-14 2:57 ` info-find-source Emanuel Berg @ 2018-01-14 7:00 ` Marcin Borkowski [not found] ` <mailman.7369.1515913231.27995.help-gnu-emacs@gnu.org> 1 sibling, 0 replies; 838+ messages in thread From: Marcin Borkowski @ 2018-01-14 7:00 UTC (permalink / raw) To: Emanuel Berg; +Cc: help-gnu-emacs On 2018-01-14, at 03:57, Emanuel Berg <moasen@zoho.com> wrote: > Marcin Borkowski wrote: > >>> Info has it's own keybindings. That can be >>> a little tricky, since "s" is the normal way >>> to search rather than "C-s" or "M-s". >>> You can rebind these functions though. >> >> I didn't know that! > > To quote the late Cipher, dreaming of > re-entering the Matrix without remembering > anything, "ignorance is a bliss". > >> Then, maybe a year or two ago, I learned >> about the index and the `i' keystroke, and >> now I can't understand how I used >> Info before. > > Unnecessary in text-mode, of course. Seriously? Try C-s'ing the string "interactive" your way to find out about the (interactive) codes. In Emacs Lisp Reference: C-x n w M-x how-many RET interactive RET result: 515 hits. The "right" one is about 1/3 down the list. >> I would really like it if someone set up >> a contest of "how fast can someone use Info >> to search for things and come back to other >> things and not get distracted by links and/or >> writing one's own functions to do what you >> can do with stock Emacs better", and made >> Emanuel and me the contestants. > > If so, I will not only defeat you. I will > punish you :) Wouldn't be so sure - see above. ;-) Best, -- Marcin Borkowski ^ permalink raw reply [flat|nested] 838+ messages in thread
[parent not found: <mailman.7369.1515913231.27995.help-gnu-emacs@gnu.org>]
* Re: info-find-source [not found] ` <mailman.7369.1515913231.27995.help-gnu-emacs@gnu.org> @ 2018-01-15 4:17 ` Emanuel Berg 2018-01-15 18:54 ` info-find-source Marcin Borkowski [not found] ` <mailman.7435.1516042498.27995.help-gnu-emacs@gnu.org> 0 siblings, 2 replies; 838+ messages in thread From: Emanuel Berg @ 2018-01-15 4:17 UTC (permalink / raw) To: help-gnu-emacs Marcin Borkowski wrote: > Seriously? Try C-s'ing the string > "interactive" your way to find out about the > (interactive) codes. > > In Emacs Lisp Reference: > > C-x n w M-x how-many RET interactive RET > > result: 515 hits. The "right" one is about > 1/3 down the list. This is the nature of this kind of search. If you are searching for an item that appears several times, and an instance somewhere in the middle is the desired one, then yes, search will have to visit each preceding instance if it starts at the beginning of the document. This situation is a part of, but not restricted to, the described "one file" method. However in time you will be more sophisticated with your searches. It'll also give you a spacial awareness (spacial as in "space", not special) of the document and what it contains, which will benefit searching - your use of it - even more. -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: info-find-source 2018-01-15 4:17 ` info-find-source Emanuel Berg @ 2018-01-15 18:54 ` Marcin Borkowski [not found] ` <mailman.7435.1516042498.27995.help-gnu-emacs@gnu.org> 1 sibling, 0 replies; 838+ messages in thread From: Marcin Borkowski @ 2018-01-15 18:54 UTC (permalink / raw) To: Emanuel Berg; +Cc: help-gnu-emacs On 2018-01-15, at 05:17, Emanuel Berg <moasen@zoho.com> wrote: > Marcin Borkowski wrote: > >> Seriously? Try C-s'ing the string >> "interactive" your way to find out about the >> (interactive) codes. >> >> In Emacs Lisp Reference: >> >> C-x n w M-x how-many RET interactive RET >> >> result: 515 hits. The "right" one is about >> 1/3 down the list. > > This is the nature of this kind of search. > If you are searching for an item that appears > several times, and an instance somewhere in the > middle is the desired one, then yes, search > will have to visit each preceding instance if > it starts at the beginning of the document. > > This situation is a part of, but not restricted > to, the described "one file" method. > > However in time you will be more sophisticated > with your searches. It'll also give you > a spacial awareness (spacial as in "space", not > special) of the document and what it contains, > which will benefit searching - your use of it - > even more. Yes, I could train myself to do that. But... I have `i' in Info! So why train myself to do something my computer (using the information Emacs developers put in) can do better? Best, -- Marcin Borkowski ^ permalink raw reply [flat|nested] 838+ messages in thread
[parent not found: <mailman.7435.1516042498.27995.help-gnu-emacs@gnu.org>]
* Re: info-find-source [not found] ` <mailman.7435.1516042498.27995.help-gnu-emacs@gnu.org> @ 2018-01-15 19:55 ` Emanuel Berg 2018-01-16 23:58 ` info-find-source Robert Thorpe ` (2 more replies) 0 siblings, 3 replies; 838+ messages in thread From: Emanuel Berg @ 2018-01-15 19:55 UTC (permalink / raw) To: help-gnu-emacs Marcin Borkowski wrote: >> This is the nature of this kind of search. >> If you are searching for an item that >> appears several times, and an instance >> somewhere in the middle is the desired one, >> then yes, search will have to visit each >> preceding instance if it starts at the >> beginning of the document. This situation is >> a part of, but not restricted to, the >> described "one file" method. However in time >> you will be more sophisticated with your >> searches. It'll also give you a spacial >> awareness (spacial as in "space", not >> special) of the document and what it >> contains, which will benefit searching - >> your use of it - even more. > > Yes, I could train myself to do that. > > But... I have `i' in Info! So why train > myself to do something my computer (using the > information Emacs developers put in) can > do better? Because you have already trained yourself to edit text and code and that happens every day from now on as well. No matter how much you train with Info, you will never get to the text/code level. And when you "train" with text and code, you do amazing stuff - well, hopefully, but almost certainly something more interesting than how to navigate a browser... -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: info-find-source 2018-01-15 19:55 ` info-find-source Emanuel Berg @ 2018-01-16 23:58 ` Robert Thorpe 2018-01-19 6:22 ` info-find-source Marcin Borkowski [not found] ` <mailman.7609.1516342943.27995.help-gnu-emacs@gnu.org> 2 siblings, 0 replies; 838+ messages in thread From: Robert Thorpe @ 2018-01-16 23:58 UTC (permalink / raw) To: Emanuel Berg, Marcin Borkowski; +Cc: help-gnu-emacs Emanuel Berg <moasen@zoho.com> writes: > Marcin Borkowski wrote: > .... >> Yes, I could train myself to do that. >> >> But... I have `i' in Info! So why train >> myself to do something my computer (using the >> information Emacs developers put in) can >> do better? > > Because you have already trained yourself to > edit text and code and that happens every day > from now on as well. No matter how much you > train with Info, you will never get to the > text/code level. And when you "train" with text > and code, you do amazing stuff - well, > hopefully, but almost certainly something more > interesting than how to navigate a browser... I agree with Marcin Borkowski. I think it's a mistake to over-emphasise the editing modes, and their keybindings. The viewing modes and the special modes are just as important. I spend a great deal of time in Dired, Info, Help and reading mail. I also spend a fair amount of time in View, Occur, Grep, Find, Compile and Shell. In my experience it's worth becoming reasonably familiar with those modes and their keybindings. It's true that doing that means less practice with the normal editing keybindings. However, as you get better at using those, each increment of extra skill comes more slowly. You reach a point of diminishing returns. At that stage it's worthwhile to pay more attention to the special modes. I don't expect you to necessarily take my advice. I'm just giving my opinion. BR, Robert Thorpe ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: info-find-source 2018-01-15 19:55 ` info-find-source Emanuel Berg 2018-01-16 23:58 ` info-find-source Robert Thorpe @ 2018-01-19 6:22 ` Marcin Borkowski [not found] ` <mailman.7609.1516342943.27995.help-gnu-emacs@gnu.org> 2 siblings, 0 replies; 838+ messages in thread From: Marcin Borkowski @ 2018-01-19 6:22 UTC (permalink / raw) To: Emanuel Berg; +Cc: help-gnu-emacs On 2018-01-15, at 20:55, Emanuel Berg <moasen@zoho.com> wrote: > [...] No matter how much you > train with Info, you will never get to the > text/code level. [...] Wrong. Info is a special mode, so uses keys without modifiers like... "escape-meta-alt-control-shift";-). That's faster. (And operable with one hand!) Best, -- Marcin Borkowski ^ permalink raw reply [flat|nested] 838+ messages in thread
[parent not found: <mailman.7609.1516342943.27995.help-gnu-emacs@gnu.org>]
* Re: info-find-source [not found] ` <mailman.7609.1516342943.27995.help-gnu-emacs@gnu.org> @ 2018-01-19 7:12 ` Emanuel Berg 2018-01-19 20:31 ` info-find-source Marcin Borkowski [not found] ` <mailman.7650.1516393881.27995.help-gnu-emacs@gnu.org> 0 siblings, 2 replies; 838+ messages in thread From: Emanuel Berg @ 2018-01-19 7:12 UTC (permalink / raw) To: help-gnu-emacs Marcin Borkowski wrote: >> No matter how much you train with Info, you >> will never get to the text/code level. > > Wrong. Info is a special mode, so uses keys > without modifiers like... > "escape-meta-alt-control-shift";-). > That's faster. (And operable with one hand!) Perhaps you should look into your editing mode keybindings? -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: info-find-source 2018-01-19 7:12 ` info-find-source Emanuel Berg @ 2018-01-19 20:31 ` Marcin Borkowski 2018-01-19 21:05 ` info-find-source Drew Adams [not found] ` <mailman.7653.1516395915.27995.help-gnu-emacs@gnu.org> [not found] ` <mailman.7650.1516393881.27995.help-gnu-emacs@gnu.org> 1 sibling, 2 replies; 838+ messages in thread From: Marcin Borkowski @ 2018-01-19 20:31 UTC (permalink / raw) To: Emanuel Berg; +Cc: help-gnu-emacs On 2018-01-19, at 08:12, Emanuel Berg <moasen@zoho.com> wrote: > Marcin Borkowski wrote: > >>> No matter how much you train with Info, you >>> will never get to the text/code level. >> >> Wrong. Info is a special mode, so uses keys >> without modifiers like... >> "escape-meta-alt-control-shift";-). >> That's faster. (And operable with one hand!) > > Perhaps you should look into your editing > mode keybindings? In editing mode, `a' to `z' run self-insrt-command. That's enough. (Unless you use some kind of Vi(m) emulation, that's another story.) Best, -- Marcin Borkowski ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: info-find-source 2018-01-19 20:31 ` info-find-source Marcin Borkowski @ 2018-01-19 21:05 ` Drew Adams [not found] ` <mailman.7653.1516395915.27995.help-gnu-emacs@gnu.org> 1 sibling, 0 replies; 838+ messages in thread From: Drew Adams @ 2018-01-19 21:05 UTC (permalink / raw) To: Marcin Borkowski, Emanuel Berg; +Cc: help-gnu-emacs BTW/FWIW, about using Info in "editing mode" or not, here's some trivia from the past... Info mode used to bind command `Info-edit' to `e'. That command lets you edit Info nodes, so you can easily update or annotate your version of a given manual, e.g., to correct or explain something to yourself or add more information. The command was declared "obsolete" in Emacs 24.4. (Personally, I see no point in that.) The reason given is told by `C-h f': This function is obsolete since 24.4; editing Info nodes by hand is not recommended. Edit the contents of this Info node. And `e' now just takes you to the end of the `*info*' buffer. (On n'arrete pas le progres.) ^ permalink raw reply [flat|nested] 838+ messages in thread
[parent not found: <mailman.7653.1516395915.27995.help-gnu-emacs@gnu.org>]
* Re: info-find-source [not found] ` <mailman.7653.1516395915.27995.help-gnu-emacs@gnu.org> @ 2018-01-19 22:19 ` Emanuel Berg 2018-01-19 23:21 ` info-find-source Drew Adams [not found] ` <mailman.7656.1516404112.27995.help-gnu-emacs@gnu.org> 0 siblings, 2 replies; 838+ messages in thread From: Emanuel Berg @ 2018-01-19 22:19 UTC (permalink / raw) To: help-gnu-emacs Drew Adams wrote: > This function is obsolete since 24.4; editing > Info nodes by hand is not recommended. I've seen this as well and wondered what it meant... "By hand" - is the recommended way having a bunch of text files and have that compiled, or should one generate the documentation straight from Elisp, including docstrings and/or comments? Also, when you could edit Info nodes that way, where did those edits go? Using the useful and sensible program that was the initial topic of this thread, we find out that for example Gnus' is here /usr/share/info/emacs-24/gnus.info while SLIME is here ~/.emacs.d/elpa/slime-20170921.1000/slime.info so while the SLIME's manual could be annotated without any hazard, how will this be done with Gnus' without sudo right and without the changes/annotations being threatened by updates? -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: info-find-source 2018-01-19 22:19 ` info-find-source Emanuel Berg @ 2018-01-19 23:21 ` Drew Adams [not found] ` <mailman.7656.1516404112.27995.help-gnu-emacs@gnu.org> 1 sibling, 0 replies; 838+ messages in thread From: Drew Adams @ 2018-01-19 23:21 UTC (permalink / raw) To: Emanuel Berg, help-gnu-emacs > > This function is obsolete since 24.4; editing > > Info nodes by hand is not recommended. > > I've seen this as well and wondered what it > meant... "By hand" - is the recommended way > having a bunch of text files and have that > compiled, or should one generate the > documentation straight from Elisp, including > docstrings and/or comments? AFAIK, the "recommended" way is to build Info files using `makeinfo' with TexInfo source files. But I'm no expert on that. > Also, when you could edit Info nodes that way, > where did those edits go? You can still edit Info nodes that way. As I said, command `Info-edit' still exists, and it still works. Try it. You are asked to confirm whether you really want to do it. After you make your changes, by editing normally, you use `C-c C-c' and enter the name of the Info file you want to write. If you give the name of the current file (see variable `Info-current-file', for instance) then you are asked to confirm overwriting it. If you instead give the name of a new file then you create a new Info file. In either case you provide an absolute file name, so that's "where" your edits go. > Using the useful and > sensible program that was the initial topic of > this thread, we find out that for example Gnus' > is here /usr/share/info/emacs-24/gnus.info > while SLIME is here: > ~/.emacs.d/elpa/slime-20170921.1000/slime.info > so while the SLIME's manual could be annotated > without any hazard, how will this be done with > Gnus' without sudo right and without the > changes/annotations being threatened > by updates? If you change that slime.info file and then you download the SLIME again to the same disk location then that will overwrite your edits. And yes, if you want to change that gnus.info file then you need the necessary permissions write to that location. Nothing new here. But you can have Info files wherever you want. See option `Info-additional-directory-list', and variables `Info-directory-list', and `Info-default-directory-list'. And see env var `INFOPATH'. To be clear, I'm not encouraging anyone to edit Info files. I'm just mentioning that you can. ^ permalink raw reply [flat|nested] 838+ messages in thread
[parent not found: <mailman.7656.1516404112.27995.help-gnu-emacs@gnu.org>]
* Re: info-find-source [not found] ` <mailman.7656.1516404112.27995.help-gnu-emacs@gnu.org> @ 2018-01-20 19:49 ` Emanuel Berg 2018-01-20 20:18 ` info-find-source Eli Zaretskii ` (3 more replies) 0 siblings, 4 replies; 838+ messages in thread From: Emanuel Berg @ 2018-01-20 19:49 UTC (permalink / raw) To: help-gnu-emacs Drew Adams wrote: >>> This function is obsolete since 24.4; >>> editing Info nodes by hand is >>> not recommended. >> >> I've seen this as well and wondered what it >> meant... "By hand" - is the recommended way >> having a bunch of text files and have that >> compiled, or should one generate the >> documentation straight from Elisp, including >> docstrings and/or comments? > > AFAIK, the "recommended" way is to build Info > files using `makeinfo' with TexInfo source > files. Yes of course, it even says so first thing: This is slime.info, produced by makeinfo version 5.2 from slime.texi. OK, so it is the *.info files* that one is disencouraged from editing? Well yeah, why would you do that?! The "by hand" phrasing is where the confusion begins because it seems to imply there is a better way to "edit" them. But to me it seems totally backward to edit the result of compilation and I don't think I ever did that because wouldn't not only update but also recompilation overwrite the edits? In general one should edit the source! and here one could simply keep a text file with any extra material. -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: info-find-source 2018-01-20 19:49 ` info-find-source Emanuel Berg @ 2018-01-20 20:18 ` Eli Zaretskii [not found] ` <<83bmhos2qd.fsf@gnu.org> ` (2 subsequent siblings) 3 siblings, 0 replies; 838+ messages in thread From: Eli Zaretskii @ 2018-01-20 20:18 UTC (permalink / raw) To: help-gnu-emacs > From: Emanuel Berg <moasen@zoho.com> > Date: Sat, 20 Jan 2018 20:49:22 +0100 > > The "by hand" phrasing is where the confusion > begins because it seems to imply there is > a better way to "edit" them. But to me it seems > totally backward to edit the result of > compilation and I don't think I ever did that > because wouldn't not only update but also > recompilation overwrite the edits? > > In general one should edit the source! and here > one could simply keep a text file with any > extra material. That command exists because Info files predate the makeinfo program; the first Info files were made by hand, because makeinfo didn't yet exist. ^ permalink raw reply [flat|nested] 838+ messages in thread
[parent not found: <<83bmhos2qd.fsf@gnu.org>]
* RE: info-find-source [not found] ` <<83bmhos2qd.fsf@gnu.org> @ 2018-01-20 23:50 ` Drew Adams 0 siblings, 0 replies; 838+ messages in thread From: Drew Adams @ 2018-01-20 23:50 UTC (permalink / raw) To: Eli Zaretskii, help-gnu-emacs > > The "by hand" phrasing is where the confusion > > begins because it seems to imply there is > > a better way to "edit" them. But to me it seems > > totally backward to edit the result of > > compilation and I don't think I ever did that > > because wouldn't not only update but also > > recompilation overwrite the edits? > > > > In general one should edit the source! and here > > one could simply keep a text file with any > > extra material. > > That command exists because Info files predate the makeinfo program; > the first Info files were made by hand, because makeinfo didn't yet > exist. Maybe `Info-edit' existed before `makeinfo' and `Texinfo'; I don't recall. But all three are very old. I recall all three back in the 80s, if I'm not mistaken. And `Info-edit' was not deprecated until recently. So unless my memory is mistaken here, the lack of `makeinfo' was not at all the reason that `Info-edit' remained available (and bound to `e') all those years, even if it was the case that it existed before `makeinfo'. `Info-edit' can be useful for someone to simply modify or add a bit of text, without needing `makeinfo' to be available (installed). IOW, it's use cases were never limited to hand-creation of entire manuals. That would give a very false impression, IMHO, of what this command was/is about. For one thing, `Info-edit' is used from Info. I'm not sure it was ever intended to be used to write whole manuals. I'd guess that at least that was not the main use case, especially all those years long. ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: info-find-source 2018-01-20 19:49 ` info-find-source Emanuel Berg 2018-01-20 20:18 ` info-find-source Eli Zaretskii [not found] ` <<83bmhos2qd.fsf@gnu.org> @ 2018-01-21 0:04 ` Drew Adams [not found] ` <mailman.7695.1516493072.27995.help-gnu-emacs@gnu.org> 3 siblings, 0 replies; 838+ messages in thread From: Drew Adams @ 2018-01-21 0:04 UTC (permalink / raw) To: Emanuel Berg, help-gnu-emacs > OK, so it is the *.info files* that one is > disencouraged from editing? Well yeah, why > would you do that?! Quick correction/annotation/addition to one's own copy of a manual. Versus re-creating lots of stuff (after having installed `makeinfo', if it's not installed locally). The existence of `makeinfo' does not obviate the usefulness of `Info-edit'. > The "by hand" phrasing is where the confusion > begins because it seems to imply there is > a better way to "edit" them. But to me it seems > totally backward to edit the result of > compilation When that result is human-readable text it's not a big deal to edit it. Of course, if you want the change to be reflected more globally or to be shared etc. then you want to only modify Texinfo source and generate Info output. You yourself argued for using *.info files in plain editing mode (e.g. after `C-x n w'). Something like `Info-edit' is nowhere near as extreme as that. It's used for simple, quick one-off changes or additions. One doesn't have to argue _against_ generating Info from Texinfo to see some utility in a command such as `Info-edit'. Granted, that utility is limited, and most people have never even heard of it. But that's not the same as saying that it has no raison d'etre. ____ I mentioned that Info+ has a command, `Info-merge-subnodes', for creating a plain-text, prettified merge of Info nodes (even a whole manual, but more typically a section of a manual, however small). Such a flat buffer can be useful sometimes (e.g., plain-text printing, some kinds of searching, sending excerpts), but I wouldn't argue that `Info-merge-subnodes' is a _super_ useful command. Some commands have limited usefulness and use cases. `Info-edit', like `Info-merge-subnodes' is one such. ^ permalink raw reply [flat|nested] 838+ messages in thread
[parent not found: <mailman.7695.1516493072.27995.help-gnu-emacs@gnu.org>]
* Re: info-find-source [not found] ` <mailman.7695.1516493072.27995.help-gnu-emacs@gnu.org> @ 2018-01-21 11:49 ` Emanuel Berg 0 siblings, 0 replies; 838+ messages in thread From: Emanuel Berg @ 2018-01-21 11:49 UTC (permalink / raw) To: help-gnu-emacs Drew Adams wrote: > You yourself argued for using *.info files in > plain editing mode (e.g. after `C-x n w'). > Something like `Info-edit' is nowhere near as > extreme as that. It's used for simple, quick > one-off changes or additions. Well, it is a thought to read the documentation that way, and have the whole program file in a single buffer, which operates like a regular file and doesn't disappear when you do something else or bring something else up thru some interface which you aren't that apt with... But after doing `C-x n w', and even `text-mode' on top of that, you still have to disable `read-only-mode' in order to edit it. And no one has suggested that. So you hear me loud and clear out there? DON'T DO THAT! Ha ha ha :) -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 838+ messages in thread
[parent not found: <mailman.7650.1516393881.27995.help-gnu-emacs@gnu.org>]
* Re: info-find-source [not found] ` <mailman.7650.1516393881.27995.help-gnu-emacs@gnu.org> @ 2018-01-19 20:43 ` Emanuel Berg 0 siblings, 0 replies; 838+ messages in thread From: Emanuel Berg @ 2018-01-19 20:43 UTC (permalink / raw) To: help-gnu-emacs Marcin Borkowski wrote: > In editing mode, `a' to `z' run > self-insrt-command. That's enough. (Unless > you use some kind of Vi(m) emulation, that's > another story.) The really short and close shortcuts, which involve either a single C or ditto M, and then a single key, which doesn't require hand movement, e.g. M-i, M-k, etc. - these are not slower to any practical extent, and whats more, you know them much better than anything that comes out of info, because without even practising 'em, that is what happens every day of writing/editing text and code. -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: info-find-source 2018-01-13 0:43 ` info-find-source Emanuel Berg 2018-01-13 3:43 ` info-find-source Robert Thorpe @ 2018-01-13 5:17 ` Marcin Borkowski [not found] ` <mailman.7313.1515820700.27995.help-gnu-emacs@gnu.org> 2 siblings, 0 replies; 838+ messages in thread From: Marcin Borkowski @ 2018-01-13 5:17 UTC (permalink / raw) To: Emanuel Berg; +Cc: help-gnu-emacs On 2018-01-13, at 01:43, Emanuel Berg <moasen@zoho.com> wrote: > The issue I have with info is that it is easy > to get lost when navigating all those node back > and forth in the tree structure, back and forth > in history, up to the parent and down to the > child until you are stuck at a leaf and you > still haven't found what you are looking for. > And you do all this with keys that you do not > use every day for editing. > > Compare this to the man pages where this never > happens (because of less complexity), *or* > a plain text files, where by definition it > cannot ever happen. > > But doesn't this mean the files will be very > long? Yes, and I don't have a problem with that > as this volume is linear, not broken down into > a complicated tree structure one has > to traverse to get to the rainbow's end. This is the point. Underneath, Info is *still* linear. You can search it with C-s/C-r, if that's your way. Also, you can bookmark Info pages (using Emacs stock bookmarks or bookmark+). I can't see *any* gain from your function. And if I really wanted something like that, I'd probably use "no new keystrokes to learn" (using your own words!) and stick with plain old `C-x n w'. Please try it out and tell me how your solution is superior. Best, -- Marcin Borkowski ^ permalink raw reply [flat|nested] 838+ messages in thread
[parent not found: <mailman.7313.1515820700.27995.help-gnu-emacs@gnu.org>]
* Re: info-find-source [not found] ` <mailman.7313.1515820700.27995.help-gnu-emacs@gnu.org> @ 2018-01-14 2:54 ` Emanuel Berg 2018-01-15 18:52 ` info-find-source Marcin Borkowski [not found] ` <mailman.7433.1516042345.27995.help-gnu-emacs@gnu.org> 0 siblings, 2 replies; 838+ messages in thread From: Emanuel Berg @ 2018-01-14 2:54 UTC (permalink / raw) To: help-gnu-emacs Marcin Borkowski wrote: > This is the point. Underneath, Info is > *still* linear. Of course, because otherwise it couldn't be put into a single file where all the items appear in order! (Here "Info" means the data, or documentation, not the browser or Emacs mode.) > I can't see *any* gain from your function. OK, the gain is it brings up the raw source file associated with the info file you are browsing. Or at least that is the purpose as I haven't had time testing it a lot. But because there exists a correlation between the source file and what is displayed with the info browser, the Holy Grail cannot be farther away than the expected initial problems. Actually, I cannot see "any gain" from displaying the data as a tree! The only gain I can see is hypertext. I see the point of that, but I see that as something similar of, you ask a person "how do you do X? what do you need to do it?" and s/he says "Ask P about that. Or go to the HW store and ask them" - if you on the contrary know what data you desire, and you know where it is, there is no need for any form of hypertext, be it "On-Line" or on the Internet. Instead of following links you go directly to the Rainbow's End, acquire the item, and return. The drawbacks from using Info compared to text are it's a mode from which you have much less experience and thus much less fluency, and it isn't always true that all your tweaks and extensions fit seamlessly into info, while this cannot be an issue for text, as that is the original habitate anyway! > And if I really wanted something like that, > I'd probably use "no new keystrokes to learn" > (using your own words!) and stick with plain > old `C-x n w'. > > Please try it out and tell me how your > solution is superior. You don't have to do `M-x text-mode RET' after you do `C-x n w'? -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: info-find-source 2018-01-14 2:54 ` info-find-source Emanuel Berg @ 2018-01-15 18:52 ` Marcin Borkowski [not found] ` <mailman.7433.1516042345.27995.help-gnu-emacs@gnu.org> 1 sibling, 0 replies; 838+ messages in thread From: Marcin Borkowski @ 2018-01-15 18:52 UTC (permalink / raw) To: Emanuel Berg; +Cc: help-gnu-emacs On 2018-01-14, at 03:54, Emanuel Berg <moasen@zoho.com> wrote: > Marcin Borkowski wrote: > > Actually, I cannot see "any gain" from > displaying the data as a tree! The only gain > I can see is hypertext. I see the point of > that, but I see that as something similar of, > you ask a person "how do you do X? what do you > need to do it?" and s/he says "Ask P about > that. Or go to the HW store and ask them" - if > you on the contrary know what data you desire, > and you know where it is, there is no need for > any form of hypertext, be it "On-Line" or on > the Internet. Instead of following links you go > directly to the Rainbow's End, acquire the > item, and return. Hypertext is an important gain. Convenience is another: many keys in Info do not need two keystrokes (`i' compared to `C-s'), so I can use Info with one hand. (And yes, I do it quite often.) > The drawbacks from using Info compared to text > are it's a mode from which you have much less > experience and thus much less fluency, and it > isn't always true that all your tweaks and > extensions fit seamlessly into info, while this > cannot be an issue for text, as that is the > original habitate anyway! But Info derives from special-mode, and shares many keys with other modes derived from that, like eww, dired etc. >> And if I really wanted something like that, >> I'd probably use "no new keystrokes to learn" >> (using your own words!) and stick with plain >> old `C-x n w'. >> >> Please try it out and tell me how your >> solution is superior. > > You don't have to do `M-x text-mode RET' after > you do `C-x n w'? Again: why would I? I would lose all the benefits (e.g., keybindings) from Info-mode! Best, -- Marcin Borkowski ^ permalink raw reply [flat|nested] 838+ messages in thread
[parent not found: <mailman.7433.1516042345.27995.help-gnu-emacs@gnu.org>]
* Re: info-find-source [not found] ` <mailman.7433.1516042345.27995.help-gnu-emacs@gnu.org> @ 2018-01-15 19:50 ` Emanuel Berg 0 siblings, 0 replies; 838+ messages in thread From: Emanuel Berg @ 2018-01-15 19:50 UTC (permalink / raw) To: help-gnu-emacs Marcin Borkowski wrote: > Hypertext is an important gain. Hypertext is an important gain to text systems just like inheritance is to OO systems, that said both are very easy to over-use and it shouldn't be relied upon, neither from the producer nor from the consumer side of a computer system. > Again: why would I? I would lose all the > benefits (e.g., keybindings) from Info-mode! That's the benefit: with text only, source file only, there is no need for Info-mode or any key that comes with it. -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 838+ messages in thread
* Reload file from disk
@ 2017-11-11 9:17 Florian Weimer
2017-11-11 10:29 ` Eli Zaretskii
` (2 more replies)
0 siblings, 3 replies; 838+ messages in thread
From: Florian Weimer @ 2017-11-11 9:17 UTC (permalink / raw)
To: emacs-devel
Some time ago, it was possible to reload the current buffer from disk
using C-x C-f RET. This was changed to run dired instead. The
argument at the time was you could use C-x C-f M-n RET to reload the
current buffer, and that dired was more important. The behavior of
M-n is documented for find-file at al.:
| but the visited file name is available through the minibuffer
| history: type M-n to pull it into the minibuffer.
But over the years, C-x C-f M-n RET started doing more and more
bizarre things. It now inserts the file name at point in the buffer,
which is particularly annoying if you try to reload a ChangeLog file.
And I just noticed that when on a domain name such as example.com, it
will apparently attempt to ping that host.
Can we please make M-n behave as documented in this context, or even
better, revert to the old C-x C-f RET behavior? One could always
browse the current directory using C-x C-f . RET, which is why never
understood the motivation behind that change.
^ permalink raw reply [flat|nested] 838+ messages in thread* Re: Reload file from disk 2017-11-11 9:17 Reload file from disk Florian Weimer @ 2017-11-11 10:29 ` Eli Zaretskii 2017-11-11 10:40 ` Eli Zaretskii 2017-11-11 12:44 ` Noam Postavsky 2017-11-12 18:28 ` Joost Kremers 2 siblings, 1 reply; 838+ messages in thread From: Eli Zaretskii @ 2017-11-11 10:29 UTC (permalink / raw) To: Florian Weimer; +Cc: emacs-devel > From: Florian Weimer <fw@deneb.enyo.de> > Date: Sat, 11 Nov 2017 10:17:18 +0100 > > | but the visited file name is available through the minibuffer > | history: type M-n to pull it into the minibuffer. > > But over the years, C-x C-f M-n RET started doing more and more > bizarre things. It now inserts the file name at point in the buffer, > which is particularly annoying if you try to reload a ChangeLog file. It does? I cannot reproduce this in "emacs -Q". Could it be that you have some optional package activated which does that? If not, can you show a recipe starting from "emacs -Q" that reproduces the behavior you describe? > And I just noticed that when on a domain name such as example.com, it > will apparently attempt to ping that host. This I can reproduce, and you can disable it by customizing file-name-at-point-functions to a nil value. > Can we please make M-n behave as documented in this context, or even > better, revert to the old C-x C-f RET behavior? One could always > browse the current directory using C-x C-f . RET, which is why never > understood the motivation behind that change. The previous behavior of "C-x C-f RET" was considered confusing and not very useful by many users, so I don't think we want to go back there. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Reload file from disk 2017-11-11 10:29 ` Eli Zaretskii @ 2017-11-11 10:40 ` Eli Zaretskii 2017-11-11 10:54 ` Florian Weimer 2017-11-11 11:59 ` Andreas Schwab 0 siblings, 2 replies; 838+ messages in thread From: Eli Zaretskii @ 2017-11-11 10:40 UTC (permalink / raw) To: fw; +Cc: emacs-devel > Date: Sat, 11 Nov 2017 12:29:24 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: emacs-devel@gnu.org > > > But over the years, C-x C-f M-n RET started doing more and more > > bizarre things. It now inserts the file name at point in the buffer, > > which is particularly annoying if you try to reload a ChangeLog file. > > It does? I cannot reproduce this in "emacs -Q". Sorry, I see that I misunderstood your somewhat ambiguous wording. I see what you meant now, and the answer is the same: customize file-name-at-point-functions to nil, and both the behaviors that annoyed you will be gone. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Reload file from disk 2017-11-11 10:40 ` Eli Zaretskii @ 2017-11-11 10:54 ` Florian Weimer 2017-11-11 11:55 ` Eli Zaretskii 2017-11-11 11:59 ` Andreas Schwab 1 sibling, 1 reply; 838+ messages in thread From: Florian Weimer @ 2017-11-11 10:54 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel * Eli Zaretskii: >> Date: Sat, 11 Nov 2017 12:29:24 +0200 >> From: Eli Zaretskii <eliz@gnu.org> >> Cc: emacs-devel@gnu.org >> >> > But over the years, C-x C-f M-n RET started doing more and more >> > bizarre things. It now inserts the file name at point in the buffer, >> > which is particularly annoying if you try to reload a ChangeLog file. >> >> It does? I cannot reproduce this in "emacs -Q". > > Sorry, I see that I misunderstood your somewhat ambiguous wording. I > see what you meant now, and the answer is the same: customize > file-name-at-point-functions to nil, and both the behaviors that > annoyed you will be gone. The documentation for find-file et al. still could use some updating and a reference to file-name-at-point-functions. For some reason, I was unable to find the latter. (I still find the default behavior thoroughly bizarre, but that's probably a matter of taste.) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Reload file from disk 2017-11-11 10:54 ` Florian Weimer @ 2017-11-11 11:55 ` Eli Zaretskii 2017-11-11 13:45 ` Ken Olum 0 siblings, 1 reply; 838+ messages in thread From: Eli Zaretskii @ 2017-11-11 11:55 UTC (permalink / raw) To: Florian Weimer; +Cc: emacs-devel > From: Florian Weimer <fw@deneb.enyo.de> > Cc: emacs-devel@gnu.org > Date: Sat, 11 Nov 2017 11:54:57 +0100 > > > Sorry, I see that I misunderstood your somewhat ambiguous wording. I > > see what you meant now, and the answer is the same: customize > > file-name-at-point-functions to nil, and both the behaviors that > > annoyed you will be gone. > > The documentation for find-file et al. still could use some updating > and a reference to file-name-at-point-functions. For some reason, I > was unable to find the latter. You are absolutely right, which is why I just updated the documentation, both the doc strings and the manual, to mention this. I was astonished to find out that this feature was first introduced in Emacs 23.2(!), but never mentioned even in NEWS. > (I still find the default behavior thoroughly bizarre, but that's > probably a matter of taste.) I'm with you, but it looks like we are the minority nowadays. Thanks for bringing up this awful gap in documentation. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Reload file from disk 2017-11-11 11:55 ` Eli Zaretskii @ 2017-11-11 13:45 ` Ken Olum 2017-11-11 14:11 ` Eli Zaretskii 0 siblings, 1 reply; 838+ messages in thread From: Ken Olum @ 2017-11-11 13:45 UTC (permalink / raw) To: emacs-devel From: Eli Zaretskii <eliz@gnu.org> Date: Sat, 11 Nov 2017 13:55:26 +0200 > From: Florian Weimer <fw@deneb.enyo.de> > (I still find the default behavior thoroughly bizarre, but that's > probably a matter of taste.) I'm with you, but it looks like we are the minority nowadays. I redefined find-file-read-args in my init file to reinstate the old behavior when the new came out. How about a variable to control this for the possibly large minority that prefer the old behavior? Ken ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Reload file from disk 2017-11-11 13:45 ` Ken Olum @ 2017-11-11 14:11 ` Eli Zaretskii 2017-11-11 15:03 ` Ken Olum 0 siblings, 1 reply; 838+ messages in thread From: Eli Zaretskii @ 2017-11-11 14:11 UTC (permalink / raw) To: Ken Olum; +Cc: emacs-devel > From: Ken Olum <kdo@cosmos.phy.tufts.edu> > Date: Sat, 11 Nov 2017 08:45:04 -0500 > > > (I still find the default behavior thoroughly bizarre, but that's > > probably a matter of taste.) > > I'm with you, but it looks like we are the minority nowadays. > > I redefined find-file-read-args in my init file to reinstate the old > behavior when the new came out. How about a variable to control this > for the possibly large minority that prefer the old behavior? There's already a variable: file-name-at-point-functions. It just was undocumented until now. Given that it's documented, do we still need a separate knob? ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Reload file from disk 2017-11-11 14:11 ` Eli Zaretskii @ 2017-11-11 15:03 ` Ken Olum 2017-11-11 16:48 ` Drew Adams 0 siblings, 1 reply; 838+ messages in thread From: Ken Olum @ 2017-11-11 15:03 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel From: Eli Zaretskii <eliz@gnu.org> Date: Sat, 11 Nov 2017 16:11:34 +0200 There's already a variable: file-name-at-point-functions. It just was undocumented until now. Given that it's documented, do we still need a separate knob? Sorry for the confusion. I think we're discussing different things here. My goal was to have the default for find-file (without typing M-n) be the current file, so that C-x C-f RET would reload the buffer. I think file-name-at-point-functions affects only the question of what you get when you type M-n. If there are enough people who would like C-x C-f RET to reload the buffer, perhaps there should be a variable for that. But perhaps there are not. (This has little consequence for me personally, since I already worked around it a different way.) Ken ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Reload file from disk 2017-11-11 15:03 ` Ken Olum @ 2017-11-11 16:48 ` Drew Adams 0 siblings, 0 replies; 838+ messages in thread From: Drew Adams @ 2017-11-11 16:48 UTC (permalink / raw) To: Ken Olum, Eli Zaretskii; +Cc: emacs-devel > My goal was to have the default for find-file (without typing > M-n) be the current file, so that C-x C-f RET would reload the buffer. FWIW, y'all should be talking about "finding" a Lisp file (in the sense of `find-file'), not "loading" a Lisp file (in the sense of `load-file' and `load-library'). I was confused for a while, because I thought you actually meant loading (evaluating) the file. And for loading, `M-x load-file' _does_ use the current buffer's file as the default. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Reload file from disk 2017-11-11 10:40 ` Eli Zaretskii 2017-11-11 10:54 ` Florian Weimer @ 2017-11-11 11:59 ` Andreas Schwab 1 sibling, 0 replies; 838+ messages in thread From: Andreas Schwab @ 2017-11-11 11:59 UTC (permalink / raw) To: Eli Zaretskii; +Cc: fw, emacs-devel On Nov 11 2017, Eli Zaretskii <eliz@gnu.org> wrote: >> Date: Sat, 11 Nov 2017 12:29:24 +0200 >> From: Eli Zaretskii <eliz@gnu.org> >> Cc: emacs-devel@gnu.org >> >> > But over the years, C-x C-f M-n RET started doing more and more >> > bizarre things. It now inserts the file name at point in the buffer, >> > which is particularly annoying if you try to reload a ChangeLog file. >> >> It does? I cannot reproduce this in "emacs -Q". > > Sorry, I see that I misunderstood your somewhat ambiguous wording. I > see what you meant now, and the answer is the same: customize > file-name-at-point-functions to nil, and both the behaviors that > annoyed you will be gone. Even better, bind revert-buffer to a key. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Reload file from disk 2017-11-11 9:17 Reload file from disk Florian Weimer 2017-11-11 10:29 ` Eli Zaretskii @ 2017-11-11 12:44 ` Noam Postavsky 2017-11-12 18:28 ` Joost Kremers 2 siblings, 0 replies; 838+ messages in thread From: Noam Postavsky @ 2017-11-11 12:44 UTC (permalink / raw) To: Florian Weimer; +Cc: Emacs developers On Sat, Nov 11, 2017 at 4:17 AM, Florian Weimer <fw@deneb.enyo.de> wrote: > Some time ago, it was possible to reload the current buffer from disk > using C-x C-f RET. This was changed to run dired instead. The > argument at the time was you could use C-x C-f M-n RET to reload the > current buffer, and that dired was more important. I usually use C-x C-v RET for this. Or if I want to reload because the file changed externally, SPC r (though the buffer must be in unmodified state for that). ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Reload file from disk 2017-11-11 9:17 Reload file from disk Florian Weimer 2017-11-11 10:29 ` Eli Zaretskii 2017-11-11 12:44 ` Noam Postavsky @ 2017-11-12 18:28 ` Joost Kremers 2017-11-13 17:24 ` Tom Tromey 2 siblings, 1 reply; 838+ messages in thread From: Joost Kremers @ 2017-11-12 18:28 UTC (permalink / raw) To: Florian Weimer; +Cc: emacs-devel On Sat, Nov 11 2017, Florian Weimer wrote: > Some time ago, it was possible to reload the current buffer from > disk > using C-x C-f RET. This was changed to run dired instead. Try C-x C-v (`find-alternate-file') instead: it defaults to the file currently being visited by the buffer, so you just need to type RET to reload it. -- Joost Kremers Life has its moments ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Reload file from disk 2017-11-12 18:28 ` Joost Kremers @ 2017-11-13 17:24 ` Tom Tromey 0 siblings, 0 replies; 838+ messages in thread From: Tom Tromey @ 2017-11-13 17:24 UTC (permalink / raw) To: Joost Kremers; +Cc: Florian Weimer, emacs-devel >>>>> "Joost" == Joost Kremers <joostkremers@fastmail.fm> writes: Joost> On Sat, Nov 11 2017, Florian Weimer wrote: >> Some time ago, it was possible to reload the current buffer from >> disk >> using C-x C-f RET. This was changed to run dired instead. Joost> Try C-x C-v (`find-alternate-file') instead: it defaults to the file Joost> currently being visited by the buffer, so you just need to type RET to Joost> reload it. This isn't always as nice as the old behavior of C-x C-f RET because it moves point to the start of the buffer. Tom ^ permalink raw reply [flat|nested] 838+ messages in thread
* How to get back to a place in a buffer, or: what is a window configuration?
@ 2016-08-03 9:30 Marcin Borkowski
2016-08-03 11:25 ` Kaushal Modi
` (2 more replies)
0 siblings, 3 replies; 838+ messages in thread
From: Marcin Borkowski @ 2016-08-03 9:30 UTC (permalink / raw)
To: Help Gnu Emacs mailing list
Hi all,
sometimes I work on a particular place in some buffer, and Emacs for
some reason scrolls me out of that place. I want then to get back to
it. Is there a way (in stock Emacs or with help of M?elpa) to
accomplish that?
Bonus points for a package/command which /temporarily/ disables C-v/M-v
and other commands that might result in scrolling text in the window.
(Narrowing to what is currently visible should do the trick, so
a combination of M-r, C-e and C-SPC would probably do what I want.
Coding that is three minutes, but maybe someone did it already?)
Note that it's not the same as keeping a position in a register.
A simple experiment shows that keeping a /window configurations/ seems
to do what I want, but from reading the manual I'm not sure what
a "window configuration" really is. What does a "window configuration"
consist of, exactly?
TIA,
--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University
^ permalink raw reply [flat|nested] 838+ messages in thread* Re: How to get back to a place in a buffer, or: what is a window configuration? 2016-08-03 9:30 How to get back to a place in a buffer, or: what is a window configuration? Marcin Borkowski @ 2016-08-03 11:25 ` Kaushal Modi 2016-08-03 18:31 ` Marcin Borkowski 2016-08-03 14:42 ` Drew Adams 2016-08-03 21:47 ` Robert Thorpe 2 siblings, 1 reply; 838+ messages in thread From: Kaushal Modi @ 2016-08-03 11:25 UTC (permalink / raw) To: Marcin Borkowski, Help Gnu Emacs mailing list Here are a couple of things that might help you: (1) Setting scroll-preserve-screen-position to a non-nil value. If you happen to C-c/M-v so that the point changes its position, but if the above is set to t and you reverse the scroll direction, you will find the cursor at the exact same position where you last left it. https://www.gnu.org/software/emacs/manual/html_node/emacs/Scrolling.html (2) Use C-u C-SPC When you do large vertical positions, emacs auto-saves the previous marks to the mark-ring. It is very convenient to jump back to those older marks by hitting C-u C-SPC. https://www.gnu.org/software/emacs/manual/html_node/emacs/Mark-Ring.html (3) Use winner-mode This is a golden mode, used to conveniently jump back and forth window configurations. The awesome thing is that you do not need to manually save those configurations. All window configuration changes are auto-saved. https://www.gnu.org/software/emacs/manual/html_node/emacs/Window-Convenience.html (4) Create mini wrapper functions to scroll current/other window without moving the cursor position. I have the below in my config. ;;; Scrolling ;; Keep point at its screen position if the scroll command moved it vertically ;; out of the window, e.g. when scrolling by full screens using C-v. (setq scroll-preserve-screen-position t) ;; Scroll without moving the point/cursor (defun modi/scroll-up (ln) "Scroll up by LN lines without moving the point. If LN is nil, defaults to 1 line." (interactive "p") (scroll-up ln)) (defun modi/scroll-down (ln) "Scroll down by LN lines without moving the point. If LN is nil, defaults to 1 line." (interactive "p") (scroll-down ln)) (defun modi/scroll-other-window-up (ln) "Scroll other window up by LN lines without moving the point. If LN is nil, defaults to 1 line." (interactive "p") (scroll-other-window ln)) (defun modi/scroll-other-window-down (ln) "Scroll other window down by LN lines without moving the point. If LN is nil, defaults to 1 line." (interactive "p") (scroll-other-window (- ln))) ;; Below bindings are made in global map and not in my minor mode as I want ;; other modes to override those bindings. (bind-keys ("<C-M-up>" . modi/scroll-down) ("<C-M-down>" . modi/scroll-up) ("<C-M-left>" . modi/scroll-other-window-down) ("<C-M-right>" . modi/scroll-other-window-up)) On Wed, Aug 3, 2016, 5:32 AM Marcin Borkowski <mbork@mbork.pl> wrote: > Hi all, > > sometimes I work on a particular place in some buffer, and Emacs for > some reason scrolls me out of that place. I want then to get back to > it. Is there a way (in stock Emacs or with help of M?elpa) to > accomplish that? > > Bonus points for a package/command which /temporarily/ disables C-v/M-v > and other commands that might result in scrolling text in the window. > (Narrowing to what is currently visible should do the trick, so > a combination of M-r, C-e and C-SPC would probably do what I want. > Coding that is three minutes, but maybe someone did it already?) > > Note that it's not the same as keeping a position in a register. > A simple experiment shows that keeping a /window configurations/ seems > to do what I want, but from reading the manual I'm not sure what > a "window configuration" really is. What does a "window configuration" > consist of, exactly? > > TIA, > > -- > Marcin Borkowski > http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski > Faculty of Mathematics and Computer Science > Adam Mickiewicz University > > -- Kaushal Modi ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: How to get back to a place in a buffer, or: what is a window configuration? 2016-08-03 11:25 ` Kaushal Modi @ 2016-08-03 18:31 ` Marcin Borkowski 0 siblings, 0 replies; 838+ messages in thread From: Marcin Borkowski @ 2016-08-03 18:31 UTC (permalink / raw) To: Kaushal Modi; +Cc: Help Gnu Emacs mailing list On 2016-08-03, at 13:25, Kaushal Modi <kaushal.modi@gmail.com> wrote: > Here are a couple of things that might help you: > > (1) Setting scroll-preserve-screen-position to a non-nil value. > If you happen to C-c/M-v so that the point changes its position, but if the > above is set to t and you reverse the scroll direction, you will find the > cursor at the exact same position where you last left it. > https://www.gnu.org/software/emacs/manual/html_node/emacs/Scrolling.html I know that, and I set scroll-preserve-screen-position to t in my init.el a long time ago. But thanks anyway, it is not very well known! > (2) Use C-u C-SPC > When you do large vertical positions, emacs auto-saves the previous marks > to the mark-ring. It is very convenient to jump back to those older marks > by hitting C-u C-SPC. > https://www.gnu.org/software/emacs/manual/html_node/emacs/Mark-Ring.html I know that, too, and I use it often. But point position is not what I'm asking for; I also want the point to get in the same place onthe screen, IOW, I want to preserve the first visible line. > (3) Use winner-mode > This is a golden mode, used to conveniently jump back and forth window > configurations. The awesome thing is that you do not need to manually save > those configurations. All window configuration changes are auto-saved. > https://www.gnu.org/software/emacs/manual/html_node/emacs/Window-Convenience.html I've heard about it, now that you recommend it, I'll try it out some day, probably sooner than later, thanks! > (4) Create mini wrapper functions to scroll current/other window without > moving the cursor position. I have the below in my config. I also had such functions some time ago, I must have deleted them from my config. OTOH, C-v/M-v with prefix arg seem to do the same, so hey seem a bit redundant to me. > ;;; Scrolling > ;; Keep point at its screen position if the scroll command moved it > vertically > ;; out of the window, e.g. when scrolling by full screens using C-v. > (setq scroll-preserve-screen-position t) > > ;; Scroll without moving the point/cursor > (defun modi/scroll-up (ln) > "Scroll up by LN lines without moving the point. > If LN is nil, defaults to 1 line." > (interactive "p") > (scroll-up ln)) > > (defun modi/scroll-down (ln) > "Scroll down by LN lines without moving the point. > If LN is nil, defaults to 1 line." > (interactive "p") > (scroll-down ln)) > > (defun modi/scroll-other-window-up (ln) > "Scroll other window up by LN lines without moving the point. > If LN is nil, defaults to 1 line." > (interactive "p") > (scroll-other-window ln)) > > (defun modi/scroll-other-window-down (ln) > "Scroll other window down by LN lines without moving the point. > If LN is nil, defaults to 1 line." > (interactive "p") > (scroll-other-window (- ln))) > > ;; Below bindings are made in global map and not in my minor mode as I want > ;; other modes to override those bindings. > (bind-keys > ("<C-M-up>" . modi/scroll-down) > ("<C-M-down>" . modi/scroll-up) > ("<C-M-left>" . modi/scroll-other-window-down) > ("<C-M-right>" . modi/scroll-other-window-up)) Thanks a lot! -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: How to get back to a place in a buffer, or: what is a window configuration? 2016-08-03 9:30 How to get back to a place in a buffer, or: what is a window configuration? Marcin Borkowski 2016-08-03 11:25 ` Kaushal Modi @ 2016-08-03 14:42 ` Drew Adams 2016-08-03 18:42 ` Marcin Borkowski 2016-08-03 21:47 ` Robert Thorpe 2 siblings, 1 reply; 838+ messages in thread From: Drew Adams @ 2016-08-03 14:42 UTC (permalink / raw) To: Marcin Borkowski, Help Gnu Emacs mailing list > sometimes I work on a particular place in some buffer, A place (position) in a buffer has little or nothing to do with windows. It sounds, from the rest of your question, like you are more interested in restoring a window configuration. But your question is still unclear, to me. Hopefully, Kaushal's answer gives you what you want. > and Emacs for some reason scrolls me out of that place. I want > then to get back to it. Getting back to a buffer position is simple - you can use temporary bookmarks or the mark ring or other methods. But I don't think that's really what you're asking. > Is there a way (in stock Emacs or with help of M?elpa) to > accomplish that? > > Bonus points for a package/command which /temporarily/ disables C-v/M-v > and other commands that might result in scrolling text in the window. I don't see the connection between that and your request (apparently) to restore a window config. Is it that you really (or additionally?) want to prevent moving `window-point'? or perhaps prevent it from moving too far? The underlying question or use case is not clear to me. > (Narrowing to what is currently visible should do the trick, so > a combination of M-r, C-e and C-SPC would probably do what I want. > Coding that is three minutes, but maybe someone did it already?) If narrowing to what is currently shown in the window is what you're looking for, then yes, you can easily code that. (If you use library zones.el then you can easily flip among multiple narrowings, in case that is related to what you want. https://www.emacswiki.org/emacs/MultipleNarrowings) > Note that it's not the same as keeping a position in a register. > A simple experiment shows that keeping a /window configurations/ seems > to do what I want, `C-x r w' puts window-config in a register. `C-x r j' restores it. > but from reading the manual I'm not sure what > a "window configuration" really is. What does a "window > configuration" consist of, exactly? What part of (elisp) `Window Configurations' is unclear to you? ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: How to get back to a place in a buffer, or: what is a window configuration? 2016-08-03 14:42 ` Drew Adams @ 2016-08-03 18:42 ` Marcin Borkowski 2016-08-03 19:39 ` Drew Adams 0 siblings, 1 reply; 838+ messages in thread From: Marcin Borkowski @ 2016-08-03 18:42 UTC (permalink / raw) To: Drew Adams; +Cc: Help Gnu Emacs mailing list On 2016-08-03, at 16:42, Drew Adams <drew.adams@oracle.com> wrote: >> sometimes I work on a particular place in some buffer, > > A place (position) in a buffer has little or nothing to do with > windows. By "place", I meant two things: (1) where the point is and (2) what is the first (topmost) actually displayed (visible) line. > It sounds, from the rest of your question, like you are more > interested in restoring a window configuration. But your > question is still unclear, to me. Hopefully, Kaushal's answer > gives you what you want. More or less. I'm now convinced that window configurations were what I was looking for. >> and Emacs for some reason scrolls me out of that place. I want >> then to get back to it. > > Getting back to a buffer position is simple - you can use > temporary bookmarks or the mark ring or other methods. But > I don't think that's really what you're asking. Right, it's not what I meant. >> Is there a way (in stock Emacs or with help of M?elpa) to >> accomplish that? >> >> Bonus points for a package/command which /temporarily/ disables C-v/M-v >> and other commands that might result in scrolling text in the window. > > I don't see the connection between that and your request > (apparently) to restore a window config. Is it that you really > (or additionally?) want to prevent moving `window-point'? > or perhaps prevent it from moving too far? The underlying > question or use case is not clear to me. My goal (though probably not my words;-), sorry) is simple: I want the "place" (in the sense of the above definition) to stay the same, /or/ I want to be able to easily restore it. The former should be doable with narrowing, the latter probably with window configurations. >> (Narrowing to what is currently visible should do the trick, so >> a combination of M-r, C-e and C-SPC would probably do what I want. >> Coding that is three minutes, but maybe someone did it already?) > > If narrowing to what is currently shown in the window is > what you're looking for, then yes, you can easily code that. > > (If you use library zones.el then you can easily flip among > multiple narrowings, in case that is related to what you want. > https://www.emacswiki.org/emacs/MultipleNarrowings) I heard about it, though I don't really see much use (for me, not in general). OTOH, I use narrowing quite a lot, so maybe I could give it a try. >> Note that it's not the same as keeping a position in a register. >> A simple experiment shows that keeping a /window configurations/ seems >> to do what I want, > > `C-x r w' puts window-config in a register. `C-x r j' restores it. I learned about it today while rereading the manual. Very useful indeed! >> but from reading the manual I'm not sure what >> a "window configuration" really is. What does a "window >> configuration" consist of, exactly? > > What part of (elisp) `Window Configurations' is unclear to you? Well, now I see it... But look at this: ,----[ (emacs) Configuration Registers ] | You can save the window configuration of the selected frame in a | register, or even the configuration of all windows in all frames, and | restore the configuration later. *Note Windows::, for information about | window configurations. `---- ,----[ (emacs) Window Convenience ] | Winner mode is a global minor mode that records the changes in the | window configuration (i.e., how the frames are partitioned into | windows), so that you can undo them. `---- See? Basically nothing in the /Emacs manual/ explains precisely what a "window configuration" is. On the other hand, the /Elisp reference/ is pretty clear. I'd consider this a bug in the docs: a /user/ should not need to consult the Elisp reference. I'll try to come up with a patch for the docs soon. Thanks, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: How to get back to a place in a buffer, or: what is a window configuration? 2016-08-03 18:42 ` Marcin Borkowski @ 2016-08-03 19:39 ` Drew Adams 0 siblings, 0 replies; 838+ messages in thread From: Drew Adams @ 2016-08-03 19:39 UTC (permalink / raw) To: Marcin Borkowski; +Cc: Help Gnu Emacs mailing list > > (If you use library zones.el then you can easily flip among > > multiple narrowings, in case that is related to what you want. > > https://www.emacswiki.org/emacs/MultipleNarrowings) > > I heard about it, though I don't really see much use (for me, not in > general). OTOH, I use narrowing quite a lot, so maybe I could give > it a try. If it doesn't help, don't use it. ;-) The idea is simple: Emacs lets you narrow to different restrictions, but there is only one level of widening: `widen'. This is analogous to simple copy+paste systems: you can copy different things at different times, but when you paste you get just the last thing copied. With this extension to narrowing: when you narrow, the restriction is pushed to a ring - analogously to copying/killing text to the `kill-ring'. And just as you can yank anything that is on the `kill-ring', so you can restore any restriction (narrowing) from the ring. (And you can have multiple rings, buffer-local or not.) As for whether you will find that useful: it might depend on how much you use narrowing. And perhaps also on what you are used to (habit). People used to simple copy+paste might not find the `kill-ring' very useful at first... > > What part of (elisp) `Window Configurations' is unclear to you? > > Well, now I see it... But look at this: > ,----[ (emacs) Configuration Registers ] ... > ,----[ (emacs) Window Convenience ] ... > See? Basically nothing in the /Emacs manual/ explains precisely what > a "window configuration" is. On the other hand, the /Elisp reference/ > is pretty clear. I'd consider this a bug in the docs: a /user/ should > not need to consult the Elisp reference. I'll try to come up with > a patch for the docs soon. What do you think a user should know about what a window config is? That's the question, if you think the Emacs manual needs more info. (`M-x report-emacs-bug'). (Note that there can also be links between the manuals.) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: How to get back to a place in a buffer, or: what is a window configuration? 2016-08-03 9:30 How to get back to a place in a buffer, or: what is a window configuration? Marcin Borkowski 2016-08-03 11:25 ` Kaushal Modi 2016-08-03 14:42 ` Drew Adams @ 2016-08-03 21:47 ` Robert Thorpe 2016-08-03 22:06 ` Drew Adams 2 siblings, 1 reply; 838+ messages in thread From: Robert Thorpe @ 2016-08-03 21:47 UTC (permalink / raw) To: Marcin Borkowski; +Cc: help-gnu-emacs Marcin Borkowski <mbork@mbork.pl> writes: > Hi all, > > sometimes I work on a particular place in some buffer, and Emacs for > some reason scrolls me out of that place. I used to have the problem. I found it was caused by using auto-revert-mode. It was either applying auto-revert-mode to dired buffers or applying it to buffer lists that caused the problem, I can't remember which. Try disabling those and see if it fixes it. BR, Robert Thorpe ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: How to get back to a place in a buffer, or: what is a window configuration? 2016-08-03 21:47 ` Robert Thorpe @ 2016-08-03 22:06 ` Drew Adams 0 siblings, 0 replies; 838+ messages in thread From: Drew Adams @ 2016-08-03 22:06 UTC (permalink / raw) To: Robert Thorpe, Marcin Borkowski; +Cc: help-gnu-emacs > > sometimes I work on a particular place in some buffer, and Emacs for > > some reason scrolls me out of that place. > > I used to have the problem. I found it was caused by using > auto-revert-mode. It was either applying auto-revert-mode to dired > buffers or applying it to buffer lists that caused the problem, I can't > remember which. Try disabling those and see if it fixes it. Reverting a Dired buffer centers the line that was current, and puts the cursor at the beginning of the file name on that line. This happens regardless of how you revert (using `g' or using `auto-rever-mode'). For buffer reverting, you have `after-revert-hook' (and `before...'), which you could no doubt use to counteract any such window and point movement. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Overriding emacs key bindings
@ 2016-05-13 14:20 xiongtk
2016-05-16 18:04 ` Eli Zaretskii
2016-05-16 18:59 ` Emanuel Berg
0 siblings, 2 replies; 838+ messages in thread
From: xiongtk @ 2016-05-13 14:20 UTC (permalink / raw)
To: help-gnu-emacs
Hi! I'm in a situation where I would like to override the following key
binding:
/Applications/Emacs.app/Contents/Resources/lisp/international/mule-cmds.el.gz
(define-key global-map "\C-\\" 'toggle-input-method)
Since this file is read only and it's not inside .emacs.d, I do not
want to change it directly if other solutions are possible.
I've tried with writing the following line in my personal customization
file:
(define-key global-map (kbd "<f8>") 'toggle-input-method)
or
(global-set-key (kbd "<f8>") 'toggle-input-method)
(I've tried both.)
Which assigns f8 to be the key binding.
However, checking the key binding with C-h a toggle-input-method gives me
the following message:
Type M-x apropos-follow on an entry to view its full documentation.
isearch-toggle-input-method M-x ... RET
Toggle input method in interactive search.
toggle-input-method <menu-bar> <options> <mule> <toggle-input-method>, <f8>, C-\
:around advice: `ad-Advice-toggle-input-method'
Apparently my method does not override the original key binding. Any
suggestions?
P.S. About why I want to do that, I use evil-leader which uses "\" as
the leader key. To execute evil-leader key bindings in non normal mode of
evil-mode, I need to use C-\ as the leader key. So it conflicts with
the default key binding for toggle-input-method.
^ permalink raw reply [flat|nested] 838+ messages in thread* Re: Overriding emacs key bindings 2016-05-13 14:20 Overriding emacs key bindings xiongtk @ 2016-05-16 18:04 ` Eli Zaretskii 2016-05-16 21:15 ` xiongtk 2016-05-16 18:59 ` Emanuel Berg 1 sibling, 1 reply; 838+ messages in thread From: Eli Zaretskii @ 2016-05-16 18:04 UTC (permalink / raw) To: help-gnu-emacs > From: xiongtk <xiongtk@gmail.com> > Date: Fri, 13 May 2016 16:20:58 +0200 > > Hi! I'm in a situation where I would like to override the following key > binding: > > /Applications/Emacs.app/Contents/Resources/lisp/international/mule-cmds.el.gz > > (define-key global-map "\C-\\" 'toggle-input-method) > > > Since this file is read only and it's not inside .emacs.d, I do not > want to change it directly if other solutions are possible. > > I've tried with writing the following line in my personal customization > file: > > (define-key global-map (kbd "<f8>") 'toggle-input-method) > or > (global-set-key (kbd "<f8>") 'toggle-input-method) > > (I've tried both.) > Which assigns f8 to be the key binding. > > However, checking the key binding with C-h a toggle-input-method gives me > the following message: > > Type M-x apropos-follow on an entry to view its full documentation. > > isearch-toggle-input-method M-x ... RET > Toggle input method in interactive search. > toggle-input-method <menu-bar> <options> <mule> <toggle-input-method>, <f8>, C-\ > :around advice: `ad-Advice-toggle-input-method' > > > Apparently my method does not override the original key binding. Correct. It just adds another binding. > Any suggestions? You want global-unset-key, evidently. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Overriding emacs key bindings 2016-05-16 18:04 ` Eli Zaretskii @ 2016-05-16 21:15 ` xiongtk 0 siblings, 0 replies; 838+ messages in thread From: xiongtk @ 2016-05-16 21:15 UTC (permalink / raw) To: help-gnu-emacs Eli Zaretskii <eliz@gnu.org> writes: >> From: xiongtk <xiongtk@gmail.com> >> Date: Fri, 13 May 2016 16:20:58 +0200 >> >> Hi! I'm in a situation where I would like to override the following key >> binding: >> >> /Applications/Emacs.app/Contents/Resources/lisp/international/mule-cmds.el.gz >> >> (define-key global-map "\C-\\" 'toggle-input-method) >> >> >> Since this file is read only and it's not inside .emacs.d, I do not >> want to change it directly if other solutions are possible. >> >> I've tried with writing the following line in my personal customization >> file: >> >> (define-key global-map (kbd "<f8>") 'toggle-input-method) >> or >> (global-set-key (kbd "<f8>") 'toggle-input-method) >> >> (I've tried both.) >> Which assigns f8 to be the key binding. >> >> However, checking the key binding with C-h a toggle-input-method gives me >> the following message: >> >> Type M-x apropos-follow on an entry to view its full documentation. >> >> isearch-toggle-input-method M-x ... RET >> Toggle input method in interactive search. >> toggle-input-method <menu-bar> <options> <mule> <toggle-input-method>, <f8>, C-\ >> :around advice: `ad-Advice-toggle-input-method' >> >> >> Apparently my method does not override the original key binding. > > Correct. It just adds another binding. > >> Any suggestions? > > You want global-unset-key, evidently. Thanks for your advice! ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Overriding emacs key bindings 2016-05-13 14:20 Overriding emacs key bindings xiongtk 2016-05-16 18:04 ` Eli Zaretskii @ 2016-05-16 18:59 ` Emanuel Berg 2016-05-16 21:14 ` xiongtk 1 sibling, 1 reply; 838+ messages in thread From: Emanuel Berg @ 2016-05-16 18:59 UTC (permalink / raw) To: help-gnu-emacs xiongtk <xiongtk@gmail.com> writes: > Since this file is read only and it's not > inside .emacs.d, I do not want to change it > directly if other solutions are possible. Good call! Because then you'll loose it for example when you upgrade Emacs, and each edit would require a sudo detour... > I've tried with writing the following line in > my personal customization file: > > (define-key global-map (kbd "<f8>") > 'toggle-input-method) or (global-set-key (kbd > "<f8>") 'toggle-input-method) Instead of (kbd "<f8>"), you can do [f8]. (But: I don't recommend using the function keys as they are remote (i.e., require arm movement as opposed to just finger ditto, which in turn implies a reset to typing position) - also they are confusing (too alike) and thus difficult to remember. And they don't work in a VT Emacs instance! - not without special efforts [1] at least.) > Apparently my method does not override the > original key binding. Any suggestions? By "override", do you mean the new keystroke won't work, or the old keystroke remains? If the old keystroke remains, that is normal. You can unset it like this: (global-unset-key "\C-hh") If the new keystroke doesn't work, sometimes it is the case that a *local* keymap has that key assigned. Changing the global keymap doesn't change the local map, of course, and the local map has priority, as far as locally goes! Here is some code to automatize setting a global key, and then disabling the same key for the desired local modes - if you want the global key to be in effect there, as well. Use the functions in the order they appear. (defvar super-global-keys '()) (defun super-global-set-key (key function) "Make a super global KEY that invokes FUNCTION." (global-set-key key function) (add-to-list 'super-global-keys key) ) (defun disable-super-global-keys (&optional map) "Disable MAP super global keystrokes, so they can be assigned." (dolist (k super-global-keys) (define-key (or map (current-local-map)) k nil) )) [1] http://user.it.uu.se/~embe8573/tty-emacs-keys.txt -- underground experts united .... http://user.it.uu.se/~embe8573 Emacs Gnus Blogomatic ......... http://user.it.uu.se/~embe8573/blogomatic - so far: 30 Blogomatic articles - ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Overriding emacs key bindings 2016-05-16 18:59 ` Emanuel Berg @ 2016-05-16 21:14 ` xiongtk 2016-05-16 23:29 ` Emanuel Berg 0 siblings, 1 reply; 838+ messages in thread From: xiongtk @ 2016-05-16 21:14 UTC (permalink / raw) To: help-gnu-emacs Emanuel Berg <embe8573@student.uu.se> writes: > xiongtk <xiongtk@gmail.com> writes: > >> Since this file is read only and it's not >> inside .emacs.d, I do not want to change it >> directly if other solutions are possible. > > Good call! Because then you'll loose it for > example when you upgrade Emacs, and each edit > would require a sudo detour... > >> I've tried with writing the following line in >> my personal customization file: >> >> (define-key global-map (kbd "<f8>") >> 'toggle-input-method) or (global-set-key (kbd >> "<f8>") 'toggle-input-method) > > Instead of (kbd "<f8>"), you can do [f8]. > > (But: I don't recommend using the function keys > as they are remote (i.e., require arm movement > as opposed to just finger ditto, which in turn > implies a reset to typing position) - also they > are confusing (too alike) and thus difficult to > remember. And they don't work in a VT Emacs > instance! - not without special efforts [1] > at least.) > I kind of run out of keys on my keyboard. Since this function is rarely used(I use English for 99% of the time), I think the function keys is fine. >> Apparently my method does not override the >> original key binding. Any suggestions? > > By "override", do you mean the new keystroke > won't work, or the old keystroke remains? > > If the old keystroke remains, that is normal. > You can unset it like this: > > (global-unset-key "\C-hh") > > If the new keystroke doesn't work, sometimes it > is the case that a *local* keymap has that key > assigned. Changing the global keymap doesn't > change the local map, of course, and the local > map has priority, as far as locally goes! > > Here is some code to automatize setting > a global key, and then disabling the same key > for the desired local modes - if you want the > global key to be in effect there, as well. > Use the functions in the order they appear. > > (defvar super-global-keys '()) > > (defun super-global-set-key (key function) > "Make a super global KEY that invokes FUNCTION." > (global-set-key key function) > (add-to-list 'super-global-keys key) ) > > (defun disable-super-global-keys (&optional map) > "Disable MAP super global keystrokes, so they can be assigned." > (dolist (k super-global-keys) > (define-key (or map (current-local-map)) k nil) )) > > [1] http://user.it.uu.se/~embe8573/tty-emacs-keys.txt I believe (global-unset-key ) is what I'm searching for. Thank you! ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Overriding emacs key bindings 2016-05-16 21:14 ` xiongtk @ 2016-05-16 23:29 ` Emanuel Berg 2016-05-17 1:55 ` Robert Thorpe ` (2 more replies) 0 siblings, 3 replies; 838+ messages in thread From: Emanuel Berg @ 2016-05-16 23:29 UTC (permalink / raw) To: help-gnu-emacs xiongtk <xiongtk@gmail.com> writes: > I kind of run out of keys on my keyboard. > Since this function is rarely used(I use > English for 99% of the time), I think the > function keys is fine. To each his own. And Emacs makes that much easier to achieve. By changing Emacs, you become a better programmer and better computer user, and even Emacs gets better, until the point you realize there is already a built-in function, or module, that does what you have done, only better, and then it all starts over at a higher level... Because, if anything can start anew, then everything must continue! That said, if you rarely use the function, there is no need for a shortcut. Remember, "optimize the common case". If you think it is to much to type the actual function name, instead make an alias - or several! You'll find that it is actually faster to invoke as it is easier to remember and, again, does not require arm movement way from typing position. Why several aliases? Because sometimes you remember "test-colors", and sometimes "color-test" - with aliases, they can all be correct! But here, compare: will you remember that "color-test" years ago was assigned F6? So, e.g., (defalias 'download 'w3m-dl-dwim) (defalias 'dl 'w3m-dl-dwim) Regardless, I don't think you are running out of shutcuts :) Many shortcuts are assigned to stuff you never use - you can replace those. It is not because the stuff is bad - it can be just appealing to another personality, or involve technology you just don't use! Here is a tool - eval, invoke, and start hammering away, and you'll see: (defun show-key-command (&optional the-key command) (interactive) (let*((key-prompt "(hit key! or C-g to quit)") (prompt (if command (format " %s %s " command key-prompt) key-prompt)) (key (or the-key (read-key-sequence-vector prompt))) (new-command (key-binding key)) (command-or-undefined (or new-command "undefined")) ) (if the-key (message "%s" command-or-undefined) (unless (equal key [7]) ; [7] is C-g (show-key-command nil command-or-undefined) )))) If you really *do* run out of shortcuts, get a new prefix key, e.g. C-o which is short and close - check your hands when at asdf jkl; and note the required movement to strike C-o! Now even a new world of shortcuts opens. E.g., (define-prefix-command 'C-o-prefix) (global-set-key "\C-o" 'C-o-prefix) (global-set-key "\C-ow" #'window-increase-size) -- underground experts united .... http://user.it.uu.se/~embe8573 Emacs Gnus Blogomatic ......... http://user.it.uu.se/~embe8573/blogomatic - so far: 31 Blogomatic articles - ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Overriding emacs key bindings 2016-05-16 23:29 ` Emanuel Berg @ 2016-05-17 1:55 ` Robert Thorpe 2016-05-17 2:41 ` Emanuel Berg ` (3 more replies) 2016-05-17 4:43 ` Marcin Borkowski 2016-05-17 4:49 ` Marcin Borkowski 2 siblings, 4 replies; 838+ messages in thread From: Robert Thorpe @ 2016-05-17 1:55 UTC (permalink / raw) To: Emanuel Berg, xiongtk; +Cc: help-gnu-emacs Emanuel Berg <embe8573@student.uu.se> writes: > xiongtk <xiongtk@gmail.com> writes: >> I kind of run out of keys on my keyboard. >> Since this function is rarely used(I use >> English for 99% of the time), I think the >> function keys is fine. ... > > If you really *do* run out of shortcuts, get > a new prefix key, e.g. C-o which is short and > close - check your hands when at asdf jkl; and > note the required movement to strike C-o! > > Now even a new world of shortcuts opens. E.g., Personally, I'm very used to C-o being open-line. That said, I agree with Emmanuel in general about this. There are a lot of options that people don't consider. Emacs reserves all keybindings of the type C-c C-<something> for modes. However, if the second key doesn't begin with ctrl then the user can use it. The entire C-c <something> keymap is reserved for the user. The something can be any key that's not prefixed by ctrl or meta. Any key works, even the numbers and symbols on the keyboard. Capitals and small letters aren't treated the same, so there's a huge space there for new keybindings. Then there are rarely used prefix keys, like the key for marking text, you can attach stuff to that one. BR, Robert Thorpe ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Overriding emacs key bindings 2016-05-17 1:55 ` Robert Thorpe @ 2016-05-17 2:41 ` Emanuel Berg 2016-05-17 4:07 ` Drew Adams 2016-05-17 3:25 ` Kaushal Modi ` (2 subsequent siblings) 3 siblings, 1 reply; 838+ messages in thread From: Emanuel Berg @ 2016-05-17 2:41 UTC (permalink / raw) To: help-gnu-emacs Robert Thorpe <rt@robertthorpeconsulting.com> writes: > Personally, I'm very used to C-o being > open-line. That said, I agree with Emmanuel > in general about this. > > There are a lot of options that people don't > consider. Emacs reserves all keybindings of > the type C-c C-<something> for modes. > > However, if the second key doesn't begin with > ctrl then the user can use it. The entire C-c > <something> keymap is reserved for the user. That is generous, however Emacs is even more generous and the user can assign any shortcut. I think C-o is better as 1) o is easier to hit than c, and 2) with C-c, both keys are on the left hand side (little and index finger hitting the keys), while with C-o, there is a pleasant combination of left and right, and the left index finger remains at f! (Now in Russia, there was once a civil war that lay the entire land to ashes, and the dispute was how to make the cross sign - either initially horizontally, or vertically! Talk about stupid...) But I also suspect C-c "single key" is underused. Luckily it is just a key so it doesn't have hurt feelings. > The something can be any key that's not > prefixed by ctrl or meta. Any key works, even > the numbers and symbols on the keyboard. > Capitals and small letters aren't treated the > same, so there's a huge space there for new > keybindings. Then there are rarely used > prefix keys, like the key for marking text, > you can attach stuff to that one. Absolutely, you don't have to hold a Ph.D. in combinatorics to understand there are more combinations than 99% of Joe Elisp Hackers could ever use sensibly! Because Emacs is like a workshop filled with tools, or a library but not with fiction but formulas and methods and strategies. You can benefit several lifetimes (if you live that long) from them tools and books, but you still will never have laid hand on every single one of them. It is just the way it goes. -- underground experts united .... http://user.it.uu.se/~embe8573 Emacs Gnus Blogomatic ......... http://user.it.uu.se/~embe8573/blogomatic - so far: 32 Blogomatic articles - ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Overriding emacs key bindings 2016-05-17 2:41 ` Emanuel Berg @ 2016-05-17 4:07 ` Drew Adams 0 siblings, 0 replies; 838+ messages in thread From: Drew Adams @ 2016-05-17 4:07 UTC (permalink / raw) To: Emanuel Berg, help-gnu-emacs > > However, if the second key doesn't begin with > > ctrl then the user can use it. The entire C-c > > <something> keymap is reserved for the user. > > That is generous, however Emacs is even more > generous and the user can assign any shortcut. Right. Users can bind any keys. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Overriding emacs key bindings 2016-05-17 1:55 ` Robert Thorpe 2016-05-17 2:41 ` Emanuel Berg @ 2016-05-17 3:25 ` Kaushal Modi 2016-05-17 4:07 ` Drew Adams ` (2 more replies) 2016-05-17 4:07 ` Drew Adams 2016-05-17 4:44 ` Overriding emacs key bindings Marcin Borkowski 3 siblings, 3 replies; 838+ messages in thread From: Kaushal Modi @ 2016-05-17 3:25 UTC (permalink / raw) To: Robert Thorpe, Emanuel Berg, xiongtk; +Cc: help-gnu-emacs On Mon, May 16, 2016, 9:56 PM Robert Thorpe <rt@robertthorpeconsulting.com> wrote: > The entire > C-c <something> keymap is reserved for the user. The something can be > any key that's not prefixed by ctrl or meta. Any key works, even the > numbers and symbols on the keyboard. While I do agree that a wide range of user bindings are available with C-c prefix, I would not recommend blindly using all available "C-c SYMBOL" bindings without checking of org-mode already uses them especially if you use org-mode a lot. I now first check if a new binding conflicts with org-mode before creating a new personal C-c binding. You can also check out the key-chord package from Melpa for a wider range of bindings. -- -- Kaushal Modi ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Overriding emacs key bindings 2016-05-17 3:25 ` Kaushal Modi @ 2016-05-17 4:07 ` Drew Adams 2016-05-17 4:15 ` Emanuel Berg 2016-05-17 20:38 ` Robert Thorpe 2 siblings, 0 replies; 838+ messages in thread From: Drew Adams @ 2016-05-17 4:07 UTC (permalink / raw) To: Kaushal Modi, Robert Thorpe, Emanuel Berg, xiongtk; +Cc: help-gnu-emacs > While I do agree that a wide range of user bindings are available with C-c > prefix, I would not recommend blindly using all available "C-c SYMBOL" > bindings without checking of org-mode already uses them especially if you > use org-mode a lot. I now first check if a new binding conflicts with > org-mode before creating a new personal C-c binding. Sure, if you use a mode that assigns certain keys, and if you want to use those keys for that mode, then use those keys for that mode. But if you want to use those keys for something else, you can always bind different keys for use by the mode. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Overriding emacs key bindings 2016-05-17 3:25 ` Kaushal Modi 2016-05-17 4:07 ` Drew Adams @ 2016-05-17 4:15 ` Emanuel Berg 2016-05-17 20:38 ` Robert Thorpe 2 siblings, 0 replies; 838+ messages in thread From: Emanuel Berg @ 2016-05-17 4:15 UTC (permalink / raw) To: help-gnu-emacs Kaushal Modi <kaushal.modi@gmail.com> writes: > While I do agree that a wide range of user > bindings are available with C-c prefix, > I would not recommend blindly using all > available "C-c SYMBOL" bindings without > checking of org-mode already uses them > especially if you use org-mode a lot. I now > first check if a new binding conflicts with > org-mode before creating a new personal > C-c binding. Interesting - in other words, it is _org-mode_ that decides what keybindings you use... Another idea, if you look for some intuitive degree of consistency, is to identify "key" concepts. For example, one such concept is "to execute". In this message-mode, C-c C-c is to send the message. I'd say that is to execute, in the setting of typing a mail! Likewise a piece of code - to execute is either to launch the program, or to compile it. Perhaps it is launch if it is a shell script, but compile if it is LaTeX source! A global DWIM function with branching can do this, or each mode can have its own function that locally is associated with C-c C-c. In Dired (and a Gnus summary for that matter), there are a bunch of things you can mark the files (posts) so that it will happen when you - execute. And in Emacs-w3m, you can fill forms with data and submit with the same key! Another axis of intuitiveness is the modes when there is no typing. Here, the whole keyboard can be used to fire of defuns! But even cooler if this mirrors, only simplifies, the standard keystrokes. Say you have scroll up one line with M-i, and ditto down with M-j. You have this all over Emacs. [1] But in w3m, which doesn't require typing when you "browse" (yuk, that word!) - here, make it super-comfortable by keeping the M-i and M-j, but supplementing with i and j, to do the same thing! So there is no need to fear getting in the way of what is already there. Instead think what you would like to do. [1] http://user.it.uu.se/~embe8573/conf/emacs-init/scroll.el -- underground experts united .... http://user.it.uu.se/~embe8573 Emacs Gnus Blogomatic ......... http://user.it.uu.se/~embe8573/blogomatic - so far: 32 Blogomatic articles - ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Overriding emacs key bindings 2016-05-17 3:25 ` Kaushal Modi 2016-05-17 4:07 ` Drew Adams 2016-05-17 4:15 ` Emanuel Berg @ 2016-05-17 20:38 ` Robert Thorpe 2 siblings, 0 replies; 838+ messages in thread From: Robert Thorpe @ 2016-05-17 20:38 UTC (permalink / raw) To: Kaushal Modi; +Cc: help-gnu-emacs, embe8573, xiongtk Kaushal Modi <kaushal.modi@gmail.com> writes: > While I do agree that a wide range of user bindings are available with C-c > prefix, I would not recommend blindly using all available "C-c SYMBOL" > bindings without checking of org-mode already uses them especially if you > use org-mode a lot. I now first check if a new binding conflicts with > org-mode before creating a new personal C-c binding. You're right. I didn't know that Org uses those keys. BR, Robert Thorpe ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Overriding emacs key bindings 2016-05-17 1:55 ` Robert Thorpe 2016-05-17 2:41 ` Emanuel Berg 2016-05-17 3:25 ` Kaushal Modi @ 2016-05-17 4:07 ` Drew Adams 2016-05-18 1:42 ` Emacs conventions (was: Re: Overriding emacs key bindings) Emanuel Berg 2016-05-17 4:44 ` Overriding emacs key bindings Marcin Borkowski 3 siblings, 1 reply; 838+ messages in thread From: Drew Adams @ 2016-05-17 4:07 UTC (permalink / raw) To: Robert Thorpe, Emanuel Berg, xiongtk; +Cc: help-gnu-emacs > Emacs reserves all keybindings of the type C-c C-<something> > for modes. No, it does not. Emacs does not reserve any keys from users. Users can bind any keys they like. What Emacs reserves (by convention) are keys from modes. It says that major modes should use only these keys and minor modes should use only those keys. And neither major nor minor should use a third set of keys, which are _only_ for users (again, by convention). But users can use _any_ keys. > However, if the second key doesn't begin with ctrl then > the user can use it. Doesn't matter what the first or second key is. Users can use all keys. They can override any key bound by any mode. Thank goodness. It would be silly if some keys were reserved for modes and not allowed for users. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Emacs conventions (was: Re: Overriding emacs key bindings) 2016-05-17 4:07 ` Drew Adams @ 2016-05-18 1:42 ` Emanuel Berg 2016-05-18 4:38 ` Drew Adams [not found] ` <mailman.37.1463546355.6543.help-gnu-emacs@gnu.org> 0 siblings, 2 replies; 838+ messages in thread From: Emanuel Berg @ 2016-05-18 1:42 UTC (permalink / raw) To: help-gnu-emacs Drew Adams <drew.adams@oracle.com> writes: > What Emacs reserves (by convention) are keys > from modes. It says that major modes should > use only these keys and minor modes should > use only those keys. And neither major nor > minor should use a third set of keys, which > are _only_ for users (again, by convention). Are those "Emacs conventions" - and not just those who deal with keys - summarized somewhere? Because they are obviously good to be aware of, so when you disregard them, it is something you do because you think it'll benefit you, and not because you are unaware of something that on the contrary makes sense... -- underground experts united .... http://user.it.uu.se/~embe8573 Emacs Gnus Blogomatic ......... http://user.it.uu.se/~embe8573/blogomatic - so far: 32 Blogomatic articles - ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Emacs conventions (was: Re: Overriding emacs key bindings) 2016-05-18 1:42 ` Emacs conventions (was: Re: Overriding emacs key bindings) Emanuel Berg @ 2016-05-18 4:38 ` Drew Adams 2016-05-18 5:22 ` Emanuel Berg [not found] ` <mailman.37.1463546355.6543.help-gnu-emacs@gnu.org> 1 sibling, 1 reply; 838+ messages in thread From: Drew Adams @ 2016-05-18 4:38 UTC (permalink / raw) To: Emanuel Berg, help-gnu-emacs > > What Emacs reserves (by convention) are keys > > from modes. It says that major modes should > > use only these keys and minor modes should > > use only those keys. And neither major nor > > minor should use a third set of keys, which > > are _only_ for users (again, by convention). > > Are those "Emacs conventions" - and not just > those who deal with keys - summarized somewhere? (elisp) `Key Binding Conventions': http://www.gnu.org/software/emacs/manual/html_node/elisp/Key-Binding-Conventions.html > Because they are obviously good to be aware of, > so when you disregard them, it is something you > do because you think it'll benefit you, and not > because you are unaware of something that on > the contrary makes sense... Yes, they are good to be aware of. But again, they are for someone writing a library for more than personal use. They are in no way restrictions on users. There is no convention (that I know of) that restricts key bindings for users or even suggests that users should stay away from certain keys. The exceptions I can think of, in terms of suggestions, are `C-u' and `C-g'. You might get into some difficulty if you try to bind `C-u' (and a few users seem to want to do that). You can use another key in place of `C-g', but there are some hard-coded bindings of `C-g' to its usual behavior, AFAIK. I would recommend that no one try to use `C-g' or `C-u' for something else. (But there is no restriction against trying to do that.) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Emacs conventions (was: Re: Overriding emacs key bindings) 2016-05-18 4:38 ` Drew Adams @ 2016-05-18 5:22 ` Emanuel Berg 2016-05-18 5:36 ` "First line is not a complete sentence" (was: Re: Emacs conventions (was: Re: Overriding emacs key bindings)) Emanuel Berg [not found] ` <mailman.40.1463549841.6543.help-gnu-emacs@gnu.org> 0 siblings, 2 replies; 838+ messages in thread From: Emanuel Berg @ 2016-05-18 5:22 UTC (permalink / raw) To: help-gnu-emacs Drew Adams <drew.adams@oracle.com> writes: > Yes, they are good to be aware of. But again, > they are for someone writing a library for > more than personal use. They are in no way > restrictions on users. > > There is no convention (that I know of) that > restricts key bindings for users or even > suggests that users should stay away from > certain keys. OK. No doubt, disregarding conventions in code that is supposed to be shared - you should have a very good reason for doing that! (The assumption being the convention makes sense.) Still, there is a hesitation in my mind doing a to sharp division between libraries that are professional, and then the user stuff... The user stuff is the best school. So it is a good place to start acting like a skilled programmer, and that skilled programmer may well write or contribute to a library, and that doesn't have to take three decades like some people think.... As they say in boxing, "you want to be a champion? Start acting like one, today". So a list of conventions, good habits, known pitfalls, etc. is a good idea. (Perhaps it can in large parts be compiled from different parts of existing material.) Just a thought - I'm not up for the job myself :) But here is one thing that might help for code that is a package: (defun check-package-style () (interactive) (checkdoc-current-buffer t) ; TAKE-NOTES (message "Style check done.") ) Eh :) -- underground experts united .... http://user.it.uu.se/~embe8573 Emacs Gnus Blogomatic ......... http://user.it.uu.se/~embe8573/blogomatic - so far: 33 Blogomatic articles - ^ permalink raw reply [flat|nested] 838+ messages in thread
* "First line is not a complete sentence" (was: Re: Emacs conventions (was: Re: Overriding emacs key bindings)) 2016-05-18 5:22 ` Emanuel Berg @ 2016-05-18 5:36 ` Emanuel Berg [not found] ` <mailman.40.1463549841.6543.help-gnu-emacs@gnu.org> 1 sibling, 0 replies; 838+ messages in thread From: Emanuel Berg @ 2016-05-18 5:36 UTC (permalink / raw) To: help-gnu-emacs Emanuel Berg <embe8573@student.uu.se> writes: > (defun check-package-style () > (interactive) > (checkdoc-current-buffer t) ; TAKE-NOTES > (message "Style check done.") ) By the way, if you put that into a package and run it on itself, it says all interactive functions should be documented, I think. But with docstrings, there is a wierd behavior - often, this is the "error": First line is not a complete sentence What does that mean and what is the definition of a complete sentence - besides that it should end with a full stop? -- underground experts united .... http://user.it.uu.se/~embe8573 Emacs Gnus Blogomatic ......... http://user.it.uu.se/~embe8573/blogomatic - so far: 33 Blogomatic articles - ^ permalink raw reply [flat|nested] 838+ messages in thread
[parent not found: <mailman.40.1463549841.6543.help-gnu-emacs@gnu.org>]
* Re: "First line is not a complete sentence" (was: Re: Emacs conventions (was: Re: Overriding emacs key bindings)) [not found] ` <mailman.40.1463549841.6543.help-gnu-emacs@gnu.org> @ 2016-05-18 13:27 ` Joost Kremers 2016-05-19 4:32 ` Emanuel Berg 0 siblings, 1 reply; 838+ messages in thread From: Joost Kremers @ 2016-05-18 13:27 UTC (permalink / raw) To: help-gnu-emacs Emanuel Berg wrote: > But with docstrings, there is a wierd behavior > - often, this is the "error": > > First line is not a complete sentence > > What does that mean see (info "(elisp) Function Documentation"): ,---- | The first line of the documentation string should stand on its own, | because ‘apropos’ displays just this first line. It should consist of | one or two complete sentences that summarize the function’s purpose. `---- > and what is the definition > of a complete sentence - besides that it should > end with a full stop? Well, I suspect Emacs can only check whether it ends with a full stop, but the idea is of course also that it is a full sentence from a grammatical point of view. In essence, it should convey a clear and (in the given context) unambiguous message. -- Joost Kremers joostkremers@fastmail.fm Selbst in die Unterwelt dringt durch Spalten Licht EN:SiS(9) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: "First line is not a complete sentence" (was: Re: Emacs conventions (was: Re: Overriding emacs key bindings)) 2016-05-18 13:27 ` Joost Kremers @ 2016-05-19 4:32 ` Emanuel Berg 0 siblings, 0 replies; 838+ messages in thread From: Emanuel Berg @ 2016-05-19 4:32 UTC (permalink / raw) To: help-gnu-emacs Joost Kremers <joost.m.kremers@gmail.com> writes: > see (info "(elisp) Function Documentation"): > > The first line of the documentation string > should stand on its own, because ‘apropos’ > displays just this first line. It should > consist of one or two complete sentences that > summarize the function’s purpose. > >> and what is the definition of a complete >> sentence - besides that it should end with >> a full stop? > > Well, I suspect Emacs can only check whether > it ends with a full stop That was I joke which refered to that the error message itself wasn't a full sentence :) Because I get that error even tho there is a full stop. > but the idea is of course also that it is > a full sentence from a grammatical point of > view. In essence, it should convey a clear > and (in the given context) > unambiguous message. Right, but if it cannot check that, it might as well *always* report "Use correct English!" No, I think it does something more sensible, only it fails to communicate what exactly so it is only confusing at this point. Wait... now I understand, I think. One gets the error if one ends the first line with \n! -- underground experts united .... http://user.it.uu.se/~embe8573 Emacs Gnus Blogomatic ......... http://user.it.uu.se/~embe8573/blogomatic - so far: 33 Blogomatic articles - ^ permalink raw reply [flat|nested] 838+ messages in thread
[parent not found: <mailman.37.1463546355.6543.help-gnu-emacs@gnu.org>]
* Re: Emacs conventions (was: Re: Overriding emacs key bindings) [not found] ` <mailman.37.1463546355.6543.help-gnu-emacs@gnu.org> @ 2016-05-18 14:31 ` Barry Margolin 2016-05-19 4:38 ` Emanuel Berg 0 siblings, 1 reply; 838+ messages in thread From: Barry Margolin @ 2016-05-18 14:31 UTC (permalink / raw) To: help-gnu-emacs In article <mailman.37.1463546355.6543.help-gnu-emacs@gnu.org>, Drew Adams <drew.adams@oracle.com> wrote: > Yes, they are good to be aware of. But again, they are > for someone writing a library for more than personal use. > They are in no way restrictions on users. > > There is no convention (that I know of) that restricts > key bindings for users or even suggests that users > should stay away from certain keys. But if a user binds a key that's supposed to be for modes, and then they load a mode that also binds that key, they'll have a conflict. The point of these conventions is to avoid conflicts like this. If you don't mind losing one of the mode's keybindings, that's fine, but you should do it with full knowledge of the potential conflict. -- Barry Margolin, barmar@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Emacs conventions (was: Re: Overriding emacs key bindings) 2016-05-18 14:31 ` Emacs conventions (was: Re: Overriding emacs key bindings) Barry Margolin @ 2016-05-19 4:38 ` Emanuel Berg 0 siblings, 0 replies; 838+ messages in thread From: Emanuel Berg @ 2016-05-19 4:38 UTC (permalink / raw) To: help-gnu-emacs Barry Margolin <barmar@alum.mit.edu> writes: >> There is no convention (that I know of) that >> restricts key bindings for users or even >> suggests that users should stay away from >> certain keys. > > But if a user binds a key that's supposed to > be for modes, and then they load a mode that > also binds that key, they'll have a conflict. > The point of these conventions is to avoid > conflicts like this. Thats exactly right. Part of the reason a convention is useful is that the convention itself makes sense, but part of it has little to do with the particular definition, and the usefulness lies in the status as convention as such, and likely some other definition would have worked just as good... -- underground experts united .... http://user.it.uu.se/~embe8573 Emacs Gnus Blogomatic ......... http://user.it.uu.se/~embe8573/blogomatic - so far: 33 Blogomatic articles - ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Overriding emacs key bindings 2016-05-17 1:55 ` Robert Thorpe ` (2 preceding siblings ...) 2016-05-17 4:07 ` Drew Adams @ 2016-05-17 4:44 ` Marcin Borkowski 2016-05-17 20:37 ` Robert Thorpe 3 siblings, 1 reply; 838+ messages in thread From: Marcin Borkowski @ 2016-05-17 4:44 UTC (permalink / raw) To: Robert Thorpe; +Cc: help-gnu-emacs, Emanuel Berg, xiongtk On 2016-05-17, at 03:55, Robert Thorpe <rt@robertthorpeconsulting.com> wrote: > Then there are rarely used prefix keys, like the key for marking text, > you can attach stuff to that one. Out of curiosity: what key do you mean? Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Overriding emacs key bindings 2016-05-17 4:44 ` Overriding emacs key bindings Marcin Borkowski @ 2016-05-17 20:37 ` Robert Thorpe 2016-05-18 2:21 ` Emanuel Berg 2016-05-18 17:52 ` Marcin Borkowski 0 siblings, 2 replies; 838+ messages in thread From: Robert Thorpe @ 2016-05-17 20:37 UTC (permalink / raw) To: Marcin Borkowski; +Cc: help-gnu-emacs, embe8573, xiongtk Marcin Borkowski <mbork@mbork.pl> writes: > On 2016-05-17, at 03:55, Robert Thorpe <rt@robertthorpeconsulting.com> wrote: > >> Then there are rarely used prefix keys, like the key for marking text, >> you can attach stuff to that one. > > Out of curiosity: what key do you mean? This is a picture of it: http://i.stack.imgur.com/sgzBP.jpg It's called "Menu" in X and "Apps" on MS Windows. You can use it as a prefix key. BR, Robert Thorpe ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Overriding emacs key bindings 2016-05-17 20:37 ` Robert Thorpe @ 2016-05-18 2:21 ` Emanuel Berg 2016-05-18 20:34 ` Robert Thorpe 2016-05-18 17:52 ` Marcin Borkowski 1 sibling, 1 reply; 838+ messages in thread From: Emanuel Berg @ 2016-05-18 2:21 UTC (permalink / raw) To: help-gnu-emacs Robert Thorpe <rt@robertthorpeconsulting.com> writes: > It's called "Menu" in X and "Apps" on > MS Windows. You can use it as a prefix key. Ha ha, "Apps" :) Fittingly, that key doesn't work with Emacs in a Linux VT - not without the efforts already mentioned in this thread. AltGr and the key with the MS flag on it reports the same key, C-@. But showkey(1) gives three different values for them so all three can be put to into different action - only, IMO they are not good keys so I wouldn't bother... -- underground experts united .... http://user.it.uu.se/~embe8573 Emacs Gnus Blogomatic ......... http://user.it.uu.se/~embe8573/blogomatic - so far: 33 Blogomatic articles - ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Overriding emacs key bindings 2016-05-18 2:21 ` Emanuel Berg @ 2016-05-18 20:34 ` Robert Thorpe 2016-05-19 1:33 ` Emanuel Berg 0 siblings, 1 reply; 838+ messages in thread From: Robert Thorpe @ 2016-05-18 20:34 UTC (permalink / raw) To: Emanuel Berg; +Cc: help-gnu-emacs Emanuel Berg <embe8573@student.uu.se> writes: > But showkey(1) gives three different values for > them so all three can be put to into different > action - only, IMO they are not good keys so > I wouldn't bother... On my keyboard the menu/apps key is next to ctrl. While your fingers are on the main part of the keyboard you can press ctrl using the bottom of your index finger, the part between the finger and the palm. You can press the menu key in the same way, so I find it a useful key. It depends on your preference, and to some degree on the size of your hands. BR, Rob ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Overriding emacs key bindings 2016-05-18 20:34 ` Robert Thorpe @ 2016-05-19 1:33 ` Emanuel Berg 0 siblings, 0 replies; 838+ messages in thread From: Emanuel Berg @ 2016-05-19 1:33 UTC (permalink / raw) To: help-gnu-emacs Robert Thorpe <rt@robertthorpeconsulting.com> writes: > On my keyboard the menu/apps key is next to > ctrl. Yes, deeming from your image, I think we have the same type of keyboard. For many years I had a lovely Sun keyboard but step by step it disintegrated and now I have a mundane keyboard, along with the Microsoft flag, and even the Swedish char layout! Hideous - but I suppose it won't matter, as I know where the US layout keys are by know. Perhaps I should do like in the Angelina Jolie movie, where the dude sprays his keyboard in a uniform color. I did that myself with a bicycle trailer when I created my new office [1] so I don't see why it shouldn't work again. > While your fingers are on the main part of > the keyboard you can press ctrl using the > bottom of your index finger, the part between > the finger and the palm. You can press the > menu key in the same way. ... really? You do that? Far out :) Does that have a name? Let me reveal my inexperience by admitting I never heard of it. Myself, my claim to fame is my dynamic signature, below - cute, to say the least :) Speaking of keys and stuff I never heard of, the AltGr key ows its name from the following fragment of computer history: AltGr was originally introduced as a means to produce box-drawing characters, also known as pseudographics, in text user interfaces. [2] Facts - for fans! (Hey, reading that, I'm almost starting to *like* the key...) [1] http://user.it.uu.se/~embe8573/photos/supertramp-1.jpg [2] https://en.wikipedia.org/w/index.php?title=AltGr&printable=yes -- underground experts united .... http://user.it.uu.se/~embe8573 Emacs Gnus Blogomatic ......... http://user.it.uu.se/~embe8573/blogomatic - so far: 33 Blogomatic articles - ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Overriding emacs key bindings 2016-05-17 20:37 ` Robert Thorpe 2016-05-18 2:21 ` Emanuel Berg @ 2016-05-18 17:52 ` Marcin Borkowski 2016-05-18 20:30 ` Robert Thorpe 1 sibling, 1 reply; 838+ messages in thread From: Marcin Borkowski @ 2016-05-18 17:52 UTC (permalink / raw) To: Robert Thorpe; +Cc: help-gnu-emacs, embe8573, xiongtk On 2016-05-17, at 22:37, Robert Thorpe <rt@robertthorpeconsulting.com> wrote: > Marcin Borkowski <mbork@mbork.pl> writes: > >> On 2016-05-17, at 03:55, Robert Thorpe <rt@robertthorpeconsulting.com> wrote: >> >>> Then there are rarely used prefix keys, like the key for marking text, >>> you can attach stuff to that one. >> >> Out of curiosity: what key do you mean? > > This is a picture of it: > http://i.stack.imgur.com/sgzBP.jpg > > It's called "Menu" in X and "Apps" on MS Windows. You can use it as a > prefix key. Ah, that one, thanks! I had no idea it had anything to do with marking text. I used to bind it to various stuff in my WM; this way, I could release all those precious keys usually taken by the WM, like M-TAB. > BR, > Robert Thorpe Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Overriding emacs key bindings 2016-05-18 17:52 ` Marcin Borkowski @ 2016-05-18 20:30 ` Robert Thorpe 0 siblings, 0 replies; 838+ messages in thread From: Robert Thorpe @ 2016-05-18 20:30 UTC (permalink / raw) To: Marcin Borkowski; +Cc: help-gnu-emacs, embe8573, xiongtk Marcin Borkowski <mbork@mbork.pl> writes: > Ah, that one, thanks! I had no idea it had anything to do with marking > text. I used to bind it to various stuff in my WM; this way, I could > release all those precious keys usually taken by the WM, like M-TAB. That's a good idea, I might try that. BR, Robert Thorpe ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Overriding emacs key bindings 2016-05-16 23:29 ` Emanuel Berg 2016-05-17 1:55 ` Robert Thorpe @ 2016-05-17 4:43 ` Marcin Borkowski 2016-05-18 1:51 ` Emanuel Berg 2016-05-17 4:49 ` Marcin Borkowski 2 siblings, 1 reply; 838+ messages in thread From: Marcin Borkowski @ 2016-05-17 4:43 UTC (permalink / raw) To: Emanuel Berg; +Cc: help-gnu-emacs On 2016-05-17, at 01:29, Emanuel Berg <embe8573@student.uu.se> wrote: > If you really *do* run out of shortcuts, get > a new prefix key, e.g. C-o which is short and > close - check your hands when at asdf jkl; and > note the required movement to strike C-o! Why use such a key bound to such a useful command (`open-line') for a new prefix key‽ Especially when C-z is totally useless (and in an extreme case when it is what you want, `suspend-frame' is duplicated on C-x C-z anyway)? Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Overriding emacs key bindings 2016-05-17 4:43 ` Marcin Borkowski @ 2016-05-18 1:51 ` Emanuel Berg 0 siblings, 0 replies; 838+ messages in thread From: Emanuel Berg @ 2016-05-18 1:51 UTC (permalink / raw) To: help-gnu-emacs Marcin Borkowski <mbork@mbork.pl> writes: > Why use such a key bound to such a useful > command (`open-line') for a new prefix key > Especially when C-z is totally useless (and > in an extreme case when it is what you want, > `suspend-frame' is duplicated on C-x C-z > anyway)? Personally, I never user use `open-line'. I actually don't know what I do instead: `C-a RET', perhaps? But I do have `C-o a' undefined, so I'll put `open-line' there, and perhaps this "opens" a door to a new world of editing proficiency :) If you use C-o for `open-line' all the time, obviously it is not a good prefix key, unless you can assign `open-line' another shortcut just as good, and then reprogram your brain/fingers, of course. As for C-z, I like that even less than I like C-c, for all the same reasons I dislike C-c *plus* it involves the little finger (compared to the index finger) and the keys are even closer than C-c where they are too close already. -- underground experts united .... http://user.it.uu.se/~embe8573 Emacs Gnus Blogomatic ......... http://user.it.uu.se/~embe8573/blogomatic - so far: 32 Blogomatic articles - ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Overriding emacs key bindings 2016-05-16 23:29 ` Emanuel Berg 2016-05-17 1:55 ` Robert Thorpe 2016-05-17 4:43 ` Marcin Borkowski @ 2016-05-17 4:49 ` Marcin Borkowski 2016-05-18 2:02 ` Emanuel Berg 2 siblings, 1 reply; 838+ messages in thread From: Marcin Borkowski @ 2016-05-17 4:49 UTC (permalink / raw) To: Emanuel Berg; +Cc: help-gnu-emacs On 2016-05-17, at 01:29, Emanuel Berg <embe8573@student.uu.se> wrote: > If you think it is to much to type the actual > function name, instead make an alias - or > several! You'll find that it is actually faster > to invoke as it is easier to remember and, > again, does not require arm movement way from > typing position. If remembering is an issue (as in seldom used commands), hydra comes to the rescue. But I also agree on the point that there's nothing wrong with using M-x and a descriptive name for rarely used commands. Though long names don't bother me beacuse autocompletion (either vanilla Emacs, or Icicles/Ivy/whatever). Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Overriding emacs key bindings 2016-05-17 4:49 ` Marcin Borkowski @ 2016-05-18 2:02 ` Emanuel Berg 0 siblings, 0 replies; 838+ messages in thread From: Emanuel Berg @ 2016-05-18 2:02 UTC (permalink / raw) To: help-gnu-emacs Marcin Borkowski <mbork@mbork.pl> writes: > But I also agree on the point that there's > nothing wrong with using M-x and > a descriptive name for rarely used commands. > Though long names don't bother me beacuse > autocompletion (either vanilla Emacs, or > Icicles/Ivy/whatever). Autocompletion I don't like - it reminds me of my VB5, Eclipse, MS SQL Server, and .net days (which all were few but traumatic) - for sure, in Emacs it is much better, as with TAB it happens at your discretion, and not instantly, all the time, and everywhere! Still, 1) I don't like to see the "false hits" as it takes 1 per mille of the mindfulness to see "something-gnus", when you look for "something-groff", and 2) I like to think my memory improves from memorizing either the long names, or, if too long, my aliases which are shorter and should click with my memory better as 1) I wrote them, and 2) the correspond to my thinking. Now this message is 1) written, and 2) sent. -- underground experts united .... http://user.it.uu.se/~embe8573 Emacs Gnus Blogomatic ......... http://user.it.uu.se/~embe8573/blogomatic - so far: 32 Blogomatic articles - ^ permalink raw reply [flat|nested] 838+ messages in thread
* Opening a bookmark in the init file @ 2015-03-03 0:47 Robert Thorpe 2015-03-03 0:56 ` Drew Adams 0 siblings, 1 reply; 838+ messages in thread From: Robert Thorpe @ 2015-03-03 0:47 UTC (permalink / raw) To: help-gnu-emacs For years I've setup Emacs so it presents me with my ToDo list at startup. It doesn't put me in the right place in the file though. I can bookmark the place in the file, but using bookmark-jump in the init file doesn't work and it doesn't work in emacs-startup-hook either. I know I can use desktop.el to save and restore everything. I don't want all the other buffers saved and restored though. BR, Robert Thorpe ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Opening a bookmark in the init file 2015-03-03 0:47 Opening a bookmark in the init file Robert Thorpe @ 2015-03-03 0:56 ` Drew Adams 2015-03-03 2:32 ` Robert Thorpe 0 siblings, 1 reply; 838+ messages in thread From: Drew Adams @ 2015-03-03 0:56 UTC (permalink / raw) To: Robert Thorpe, help-gnu-emacs > For years I've setup Emacs so it presents me with my ToDo list at > startup. It doesn't put me in the right place in the file though. I > can bookmark the place in the file, but using bookmark-jump in the init > file doesn't work and it doesn't work in emacs-startup-hook either. Why doesn't it work in your init file? Of course you will need to load your bookmarks file before trying to jump to the bookmark. But doing that and jumping to a bookmark is just invoking Lisp functions. Nothing special - you can invoke pretty much any Lisp functions you like from your init file. I suggest that you specify in detail what you have tried, and perhaps people here will be able to help. If you do that, keep it simple - an init file that does only what you are trying to do in this regard. Start by just trying to jump to a simple bookmark from your init file - not a special bookmark (just a static file position), not involving any other code, whether Org to-do stuff or anything else, and with a bookmarks file that contains very little - maybe only that bookmark. And start from `emacs -Q`, of course. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Opening a bookmark in the init file 2015-03-03 0:56 ` Drew Adams @ 2015-03-03 2:32 ` Robert Thorpe 2015-03-08 19:18 ` Robert Thorpe 0 siblings, 1 reply; 838+ messages in thread From: Robert Thorpe @ 2015-03-03 2:32 UTC (permalink / raw) To: Drew Adams; +Cc: help-gnu-emacs Drew Adams <drew.adams@oracle.com> writes: >> For years I've setup Emacs so it presents me with my ToDo list at >> startup. It doesn't put me in the right place in the file though. I >> can bookmark the place in the file, but using bookmark-jump in the init >> file doesn't work and it doesn't work in emacs-startup-hook either. > > Why doesn't it work in your init file? Of course you will need to > load your bookmarks file before trying to jump to the bookmark. That was the problem. When I loaded the file with (bookmark-load "~/.emacs.bmk") it worked. BR, Robert Thorpe ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Opening a bookmark in the init file 2015-03-03 2:32 ` Robert Thorpe @ 2015-03-08 19:18 ` Robert Thorpe 2015-03-08 21:24 ` Drew Adams 0 siblings, 1 reply; 838+ messages in thread From: Robert Thorpe @ 2015-03-08 19:18 UTC (permalink / raw) To: Robert Thorpe; +Cc: help-gnu-emacs Robert Thorpe <rt@robertthorpeconsulting.com> writes: > Drew Adams <drew.adams@oracle.com> writes: > >>> For years I've setup Emacs so it presents me with my ToDo list at >>> startup. It doesn't put me in the right place in the file though. I >>> can bookmark the place in the file, but using bookmark-jump in the init >>> file doesn't work and it doesn't work in emacs-startup-hook either. >> >> Why doesn't it work in your init file? Of course you will need to >> load your bookmarks file before trying to jump to the bookmark. > > That was the problem. When I loaded the file with (bookmark-load > "~/.emacs.bmk") it worked. This fix only worked for a while. In my .emacs file I put: (bookmark-load "~/.emacs.bmk") (add-hook 'emacs-startup-hook '(lambda () (bookmark-jump "TODO"))) It worked for a few days but I noticed Emacs was becoming slow to startup. Today I had to restart Emacs a few times. The last time it took several minutes to starts. The bookmark file was the culprit. For some reason every entry had been duplicated with the text <2> in front of it. Then it had been duplicated again with the text <3> in front of that, and so one. This caused by bookmark file to double in size on every restart until it was ~50MB long. I found that the two lines above are the cause. If you add a bookmark-jump to emacs-startup-hook then something goes wrong somewhere. BR, Robert Thorpe ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Opening a bookmark in the init file 2015-03-08 19:18 ` Robert Thorpe @ 2015-03-08 21:24 ` Drew Adams 2015-03-08 21:48 ` Robert Thorpe 0 siblings, 1 reply; 838+ messages in thread From: Drew Adams @ 2015-03-08 21:24 UTC (permalink / raw) To: Robert Thorpe; +Cc: help-gnu-emacs > In my .emacs file I put: > (bookmark-load "~/.emacs.bmk") > (add-hook 'emacs-startup-hook '(lambda () (bookmark-jump "TODO"))) > > It worked for a few days but I noticed Emacs was becoming slow to > startup. Today I had to restart Emacs a few times. The last time it > took several minutes to starts. The bookmark file was the culprit. For > some reason every entry had been duplicated with the text <2> in front > of it. Then it had been duplicated again with the text <3> in front of > that, and so one. This caused by bookmark file to double in size on > every restart until it was ~50MB long. I found that the two lines above > are the cause. If you add a bookmark-jump to emacs-startup-hook then > something goes wrong somewhere. For some reason, you chose to call function `bookmark-load'. If you do that it behooves you to check its doc first ;-): ,---- | bookmark-load is an interactive autoloaded Lisp function in | `bookmark.el'. | | It is bound to <menu-bar> <edit> <bookmark> <load>. | | (bookmark-load FILE &optional OVERWRITE NO-MSG) | | Load bookmarks from FILE (which must be in bookmark format). | Appends loaded bookmarks to the front of the list of bookmarks. If | optional second argument OVERWRITE is non-nil, existing bookmarks are | destroyed. Optional third arg NO-MSG means don't display any messages | while loading. | | If you load a file that doesn't contain a proper bookmark alist, you | will corrupt Emacs's bookmark list. Generally, you should only load | in files that were created with the bookmark functions in the first | place. Your own personal bookmark file, `~/.emacs.bmk', is | maintained automatically by Emacs; you shouldn't need to load it | explicitly. | | If you load a file containing bookmarks with the same names as | bookmarks already present in your Emacs, the new bookmarks will get | unique numeric suffixes "<2>", "<3>", etc. `---- See the last paragraph. You are loading your bookmark file more than once. Most likely you are doing an explicit `bookmark-load' when your bookmark file has already been loaded. Don't do that. ;-) You can use function `bookmark-maybe-load-default-file' instead of `bookmark-load'. (There is also variable `bookmarks-already-loaded', but you should not need to check it.) But before bothering to fiddle with such things, check what you are really doing, to see how/why/where else you are loading your bookmark file, and perhaps simplify your code accordingly. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Opening a bookmark in the init file 2015-03-08 21:24 ` Drew Adams @ 2015-03-08 21:48 ` Robert Thorpe 2015-03-08 22:52 ` Drew Adams 0 siblings, 1 reply; 838+ messages in thread From: Robert Thorpe @ 2015-03-08 21:48 UTC (permalink / raw) To: Drew Adams; +Cc: help-gnu-emacs Drew Adams <drew.adams@oracle.com> writes: > For some reason, you chose to call function `bookmark-load'. > If you do that it behooves you to check its doc first ;-): Good point. > You can use function `bookmark-maybe-load-default-file' > instead of `bookmark-load'. (There is also variable > `bookmarks-already-loaded', but you should not need to check it.) Using that works without any problems. Thanks. > But before bothering to fiddle with such things, check what you > are really doing, to see how/why/where else you are loading your > bookmark file, and perhaps simplify your code accordingly. I'm loading the bookmark file because it doesn't work otherwise. If I just do: (add-hook 'emacs-startup-hook '(lambda () (bookmark-jump "TODO"))) Then Emacs gives an error "Invalid Bookmark TODO". It seems that the bookmarks are loaded after emacs-startup-hook, which is odd. If I load them before it works though. BR, Robert Thorpe ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Opening a bookmark in the init file 2015-03-08 21:48 ` Robert Thorpe @ 2015-03-08 22:52 ` Drew Adams 0 siblings, 0 replies; 838+ messages in thread From: Drew Adams @ 2015-03-08 22:52 UTC (permalink / raw) To: Robert Thorpe; +Cc: help-gnu-emacs > > But before bothering to fiddle with such things, check what you > > are really doing, to see how/why/where else you are loading your > > bookmark file, and perhaps simplify your code accordingly. > > I'm loading the bookmark file because it doesn't work otherwise. > If I just do: > > (add-hook 'emacs-startup-hook '(lambda () (bookmark-jump "TODO"))) > > Then Emacs gives an error "Invalid Bookmark TODO". It seems that the > bookmarks are loaded after emacs-startup-hook, which is odd. If I load > them before it works though. Many functions call `bookmark-maybe-load-default-file' (which loads the bookmark file if it has not been loaded). If you don't want to call that instead of `bookmark-load' then try to find out what, during your startup, loads the file. Do `M-x debug-on-entry RET bookmark-load RET' to see what calls `bookmark-load' the first time. There is no harm in calling `bookmark-maybe-load-default-file'. I mention trying to find out what was causing the first load as a way of helping you understanding what was happening. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Info: how to get back from a footnote @ 2015-01-14 22:12 Marcin Borkowski 2015-01-15 2:42 ` Robert Thorpe 0 siblings, 1 reply; 838+ messages in thread From: Marcin Borkowski @ 2015-01-14 22:12 UTC (permalink / raw) To: Help Gnu Emacs mailing list Hi, it's me again! Oftentimes I read something in Info and follow a link to a footnote (within the same node). How? To? Come? Back? to the footnote reference? C-x SPC didn't help... TIA -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Info: how to get back from a footnote 2015-01-14 22:12 Info: how to get back from a footnote Marcin Borkowski @ 2015-01-15 2:42 ` Robert Thorpe 2015-01-15 3:11 ` Drew Adams 2015-01-15 5:51 ` Marcin Borkowski 0 siblings, 2 replies; 838+ messages in thread From: Robert Thorpe @ 2015-01-15 2:42 UTC (permalink / raw) To: Marcin Borkowski; +Cc: help-gnu-emacs Marcin Borkowski <mbork@wmi.amu.edu.pl> writes: > Oftentimes I read something in Info and follow a link to a footnote > (within the same node). > > How? To? Come? Back? to the footnote reference? C-x SPC didn't help... How do you do that? I've never been able to find a command to follow footnotes. Do you mean things like "(1)"? Is this a function of something like Info+ or Icicles? BR, Robert Thorpe ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Info: how to get back from a footnote 2015-01-15 2:42 ` Robert Thorpe @ 2015-01-15 3:11 ` Drew Adams 2015-01-15 5:51 ` Marcin Borkowski 1 sibling, 0 replies; 838+ messages in thread From: Drew Adams @ 2015-01-15 3:11 UTC (permalink / raw) To: Robert Thorpe, Marcin Borkowski; +Cc: help-gnu-emacs > Is this a function of something like Info+ or Icicles? Nope. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Info: how to get back from a footnote 2015-01-15 2:42 ` Robert Thorpe 2015-01-15 3:11 ` Drew Adams @ 2015-01-15 5:51 ` Marcin Borkowski 2015-01-16 2:38 ` Robert Thorpe 1 sibling, 1 reply; 838+ messages in thread From: Marcin Borkowski @ 2015-01-15 5:51 UTC (permalink / raw) To: help-gnu-emacs On 2015-01-15, at 03:42, Robert Thorpe <rt@robertthorpeconsulting.com> wrote: > Marcin Borkowski <mbork@wmi.amu.edu.pl> writes: >> Oftentimes I read something in Info and follow a link to a footnote >> (within the same node). >> >> How? To? Come? Back? to the footnote reference? C-x SPC didn't help... Stupid me. Pressing RET on the link to the footnote jumps there, pressing RET again (on the footnote number next to its text) gets me back. > How do you do that? I've never been able to find a command to follow > footnotes. Do you mean things like "(1)"? Is this a function of something like Info+ or Icicles? No idea. It Just Works (in GNU Emacs 25.0.50.1). > BR, > Robert Thorpe Regards, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Info: how to get back from a footnote 2015-01-15 5:51 ` Marcin Borkowski @ 2015-01-16 2:38 ` Robert Thorpe 0 siblings, 0 replies; 838+ messages in thread From: Robert Thorpe @ 2015-01-16 2:38 UTC (permalink / raw) To: Marcin Borkowski; +Cc: help-gnu-emacs Marcin Borkowski <mbork@wmi.amu.edu.pl> writes: >> How do you do that? I've never been able to find a command to follow >> footnotes. Do you mean things like "(1)"? Is this a function of something like Info+ or Icicles? > > No idea. It Just Works (in GNU Emacs 25.0.50.1). I was looking at Emacs 24.3, it's a new feature in Emacs 24.4. And very useful too. BR, Robert Thorpe ^ permalink raw reply [flat|nested] 838+ messages in thread
[parent not found: <mailman.16504.1419019164.1147.help-gnu-emacs@gnu.org>]
* Re: Abbrevs for the most frequent elisp symbols [not found] <mailman.16504.1419019164.1147.help-gnu-emacs@gnu.org> @ 2014-12-29 4:21 ` Emanuel Berg 2014-12-29 11:24 ` Marcin Borkowski ` (2 more replies) 0 siblings, 3 replies; 838+ messages in thread From: Emanuel Berg @ 2014-12-29 4:21 UTC (permalink / raw) To: help-gnu-emacs Tom <adatgyujto@gmail.com> writes: > The other day it occurred to me I could use simple > abbrevs for elisp programming, but defining these > manually is tiresome, so I did some automation ... > The idea is trivial ... Not exactly trivial I would say, and certainly not the implementation. > so I collected the usage statistics of all elisp > symbols from the emacs lisp sources Cool: most likely there isn't a better example for how to properly use Elisp for real software, than Emacs and the associated software and libraries. But even so, what if some guy is the other way around, e.g., he prefers `garbage-collect' to `goto-char'? Is that easily rerouted in some automatically generated (but after that manually editable) abbrev table? > so probably somebody has done something like this > already Yes: I've seen something similar but I think that was the typing of commands after M-x, and not the whole Elisp language when typing it in a buffer. Personally, though I think this an interesting/cool project, I don't have a problem typing (on the contrary, I like it very much) and I am actually very fond of the Elisp verbose style (compare the C style with very short names, with "undelimited" abbreviations and often digits and such in between and all over) - I mean, I like C, and when I do C I do that as well, but when I do Elisp, I really enjoy those long this-is-a-function-that-does-something - it isn't too slow to type as long as it is normal words and normal chars, not asymmetric-asynchronous-continuous-anonymous or anything. My second concern is that if this is abbrevs, don't you get crazy from them expanding all the time as you type? But anyway, thumbs up for activity and zeal! -- underground experts united ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Abbrevs for the most frequent elisp symbols 2014-12-29 4:21 ` Abbrevs for the most frequent elisp symbols Emanuel Berg @ 2014-12-29 11:24 ` Marcin Borkowski 2014-12-29 13:09 ` Robert Thorpe 2014-12-29 13:26 ` Stefan Monnier 2014-12-29 15:49 ` Tom [not found] ` <mailman.16844.1419852282.1147.help-gnu-emacs@gnu.org> 2 siblings, 2 replies; 838+ messages in thread From: Marcin Borkowski @ 2014-12-29 11:24 UTC (permalink / raw) To: help-gnu-emacs On 2014-12-29, at 05:21, Emanuel Berg <embe8573@student.uu.se> wrote: > Tom <adatgyujto@gmail.com> writes: > >> The other day it occurred to me I could use simple >> abbrevs for elisp programming, but defining these >> manually is tiresome, so I did some automation ... >> The idea is trivial ... > > Not exactly trivial I would say, and certainly not the > implementation. > >> so I collected the usage statistics of all elisp >> symbols from the emacs lisp sources > > Cool: most likely there isn't a better example for how > to properly use Elisp for real software, than Emacs > and the associated software and libraries. False assumption: that Emacs libraries contain good practices only. I know you dislike Emacs.SE, but there was a question there about good Elisp code to read (to learn Elisp), and someone warned about reading Emacs code (especially older libraries). Recently, I grepped the Emacs Lisp sources for occurences of `mapcar', and there is *no* consistency in e.g. using ' versus #', or quoted lambdas (which I hear are a no-no unless in special circumstances, like macros). > But even so, what if some guy is the other way around, > e.g., he prefers `garbage-collect' to `goto-char'? Is > that easily rerouted in some automatically generated > (but after that manually editable) abbrev table? > >> so probably somebody has done something like this >> already > > Yes: I've seen something similar but I think that was > the typing of commands after M-x, and not the whole > Elisp language when typing it in a buffer. BTW: what's wrong with Yasnippet? Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Abbrevs for the most frequent elisp symbols 2014-12-29 11:24 ` Marcin Borkowski @ 2014-12-29 13:09 ` Robert Thorpe 2014-12-29 15:28 ` Drew Adams 2014-12-29 13:26 ` Stefan Monnier 1 sibling, 1 reply; 838+ messages in thread From: Robert Thorpe @ 2014-12-29 13:09 UTC (permalink / raw) To: help-gnu-emacs; +Cc: Tom, Emanuel Berg, Marcin Borkowski There are the dynamic abbrevs facilities, M-\ and C-M-\. They search through the open buffers looking for completion candidates. They're included by default in hippie-expand's completers. Personally, I prefer that style of completion to abbrev. You could use a similar strategy with normal abbrev though. Load up a set of Elisp files that are typical of your personal usage. You could then use the code in dabbrev-expand or dabbrev-completion to find the completions you want. You could wrap that in a bit of Elisp and run it once to generate a table, then decide on the abbrevs manually or by taking a prefix. Martin mentions that the Emacs sources themselves contain some code that's frowned upon these days. That's true, there are many old parts of Emacs. The parts that are new are a good guide though. There are some peculiarities even there though, Emacs code doesn't use certain features to avoid loading them when Emacs starts, easymenu for example. BR, Robert Thorpe ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: Abbrevs for the most frequent elisp symbols 2014-12-29 13:09 ` Robert Thorpe @ 2014-12-29 15:28 ` Drew Adams 2014-12-29 16:28 ` Robert Thorpe 0 siblings, 1 reply; 838+ messages in thread From: Drew Adams @ 2014-12-29 15:28 UTC (permalink / raw) To: Robert Thorpe, help-gnu-emacs; +Cc: Emanuel Berg, Tom, Marcin Borkowski > There are the dynamic abbrevs facilities, M-\ and C-M-\. And the little-known but there-forever and useful `dynamic-completion-mode, from built-in library `completions.el'. (The file Commentary is the doc.) The keys for it are, by default, `C-RET' and `M-RET'. > They search through the open buffers looking for completion candidates. > They're included by default in hippie-expand's completers. Personally, > I prefer that style of completion to abbrev. The use is different, but yes, very useful. > You could use a similar strategy with normal abbrev though. Load up > a set of Elisp files that are typical of your personal usage. You > could then use the code in dabbrev-expand or dabbrev-completion to find > the completions you want. You could wrap that in a bit of Elisp and run > it once to generate a table, then decide on the abbrevs manually or by > taking a prefix. Yes. > Martin mentions that the Emacs sources themselves contain some code > that's frowned upon these days. That's true, there are many old > parts of Emacs. The parts that are new are a good guide though. There > are some peculiarities even there though, Emacs code doesn't use certain > features to avoid loading them when Emacs starts, easymenu for > example. +1. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Abbrevs for the most frequent elisp symbols 2014-12-29 15:28 ` Drew Adams @ 2014-12-29 16:28 ` Robert Thorpe 0 siblings, 0 replies; 838+ messages in thread From: Robert Thorpe @ 2014-12-29 16:28 UTC (permalink / raw) To: Drew Adams; +Cc: help-gnu-emacs, embe8573, adatgyujto, mbork Drew Adams <drew.adams@oracle.com> writes: >> There are the dynamic abbrevs facilities, M-\ and C-M-\. > > And the little-known but there-forever and useful `dynamic-completion-mode, > from built-in library `completions.el'. (The file Commentary is the doc.) > The keys for it are, by default, `C-RET' and `M-RET'. Thanks. I didn't know about that, I'll give it a try. BR, Robert Thorpe ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Abbrevs for the most frequent elisp symbols 2014-12-29 11:24 ` Marcin Borkowski 2014-12-29 13:09 ` Robert Thorpe @ 2014-12-29 13:26 ` Stefan Monnier 2014-12-29 13:40 ` Marcin Borkowski 1 sibling, 1 reply; 838+ messages in thread From: Stefan Monnier @ 2014-12-29 13:26 UTC (permalink / raw) To: help-gnu-emacs > Elisp code to read (to learn Elisp), and someone warned about reading > Emacs code (especially older libraries). That's one person's opinion. > Recently, I grepped the Emacs Lisp sources for occurences of `mapcar', > and there is *no* consistency in e.g. using ' versus #', Indeed. But to a large extend, for quoted function names, the difference between the two is a question of taste. IOW there are usually much bigger elephants to deal with before it's worth worrying about such details. > or quoted lambdas (which I hear are a no-no unless in special > circumstances, like macros). AFAIK there have been no quoted lambdas left in Emacs's own code for quite a few years now. There are still some backquoted lambdas which should be converted to closures, admittedly (usually it's either because converting those packages to lexical-binding is a bit more tricky than usual, so it hasn't been done yet, or it's because the conversion can't be done because the package is also distributed outside Emacs and needs to work on Emacs<24). >> Yes: I've seen something similar but I think that was >> the typing of commands after M-x, and not the whole >> Elisp language when typing it in a buffer. That also works in Elisp buffers, actually: type "(g-c" and then M-TAB and you'll be offered completion on all the g<something>-c<something> functions. It's not really the same as the OP's abbrevs, tho, because there are *many* functions matching "(g-c". Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Abbrevs for the most frequent elisp symbols 2014-12-29 13:26 ` Stefan Monnier @ 2014-12-29 13:40 ` Marcin Borkowski 2014-12-29 14:57 ` Stefan Monnier 0 siblings, 1 reply; 838+ messages in thread From: Marcin Borkowski @ 2014-12-29 13:40 UTC (permalink / raw) To: help-gnu-emacs On 2014-12-29, at 14:26, Stefan Monnier <monnier@iro.umontreal.ca> wrote: >> Elisp code to read (to learn Elisp), and someone warned about reading >> Emacs code (especially older libraries). > > That's one person's opinion. No offence meant; Emacs is older than many people on this list (including me), both the language and the libraries did evolve quite a bit, and then there is the problem of manpower - no surprise some code in Emacs is rather dated. >> Recently, I grepped the Emacs Lisp sources for occurences of `mapcar', >> and there is *no* consistency in e.g. using ' versus #', > > Indeed. But to a large extend, for quoted function names, the > difference between the two is a question of taste. IOW there are > usually much bigger elephants to deal with before it's worth worrying > about such details. Maybe - I just wrote about something I noticed, I don't read Emacs sources on a daily basis (and I'm not competent enough in Elisp to notice many things). >> or quoted lambdas (which I hear are a no-no unless in special >> circumstances, like macros). > > AFAIK there have been no quoted lambdas left in Emacs's own code for > quite a few years now. There are still some backquoted lambdas which > should be converted to closures, admittedly (usually it's either > because converting those packages to lexical-binding is a bit more > tricky than usual, so it hasn't been done yet, or it's because the > conversion can't be done because the package is also distributed > outside Emacs and needs to work on Emacs<24). I have Emacs 24.3, maybe that's the reason. > Stefan Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Abbrevs for the most frequent elisp symbols 2014-12-29 13:40 ` Marcin Borkowski @ 2014-12-29 14:57 ` Stefan Monnier 0 siblings, 0 replies; 838+ messages in thread From: Stefan Monnier @ 2014-12-29 14:57 UTC (permalink / raw) To: help-gnu-emacs >> AFAIK there have been no quoted lambdas left in Emacs's own code for >> quite a few years now. There are still some backquoted lambdas which >> should be converted to closures, admittedly (usually it's either >> because converting those packages to lexical-binding is a bit more >> tricky than usual, so it hasn't been done yet, or it's because the >> conversion can't be done because the package is also distributed >> outside Emacs and needs to work on Emacs<24). > I have Emacs 24.3, maybe that's the reason. No: "quite a few years" here means something like since before Emacs-24.1, IIRC. If you see a quoted lambda in Emacs's code, report it as a bug. Stefan ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Abbrevs for the most frequent elisp symbols 2014-12-29 4:21 ` Abbrevs for the most frequent elisp symbols Emanuel Berg 2014-12-29 11:24 ` Marcin Borkowski @ 2014-12-29 15:49 ` Tom [not found] ` <mailman.16844.1419852282.1147.help-gnu-emacs@gnu.org> 2 siblings, 0 replies; 838+ messages in thread From: Tom @ 2014-12-29 15:49 UTC (permalink / raw) To: help-gnu-emacs Emanuel Berg <embe8573 <at> student.uu.se> writes: > > Tom <adatgyujto <at> gmail.com> writes: > > But even so, what if some guy is the other way around, > e.g., he prefers `garbage-collect' to `goto-char'? Is > that easily rerouted in some automatically generated > (but after that manually editable) abbrev table? Something like this could be added, but I don't see the reason, because I think the elisp sources are fairly representative of the usage frequency of symbols. I'm pretty sure most people use goto-char more often than garbage-collect. The aim was to provide a very convenient way to type the most frequent symbols. For the less frequent one you always have some kind of completion. I was tired of typing save-exursion, etc. all the time and while I use completion (company) for elisp symbols it's still cumbersome to type for the most frequent symbols while typing simply 'se' is very convenient. > My second concern is that if this is abbrevs, don't > you get crazy from them expanding all the time as you > type? There was one problematic abbrev I found when I tried it 'if' which mapped to some lesser used function, don't remember which, so I deleted it manually. Otherwise, the abbrevs are surprisingly unique and didn't interfere with normal typing, though I haven't tested it extensively. ^ permalink raw reply [flat|nested] 838+ messages in thread
[parent not found: <mailman.16844.1419852282.1147.help-gnu-emacs@gnu.org>]
* Re: Abbrevs for the most frequent elisp symbols [not found] ` <mailman.16844.1419852282.1147.help-gnu-emacs@gnu.org> @ 2015-01-03 2:25 ` Emanuel Berg 2015-01-04 0:19 ` Artur Malabarba [not found] ` <mailman.17204.1420330787.1147.help-gnu-emacs@gnu.org> 2015-01-03 2:31 ` Emanuel Berg 1 sibling, 2 replies; 838+ messages in thread From: Emanuel Berg @ 2015-01-03 2:25 UTC (permalink / raw) To: help-gnu-emacs Marcin Borkowski <mbork@wmi.amu.edu.pl> writes: > False assumption: that Emacs libraries contain good > practices only. I know you dislike Emacs.SE No, not really. I supported it from day one (verbally, I mean). When they do a message-mode/Gnus-like interface, I might even use it! But only once or twice for my favorite questions so they perhaps reach a wider audience... I can't say I like it but I don't dislike it. > but there was a question there about good Elisp code > to read (to learn Elisp), and someone warned about > reading Emacs code (especially older libraries). That reading Emacs code in any way should be harmful of course I don't believe in. I always emphasize activity rather than consumption but if there is room for any consumption reading Emacs code is a good choice for any programmer, no doubt. > Recently, I grepped the Emacs Lisp sources for > occurences of `mapcar', and there is *no* > consistency in e.g. using ' versus #', or quoted > lambdas (which I hear are a no-no unless in special > circumstances, like macros). Yeah, I have no illusions that it is consistent or perfect in the abstract sense. Of course it isn't as so many people worked on it. Still, the definition of good software is what it can do, or, what it enables you to do. You can't beat that. It is good. -- underground experts united ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Abbrevs for the most frequent elisp symbols 2015-01-03 2:25 ` Emanuel Berg @ 2015-01-04 0:19 ` Artur Malabarba [not found] ` <mailman.17204.1420330787.1147.help-gnu-emacs@gnu.org> 1 sibling, 0 replies; 838+ messages in thread From: Artur Malabarba @ 2015-01-04 0:19 UTC (permalink / raw) To: Emanuel Berg; +Cc: help-gnu-emacs > No, not really. I supported it from day one (verbally, > I mean). When they do a message-mode/Gnus-like > interface, I might even use it! You might like sx.el. I don't know if I'd call it gnus-like, but it's pretty good. ^ permalink raw reply [flat|nested] 838+ messages in thread
[parent not found: <mailman.17204.1420330787.1147.help-gnu-emacs@gnu.org>]
* Re: Abbrevs for the most frequent elisp symbols [not found] ` <mailman.17204.1420330787.1147.help-gnu-emacs@gnu.org> @ 2015-01-05 21:16 ` Emanuel Berg 2015-01-08 20:53 ` Artur Malabarba 0 siblings, 1 reply; 838+ messages in thread From: Emanuel Berg @ 2015-01-05 21:16 UTC (permalink / raw) To: help-gnu-emacs Artur Malabarba <arturmalabarba@gmail.com> writes: >> No, not really. I supported it from day one >> (verbally, I mean). When they do a >> message-mode/Gnus-like interface, I might even use >> it! > > You might like sx.el. I don't know if I'd call it > gnus-like, but it's pretty good. Yes, I found it in melpa ("sx", version 20150105.1006), but it requires "let-alist-1.0.3" which "is an orphan package" - what does that mean? no parents as in dependencies up the ladder? - but worse, the package itself seems to be missing. Here is what Help says: Status: Orphan. Archive: n/a Summary: And I can't find it, either. Anyway, I would really push for sx and other attempts to access/use the SX sites from Emacs, be included in Emacs when they reach maturity, if they didn't already... Ha! melpa sure is fun. How about this: sunny-day-theme ... Emacs24 theme with a light background. :) -- underground experts united ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Abbrevs for the most frequent elisp symbols 2015-01-05 21:16 ` Emanuel Berg @ 2015-01-08 20:53 ` Artur Malabarba 0 siblings, 0 replies; 838+ messages in thread From: Artur Malabarba @ 2015-01-08 20:53 UTC (permalink / raw) To: Emanuel Berg; +Cc: help-gnu-emacs > Yes, I found it in melpa ("sx", version > 20150105.1006), but it requires "let-alist-1.0.3" > which "is an orphan package" - what does that mean? no > parents as in dependencies up the ladder? - but worse, > the package itself seems to be missing. It's on GNU Elpa, do you not have it configured by any chance? ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: Abbrevs for the most frequent elisp symbols [not found] ` <mailman.16844.1419852282.1147.help-gnu-emacs@gnu.org> 2015-01-03 2:25 ` Emanuel Berg @ 2015-01-03 2:31 ` Emanuel Berg 1 sibling, 0 replies; 838+ messages in thread From: Emanuel Berg @ 2015-01-03 2:31 UTC (permalink / raw) To: help-gnu-emacs Marcin Borkowski <mbork@wmi.amu.edu.pl> writes: > BTW: what's wrong with Yasnippet? What's wrong with typing? All those expanders are like ants in a colony. I want it to be a bare mountain and a clear horizon. I don't want to type less. If you do it 18 hours a day I can see the point: it could save your fingers from disintegrating. But I don't do it all day long so when I do it I think typing is superior to all those schemes. But the OP is of course not me: he wants it and he did it, the same goes for Yasnippet, whoever wrote that, so CRED to them. -- underground experts united ^ permalink raw reply [flat|nested] 838+ messages in thread
* When do you prefer frames instead of windows?
@ 2014-11-24 16:40 Raffaele Ricciardi
2014-11-24 17:20 ` Drew Adams
` (10 more replies)
0 siblings, 11 replies; 838+ messages in thread
From: Raffaele Ricciardi @ 2014-11-24 16:40 UTC (permalink / raw)
To: help-gnu-emacs
The usefulness of frames is evident for buffers that update their
content according to the current buffer (like Speedbar and ECB).
Besides this kind of use, when do you prefer frames instead of windows?
Thank you.
^ permalink raw reply [flat|nested] 838+ messages in thread* RE: When do you prefer frames instead of windows? 2014-11-24 16:40 When do you prefer frames instead of windows? Raffaele Ricciardi @ 2014-11-24 17:20 ` Drew Adams 2014-11-25 8:03 ` Gian Uberto Lauri ` (2 more replies) [not found] ` <mailman.14479.1416849631.1147.help-gnu-emacs@gnu.org> ` (9 subsequent siblings) 10 siblings, 3 replies; 838+ messages in thread From: Drew Adams @ 2014-11-24 17:20 UTC (permalink / raw) To: Raffaele Ricciardi, help-gnu-emacs > The usefulness of frames is evident for buffers that update their > content according to the current buffer (like Speedbar and ECB). > Besides this kind of use, when do you prefer frames instead of > windows? Personally, almost always. A window-manager window (Emacs frame) is more flexible than an Emacs window - more features/possibilities. Emacs windows were conceived long, long ago - before window managers were supported/recognized by Emacs and even, for the most part, before they existed. They are vestigial organs that have some limited uses but are generally not the best way to interact, IMO. I generally don't like apps to try to lock everything they do into a single window-mgr window (frame) and provide their own internal windows within that frame. That applies to Emacs also. Whenever possible/practical, I free such internal windows to become normal window-mgr windows. With Emacs this is even better, as you can manipulate frames using the keyboard, not just the mouse. However, out of the box, support for using Emacs frames is pretty primitive. So I jump through a bunch of configuration hooks to be able to use them easily (including keyboard manipulation). Just one (minority) opinion. I would ask an opposite question: IF you could use Emacs frames as easily as you can use Emacs windows, in what scenarios would you prefer using Emacs windows, and why? ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: When do you prefer frames instead of windows? 2014-11-24 17:20 ` Drew Adams @ 2014-11-25 8:03 ` Gian Uberto Lauri 2014-11-25 15:46 ` Drew Adams 2014-11-25 8:33 ` When do you prefer windows instead of frames? Was: " H. Dieter Wilhelm 2014-11-25 8:52 ` Rainer M Krug 2 siblings, 1 reply; 838+ messages in thread From: Gian Uberto Lauri @ 2014-11-25 8:03 UTC (permalink / raw) To: Drew Adams; +Cc: help-gnu-emacs, Raffaele Ricciardi Drew Adams writes: > I would ask an opposite question: IF you could use Emacs frames > as easily as you can use Emacs windows, in what scenarios would > you prefer using Emacs windows, and why? My favourite use of windows is for mail reading, sql interaction and when working on two parts of the same file or two files with a macro. For e-mail, I think you all know at least one between rmail, gnus and vm. For sql interaction a sql editing buffer and a db connection buffer are really a nice way to shot queries to a db for test and debug purposes. In these situations I feel that Emacs is "running an application" and I feel more comfortable with all the application windows in the same frame. If the frames could really be used like windows, then, it could be that I would be comfortable with separate frames. On the other hand, my favourite use of frames is on an application specific basis. One frame for e-mail, one for DB-interaction... Some version ago Emacs had a nice bug/feature that allowed you to create several WindowMaker application icons with a single Emacs instance, and using a different image for each application icon. This was nice because that let me associate a certain frame with a certain workspace (i.e. e-mail on workspace 1 and db-interaction on workspace 6) and use a click on the application icon to jump to that workspace. [Now I can just assign different images to different miniwindows.] -- /\ ___ Ubuntu: ancient /___/\_|_|\_|__|___Gian Uberto Lauri_____ African word //--\| | \| | Integralista GNUslamico meaning "I can \/ coltivatore diretto di software not install già sistemista a tempo (altrui) perso... Debian" Warning: gnome-config-daemon considered more dangerous than GOTO ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: When do you prefer frames instead of windows? 2014-11-25 8:03 ` Gian Uberto Lauri @ 2014-11-25 15:46 ` Drew Adams 2014-11-25 15:54 ` Gian Uberto Lauri 0 siblings, 1 reply; 838+ messages in thread From: Drew Adams @ 2014-11-25 15:46 UTC (permalink / raw) To: Gian Uberto Lauri; +Cc: help-gnu-emacs, Raffaele Ricciardi > > I would ask an opposite question: IF you could use Emacs frames > > as easily as you can use Emacs windows, in what scenarios would > > you prefer using Emacs windows, and why? > > ...mail reading, sql interaction and when working on two parts of > the same file or two files with a macro... > > If the frames could really be used like windows, then, it could be > that I would be comfortable with separate frames. That was the question. "IF you could use frames as easily as you can use Emacs windows..." I certainly agree that currently you cannot, especially with just vanilla Emacs. But if you could... > create several WindowMaker application icons with a single Emacs > instance, and using a different image for each application icon. That sounds like something that would pertain only to certain platforms, since different platforms have different notions of "icon" etc. But the ability you mention sounds like it might be useful. > This was nice because that let me associate a certain frame with a > certain workspace (i.e. e-mail on workspace 1 and db-interaction on > workspace 6) and use a click on the application icon to jump to that > workspace. FYI, you can use bookmarks to similar effect. With Bookmark+ you can just jump to this or that desktop bookmark, to change between Emacs "workspaces", as defined by desktop.el. And it doesn't matter whether you use one frame or 37 frames for such a workspace. http://www.emacswiki.org/BookmarkPlus#DesktopBookmarks ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: When do you prefer frames instead of windows? 2014-11-25 15:46 ` Drew Adams @ 2014-11-25 15:54 ` Gian Uberto Lauri 0 siblings, 0 replies; 838+ messages in thread From: Gian Uberto Lauri @ 2014-11-25 15:54 UTC (permalink / raw) To: Drew Adams; +Cc: Raffaele Ricciardi, help-gnu-emacs, Gian Uberto Lauri Drew Adams writes: > > > I would ask an opposite question: IF you could use Emacs frames > > > as easily as you can use Emacs windows, in what scenarios would > > > you prefer using Emacs windows, and why? > > > > ...mail reading, sql interaction and when working on two parts of > > the same file or two files with a macro... > > > > If the frames could really be used like windows, then, it could be > > that I would be comfortable with separate frames. > > That was the question. "IF you could use frames as easily as you > can use Emacs windows..." I certainly agree that currently you > cannot, especially with just vanilla Emacs. But if you could... Frankly, the answer is "I can't answer until I see it working". But it could be yes, especially if it changes my habits only slightly. > FYI, you can use bookmarks to similar effect. With Bookmark+ you > can just jump to this or that desktop bookmark, to change between > Emacs "workspaces", as defined by desktop.el. And it doesn't > matter whether you use one frame or 37 frames for such a workspace. > > http://www.emacswiki.org/BookmarkPlus#DesktopBookmarks I will give it a look, thank you! -- /\ ___ Ubuntu: ancient /___/\_|_|\_|__|___Gian Uberto Lauri_____ African word //--\| | \| | Integralista GNUslamico meaning "I can \/ coltivatore diretto di software not install già sistemista a tempo (altrui) perso... Debian" Warning: gnome-config-daemon considered more dangerous than GOTO ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: When do you prefer windows instead of frames? Was: When do you prefer frames instead of windows? 2014-11-24 17:20 ` Drew Adams 2014-11-25 8:03 ` Gian Uberto Lauri @ 2014-11-25 8:33 ` H. Dieter Wilhelm 2014-11-25 15:46 ` Drew Adams 2014-11-25 8:52 ` Rainer M Krug 2 siblings, 1 reply; 838+ messages in thread From: H. Dieter Wilhelm @ 2014-11-25 8:33 UTC (permalink / raw) To: help-gnu-emacs Drew Adams <drew.adams@oracle.com> writes: .. > I would ask an opposite question: IF you could use Emacs frames > as easily as you can use Emacs windows, in what scenarios would > you prefer using Emacs windows, and why? For supporting tasks only: Imagine you are starting from a full-screen window and want to see temporarily a variable definition in a second window while still hacking away. The advantage is that window operations, like C-x } enlarge-window-horizontally, delete-other-windows-vertically,... operate simultaneously on all windows. In such situations it seems to me much more convenient to use windows than set it up with frames. Dieter -- Best wishes H. Dieter Wilhelm Darmstadt, Germany ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: When do you prefer windows instead of frames? Was: When do you prefer frames instead of windows? 2014-11-25 8:33 ` When do you prefer windows instead of frames? Was: " H. Dieter Wilhelm @ 2014-11-25 15:46 ` Drew Adams 2014-11-25 18:40 ` MBR 0 siblings, 1 reply; 838+ messages in thread From: Drew Adams @ 2014-11-25 15:46 UTC (permalink / raw) To: dieter, help-gnu-emacs > > I would ask an opposite question: IF you could use Emacs frames > > as easily as you can use Emacs windows, in what scenarios would > > you prefer using Emacs windows, and why? > > For supporting tasks only: Imagine you are starting from a full-screen > window and want to see temporarily a variable definition in a second > window while still hacking away. The advantage is that window > operations, like C-x } enlarge-window-horizontally, > delete-other-windows-vertically,... operate simultaneously on all > windows. In such situations it seems to me much more convenient to > use windows than set it up with frames. Again - but what "IF you could use Emacs frames as easily as you can use Emacs windows"? That's the question. Pop up a *Help* frame instead of a *Help* window to show help. Hit `C-x 0' to get rid of that frame when you're done. You probably do not need to resize the frame (e.g., if the frame is automatically fit to the size of just the *Help* text). But if you do, then use keys to resize it, just as you would for a window. IOW, think past what you can do with a window (resize, move, control where it pops up, etc.) that you think you cannot easily do with a frame now. I certainly agree that if frames are not made as convenient to interact with (i.e., the same kinds of operations you use on windows) then Emacs windows remain useful. But if Emacs *did* support such operations with frames, out of the box,... ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: When do you prefer windows instead of frames? Was: When do you prefer frames instead of windows? 2014-11-25 15:46 ` Drew Adams @ 2014-11-25 18:40 ` MBR 2014-11-25 18:52 ` Drew Adams ` (2 more replies) 0 siblings, 3 replies; 838+ messages in thread From: MBR @ 2014-11-25 18:40 UTC (permalink / raw) To: Drew Adams, dieter, help-gnu-emacs Be very careful with the phrase "use ... as easily as you can use ...". There are some people out there who consider pointing with the mouse easy. I, on the other hand find it easier to use the keyboard. The keyboard, along with Emacs' wide array of cursor positioning commands, gives me the ability to quickly and easily get to specific precise positions - at least precise based on character position in a character cell terminal or editor window. There are probably other areas where different Emacs users would have diametrically opposite views on what they consider to be easy. Mark Rosenthal On 11/25/14 10:46 AM, Drew Adams wrote: >>> I would ask an opposite question: IF you could use Emacs frames >>> as easily as you can use Emacs windows, in what scenarios would >>> you prefer using Emacs windows, and why? >> For supporting tasks only: Imagine you are starting from a full-screen >> window and want to see temporarily a variable definition in a second >> window while still hacking away. The advantage is that window >> operations, like C-x } enlarge-window-horizontally, >> delete-other-windows-vertically,... operate simultaneously on all >> windows. In such situations it seems to me much more convenient to >> use windows than set it up with frames. > Again - but what "IF you could use Emacs frames as easily as you > can use Emacs windows"? That's the question. > > Pop up a *Help* frame instead of a *Help* window to show help. Hit > `C-x 0' to get rid of that frame when you're done. You probably do > not need to resize the frame (e.g., if the frame is automatically > fit to the size of just the *Help* text). But if you do, then use > keys to resize it, just as you would for a window. Yes, but typing C-x o is something I can do easily because it involves two fingers on the left hand immediately followed by one finger on the right hand, without fingers my ever having to leave home position. C-x 5 o, on the other hand involves my typing two successive characters with my left hand before I can switch to the right hand for the "o". And, worse than that, "x" is in the bottom row but "5" is in the top row, which means that even though my fingers' average position is over home position, they're jumping Saturday as far as they ever do on vertically. All this means that my mental focus on the code I'm writing doesn't get distracted when I type C-x 0, but when I type C-x 5 o, I have to take some of my focus away from the code to make sure I don't miss the "5" after the "x". > > IOW, think past what you can do with a window (resize, move, control > where it pops up, etc.) that you think you cannot easily do with a > frame now. > > I certainly agree that if frames are not made as convenient to > interact with (i.e., the same kinds of operations you use on > windows) then Emacs windows remain useful. But if Emacs *did* > support such operations with frames, out of the box,... > > ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: When do you prefer windows instead of frames? Was: When do you prefer frames instead of windows? 2014-11-25 18:40 ` MBR @ 2014-11-25 18:52 ` Drew Adams 2014-11-26 2:31 ` Yuri Khan 2014-12-19 16:08 ` Jude DaShiell 2 siblings, 0 replies; 838+ messages in thread From: Drew Adams @ 2014-11-25 18:52 UTC (permalink / raw) To: MBR, dieter, help-gnu-emacs > Be very careful with the phrase "use ... as easily as you > can use ...". There are some people out there who consider > pointing with the mouse easy. As easily as you can using whatever way you currently interact with windows - keyboard, mouse, foot pedals,... And I made it clear that being able to use only the keyboard (if a user prefers that) is required. That's definitely part of being able to use windows easily and would need to be part of being able to use frames easily. I thought I was clear about this. > There are probably other areas where different Emacs users > would have diametrically opposite views on what they consider > to be easy. Emacs accommodates them all, now, for windows. It would be good for it to do likewise for frames too. That's the point. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: When do you prefer windows instead of frames? Was: When do you prefer frames instead of windows? 2014-11-25 18:40 ` MBR 2014-11-25 18:52 ` Drew Adams @ 2014-11-26 2:31 ` Yuri Khan 2014-12-19 16:08 ` Jude DaShiell 2 siblings, 0 replies; 838+ messages in thread From: Yuri Khan @ 2014-11-26 2:31 UTC (permalink / raw) To: MBR; +Cc: dieter, help-gnu-emacs@gnu.org On Wed, Nov 26, 2014 at 12:40 AM, MBR <mbr@arlsoft.com> wrote: > Be very careful with the phrase "use ... as easily as you can use ...". […] > Yes, but typing C-x o is something I can do easily because it involves two > fingers on the left hand immediately followed by one finger on the right > hand, without fingers my ever having to leave home position. C-x 5 o, on > the other hand[…] Here you presuppose existing Emacs bindings. Which, as already known, do not satisfy the “as easily as” criterion. On the other hand, consider the windmove and framemove packages. windmove gives you easy bindings, by default Shift+arrows[1], that switch to an adjacent window in the given direction. Then, framemove hooks into that and when you don’t have an adjacent window in the indicated direction, it switches to an adjacent frame in that direction. [1]: if you use cua-mode, it makes sense to rebind windmove to e.g. Alt+arrows. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: When do you prefer windows instead of frames? Was: When do you prefer frames instead of windows? 2014-11-25 18:40 ` MBR 2014-11-25 18:52 ` Drew Adams 2014-11-26 2:31 ` Yuri Khan @ 2014-12-19 16:08 ` Jude DaShiell 2 siblings, 0 replies; 838+ messages in thread From: Jude DaShiell @ 2014-12-19 16:08 UTC (permalink / raw) To: MBR; +Cc: dieter, help-gnu-emacs For those of you who find keyboards easier than mice to use have you ever tried using a track bal and if so how do you grade that in comparison to use of the mouse? On Tue, 25 Nov 2014, MBR wrote: > Be very careful with the phrase "use ... as easily as you can use ...". There > are some people out there who consider pointing with the mouse easy. I, on > the other hand find it easier to use the keyboard. The keyboard, along with > Emacs' wide array of cursor positioning commands, gives me the ability to > quickly and easily get to specific precise positions - at least precise based > on character position in a character cell terminal or editor window. > > There are probably other areas where different Emacs users would have > diametrically opposite views on what they consider to be easy. > > Mark Rosenthal > > On 11/25/14 10:46 AM, Drew Adams wrote: > > > > I would ask an opposite question: IF you could use Emacs frames > > > > as easily as you can use Emacs windows, in what scenarios would > > > > you prefer using Emacs windows, and why? > > > For supporting tasks only: Imagine you are starting from a full-screen > > > window and want to see temporarily a variable definition in a second > > > window while still hacking away. The advantage is that window > > > operations, like C-x } enlarge-window-horizontally, > > > delete-other-windows-vertically,... operate simultaneously on all > > > windows. In such situations it seems to me much more convenient to > > > use windows than set it up with frames. > > Again - but what "IF you could use Emacs frames as easily as you > > can use Emacs windows"? That's the question. > > > > Pop up a *Help* frame instead of a *Help* window to show help. Hit > > `C-x 0' to get rid of that frame when you're done. You probably do > > not need to resize the frame (e.g., if the frame is automatically > > fit to the size of just the *Help* text). But if you do, then use > > keys to resize it, just as you would for a window. > Yes, but typing C-x o is something I can do easily because it involves two > fingers on the left hand immediately followed by one finger on the right hand, > without fingers my ever having to leave home position. C-x 5 o, on the other > hand involves my typing two successive characters with my left hand before I > can switch to the right hand for the "o". And, worse than that, "x" is in the > bottom row but "5" is in the top row, which means that even though my fingers' > average position is over home position, they're jumping Saturday as far as > they ever do on vertically. > > All this means that my mental focus on the code I'm writing doesn't get > distracted when I type C-x 0, but when I type C-x 5 o, I have to take some of > my focus away from the code to make sure I don't miss the "5" after the "x". > > > > IOW, think past what you can do with a window (resize, move, control > > where it pops up, etc.) that you think you cannot easily do with a > > frame now. > > > > I certainly agree that if frames are not made as convenient to > > interact with (i.e., the same kinds of operations you use on > > windows) then Emacs windows remain useful. But if Emacs *did* > > support such operations with frames, out of the box,... > > > > > > jude <jdashiel@shellworld.net> Twitter: @jdashiel ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: When do you prefer frames instead of windows? 2014-11-24 17:20 ` Drew Adams 2014-11-25 8:03 ` Gian Uberto Lauri 2014-11-25 8:33 ` When do you prefer windows instead of frames? Was: " H. Dieter Wilhelm @ 2014-11-25 8:52 ` Rainer M Krug 2 siblings, 0 replies; 838+ messages in thread From: Rainer M Krug @ 2014-11-25 8:52 UTC (permalink / raw) To: Drew Adams; +Cc: help-gnu-emacs, Raffaele Ricciardi [-- Attachment #1: Type: text/plain, Size: 2783 bytes --] Drew Adams <drew.adams@oracle.com> writes: >> The usefulness of frames is evident for buffers that update their >> content according to the current buffer (like Speedbar and ECB). >> Besides this kind of use, when do you prefer frames instead of >> windows? > > Personally, almost always. A window-manager window (Emacs frame) > is more flexible than an Emacs window - more features/possibilities. > > Emacs windows were conceived long, long ago - before window > managers were supported/recognized by Emacs and even, for the > most part, before they existed. They are vestigial organs that > have some limited uses but are generally not the best way to > interact, IMO. > > I generally don't like apps to try to lock everything they do into > a single window-mgr window (frame) and provide their own internal > windows within that frame. That applies to Emacs also. Whenever > possible/practical, I free such internal windows to become normal > window-mgr windows. With Emacs this is even better, as you can > manipulate frames using the keyboard, not just the mouse. > > However, out of the box, support for using Emacs frames is pretty > primitive. So I jump through a bunch of configuration hooks to > be able to use them easily (including keyboard manipulation). > > Just one (minority) opinion. > > I would ask an opposite question: IF you could use Emacs frames > as easily as you can use Emacs windows, in what scenarios would > you prefer using Emacs windows, and why? In the old Windows (95, 98, 2000 - after that I gave up with Windows) there were also the options to have in e.g. the Turbo Pascal IDE the windows in one application window (as "windows" under emacs) or as separate windows (as frames under emacs). And everybody had different preferences. And I think it it the same here. One major advantage under Linux when using frames instead of windows, is "focus follows mouse" - you can simply switch between different emacs frames by moving the mouse, which you can't when using windows. I know - I take cover - real emacs user don't use the mose, but for me it was faster to move the mouse then switching to a different frame, especially when more then one frame was present. Now I am using a Mac - not because I don not like Linux anymore, but because I think the hardware is simply brilliant - with OSX (Linux does not play nicely along with the retina display and the touch pad the last time I teried it out) the focus does not follow the mouse, so I am using frames as kind of topical separation for my buffers. One other advantage of using frames is multiple monitors - one frame per monitor. Cheers, Rainer > > -- Rainer M. Krug email: Rainer<at>krugs<dot>de PGP: 0x0F52F982 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 494 bytes --] ^ permalink raw reply [flat|nested] 838+ messages in thread
[parent not found: <mailman.14479.1416849631.1147.help-gnu-emacs@gnu.org>]
* Re: When do you prefer frames instead of windows? [not found] ` <mailman.14479.1416849631.1147.help-gnu-emacs@gnu.org> @ 2014-11-24 17:47 ` Barry Margolin 2014-11-24 18:06 ` Jai Dayal 2014-11-25 17:32 ` Joost Kremers [not found] ` <<slrnm79f8k.a37.joost.m.kremers@j.kremers4.news.arnhem.chello.nl> 2 siblings, 1 reply; 838+ messages in thread From: Barry Margolin @ 2014-11-24 17:47 UTC (permalink / raw) To: help-gnu-emacs In article <mailman.14479.1416849631.1147.help-gnu-emacs@gnu.org>, Drew Adams <drew.adams@oracle.com> wrote: > > The usefulness of frames is evident for buffers that update their > > content according to the current buffer (like Speedbar and ECB). > > Besides this kind of use, when do you prefer frames instead of > > windows? > > Personally, almost always. A window-manager window (Emacs frame) > is more flexible than an Emacs window - more features/possibilities. > > Emacs windows were conceived long, long ago - before window > managers were supported/recognized by Emacs and even, for the > most part, before they existed. They are vestigial organs that > have some limited uses but are generally not the best way to > interact, IMO. Yes, they came about on ASCII terminals, long before graphical interfaces became common. Since I've been using Emacs since those days, I long got used to using a single frame with Emacs windows in it. Now, even though I use it on a Mac with a wide screen, I still can't get into the habit of using multiple frames. -- Barry Margolin, barmar@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: When do you prefer frames instead of windows? 2014-11-24 17:47 ` Barry Margolin @ 2014-11-24 18:06 ` Jai Dayal 0 siblings, 0 replies; 838+ messages in thread From: Jai Dayal @ 2014-11-24 18:06 UTC (permalink / raw) To: Barry Margolin; +Cc: help-gnu-emacs I just use them when I like having different window arrangements based on content. For example, I like my code buffers split one way, but for actually running the application's workflow, I like having a window with 4 different ansi-terms split in quarters. Being able to switch easily between the different frames makes it very easy. On Mon, Nov 24, 2014 at 12:47 PM, Barry Margolin <barmar@alum.mit.edu> wrote: > In article <mailman.14479.1416849631.1147.help-gnu-emacs@gnu.org>, > Drew Adams <drew.adams@oracle.com> wrote: > > > > The usefulness of frames is evident for buffers that update their > > > content according to the current buffer (like Speedbar and ECB). > > > Besides this kind of use, when do you prefer frames instead of > > > windows? > > > > Personally, almost always. A window-manager window (Emacs frame) > > is more flexible than an Emacs window - more features/possibilities. > > > > Emacs windows were conceived long, long ago - before window > > managers were supported/recognized by Emacs and even, for the > > most part, before they existed. They are vestigial organs that > > have some limited uses but are generally not the best way to > > interact, IMO. > > Yes, they came about on ASCII terminals, long before graphical > interfaces became common. > > Since I've been using Emacs since those days, I long got used to using a > single frame with Emacs windows in it. Now, even though I use it on a > Mac with a wide screen, I still can't get into the habit of using > multiple frames. > > -- > Barry Margolin, barmar@alum.mit.edu > Arlington, MA > *** PLEASE post questions in newsgroups, not directly to me *** > ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: When do you prefer frames instead of windows? [not found] ` <mailman.14479.1416849631.1147.help-gnu-emacs@gnu.org> 2014-11-24 17:47 ` Barry Margolin @ 2014-11-25 17:32 ` Joost Kremers [not found] ` <<slrnm79f8k.a37.joost.m.kremers@j.kremers4.news.arnhem.chello.nl> 2 siblings, 0 replies; 838+ messages in thread From: Joost Kremers @ 2014-11-25 17:32 UTC (permalink / raw) To: help-gnu-emacs Drew Adams wrote: > I would ask an opposite question: IF you could use Emacs frames > as easily as you can use Emacs windows, in what scenarios would > you prefer using Emacs windows, and why? The one thing I like about Emacs windows as opposed to frames is that they resize automatically: when you create one, another window is reduced in size, so that the new window doesn't cover it, and when you delete one, another one grows in order to occupy the space that becomes available. I tend to work in a single window occupying a maximised frame, and when I want/need to do something else, I usually switch to that buffer. (I'm perfectly happy letting mu4e or ebib or ediff or whatever take over the entire window, hiding what I was working on before.) When I do split the one window, it's usually for something I only need to take a quick look at (help buffer, error messages, etc.) I don't want that window to cover what is in my "main" window, and I want to get rid of the extra window as soon as I'm done with it. AFAIK this automatic resizing isn't possible or at least not as easy with frames. I find this a definite advantage of windows over frames, and to be honest, I don't see what advantages frames have over windows. (You mention they have more features/possibilities, but I'm not sure which features you mean...) -- Joost Kremers joostkremers@fastmail.fm Selbst in die Unterwelt dringt durch Spalten Licht EN:SiS(9) ^ permalink raw reply [flat|nested] 838+ messages in thread
[parent not found: <<slrnm79f8k.a37.joost.m.kremers@j.kremers4.news.arnhem.chello.nl>]
* RE: When do you prefer frames instead of windows? [not found] ` <<slrnm79f8k.a37.joost.m.kremers@j.kremers4.news.arnhem.chello.nl> @ 2014-11-25 18:09 ` Drew Adams 0 siblings, 0 replies; 838+ messages in thread From: Drew Adams @ 2014-11-25 18:09 UTC (permalink / raw) To: Joost Kremers, help-gnu-emacs > > I would ask an opposite question: IF you could use Emacs frames > > as easily as you can use Emacs windows, in what scenarios would > > you prefer using Emacs windows, and why? > > The one thing I like about Emacs windows as opposed to frames is > that they resize automatically: when you create one, another window > is reduced in size, so that the new window doesn't cover it, and > when you delete one, another one grows in order to occupy the space > that becomes available. Agreed, but in a way you are making a virtue of necessity. From the moment that the design is such that windows cannot overlap, they *must* be resized, repositioned within the frame, or replaced by another window, as the only possible adjustments for visibility. Frames can overlap. That is a strength, not a weakness. It is an additional possibility, but they need not overlap. Nothing prevents a set of frames from having the same limited behavior that you like in Emacs windows: tiling, replacing each other, resizing relative to others shown, etc. In addition or alternatively, frames can overlap each other (by default). Are there advantages to overlapping and arbitrary (pixel-level) positioning? I think so. The analog to overlapping, for windows, is to turn on line truncation and allow an adjacent window more space. IOW, when you want to see more of one and are willing to forego seeing some of the other (but still see some of it), that's what you do with windows. (For the vertical case, just resize.) > I tend to work in a single window occupying a maximised frame, > and when I want/need to do something else, I usually switch to > that buffer. AFAIK this automatic resizing isn't possible or > at least not as easy with frames. It is possible. It is not provided (so no, it is not as easy). > I find this a definite advantage of windows over frames, Agreed. > and to be honest, I don't see what advantages frames have over > windows. (You mention they have more features/possibilities, > but I'm not sure which features you mean...) Whatever can be done with windows could be done with frames, AFAICT. That all of that is not easily available is another story. In addition, frames can be positioned arbitrarily. They are not constrained to be within anything, other than your display. And positioning is at the pixel level. That's about it, AFAIK. There are some other frame parameters that might not have analogs for windows (can't think of them, offhand), but essentially it's about arbitrary positioning. (There is also iconifying, but whether you look at that as a useful feature is up to you.) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: When do you prefer frames instead of windows? 2014-11-24 16:40 When do you prefer frames instead of windows? Raffaele Ricciardi 2014-11-24 17:20 ` Drew Adams [not found] ` <mailman.14479.1416849631.1147.help-gnu-emacs@gnu.org> @ 2014-11-24 19:10 ` MBR 2014-11-24 19:14 ` Drew Adams 2014-11-24 22:12 ` H. Dieter Wilhelm ` (7 subsequent siblings) 10 siblings, 1 reply; 838+ messages in thread From: MBR @ 2014-11-24 19:10 UTC (permalink / raw) To: Raffaele Ricciardi, help-gnu-emacs I use M-x compare-windows a LOT. So, I'll usually have at least one frame big enough to hold two side-by-side 80 column windows, and that's where I'll do most of my work. However I tend to open a new frame for things where I want to see an additional file briefly. Also, I'm frequently running a local terminal emulator, and from that emulator's shell prompt I've got an ssh connection to a remote host on which I'm running emacs. Under those circumstances, frames are not an option, so I use emacs windows for everything. Mark Rosenthal On 11/24/14 11:40 AM, Raffaele Ricciardi wrote: > The usefulness of frames is evident for buffers that update their > content according to the current buffer (like Speedbar and ECB). > Besides this kind of use, when do you prefer frames instead of windows? > > Thank you. > ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: When do you prefer frames instead of windows? 2014-11-24 19:10 ` MBR @ 2014-11-24 19:14 ` Drew Adams 0 siblings, 0 replies; 838+ messages in thread From: Drew Adams @ 2014-11-24 19:14 UTC (permalink / raw) To: MBR, Raffaele Ricciardi, help-gnu-emacs > I use M-x compare-windows a LOT. Thanks for the reminder. That is one of the few cases where I do split a frame into windows. Only because `compare-windows' (unlike Ediff, for example) does not work across frames. I should probably code up an enhancement for it that does, but I don't use `compare-windows' that often anymore, for some reason. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: When do you prefer frames instead of windows? 2014-11-24 16:40 When do you prefer frames instead of windows? Raffaele Ricciardi ` (2 preceding siblings ...) 2014-11-24 19:10 ` MBR @ 2014-11-24 22:12 ` H. Dieter Wilhelm [not found] ` <mailman.14497.1416867184.1147.help-gnu-emacs@gnu.org> ` (6 subsequent siblings) 10 siblings, 0 replies; 838+ messages in thread From: H. Dieter Wilhelm @ 2014-11-24 22:12 UTC (permalink / raw) To: help-gnu-emacs Raffaele Ricciardi <rfflrccrd@gmail.com> writes: > The usefulness of frames is evident for buffers that update their > content according to the current buffer (like Speedbar and > ECB). Besides this kind of use, when do you prefer frames instead of > windows? To preserve sane window layouts despite a multitude of major modes. For example: Barry Margolin pointed out that he prefers 4 ansi terminals in a "shell frame". I like to have a "file manager" frame with two dired buffers side by side. Gnus literally "demands" his own frame in its default mode of operation! Here's an illustration of my frame setup which is based on Alan Mackenzie work, so that I'm able to open frames with predefined window layouts according to various tasks or - if a task frame already exists, just switch to it. ;; ====================================================================== ;; `frames' based on Alan Mackenzie's setup (set-frame-name "Work") (modify-frame-parameters (selected-frame) '((acm-no . 2))) (find-file "~/org/blog/dddlll.org") (defun assign-acm-no (frame) "FRAME is a (typically newly created) frame. Give it an acm-no frame-parameter if there is one free (in the range 0..11). Return that number or nil." (let ((assigned (make-bool-vector 12 nil)) (f (frame-list)) n) (while f (if (setq n (frame-parameter (car f) 'acm-no)) (aset assigned n t)) (setq f (cdr f))) (setq n 0) (while (and (< n 12) (aref assigned n)) (setq n (1+ n))) (if (= n 12) nil (modify-frame-parameters frame `((acm-no . ,n))) n))) ;(add-hook 'after-make-frame-functions 'assign-acm-no) (defun find-acm-no-frame (n) "Return the frame with parameter (acm-no . N), or nil." (let ((f (frame-list))) (while (and f (not (eq (frame-parameter (car f) 'acm-no) n))) (setq f (cdr f))) (car f))) (defun focus-frame-acm-no (n) "Select the frame with acm-no frame-parameter N, or do nothing." (let ((frame (find-acm-no-frame n))) (when frame (select-frame-set-input-focus frame)) (framep frame))) ;; frame 2, 3, ... (defun focus-or-make-named-frame ( no) "bla" (unless (focus-frame-acm-no no) (let ((frame (make-frame-command))) (select-frame-set-input-focus frame) (cond ((= no 1) (modify-frame-parameters frame '((acm-no . 1))) (set-frame-name "F1 Informations, info, eww") (unless (get-buffer "*info*") (info)) ) ((= no 2) (modify-frame-parameters frame '((acm-no . 2))) (set-frame-name "F2 Work") ) ((= no 3) (modify-frame-parameters frame '((acm-no . 3))) (set-frame-name "F3 Communications Gnus, BBDB") (unless (get-buffer "*Group*") (gnus-unplugged)) ) ((= no 4) (modify-frame-parameters frame '((acm-no . 4))) (set-frame-name "F4 OS terminal, shell") (split-window-horizontally) (unless (get-buffer "*terminal*") (term "/bin/bash")) ) ((= no 5) (modify-frame-parameters frame '((acm-no . 5))) (set-frame-name "Time Management and Planning") (unless (get-buffer "*Calendar*") (calendar)) ) ((= no 6) (modify-frame-parameters frame '((acm-no . 6))) (set-frame-name "Programming and Configuration") (unless (get-buffer "init.el") (find-file "~/.emacs.d/init.el")) ) ((= no 7) (modify-frame-parameters frame '((acm-no . 7))) (set-frame-name "Dired File Manipulations") (dired "~")) ((= no 8) (modify-frame-parameters frame '((acm-no . 8))) (set-frame-name "Helper Frame")) ((= no 9) (modify-frame-parameters frame '((acm-no . 9))) (set-frame-name "ERC")) ((= no 10) (modify-frame-parameters frame '((acm-no . 9))) (set-frame-name "Image Dired")) )))) (global-set-key [f1] (lambda () "Switch to frame 1" (interactive) (focus-or-make-named-frame 1))) (global-set-key [f2] (lambda () "Switch to frame 2" (interactive) (focus-or-make-named-frame 2))) (global-set-key [f3] (lambda () "Switch to frame 3" (interactive) (focus-or-make-named-frame 3))) (global-set-key [f4] (lambda () "Switch to frame 4" (interactive) (focus-or-make-named-frame 4))) (global-set-key [f5] (lambda () "Switch to frame 5" (interactive) (focus-or-make-named-frame 5))) (global-set-key [f6] (lambda () "Switch to frame 6" (interactive) (focus-or-make-named-frame 6))) (global-set-key [f7] (lambda () "Switch to frame 7" (interactive) (focus-or-make-named-frame 7))) (global-set-key [f8] (lambda () "Switch to frame 8" (interactive) (focus-or-make-named-frame 8))) (global-set-key [f9] (lambda () "Switch to frame 9" (interactive) (focus-or-make-named-frame 9))) (global-set-key [f10] (lambda () "Switch to frame 10" (interactive) (focus-or-make-named-frame 10))) ;; F11 is toggle full-screen ;; (global-set-key [f12] (lambda () "Switch to frame 12" (interactive) (focus-or-make-named-frame 12))) Dieter -- Best wishes H. Dieter Wilhelm Darmstadt, Germany ^ permalink raw reply [flat|nested] 838+ messages in thread
[parent not found: <mailman.14497.1416867184.1147.help-gnu-emacs@gnu.org>]
* Re: When do you prefer frames instead of windows? [not found] ` <mailman.14497.1416867184.1147.help-gnu-emacs@gnu.org> @ 2014-11-25 0:59 ` Barry Margolin 0 siblings, 0 replies; 838+ messages in thread From: Barry Margolin @ 2014-11-25 0:59 UTC (permalink / raw) To: help-gnu-emacs In article <mailman.14497.1416867184.1147.help-gnu-emacs@gnu.org>, dieter@duenenhof-wilhelm.de (H. Dieter Wilhelm) wrote: > For example: Barry Margolin pointed out that he prefers 4 ansi terminals > in a "shell frame". I like to have a "file manager" frame with two > dired buffers side by side. Gnus literally "demands" his own frame in > its default mode of operation! That wasn't me, it was someone replying to my post. I just said I use one frame because it's an old habit. I've been using Emacs since 1980, multiple frames weren't added until 1994. Another advantage of windows over frames is they work the same whether you're using Emacs in a GUI or terminal. Although I admit that when I need to do a quick edit in a terminal, I usually use vi. This is usually when I'm ssh'ed into a server, and they usually don't have Emacs installed, and even if they did I wouldn't have all my extensions there. -- Barry Margolin, barmar@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: When do you prefer frames instead of windows? 2014-11-24 16:40 When do you prefer frames instead of windows? Raffaele Ricciardi ` (4 preceding siblings ...) [not found] ` <mailman.14497.1416867184.1147.help-gnu-emacs@gnu.org> @ 2014-11-25 1:29 ` Robert Thorpe 2014-11-25 4:21 ` Drew Adams 2014-11-25 1:45 ` Yuri Khan ` (4 subsequent siblings) 10 siblings, 1 reply; 838+ messages in thread From: Robert Thorpe @ 2014-11-25 1:29 UTC (permalink / raw) To: Raffaele Ricciardi; +Cc: help-gnu-emacs Raffaele Ricciardi <rfflrccrd@gmail.com> writes: > The usefulness of frames is evident for buffers that update their > content according to the current buffer (like Speedbar and ECB). > Besides this kind of use, when do you prefer frames instead of windows? If I have two distinct tasks that each require a set of buffers then sometimes I create two frames. As others have mentioned there are advantages to using frames. Modern X Windows environments have keybindings for common operations on frames. However, Microsoft Windows only has a few of those, to tiresome switching between the keyboard and mouse is needed. I use both X and MS Windows daily. I generally prefer using Emacs windows rather than frames becuase they can be manipulated using the keyboard on all platforms. BR, Robert Thorpe ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: When do you prefer frames instead of windows? 2014-11-25 1:29 ` Robert Thorpe @ 2014-11-25 4:21 ` Drew Adams 2014-11-25 8:54 ` Rainer M Krug 0 siblings, 1 reply; 838+ messages in thread From: Drew Adams @ 2014-11-25 4:21 UTC (permalink / raw) To: Robert Thorpe, Raffaele Ricciardi; +Cc: help-gnu-emacs > Modern X Windows environments have keybindings for common operations > on frames. However, Microsoft Windows only has a few of those, to > tiresome switching between the keyboard and mouse is needed. I use > both X and MS Windows daily. I generally prefer using Emacs windows > rather than frames becuase they can be manipulated using the keyboard > on all platforms. It should be possible, out of the box, to do that in Emacs itself. One set of keys for all platforms, and any set of keys you yourself choose. I wrote: > With Emacs this is even better, as you can manipulate frames > using the keyboard, not just the mouse. > > However, out of the box, support for using Emacs frames is pretty > primitive. So I jump through a bunch of configuration hooks to > be able to use them easily (including keyboard manipulation). You need to be able to do the same kinds of things with frames that you can do with Emacs windows - *from the keyboard* (and with a mouse). Including move around incrementally, resize incrementally, cycle/choose, tile/split, and so on. I use Emacs that way, but as I say, this is not provided out of the box with `emacs -Q'. (It should be, IMO.) I really would be interested in people's answers to my question, BTW: > IF you could use Emacs frames as easily as you can use Emacs > windows, in what scenarios would you prefer using Emacs windows, > and why? ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: When do you prefer frames instead of windows? 2014-11-25 4:21 ` Drew Adams @ 2014-11-25 8:54 ` Rainer M Krug 2014-11-25 15:47 ` Drew Adams 0 siblings, 1 reply; 838+ messages in thread From: Rainer M Krug @ 2014-11-25 8:54 UTC (permalink / raw) To: Drew Adams; +Cc: Raffaele Ricciardi, help-gnu-emacs, Robert Thorpe [-- Attachment #1: Type: text/plain, Size: 1760 bytes --] Drew Adams <drew.adams@oracle.com> writes: >> Modern X Windows environments have keybindings for common operations >> on frames. However, Microsoft Windows only has a few of those, to >> tiresome switching between the keyboard and mouse is needed. I use >> both X and MS Windows daily. I generally prefer using Emacs windows >> rather than frames becuase they can be manipulated using the keyboard >> on all platforms. > > It should be possible, out of the box, to do that in Emacs itself. > One set of keys for all platforms, and any set of keys you yourself > choose. > > I wrote: > > > With Emacs this is even better, as you can manipulate frames > > using the keyboard, not just the mouse. > > > > However, out of the box, support for using Emacs frames is pretty > > primitive. So I jump through a bunch of configuration hooks to > > be able to use them easily (including keyboard manipulation). > > You need to be able to do the same kinds of things with frames > that you can do with Emacs windows - *from the keyboard* (and with > a mouse). Including move around incrementally, resize incrementally, > cycle/choose, tile/split, and so on. > > I use Emacs that way, but as I say, this is not provided out of the > box with `emacs -Q'. (It should be, IMO.) You are throwing teaser around - is your emacs config some=where on=ine, so that I could take a look at your configuration regarding frames? > > I really would be interested in people's answers to my question, BTW: > > > IF you could use Emacs frames as easily as you can use Emacs > > windows, in what scenarios would you prefer using Emacs windows, > > and why? > > -- Rainer M. Krug email: Rainer<at>krugs<dot>de PGP: 0x0F52F982 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 494 bytes --] ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: When do you prefer frames instead of windows? 2014-11-25 8:54 ` Rainer M Krug @ 2014-11-25 15:47 ` Drew Adams 0 siblings, 0 replies; 838+ messages in thread From: Drew Adams @ 2014-11-25 15:47 UTC (permalink / raw) To: Rainer M Krug; +Cc: Raffaele Ricciardi, help-gnu-emacs, Robert Thorpe > > You need to be able to do the same kinds of things with frames > > that you can do with Emacs windows - *from the keyboard* (and with > > a mouse). Including move around incrementally, resize > > incrementally, cycle/choose, tile/split, and so on. > > > > I use Emacs that way, but as I say, this is not provided out of > > the box with `emacs -Q'. (It should be, IMO.) > > You are throwing teaser around - is your emacs config some=where > on=ine, so that I could take a look at your configuration regarding > frames? I really did not mean it that way. I'm more interested here in looking at the use cases that people might think really apply to Emacs windows inherently. It's about a thought experiment: WHAT IF you could easily do with frames what you do with windows, using the keyboard (or the mouse)? Would you still see some scenarios where you would prefer to use a window? If so, what would they be? I do use code that tries to make frames more convenient to use, but that really is beside the point of my question. What I would like is for vanilla Emacs to provide frame-friendly manipulation. I do understand that Emacs does not have real control over window-manager windows (i.e., frames); it can only request/suggest changes to be made by the window manager. And different platforms & window managers are different, so it is likely that there would never be a 100% cross-platform solution with the level of control that we have with Emacs windows. Still, I know from my own experience that it is possible to obtain pretty much all of the control I expect, at least across GNU/Linux, UNIX, and MS Windows - I can't vouch for others. [If you do want to try the code I use, just to get an idea of what I mean, look here: http://www.emacswiki.org/OneOnOneEmacs. But again, I'm *not* proposing such code as the solution or even as *a* solution to the problem of easily doing with frames what you do with Emacs windows. This is code that I use to try to overcome the problem, imperfectly. That's all.] ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: When do you prefer frames instead of windows? 2014-11-24 16:40 When do you prefer frames instead of windows? Raffaele Ricciardi ` (5 preceding siblings ...) 2014-11-25 1:29 ` Robert Thorpe @ 2014-11-25 1:45 ` Yuri Khan 2014-11-25 9:27 ` Ralf Fassel ` (3 subsequent siblings) 10 siblings, 0 replies; 838+ messages in thread From: Yuri Khan @ 2014-11-25 1:45 UTC (permalink / raw) To: Raffaele Ricciardi; +Cc: help-gnu-emacs@gnu.org On Mon, Nov 24, 2014 at 10:40 PM, Raffaele Ricciardi <rfflrccrd@gmail.com> wrote: > The usefulness of frames is evident for buffers that update their content > according to the current buffer (like Speedbar and ECB). Besides this kind > of use, when do you prefer frames instead of windows? At my job, I have a dual monitor setup (16:9 24" + 4:3 20"). I split my left monitor into two window stacks with i3wm, then put an Emacs frame in each stack. This gives me roughly 100-character-wide frames which happily coincides with my team’s coding standard. This way, I can work with up to 4 buffers when necessary, or independently switch any of the stacks to a different application (xterm or Firefox or whatever). ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: When do you prefer frames instead of windows? 2014-11-24 16:40 When do you prefer frames instead of windows? Raffaele Ricciardi ` (6 preceding siblings ...) 2014-11-25 1:45 ` Yuri Khan @ 2014-11-25 9:27 ` Ralf Fassel 2014-11-25 15:47 ` Drew Adams [not found] ` <mailman.14554.1416930453.1147.help-gnu-emacs@gnu.org> 2014-11-25 22:28 ` Bob Proulx ` (2 subsequent siblings) 10 siblings, 2 replies; 838+ messages in thread From: Ralf Fassel @ 2014-11-25 9:27 UTC (permalink / raw) To: help-gnu-emacs * Raffaele Ricciardi <rfflrccrd@gmail.com> | The usefulness of frames is evident for buffers that update their | content according to the current buffer (like Speedbar and | ECB). Besides this kind of use, when do you prefer frames instead of | windows? Single frame for Ediff: A on top, B in the middle, Control at bottom. The separate control frame is a nuisance with focus-follows-mouse, it almost always is out of focus, loses the cursor, or misbehaves in other fashions... R' ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: When do you prefer frames instead of windows? 2014-11-25 9:27 ` Ralf Fassel @ 2014-11-25 15:47 ` Drew Adams [not found] ` <mailman.14554.1416930453.1147.help-gnu-emacs@gnu.org> 1 sibling, 0 replies; 838+ messages in thread From: Drew Adams @ 2014-11-25 15:47 UTC (permalink / raw) To: Ralf Fassel, help-gnu-emacs > Single frame for Ediff: A on top, B in the middle, Control at > bottom. The separate control frame is a nuisance with > focus-follows-mouse, it almost always is out of focus, loses > the cursor, or misbehaves in other fashions... Seems like that is something that could be fixed. Have you thought about filing a bug report / enhancement request? (`M-x report-emacs-bug') FWIW, I've been using Ediff with separate frames for decades, and I don't have any such problem. But I don't use `focus-follows-mouse'. In principle, Ediff should play well with separate frames. ^ permalink raw reply [flat|nested] 838+ messages in thread
[parent not found: <mailman.14554.1416930453.1147.help-gnu-emacs@gnu.org>]
* Re: When do you prefer frames instead of windows? [not found] ` <mailman.14554.1416930453.1147.help-gnu-emacs@gnu.org> @ 2014-11-25 15:57 ` Ralf Fassel 2014-11-25 16:57 ` Drew Adams ` (2 more replies) 0 siblings, 3 replies; 838+ messages in thread From: Ralf Fassel @ 2014-11-25 15:57 UTC (permalink / raw) To: help-gnu-emacs * Drew Adams <drew.adams@oracle.com> | > Single frame for Ediff: A on top, B in the middle, Control at | > bottom. The separate control frame is a nuisance with | > focus-follows-mouse, it almost always is out of focus, loses | > the cursor, or misbehaves in other fashions... > | Seems like that is something that could be fixed. Have you | thought about filing a bug report / enhancement request? | (`M-x report-emacs-bug') It's not a bug... :-) I don't think there is anything that emacs can do about it. If I want focus-follows-mouse (and I want it :-), then moving the mouse out of the ediff control frame really should move the mouse out of it, and not try to be helpful and force the mouse inside the control frame or such nonsense. I now have bound a key to get my ediff control panel back: <C-M-up> runs the command (lambda nil (interactive) (let ((buf (get-buffer "*Ediff Control Panel*"))) (if buf (pop-to-buffer buf)))), which is an interactive Lisp function. and then C-l recenters everything (could even pack that in the keybinding, but...) My EUR 0.02 R' ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: When do you prefer frames instead of windows? 2014-11-25 15:57 ` Ralf Fassel @ 2014-11-25 16:57 ` Drew Adams [not found] ` <mailman.14564.1416934703.1147.help-gnu-emacs@gnu.org> 2014-11-26 5:02 ` Yuri Khan 2 siblings, 0 replies; 838+ messages in thread From: Drew Adams @ 2014-11-25 16:57 UTC (permalink / raw) To: Ralf Fassel, help-gnu-emacs > | > Single frame for Ediff: A on top, B in the middle, Control at > | > bottom. The separate control frame is a nuisance with > | > focus-follows-mouse, it almost always is out of focus, loses > | > the cursor, or misbehaves in other fashions... > > > | Seems like that is something that could be fixed. Have you > | thought about filing a bug report / enhancement request? > | (`M-x report-emacs-bug') > > It's not a bug... :-) I don't think there is anything that emacs can > do about it. If I want focus-follows-mouse (and I want it :-), then > moving the mouse out of the ediff control frame really should move the > mouse out of it, and not try to be helpful and force the mouse inside > the control frame or such nonsense. Is that not what happens? I would think that that is a bug. I agree that with focus-follow-mouse the focus should follow the mouse. ;-) And if it did do that? What would the problem be with Ediff, in that case? I should think that there would be no problem. If you leave your mouse in the Ediff Control Panel frame then focus should stay there, and if you move it out of that frame, into another frame, then focus should leave that frame. That should be no different from turning off focus-follows-mouse and clicking in a frame to focus it. Assuming that this worked (if it does not), what would the problem be for Ediff, for your use? > I now have bound a key to get my ediff control panel back: > <C-M-up> runs the command (lambda nil (interactive) (let ((buf > (get-buffer "*Ediff Control Panel*"))) (if buf (pop-to-buffer > buf)))), > which is an interactive Lisp function. > and then C-l recenters everything (could even pack that in the > keybinding, but...) I don't think Ediff should be grabbing focus back, if you have asked that focus move elsewhere (which you do when you move the mouse out of the control frame). This sounds like a bug, to me (FWIW). ^ permalink raw reply [flat|nested] 838+ messages in thread
[parent not found: <mailman.14564.1416934703.1147.help-gnu-emacs@gnu.org>]
* Re: When do you prefer frames instead of windows? [not found] ` <mailman.14564.1416934703.1147.help-gnu-emacs@gnu.org> @ 2014-11-25 17:16 ` Ralf Fassel 2014-11-25 18:09 ` Drew Adams 2014-11-25 22:02 ` Subhan Michael Tindall 0 siblings, 2 replies; 838+ messages in thread From: Ralf Fassel @ 2014-11-25 17:16 UTC (permalink / raw) To: help-gnu-emacs * Drew Adams <drew.adams@oracle.com> | If you leave your mouse in the Ediff Control Panel frame then focus | should stay there, and if you move it out of that frame, into another | frame, then focus should leave that frame. That should be no | different from turning off focus-follows-mouse and clicking in a frame | to focus it. Agreed, and that is exactly what happens. No fault of emacs anywhere in sight. Problem is completely located between chair and screen. | Assuming that this worked (if it does not), what would the problem be | for Ediff, for your use? During an Ediff Session, sometimes I have to leave the Control Panel to check something in a different window or buffer, or even on a different desktop. When I get back to Ediff: where is my Control Panel? Yes, of course it is still where I left it, upper right corner of the screen, but obscured now by the terminal, firefox or any other odd window I happened to raise over it during my check-something-outside-of-ediff. And even if the Control Panel is still visible on the screen, the mouse is no longer inside that Control Panel. In order to get my ediff session back, I have to accurately raise the control panel, raise emacs (I *think* they are connected somehow, so maybe this is not necessary), place mouse accurately inside (tiny) Control Panel, pay attention not to nudge it out of there etc etc. Compare to single frame ediff: move mouse anywhere into (large) emacs window, press C-M-Up, press C-L, continue with ediff. And no, I will *not* enter a bug report for this, even if it were one ;-) R' ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: When do you prefer frames instead of windows? 2014-11-25 17:16 ` Ralf Fassel @ 2014-11-25 18:09 ` Drew Adams 2014-11-25 22:08 ` Subhan Michael Tindall [not found] ` <mailman.14600.1416953316.1147.help-gnu-emacs@gnu.org> 2014-11-25 22:02 ` Subhan Michael Tindall 1 sibling, 2 replies; 838+ messages in thread From: Drew Adams @ 2014-11-25 18:09 UTC (permalink / raw) To: Ralf Fassel, help-gnu-emacs > During an Ediff Session, sometimes I have to leave the Control Panel > to check something in a different window or buffer, or even on a > different desktop. When I get back to Ediff: where is my Control Panel? > Yes, of course it is still where I left it, upper right corner of the > screen, but obscured now by the terminal, firefox or any other odd > window I happened to raise over it during my check-something-outside-of- > ediff. And even if the Control Panel is still visible on the screen, > the mouse is no longer inside that Control Panel. Yes, this is why Emacs should provide simple key sequences to raise and refocus frames. It's no different from what happens if you (one way or another) select another window, if that window obscures (e.g. replaces) the window you previously had selected. You need an easy way to select arbitrary windows and frames, including from the keyboard. Wrt frames obscuring/overlapping other frames (for which the window analogy is windows replacing other windows, or windows simply being removed), it helps a lot if you let frames be automatically fit to the size of their displayed text (within max & min limits you set). > In order to get my ediff session back, I have to accurately raise > the control panel, raise emacs (I *think* they are connected somehow, > so maybe this is not necessary), place mouse accurately inside (tiny) > Control Panel, pay attention not to nudge it out of there etc etc. Yup. A PITA. > Compare to single frame ediff: move mouse anywhere into (large) > emacs window, press C-M-Up, press C-L, continue with ediff. Yes. Consider binding a key to refocus the Ediff Control Panel frame. You can bind it for just the duration of the Ediff command. (The function to raise and focus a frame is `select-frame-set-input-focus'.) > And no, I will *not* enter a bug report for this, even if it were > one ;-) OK. ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: When do you prefer frames instead of windows? 2014-11-25 18:09 ` Drew Adams @ 2014-11-25 22:08 ` Subhan Michael Tindall 2014-11-25 22:22 ` Drew Adams [not found] ` <mailman.14600.1416953316.1147.help-gnu-emacs@gnu.org> 1 sibling, 1 reply; 838+ messages in thread From: Subhan Michael Tindall @ 2014-11-25 22:08 UTC (permalink / raw) To: Drew Adams, Ralf Fassel, help-gnu-emacs@gnu.org > -----Original Message----- > From: help-gnu-emacs-bounces+subhant=familycareinc.org@gnu.org > [mailto:help-gnu-emacs-bounces+subhant=familycareinc.org@gnu.org] On > Behalf Of Drew Adams > Sent: Tuesday, November 25, 2014 10:10 AM > To: Ralf Fassel; help-gnu-emacs@gnu.org > Subject: RE: When do you prefer frames instead of windows? > [SNIP] > > Yes, this is why Emacs should provide simple key sequences to raise and > refocus frames. Raise-frame and lower-frame can be easily bound to whatever keys you like. Other-frame is already bound by default to C-x 5 0 It can't get much easier than that. There's a host of functions for frame management, try C-h a frame for many more Hope this makes your world less frustrating, Subhan This message is intended for the sole use of the individual and entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended addressee, nor authorized to receive for the intended addressee, you are hereby notified that you may not use, copy, disclose or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete the message. Thank you. ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: When do you prefer frames instead of windows? 2014-11-25 22:08 ` Subhan Michael Tindall @ 2014-11-25 22:22 ` Drew Adams 0 siblings, 0 replies; 838+ messages in thread From: Drew Adams @ 2014-11-25 22:22 UTC (permalink / raw) To: Subhan Michael Tindall, Ralf Fassel, help-gnu-emacs > > Yes, this is why Emacs should provide simple key sequences to > > raise and refocus frames. > > Raise-frame and lower-frame can be easily bound to whatever keys > you like. Of course. > Other-frame is already bound by default to C-x 5 0 > It can't get much easier than that. Yes, it can. If you have 30 frames then you don't want to cycle through them to get to the frame you want. Same problem with windows and `C-x o', but there you are limited to the windows in a single frame (by default), and it is less likely that you will have 30 of them, or even 10. Cycling through lots of candidates, even given the additional (prefix-arg) possibility of specifying how many to go forward or back, is a pretty rudimentary UI when there are many candidates. It can definitely get easier than that. One possibility is to let you (i.e., optionally) choose a window/frame by name, with completion. > There's a host of functions for frame management, try C-h a > frame for many more Still not good enough, IMHO. There is lots of room for improving how Emacs plays with frames. FWIW, this is what I bind to `C-x o': ,---- | C-x o runs the command icicle-other-window-or-frame, which is an | interactive compiled Lisp function in `icicles-cmd1.el'. | | It is bound to C-x o. | | (icicle-other-window-or-frame ARG) | | Select a window or frame, by name or by order. | This command combines Emacs commands `other-window' and `other-frame', | together with Icicles commands `icicle-select-window', | `icicle-select-frame', and `icicle-choose-window-for-buffer-display'. | Use the prefix argument to choose the behavior, as follows: | | With no prefix arg or a non-zero numeric prefix arg: | If the selected frame has multiple windows, then this is | `other-window'. Otherwise, it is `other-frame'. | | With a zero prefix arg (e.g. `C-0'): | If the selected frame has multiple windows, then this is | `icicle-select-window' with windows in the frame as candidates. | Otherwise (single-window frame), this is `icicle-select-frame'. | | With plain `C-u': | If the selected frame has multiple windows, then this is | `icicle-select-window' with windows from all visible frames as | candidates. Otherwise, this is `icicle-select-frame'. | | With plain `C-u C-u': | Same as `icicle-select-window' with a negative prefix arg: Select a | window from any frame, including iconified and invisible frames. | | With plain `C-u C-u C-u': | This is `icicle-choose-window-for-buffer-display', with windows from | all frames (i.e., iconified and invisible) frames as candidates. | | If you use library `oneonone.el' with a standalone minibuffer frame, | and if option `1on1-remap-other-frame-command-flag' is non-nil, then | frame selection can include the standalone minibuffer frame. | | By default, Icicle mode remaps all key sequences that are normally | bound to `other-window' to `icicle-other-window-or-frame'. If you do | not want this remapping, then customize option | `icicle-top-level-key-bindings'. `---- ^ permalink raw reply [flat|nested] 838+ messages in thread
[parent not found: <mailman.14600.1416953316.1147.help-gnu-emacs@gnu.org>]
* Re: When do you prefer frames instead of windows? [not found] ` <mailman.14600.1416953316.1147.help-gnu-emacs@gnu.org> @ 2014-11-26 9:34 ` Joost Kremers 0 siblings, 0 replies; 838+ messages in thread From: Joost Kremers @ 2014-11-26 9:34 UTC (permalink / raw) To: help-gnu-emacs Subhan Michael Tindall wrote: > Other-frame is already bound by default to C-x 5 0 `C-x 5 0` is bound to `delete-frame`. `other-frame` is bound to `C-x 5 o`. That's the letter `o`, not the number `0`. :-) -- Joost Kremers joostkremers@fastmail.fm Selbst in die Unterwelt dringt durch Spalten Licht EN:SiS(9) ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: When do you prefer frames instead of windows? 2014-11-25 17:16 ` Ralf Fassel 2014-11-25 18:09 ` Drew Adams @ 2014-11-25 22:02 ` Subhan Michael Tindall 1 sibling, 0 replies; 838+ messages in thread From: Subhan Michael Tindall @ 2014-11-25 22:02 UTC (permalink / raw) To: Ralf Fassel, help-gnu-emacs@gnu.org > -----Original Message----- > From: help-gnu-emacs-bounces+subhant=familycareinc.org@gnu.org > [mailto:help-gnu-emacs-bounces+subhant=familycareinc.org@gnu.org] On > Behalf Of Ralf Fassel > Sent: Tuesday, November 25, 2014 9:16 AM > To: help-gnu-emacs@gnu.org > Subject: Re: When do you prefer frames instead of windows? > > * Drew Adams <drew.adams@oracle.com> > | If you leave your mouse in the Ediff Control Panel frame then focus > | should stay there, and if you move it out of that frame, into another > | frame, then focus should leave that frame. That should be no > | different from turning off focus-follows-mouse and clicking in a frame > | to focus it. > > Agreed, and that is exactly what happens. No fault of emacs anywhere in > sight. Problem is completely located between chair and screen. > > | Assuming that this worked (if it does not), what would the problem be > | for Ediff, for your use? > > During an Ediff Session, sometimes I have to leave the Control Panel to check > something in a different window or buffer, or even on a different desktop. > When I get back to Ediff: where is my Control Panel? Yes, of course it is still > where I left it, upper right corner of the screen, but obscured now by the > terminal, firefox or any other odd window I happened to raise over it during > my check-something-outside-of-ediff. > And even if the Control Panel is still visible on the screen, the mouse is no > longer inside that Control Panel. > > In order to get my ediff session back, I have to accurately raise the control > panel, raise emacs (I *think* they are connected somehow, so maybe this is > not necessary), place mouse accurately inside (tiny) Control Panel, pay > attention not to nudge it out of there etc etc. > > Compare to single frame ediff: move mouse anywhere into (large) emacs > window, press C-M-Up, press C-L, continue with ediff.[>] Compare with frames: C-x 5 o to cycle through the frames until you're back to the control panel(1-n times depending on how many other frames you have). Works way better than trying to raise/lower/etc. > > And no, I will *not* enter a bug report for this, even if it were one ;-) > > R' This message is intended for the sole use of the individual and entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended addressee, nor authorized to receive for the intended addressee, you are hereby notified that you may not use, copy, disclose or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete the message. Thank you. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: When do you prefer frames instead of windows? 2014-11-25 15:57 ` Ralf Fassel 2014-11-25 16:57 ` Drew Adams [not found] ` <mailman.14564.1416934703.1147.help-gnu-emacs@gnu.org> @ 2014-11-26 5:02 ` Yuri Khan 2 siblings, 0 replies; 838+ messages in thread From: Yuri Khan @ 2014-11-26 5:02 UTC (permalink / raw) To: Ralf Fassel; +Cc: help-gnu-emacs@gnu.org On Tue, Nov 25, 2014 at 9:57 PM, Ralf Fassel <ralfixx@gmx.de> wrote: > I now have bound a key to get my ediff control panel back: > <C-M-up> runs the command (lambda nil (interactive) (let ((buf > (get-buffer "*Ediff Control Panel*"))) (if buf (pop-to-buffer buf)))), > which is an interactive Lisp function. > and then C-l recenters everything (could even pack that in the > keybinding, but...) You might want to go further (I know I do!) and make bindings that (1) temporarily switch to the ediff control panel, (2) perform an ediff control panel command, (3) switch back to the buffer you were in — for each command that you frequently use in ediff. (Personally I find next-difference and previous-difference sufficient.) Something like this: (require 'cl) (defun yk-global-ediff--find-session (buffer) "Return the control buffer of the first ediff session involving BUFFER, or the control buffer of the first ediff session, or nil." (or (cl-find-if (lambda (control-buffer) (with-current-buffer control-buffer (memq buffer (list ediff-buffer-A ediff-buffer-B ediff-buffer-C)))) ediff-session-registry) (car-safe ediff-session-registry))) (defun yk-global-ediff-next-difference () "Go to the next difference according to the ediff session involving the current buffer, or if there is no such session, according to the first ediff session." (interactive) (let ((session (yk-global-ediff--find-session (current-buffer)))) (when session (save-window-excursion (with-current-buffer session (ediff-next-difference)))))) (defun yk-global-ediff-previous-difference () "Go to the previous difference according to the ediff session involving the current buffer, or if there is no such session, according to the first ediff session." (interactive) (let ((session (yk-global-ediff--find-session (current-buffer)))) (when session (save-window-excursion (with-current-buffer session (ediff-previous-difference)))))) (define-minor-mode yk-global-ediff-navigation-mode "Toggle global ediff navigation mode." :global t :lighter " E≜" :init-value nil :keymap `((,(kbd "M-n") . yk-global-ediff-next-difference) (,(kbd "M-p") . yk-global-ediff-previous-difference))) (defun yk-global-ediff--cleanup () (unless ediff-session-registry (yk-global-ediff-navigation-mode 0))) (add-hook 'ediff-mode-hook 'yk-global-ediff-navigation-mode) (add-hook 'ediff-cleanup-hook 'yk-global-ediff--cleanup) ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: When do you prefer frames instead of windows? 2014-11-24 16:40 When do you prefer frames instead of windows? Raffaele Ricciardi ` (7 preceding siblings ...) 2014-11-25 9:27 ` Ralf Fassel @ 2014-11-25 22:28 ` Bob Proulx 2014-11-25 22:54 ` Drew Adams 2014-11-26 16:37 ` Ken Goldman 2014-11-27 21:02 ` Chris F.A. Johnson 10 siblings, 1 reply; 838+ messages in thread From: Bob Proulx @ 2014-11-25 22:28 UTC (permalink / raw) To: help-gnu-emacs Raffaele Ricciardi wrote: > The usefulness of frames is evident for buffers that update their content > according to the current buffer (like Speedbar and ECB). Besides this kind > of use, when do you prefer frames instead of windows? I have seen a lot of commentary about frames. One thing that has been missing is the discussion of the window manager used to manage those frames. It really isn't possible to talk about emacs and frame management without also involving the window manager. "Ay, there's the rub." And that is as personal of a choice as the choice of editor. Focus follows mouse? Click to focus? Click to raise? Autoraise? Tiling? Single or multiple screens? The combination of possibilities will create a large number of answers. None of which is canonically correct. All are correct for that individual. Personally I tend to use one frame for everything. I sometimes use additional frames but only rarely. Bob ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: When do you prefer frames instead of windows? 2014-11-25 22:28 ` Bob Proulx @ 2014-11-25 22:54 ` Drew Adams 2014-11-26 8:12 ` Alan Schmitt 0 siblings, 1 reply; 838+ messages in thread From: Drew Adams @ 2014-11-25 22:54 UTC (permalink / raw) To: Bob Proulx, help-gnu-emacs > I have seen a lot of commentary about frames. One thing that has > been missing is the discussion of the window manager used to manage > those frames. It really isn't possible to talk about emacs and frame > management without also involving the window manager. "Ay, there's > the rub." And that is as personal of a choice as the choice of > editor. Focus follows mouse? Click to focus? Click to raise? > Autoraise? Tiling? Single or multiple screens? The combination of > possibilities will create a large number of answers. None of which > is canonically correct. All are correct for that individual. Of course. But Emacs does provide basic operations for manipulating frames, and they work across platforms, and they already take into account user choices (focus follows mouse etc.). What is missing out of the box, IMO are: * Better UI - commands and bindings, to do things that we currently do with windows. * Better interaction between the rest of Emacs and frames. The second one is harder to fix in one sense: doing so probably will involve fixes across different platforms. But the main obstacle, IMO, is that few people use frames a lot, and with fewer users there is not the necessary consideration of cross-functional behavior (e.g. how this or that feature plays well with frames). Emacs developers, like most Emacs users, do not pay as much attention to the case of using frames instead of windows. Less attention when it comes to design and implementation, and less attention when it comes to updates & bugs. That's just the way it is, and it's normal: more attention goes to what more people use more often. > Personally I tend to use one frame for everything. I sometimes use > additional frames but only rarely. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: When do you prefer frames instead of windows? 2014-11-25 22:54 ` Drew Adams @ 2014-11-26 8:12 ` Alan Schmitt 2014-11-26 13:42 ` H. Dieter Wilhelm 2014-11-28 13:51 ` Tom Davey 0 siblings, 2 replies; 838+ messages in thread From: Alan Schmitt @ 2014-11-26 8:12 UTC (permalink / raw) To: help-gnu-emacs [-- Attachment #1: Type: text/plain, Size: 1069 bytes --] On 2014-11-25 14:54, Drew Adams <drew.adams@oracle.com> writes: > But the main obstacle, IMO, is that few people use frames a lot, > and with fewer users there is not the necessary consideration > of cross-functional behavior (e.g. how this or that feature > plays well with frames). The main reason why I don't use frames is because the window manager on OS X lacks too many features (in particular regarding multiple desktops and keyboard navigation). So I use a single emacs frame in full screen mode, and workgroups2 to manage several groups of windows (this is quite useful for modes that enjoy destroying carefully arranged windows, yes gnus I'm looking at you). I was using multiple (full screen) frames instead of workgroups at some point, but I stopped because ERC notifications would not be aware of the frame being visible or not, so I would get no notification at all. Also, the possibility of restoring frames using desktop.el was not available then (I think it's new in emacs 24.4). Alan -- OpenPGP Key ID : 040D0A3B4ED2E5C7 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 494 bytes --] ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: When do you prefer frames instead of windows? 2014-11-26 8:12 ` Alan Schmitt @ 2014-11-26 13:42 ` H. Dieter Wilhelm 2014-11-28 13:51 ` Tom Davey 1 sibling, 0 replies; 838+ messages in thread From: H. Dieter Wilhelm @ 2014-11-26 13:42 UTC (permalink / raw) To: help-gnu-emacs Alan Schmitt <alan.schmitt@polytechnique.org> writes: > I was using multiple (full screen) frames instead of workgroups at some > point, but I stopped because ERC notifications would not be aware of the > frame being visible or not, so I would get no notification at all. Also, Hello, setting erc-track-visibility to 'selected-visible should do. Dieter -- Best wishes H. Dieter Wilhelm Darmstadt, Germany ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: When do you prefer frames instead of windows? 2014-11-26 8:12 ` Alan Schmitt 2014-11-26 13:42 ` H. Dieter Wilhelm @ 2014-11-28 13:51 ` Tom Davey 2014-11-28 15:39 ` Drew Adams 1 sibling, 1 reply; 838+ messages in thread From: Tom Davey @ 2014-11-28 13:51 UTC (permalink / raw) To: help-gnu-emacs Alan Schmitt writes: > So I use a single emacs frame in full screen > mode, and workgroups2 to manage several groups of windows This. Workgroups is an outstanding extension. It seems to me that, for all the presumed uses of frames for managing multiple groups of windows, workgroups can do it better, providing out of the box most of what this thread is seeking from frames. On Wed, Nov 26, 2014 at 3:12 AM, Alan Schmitt < alan.schmitt@polytechnique.org> wrote: > On 2014-11-25 14:54, Drew Adams <drew.adams@oracle.com> writes: > > > But the main obstacle, IMO, is that few people use frames a lot, > > and with fewer users there is not the necessary consideration > > of cross-functional behavior (e.g. how this or that feature > > plays well with frames). > > The main reason why I don't use frames is because the window manager on > OS X lacks too many features (in particular regarding multiple desktops > and keyboard navigation). So I use a single emacs frame in full screen > mode, and workgroups2 to manage several groups of windows (this is quite > useful for modes that enjoy destroying carefully arranged windows, yes > gnus I'm looking at you). > > I was using multiple (full screen) frames instead of workgroups at some > point, but I stopped because ERC notifications would not be aware of the > frame being visible or not, so I would get no notification at all. Also, > the possibility of restoring frames using desktop.el was not available > then (I think it's new in emacs 24.4). > > Alan > > -- > OpenPGP Key ID : 040D0A3B4ED2E5C7 > -- -- Tom Davey tom@tomdavey.com New York NY USA ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: When do you prefer frames instead of windows? 2014-11-28 13:51 ` Tom Davey @ 2014-11-28 15:39 ` Drew Adams 0 siblings, 0 replies; 838+ messages in thread From: Drew Adams @ 2014-11-28 15:39 UTC (permalink / raw) To: Tom Davey, help-gnu-emacs > > So I use a single emacs frame in full screen > > mode, and workgroups2 to manage several groups of windows > > This. Workgroups is an outstanding extension. It seems to me that, > for all the presumed uses of frames for managing multiple groups > of windows, workgroups can do it better, OK, that's one point. > providing out of the box most of what this thread is seeking > from frames. But that's a different point. I'm not familiar with workgroups2, but "managing multiple groups of [Emacs] windows" is not "most of what this thread is seeking from frames." IOW, so far, it sounds like workgroups2 might be an argument *not* to use Emacs windows instead of frames. But so far, it does not sound like an argument for using workgroups2 (or using Emacs windows) instead of frames. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: When do you prefer frames instead of windows? 2014-11-24 16:40 When do you prefer frames instead of windows? Raffaele Ricciardi ` (8 preceding siblings ...) 2014-11-25 22:28 ` Bob Proulx @ 2014-11-26 16:37 ` Ken Goldman 2014-11-27 21:02 ` Chris F.A. Johnson 10 siblings, 0 replies; 838+ messages in thread From: Ken Goldman @ 2014-11-26 16:37 UTC (permalink / raw) To: help-gnu-emacs On 11/24/2014 11:40 AM, Raffaele Ricciardi wrote: > The usefulness of frames is evident for buffers that update their > content according to the current buffer (like Speedbar and ECB). Besides > this kind of use, when do you prefer frames instead of windows? I always have 10's of frames open when coding, so I can easily switch between them, while each is a full window. I use windows a lot in conjunction with keyboard macros. The macro will do something in one window, switch to the other window to do something else, then back. E.g., converting a big case statement <-> macro #defines, making function prototypes from functions, any repetitive multi-file macro. ^ permalink raw reply [flat|nested] 838+ messages in thread
* Re: When do you prefer frames instead of windows? 2014-11-24 16:40 When do you prefer frames instead of windows? Raffaele Ricciardi ` (9 preceding siblings ...) 2014-11-26 16:37 ` Ken Goldman @ 2014-11-27 21:02 ` Chris F.A. Johnson 10 siblings, 0 replies; 838+ messages in thread From: Chris F.A. Johnson @ 2014-11-27 21:02 UTC (permalink / raw) To: help-gnu-emacs On Mon, 24 Nov 2014, Raffaele Ricciardi wrote: > The usefulness of frames is evident for buffers that update their content > according to the current buffer (like Speedbar and ECB). Besides this kind of > use, when do you prefer frames instead of windows? I use a new frame only when I want it on a different workspace. I use a second (or, occasionally, a third) window when I need to refer to one buffer while working in another (e.g. http://t.cfaj.ca/emacs-cv.jpg). Other than that, I use multiple buffers, often having as many as 50 open at once. -- Chris F.A. Johnson, <http://cfajohnson.com> ^ permalink raw reply [flat|nested] 838+ messages in thread
* when you gotta have a variable value for a symbol name
@ 2014-07-23 21:37 Buchs, Kevin J.
2014-07-23 22:02 ` Drew Adams
[not found] ` <mailman.5936.1406152985.1147.help-gnu-emacs@gnu.org>
0 siblings, 2 replies; 838+ messages in thread
From: Buchs, Kevin J. @ 2014-07-23 21:37 UTC (permalink / raw)
To: help-gnu-emacs
I want to evaluate (kmacro-name-last-macro variable), where I want the
value of "variable" passed as the symbol name. Despite years of trying,
I don't think I ever really conceptually "got" the distinction between
symbols and variables and that seems to be critical here. I'm working
with the code below, but it is not suceeding in naming the macros (no
error messages, however). Of course (kmacro-name-last-macro 'my-macro)
works just fine.
--
Kevin Buchs Research Computer Services Phone: 507-538-5459
Mayo Clinic 200 1st. St SW Rochester, MN 55905
http://mayoclinic.org http://facebook.com/MayoClinic http://youtube.com/MayoClinic http://twitter.com/MayoClinic
(defun name-my-macro-sequentially ()
"Names the last recorded macro as my-macro#, where # is a number sequentially incremented"
(interactive)
(unless (boundp 'my-macro-counter) (setq my-macro-counter 0))
(setq my-macro-counter (1+ my-macro-counter))
(let ((macro-name (format "my-macro-%d" my-macro-counter)))
(kmacro-name-last-macro (make-symbol macro-name))
(message "named keyboard macro %s" macro-name)))
^ permalink raw reply [flat|nested] 838+ messages in thread* RE: when you gotta have a variable value for a symbol name 2014-07-23 21:37 when you gotta have a variable value for a symbol name Buchs, Kevin J. @ 2014-07-23 22:02 ` Drew Adams [not found] ` <(message> 2014-07-24 21:57 ` Robert Thorpe [not found] ` <mailman.5936.1406152985.1147.help-gnu-emacs@gnu.org> 1 sibling, 2 replies; 838+ messages in thread From: Drew Adams @ 2014-07-23 22:02 UTC (permalink / raw) To: Buchs, Kevin J., help-gnu-emacs > I want to evaluate (kmacro-name-last-macro variable), where I want the > value of "variable" passed as the symbol name. Despite years of trying, > I don't think I ever really conceptually "got" the distinction between > symbols and variables and that seems to be critical here. I'm working > with the code below, but it is not suceeding in naming the macros (no > error messages, however). Of course (kmacro-name-last-macro 'my-macro) > works just fine. > > (defun name-my-macro-sequentially () > "Names the last recorded macro as my-macro#, where # is a number > sequentially incremented" > (interactive) > (unless (boundp 'my-macro-counter) (setq my-macro-counter 0)) > (setq my-macro-counter (1+ my-macro-counter)) > (let ((macro-name (format "my-macro-%d" my-macro-counter))) > (kmacro-name-last-macro (make-symbol macro-name)) ^^^^^^^^^^^ > (message "named keyboard macro %s" macro-name))) Change `make-symbol' to `intern' and you're good to go. `make-symbol' returns an uninterned symbol. ^ permalink raw reply [flat|nested] 838+ messages in thread
[parent not found: <(message>]
[parent not found: <from>]
[parent not found: <Raffaele>]
[parent not found: <Robert>]
[parent not found: <Richard>]
[parent not found: <Juri>]
[parent not found: <Emanuel>]
[parent not found: <Eli>]
[parent not found: <Marcin>]
[parent not found: <Drew>]
[parent not found: <Adams>]
[parent not found: <on>]
[parent not found: <Barry>]
* Re: when you gotta have a variable value for a symbol name 2014-07-23 22:02 ` Drew Adams [not found] ` <(message> @ 2014-07-24 21:57 ` Robert Thorpe 2014-07-25 0:06 ` Drew Adams 1 sibling, 1 reply; 838+ messages in thread From: Robert Thorpe @ 2014-07-24 21:57 UTC (permalink / raw) To: Drew Adams; +Cc: buchs.kevin, help-gnu-emacs Drew Adams <drew.adams@oracle.com> writes: >> I want to evaluate (kmacro-name-last-macro variable), where I want the >> value of "variable" passed as the symbol name. Despite years of trying, >> I don't think I ever really conceptually "got" the distinction between >> symbols and variables and that seems to be critical here. I'm working >> with the code below, but it is not suceeding in naming the macros (no >> error messages, however). Of course (kmacro-name-last-macro 'my-macro) >> works just fine. Lisp is like the insides of a compiler. There's a big hash-map, the obarray, which is the symbol-table. It stores strings along with some information about them. These strings are "symbols". There are three pieces of information: the symbol's value as a variable, the symbols value as a function and a property list. An interned symbol is one that is an entry in the obarray (there can be multiple obarrays though that feature isn't used much). An uninterned symbol is one that sits by itself, it has the same parts as usual: string, function entry, variable entry and plist, but it's not attached to an obarray. If we have a function call: (foo bar 'baz) then lisp treats each of these symbols differently. It finds the function slot for foo because that's the first symbol, it finds the variable slot for bar because it's not first. Finally, 'baz returns the symbol itself. To be more careful: (quote baz) returns a list containing the symbol, which evaluates to the symbol. (info "(elisp) Symbols") BR, Robert Thorpe ^ permalink raw reply [flat|nested] 838+ messages in thread
* RE: when you gotta have a variable value for a symbol name 2014-07-24 21:57 ` Robert Thorpe @ 2014-07-25 0:06 ` Drew Adams 0 siblings, 0 replies; 838+ messages in thread From: Drew Adams @ 2014-07-25 0:06 UTC (permalink / raw) To: Robert Thorpe; +Cc: buchs.kevin, help-gnu-emacs > Drew Adams <drew.adams@oracle.com> writes: ... Quoted text, none of which I wrote... ^ permalink raw reply [flat|nested] 838+ messages in thread
[parent not found: <mailman.5936.1406152985.1147.help-gnu-emacs@gnu.org>]
* Re: when you gotta have a variable value for a symbol name [not found] ` <mailman.5936.1406152985.1147.help-gnu-emacs@gnu.org> @ 2014-07-23 22:12 ` Pascal J. Bourguignon 0 siblings, 0 replies; 838+ messages in thread From: Pascal J. Bourguignon @ 2014-07-23 22:12 UTC (permalink / raw) To: help-gnu-emacs Drew Adams <drew.adams@oracle.com> writes: >> I want to evaluate (kmacro-name-last-macro variable), where I want the >> value of "variable" passed as the symbol name. Despite years of trying, >> I don't think I ever really conceptually "got" the distinction between >> symbols and variables and that seems to be critical here. I'm working >> with the code below, but it is not suceeding in naming the macros (no >> error messages, however). Of course (kmacro-name-last-macro 'my-macro) >> works just fine. >> >> (defun name-my-macro-sequentially () >> "Names the last recorded macro as my-macro#, where # is a number >> sequentially incremented" >> (interactive) >> (unless (boundp 'my-macro-counter) (setq my-macro-counter 0)) >> (setq my-macro-counter (1+ my-macro-counter)) >> (let ((macro-name (format "my-macro-%d" my-macro-counter))) >> (kmacro-name-last-macro (make-symbol macro-name)) > ^^^^^^^^^^^ >> (message "named keyboard macro %s" macro-name))) > > Change `make-symbol' to `intern' and you're good to go. `make-symbol' > returns an uninterned symbol. And use: (defvar my-macro-counter 0) (defun … ) instead of: (defun … … (unless (boundp 'my-macro-counter) (setq my-macro-counter 0)) …) -- __Pascal Bourguignon__ http://www.informatimago.com/ “The factory of the future will have only two employees, a man and a dog. The man will be there to feed the dog. The dog will be there to keep the man from touching the equipment.” -- Carl Bass CEO Autodesk ^ permalink raw reply [flat|nested] 838+ messages in thread
[parent not found: <Your>]
[parent not found: <message>]
end of thread, other threads:[~2022-01-22 14:43 UTC | newest]
Thread overview: 838+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-09-18 21:57 [PATCH] Fixing package-initialize, adding early init file Radon Rosborough
2017-09-19 12:30 ` Stefan Monnier
2017-09-25 16:27 ` Radon Rosborough
2017-09-25 16:54 ` John Wiegley
2017-09-25 19:38 ` Radon Rosborough
2017-09-25 21:23 ` Mark Oteiza
2017-09-25 22:16 ` Radon Rosborough
2017-09-25 23:15 ` Mark Oteiza
2017-09-26 3:00 ` Radon Rosborough
2017-09-29 10:22 ` Eli Zaretskii
2017-09-25 16:58 ` Stefan Monnier
2017-09-25 19:40 ` Radon Rosborough
2017-10-09 23:17 ` Radon Rosborough
2017-10-10 16:52 ` Robert Weiner
2017-10-10 16:59 ` Eli Zaretskii
2017-10-14 21:30 ` Mark Oteiza
2017-10-14 21:52 ` Stefan Monnier
2017-10-15 1:18 ` Radon Rosborough
2017-10-15 14:16 ` Eli Zaretskii
2017-10-15 16:26 ` Stefan Monnier
2017-10-25 22:13 ` Radon Rosborough
2017-10-26 0:11 ` Stefan Monnier
2017-12-18 0:45 ` Radon Rosborough
2018-01-25 4:35 ` Radon Rosborough
2018-01-25 15:43 ` Clément Pit-Claudel
2018-01-25 16:03 ` Stefan Monnier
2018-01-25 16:22 ` Clément Pit-Claudel
2018-01-25 17:12 ` Stefan Monnier
2018-01-26 9:31 ` Eli Zaretskii
2018-01-26 14:34 ` Loading a package applies automatically to future sessions? Richard Stallman
2018-01-26 17:03 ` Stefan Monnier
2018-01-28 12:07 ` Richard Stallman
2018-01-28 13:24 ` Stefan Monnier
2018-01-29 1:50 ` Richard Stallman
2018-01-29 5:56 ` Radon Rosborough
2018-02-02 2:14 ` Richard Stallman
2018-02-02 3:05 ` Clément Pit-Claudel
2018-02-04 3:08 ` Richard Stallman
2018-02-04 15:21 ` Clément Pit-Claudel
2018-02-04 21:27 ` Tim Cross
2018-02-05 10:07 ` George Plymale II
2018-02-05 21:27 ` Tim Cross
2018-02-05 1:08 ` Richard Stallman
2018-02-05 4:15 ` Clément Pit-Claudel
2018-02-05 20:36 ` Richard Stallman
2018-01-26 19:24 ` Radon Rosborough
2018-01-26 20:02 ` Eli Zaretskii
2018-01-28 18:20 ` Radon Rosborough
2018-01-29 1:52 ` Richard Stallman
2018-02-10 12:00 ` Eli Zaretskii
2018-02-11 1:23 ` George Plymale II
2018-02-13 21:14 ` Stefan's patch to improve package loading (was Loading a package applies automatically to future sessions?) George Plymale II
2018-02-14 2:56 ` John Wiegley
2018-02-14 23:32 ` George Plymale II
2018-03-09 2:54 ` Stefan's patch to improve package loading George Plymale II
2018-02-15 4:40 ` Loading a package applies automatically to future sessions? Radon Rosborough
2018-01-27 20:44 ` Richard Stallman
2018-01-28 6:30 ` Radon Rosborough
2018-01-28 9:33 ` Charles A. Roelli
2018-01-28 13:21 ` Stefan Monnier
2018-01-28 17:32 ` Radon Rosborough
2018-01-28 22:11 ` Stefan Monnier
2018-01-29 1:08 ` T.V Raman
2018-01-29 5:53 ` Radon Rosborough
2018-01-29 7:21 ` John Wiegley
2018-01-29 18:54 ` Stefan Monnier
2018-01-29 19:19 ` John Wiegley
2018-01-29 19:55 ` Stefan Monnier
2018-01-29 6:55 ` John Wiegley
2018-01-29 19:08 ` Stefan Monnier
2018-01-29 19:55 ` John Wiegley
2018-01-29 21:50 ` Stefan Monnier
2018-01-29 23:13 ` Clément Pit-Claudel
2018-01-30 1:37 ` T.V Raman
2018-01-29 20:18 ` Clément Pit-Claudel
2018-01-30 15:11 ` Stefan Monnier
2018-01-30 22:33 ` George Plymale II
2018-01-30 22:56 ` George Plymale II
2018-01-31 3:47 ` Stefan Monnier
2018-01-31 5:17 ` George Plymale II
2018-01-31 20:49 ` George Plymale II
2018-01-31 21:35 ` Stefan Monnier
2018-01-31 21:58 ` George Plymale II
2018-01-31 22:06 ` George Plymale II
2018-02-01 14:48 ` Stefan Monnier
2018-02-01 17:47 ` George Plymale II
2018-02-01 19:11 ` Stefan Monnier
2018-02-01 19:19 ` Stephen Berman
2018-02-01 19:28 ` Stephen Berman
2018-02-01 21:44 ` George Plymale II
2018-02-01 22:16 ` Stephen Berman
2018-02-01 23:02 ` George Plymale II
2018-02-02 8:43 ` Eli Zaretskii
2018-02-02 17:19 ` George Plymale II
2018-02-02 17:57 ` Stefan Monnier
2018-02-02 18:06 ` Eli Zaretskii
2018-02-02 12:19 ` Phillip Lord
2018-02-02 19:20 ` Radon Rosborough
2018-02-02 22:53 ` Richard Stallman
2018-02-05 9:17 ` A response to RMS (was Loading a package applies automatically to future sessions?) George Plymale II
2018-02-05 12:55 ` Clément Pit-Claudel
2018-02-06 23:34 ` George Plymale II
2018-02-05 20:36 ` Richard Stallman
2018-02-06 23:42 ` George Plymale II
2018-02-07 20:45 ` Richard Stallman
2018-02-05 20:36 ` Richard Stallman
2018-02-05 20:36 ` Richard Stallman
2018-02-06 15:06 ` Loading a package applies automatically to future sessions? Sam Steingold
2018-02-02 22:53 ` Richard Stallman
2018-02-02 23:12 ` Stephen Berman
2018-02-03 19:13 ` Richard Stallman
2018-02-03 20:40 ` Stephen Berman
2018-02-04 3:07 ` Richard Stallman
2018-02-05 9:26 ` George Plymale II
2018-02-05 9:22 ` Finding an online resource for the agreement (was Loading a package applies automatically to future sessions?) George Plymale II
2018-02-02 2:14 ` Loading a package applies automatically to future sessions? Richard Stallman
2018-02-02 7:25 ` George Plymale II
2018-02-02 9:39 ` Eli Zaretskii
2018-02-02 17:07 ` George Plymale II
2018-02-02 17:59 ` Stefan Monnier
2018-02-02 22:56 ` Richard Stallman
2018-02-14 22:28 ` Richard Stallman
2018-02-14 23:18 ` George Plymale II
2018-02-02 8:39 ` Eli Zaretskii
2018-02-02 17:21 ` George Plymale II
2018-02-02 18:08 ` Eli Zaretskii
2018-02-02 2:12 ` Richard Stallman
2018-02-02 6:15 ` George Plymale II
2018-02-04 3:07 ` Richard Stallman
2018-02-05 9:35 ` Another response to RMS (was Loading a package applies automatically to future sessions?) George Plymale II
2018-02-05 20:37 ` Richard Stallman
2018-02-06 23:47 ` George Plymale II
2018-02-02 2:13 ` Loading a package applies automatically to future sessions? Richard Stallman
2018-02-01 19:24 ` Richard Stallman
2018-02-01 21:36 ` George Plymale II
2018-02-02 2:08 ` Tim Landscheidt
2018-02-02 22:53 ` Richard Stallman
2018-02-02 2:17 ` Richard Stallman
2018-02-02 6:26 ` George Plymale II
2018-02-02 9:26 ` Eli Zaretskii
2018-02-02 17:14 ` George Plymale II
2018-02-02 22:56 ` Richard Stallman
2018-02-05 9:19 ` George Plymale II
2018-02-05 20:36 ` Richard Stallman
2018-02-06 23:44 ` George Plymale II
2018-02-02 2:17 ` Richard Stallman
2018-02-02 7:33 ` George Plymale II
2018-02-02 18:38 ` Drew Adams
2018-02-02 19:05 ` Generations (was: Loading a package applies automatically to future sessions?) Stefan Monnier
2018-02-02 21:40 ` Drew Adams
2018-02-02 22:57 ` Richard Stallman
2018-02-02 23:03 ` Drew Adams
2018-02-02 20:36 ` Loading a package applies automatically to future sessions? Phillip Lord
2018-02-02 2:17 ` Richard Stallman
2018-02-02 7:24 ` George Plymale II
2018-02-02 22:28 ` Paul Eggert
2018-02-05 8:21 ` George Plymale II
2018-02-05 20:36 ` Richard Stallman
2018-02-04 3:09 ` Richard Stallman
2018-02-02 13:37 ` Clément Pit-Claudel
2018-02-02 17:20 ` Drew Adams
2018-02-05 4:51 ` Herring, Davis
2018-02-01 19:47 ` Stefan Monnier
2018-02-01 22:10 ` George Plymale II
2018-02-01 22:44 ` George Plymale II
2018-02-02 1:54 ` Stefan Monnier
2018-02-02 20:32 ` George Plymale II
2018-01-31 3:51 ` T.V Raman
2018-01-31 5:18 ` George Plymale II
2018-01-31 6:56 ` Tim Cross
2018-01-31 7:07 ` George Plymale II
2018-01-31 8:05 ` John Wiegley
2018-02-01 7:26 ` Tim Cross
2018-02-01 15:00 ` Stefan Monnier
2018-02-01 16:23 ` T.V Raman
2018-02-03 0:39 ` Tim Cross
2018-02-05 9:24 ` George Plymale II
2018-01-29 1:50 ` Richard Stallman
2018-01-25 17:07 ` [PATCH] Fixing package-initialize, adding early init file Stefan Monnier
2018-01-28 19:42 ` Radon Rosborough
2018-01-30 15:02 ` Stefan Monnier
2018-01-30 15:44 ` Eli Zaretskii
2018-02-01 3:12 ` Mark Oteiza
2018-02-01 4:22 ` Radon Rosborough
2018-02-01 13:36 ` Stefan Monnier
2018-02-18 5:40 ` Stefan Monnier
2018-02-08 5:54 ` Radon Rosborough
2018-02-08 15:27 ` Eli Zaretskii
2018-01-30 19:30 ` Radon Rosborough
2018-02-10 11:56 ` Eli Zaretskii
2018-02-10 23:37 ` Stefan Monnier
2018-02-11 3:26 ` Radon Rosborough
2018-02-11 14:45 ` Stefan Monnier
2018-02-11 13:31 ` Basil L. Contovounesios
2018-02-15 4:38 ` Radon Rosborough
2018-02-15 15:54 ` Drew Adams
2018-02-15 16:25 ` Stefan Monnier
2018-02-15 19:32 ` John Wiegley
2018-02-15 21:13 ` Stefan Monnier
2018-02-16 7:00 ` John Wiegley
2018-02-17 11:38 ` Eli Zaretskii
2018-02-17 14:14 ` Clément Pit-Claudel
2018-02-17 18:17 ` Radon Rosborough
2018-02-18 18:26 ` Basil L. Contovounesios
2018-02-18 18:55 ` Radon Rosborough
2018-02-19 3:10 ` Stefan Monnier
2018-02-20 19:13 ` Basil L. Contovounesios
2018-02-20 19:26 ` Basil L. Contovounesios
2018-02-20 20:35 ` Radon Rosborough
2018-02-21 3:48 ` T.V Raman
2018-02-21 8:16 ` Stefan Monnier
2018-02-21 20:48 ` Radon Rosborough
2018-02-21 21:26 ` Stefan Monnier
2018-02-21 3:43 ` T.V Raman
2017-10-10 19:03 ` Radon Rosborough
2017-10-10 19:31 ` Robert Weiner
2017-10-10 19:41 ` Radon Rosborough
2017-10-13 21:29 ` John Wiegley
2017-10-14 0:49 ` Radon Rosborough
2017-10-14 5:15 ` João Távora
2017-10-14 6:19 ` Radon Rosborough
2017-10-14 9:04 ` João Távora
2017-10-14 13:47 ` Stefan Monnier
-- strict thread matches above, loose matches on Subject: below --
2020-11-01 16:08 bounds-of-thing-at-point for paragraphs Christopher Dimech
2020-11-01 18:22 ` Jean Louis
2020-11-01 18:34 ` Christopher Dimech
2020-11-01 18:45 ` Drew Adams
2020-11-01 18:52 ` Jean Louis
2020-11-01 19:00 ` Drew Adams
2020-11-01 20:07 ` Christopher Dimech
2020-11-01 22:06 ` Drew Adams
2020-11-01 22:36 ` Christopher Dimech
2020-11-01 22:47 ` Jean Louis
2020-11-01 22:52 ` Drew Adams
2020-11-01 23:14 ` Christopher Dimech
2020-11-02 1:07 ` Drew Adams
2020-11-02 4:09 ` Robert Thorpe
2020-11-02 15:41 ` Drew Adams
2020-11-03 6:00 ` Corwin Brust
2020-11-03 6:40 ` Stefan Kangas
2020-11-03 7:41 ` Corwin Brust
2020-11-03 16:07 ` Drew Adams
2020-11-06 23:45 ` Corwin Brust
2020-11-07 1:26 ` Stefan Kangas
2020-11-02 6:07 ` finder-commentary Jean Louis
2020-11-02 15:48 ` finder-commentary Drew Adams
2020-11-02 16:02 ` finder-commentary Drew Adams
2020-11-02 16:58 ` finder-commentary Jean Louis
2020-11-02 17:27 ` finder-commentary Drew Adams
2020-11-01 22:49 ` RE: RE: bounds-of-thing-at-point for paragraphs Jean Louis
2020-11-01 22:51 ` Drew Adams
2020-11-01 23:10 ` Christopher Dimech
2020-11-02 1:05 ` Drew Adams
2020-11-01 20:36 ` Jean Louis
2020-11-01 21:32 ` Michael Heerdegen
2020-11-01 21:43 ` Jean Louis
2020-11-01 21:43 ` Jean Louis
2020-11-01 19:27 ` Eli Zaretskii
2020-11-01 19:51 ` Christopher Dimech
2020-11-01 20:00 ` Eli Zaretskii
2020-11-01 20:09 ` Christopher Dimech
2020-11-01 20:13 ` Eli Zaretskii
2020-11-01 20:27 ` Emanuel Berg via Users list for the GNU Emacs text editor
2020-11-01 20:31 ` Christopher Dimech
2020-11-01 22:10 ` Emanuel Berg via Users list for the GNU Emacs text editor
2020-11-01 21:46 ` Drew Adams
2020-11-01 20:23 ` Michael Heerdegen
2020-11-01 20:29 ` Christopher Dimech
2020-11-01 22:10 ` Drew Adams
2020-11-01 21:01 ` Stefan Monnier
2020-11-01 18:45 ` Jean Louis
2020-11-01 18:51 ` Drew Adams
2020-10-08 15:30 Proposal for an Emacs User Survey Adrien Brochard
2020-10-08 17:27 ` Philip K.
2020-10-08 17:45 ` Adrien Brochard
2020-10-09 11:30 ` Philip K.
2020-10-09 14:37 ` tomas
2020-10-09 17:23 ` Adrien Brochard
2020-10-09 18:17 ` Philip K.
2020-10-09 19:52 ` Adrien Brochard
2020-10-10 3:56 ` Richard Stallman
2020-10-10 9:36 ` Philip K.
2020-10-10 16:33 ` Drew Adams
2020-10-10 18:02 ` Dmitry Gutov
2020-10-11 10:46 ` Jean Louis
2020-10-11 18:42 ` Philip K.
2020-10-11 19:46 ` Jean Louis
2020-10-11 1:00 ` Drew Adams
2020-10-10 10:35 ` Philip K.
2020-10-11 5:24 ` Richard Stallman
2020-10-11 17:59 ` Philip K.
2020-10-12 2:03 ` Richard Stallman
2020-10-11 7:31 ` Tomas Hlavaty
2020-10-11 12:04 ` Jean Louis
2020-10-11 17:47 ` Philip K.
2020-10-09 17:59 ` Jean Louis
2020-10-09 0:41 ` Karl Fogel
2020-10-09 1:26 ` Adrien Brochard
2020-10-10 3:52 ` Richard Stallman
2020-10-10 21:44 ` Dmitry Gutov
2020-10-12 2:04 ` Richard Stallman
2020-10-09 3:35 ` Richard Stallman
2020-10-09 18:01 ` Jean Louis
2020-10-09 23:12 ` Adrien Brochard
2020-10-09 23:31 ` Drew Adams
2020-10-09 23:36 ` Adrien Brochard
2020-10-10 2:21 ` Drew Adams
2020-10-10 2:40 ` Adrien Brochard
2020-10-10 3:53 ` Drew Adams
2020-10-10 8:09 ` Teemu Likonen
2020-10-10 10:45 ` Rasmus
2020-10-11 10:32 ` Jean Louis
2020-10-11 15:15 ` Drew Adams
2020-10-11 18:25 ` Jean Louis
2020-10-11 19:47 ` Drew Adams
2020-10-11 20:36 ` Jean Louis
2020-10-13 3:48 ` How to request changes in Emacs Richard Stallman
2020-10-13 4:59 ` Jean Louis
2020-10-16 4:00 ` Richard Stallman
2020-10-16 4:47 ` Drew Adams
2020-10-13 15:56 ` Drew Adams
2020-10-14 4:42 ` Richard Stallman
2020-10-14 5:12 ` Drew Adams
2020-10-11 20:19 ` Proposal for an Emacs User Survey Drew Adams
2020-10-11 20:42 ` Jean Louis
2020-10-11 18:33 ` Philip K.
2020-10-11 18:45 ` Jean Louis
2020-10-13 3:48 ` Richard Stallman
2020-10-11 19:47 ` Drew Adams
2020-10-11 20:33 ` Jean Louis
2020-10-11 23:24 ` Drew Adams
2020-10-12 4:10 ` Jean Louis
2020-10-12 17:35 ` Drew Adams
2020-10-12 18:33 ` Jean Louis
2020-10-12 18:41 ` Drew Adams
2020-10-11 20:54 ` Jean Louis
2020-10-12 14:32 ` Adrien Brochard
2020-10-10 10:54 ` Thibaut Verron
2020-10-10 13:50 ` Philip K.
2020-10-12 14:36 ` Adrien Brochard
2020-10-11 11:58 ` Jean Louis
2020-10-12 14:36 ` Adrien Brochard
2020-10-10 13:17 ` Rasmus
2020-10-12 14:41 ` Adrien Brochard
2020-10-11 5:23 ` Richard Stallman
2020-10-11 7:35 ` Vasilij Schneidermann
2020-10-11 12:08 ` Jean Louis
2020-10-11 12:50 ` Vasilij Schneidermann
2020-10-11 17:15 ` Jean Louis
2020-10-11 17:36 ` Thibaut Verron
2020-10-11 18:13 ` Brett Gilio
2020-10-11 18:27 ` Thibaut Verron
2020-10-11 18:44 ` Jean Louis
2020-10-11 18:58 ` Thibaut Verron
2020-10-11 20:12 ` Jean Louis
2020-10-11 18:34 ` Jean Louis
2020-10-11 19:15 ` Thibaut Verron
2020-10-11 19:22 ` Qiantan Hong
2020-10-13 3:47 ` Richard Stallman
2020-10-11 20:26 ` Jean Louis
2020-10-12 2:04 ` Richard Stallman
2020-10-12 3:32 ` Thibaut Verron
2020-10-12 5:04 ` Jean Louis
2020-10-12 5:33 ` Thibaut Verron
2020-10-12 6:29 ` Jean Louis
2020-10-12 6:58 ` Thibaut Verron
2020-10-12 8:16 ` Jean Louis
2020-10-12 8:37 ` Thibaut Verron
2020-10-12 14:09 ` Jean Louis
2020-10-12 7:54 ` Ihor Radchenko
2020-10-12 8:34 ` Jean Louis
2020-10-12 8:54 ` Ihor Radchenko
2020-10-12 16:36 ` Jean Louis
2020-10-13 3:53 ` Richard Stallman
2020-10-13 5:25 ` Jean Louis
2020-10-15 3:59 ` Richard Stallman
2020-10-15 5:19 ` Jean Louis
2020-10-13 3:53 ` Richard Stallman
2020-10-13 5:27 ` Jean Louis
2020-10-16 3:59 ` Richard Stallman
2020-10-16 6:02 ` Marcel Ventosa
2020-10-16 6:52 ` Thibaut Verron
2020-10-16 7:24 ` Marcel Ventosa
2020-10-16 7:53 ` Thibaut Verron
2020-10-16 8:25 ` Marcel Ventosa
2020-10-16 12:17 ` Dmitry Gutov
2020-10-16 13:45 ` Marcel Ventosa
2020-10-16 14:04 ` Dmitry Gutov
2020-10-16 14:33 ` Marcel Ventosa
2020-10-16 14:58 ` Thibaut Verron
2020-10-16 15:51 ` Alfred M. Szmidt
2020-10-16 16:10 ` Thibaut Verron
2020-10-16 16:16 ` Alfred M. Szmidt
2020-10-16 16:32 ` Thibaut Verron
2020-10-16 16:50 ` Alfred M. Szmidt
2020-10-16 17:16 ` Thibaut Verron
2020-10-16 17:32 ` Alfred M. Szmidt
2020-10-16 17:55 ` Thibaut Verron
2020-10-16 18:16 ` Alfred M. Szmidt
2020-10-17 4:20 ` Richard Stallman
2020-10-17 4:50 ` Thibaut Verron
2020-10-17 5:44 ` Jean Louis
2020-10-17 6:42 ` Thibaut Verron
2020-10-17 7:52 ` Jean Louis
2020-10-18 4:16 ` Richard Stallman
2020-10-18 5:49 ` Jean Louis
2020-10-18 4:16 ` Richard Stallman
2020-10-18 5:52 ` Jean Louis
2020-10-18 4:16 ` Richard Stallman
2020-10-18 8:36 ` Thibaut Verron
2020-10-20 5:10 ` Richard Stallman
2020-10-17 9:42 ` Yuri Khan
2020-10-16 15:36 ` Ergus
2020-10-16 19:08 ` Dmitry Gutov
2020-10-16 19:52 ` Jean Louis
2020-10-16 20:16 ` Dmitry Gutov
2020-10-16 20:17 ` Alfred M. Szmidt
2020-10-17 11:40 ` Marcel Ventosa
2020-10-17 19:51 ` Dmitry Gutov
2020-10-17 21:38 ` Alfred M. Szmidt
2020-10-18 2:58 ` Marcel Ventosa
2020-10-16 19:22 ` Jean Louis
2020-10-16 19:17 ` Jean Louis
2020-10-16 19:36 ` Dmitry Gutov
2020-10-16 19:43 ` Dmitry Gutov
2020-10-16 20:03 ` Jean Louis
2020-10-16 20:29 ` Thibaut Verron
2020-10-16 20:40 ` Jean Louis
2020-10-17 4:19 ` Richard Stallman
2020-10-17 5:02 ` Thibaut Verron
2020-10-17 13:13 ` Stefan Monnier
2020-10-17 5:07 ` Jean Louis
2020-10-17 12:34 ` Andy Moreton
2020-10-17 15:56 ` Alfred M. Szmidt
2020-10-17 16:13 ` Eli Zaretskii
2020-10-17 21:38 ` Alfred M. Szmidt
2020-10-18 2:40 ` Eli Zaretskii
2020-10-18 4:13 ` Richard Stallman
2020-10-18 15:20 ` Alfred M. Szmidt
2020-10-16 21:10 ` Dmitry Gutov
2020-10-16 22:02 ` Jean Louis
2020-10-16 19:08 ` Jean Louis
2020-10-16 19:47 ` Drew Adams
2020-10-16 20:15 ` Jean Louis
2020-10-16 20:59 ` Drew Adams
2020-10-16 21:50 ` Jean Louis
2020-10-17 4:19 ` Richard Stallman
2020-10-17 4:19 ` Richard Stallman
2020-10-16 13:57 ` Ergus
2020-10-16 15:31 ` Eli Zaretskii
2020-10-16 19:11 ` Jean Louis
2020-10-16 16:09 ` Alfred M. Szmidt
2020-10-16 17:29 ` Jean Louis
2020-10-16 19:11 ` Thibaut Verron
2020-10-16 19:54 ` Jean Louis
2020-10-16 20:20 ` Thibaut Verron
2020-10-17 4:22 ` Richard Stallman
2020-10-17 4:31 ` Qiantan Hong
2020-10-19 10:12 ` Robert Pluim
2020-10-19 16:15 ` Qiantan Hong
2020-10-20 13:45 ` Dmitry Gutov
2020-10-16 18:57 ` Jean Louis
2020-10-16 17:08 ` Jean Louis
2020-10-16 17:04 ` Jean Louis
2020-10-16 17:39 ` Vasilij Schneidermann
2020-10-18 4:09 ` Richard Stallman
2020-10-16 16:33 ` MELPA issues - " Jean Louis
2020-10-16 18:09 ` Dmitry Gutov
2020-10-16 22:00 ` Qiantan Hong
2020-10-16 22:08 ` Dmitry Gutov
2020-10-17 4:18 ` Richard Stallman
2020-10-17 4:59 ` chad
2020-10-17 5:05 ` Qiantan Hong
2020-10-17 5:06 ` Thibaut Verron
2020-10-17 2:59 ` Marcel Ventosa
2020-10-18 4:12 ` Richard Stallman
2020-10-18 5:16 ` Jean Louis
2020-10-18 4:10 ` Richard Stallman
2020-10-18 7:51 ` Marcel Ventosa
2020-10-18 9:29 ` Dmitry Gutov
2020-10-18 9:36 ` Jean Louis
2020-10-18 8:57 ` Thibaut Verron
2020-10-19 3:44 ` Richard Stallman
2020-10-18 15:57 ` Philip K.
2020-10-19 3:48 ` Richard Stallman
2020-10-19 11:36 ` Dmitry Gutov
2020-10-19 12:43 ` Proposal to include obligatory PGP verification of packages from any repository Jean Louis
2020-10-19 15:55 ` Stefan Kangas
2020-10-19 16:38 ` Jean Louis
2020-10-19 17:30 ` Stefan Monnier
2020-10-19 17:47 ` Jean Louis
2020-10-19 18:02 ` Stefan Monnier
2020-10-19 19:04 ` Jean Louis
2020-10-19 20:17 ` Stefan Monnier
2020-10-19 21:02 ` Jean Louis
[not found] ` <jwvft69evmy.fsf-monnier+emacs@gnu.org>
2020-10-20 7:40 ` Jean Louis
2020-10-22 21:25 ` Stefan Monnier
2020-10-23 9:17 ` Jean Louis
2020-10-23 14:52 ` Stefan Monnier
2020-10-23 16:59 ` Jean Louis
2020-10-23 18:25 ` Stefan Monnier
2020-10-24 6:26 ` Jean Louis
2020-10-24 15:29 ` Stefan Monnier
2020-10-19 18:53 ` Stefan Kangas
2020-10-19 18:57 ` Vasilij Schneidermann
2020-10-19 19:20 ` Stefan Monnier
2020-10-19 18:28 ` Vasilij Schneidermann
2020-10-19 19:00 ` ELPA security (was: Proposal to include obligatory PGP verification of packages from any repository) Stefan Monnier
2020-10-19 19:50 ` Proposal to include obligatory PGP verification of packages from any repository Jean Louis
2020-10-20 5:17 ` Richard Stallman
2020-10-20 5:52 ` Stefan Monnier
2020-10-21 4:46 ` Richard Stallman
2020-10-20 16:17 ` Vasilij Schneidermann
2020-10-19 15:46 ` Proposal for an Emacs User Survey Drew Adams
2020-10-19 16:42 ` Jean Louis
2020-10-20 5:19 ` Richard Stallman
2020-10-19 16:42 ` Thibaut Verron
2020-10-19 16:53 ` Drew Adams
2020-10-20 5:14 ` Richard Stallman
2020-10-20 10:47 ` Dmitry Gutov
2020-10-16 7:05 ` Thibaut Verron
2020-10-16 13:23 ` Philip K.
2020-10-16 18:46 ` Jean Louis
2020-10-17 4:22 ` Richard Stallman
2020-10-15 3:52 ` Richard Stallman
2020-10-15 5:57 ` Thibaut Verron
2020-10-12 5:36 ` Jean Louis
2020-10-12 5:52 ` Thibaut Verron
2020-10-12 2:04 ` Richard Stallman
2020-10-12 2:04 ` Richard Stallman
2020-10-12 15:16 ` Adrien Brochard
2020-10-12 16:55 ` Jean Louis
2020-10-12 17:15 ` Drew Adams
2020-10-13 3:49 ` Richard Stallman
2020-10-11 20:54 ` Bonface M. K.
2020-10-16 13:30 ` Philip K.
2020-10-19 16:20 ` Philip K.
2020-10-19 19:44 ` Dmitry Gutov
2020-10-20 5:19 ` Richard Stallman
2020-10-20 8:22 ` Thibaut Verron
2020-10-20 9:48 ` Jean Louis
2020-10-20 11:03 ` Thibaut Verron
2020-10-20 11:38 ` Jean Louis
2020-10-26 17:43 ` Teemu Likonen
2020-10-26 19:36 ` Jean Louis
2020-10-26 19:58 ` Jean Louis
2020-10-27 3:44 ` Richard Stallman
2020-10-26 18:13 ` Ivan Yonchovski
2020-10-26 20:21 ` Jean Louis
[not found] <<fdimdgyaxf.fsf@norden.tntech.edu>
[not found] ` <<83r1s4ftc7.fsf@gnu.org>
2020-08-18 16:13 ` Delete variables obsolete since Emacs 23 Drew Adams
2020-08-18 19:27 ` Stefan Monnier
2020-08-18 20:21 ` Drew Adams
2020-08-18 21:00 ` Gregory Heytings via Emacs development discussions.
2020-08-18 21:55 ` Stefan Monnier
2020-08-18 21:30 ` Jeff Norden
2020-07-30 4:01 bug#42611: 26.3; edit-abbrevs lets me type and commit, but doesn't store anywhere and abbrevs don't work Brett Randall
[not found] ` <handler.42611.B.159608273314264.ack@debbugs.gnu.org>
[not found] ` <(Brett>
2020-10-17 8:41 ` Lars Ingebrigtsen
2020-10-27 10:36 ` brett.randall
[not found] ` <(brett>
[not found] ` <randall's>
[not found] ` <"Tue,>
2020-10-27 10:43 ` Lars Ingebrigtsen
2020-10-27 10:49 ` Brett Randall
2020-10-27 11:08 ` Lars Ingebrigtsen
[not found] ` <(Lars>
[not found] ` <Ingebrigtsen's>
[not found] ` <12:08:50>
2020-10-27 11:19 ` bug#42611: (no subject) Lars Ingebrigtsen
[not found] ` <877drbhq6c.fsf@gnus.org>
[not found] ` <handler.42611.C.160379757411378.notifdonectrl.0@debbugs.gnu.org>
2020-10-27 22:22 ` bug#42611: 26.3; edit-abbrevs lets me type and commit, but doesn't store anywhere and abbrevs don't work Brett Randall
2020-05-21 16:56 bug#41438: [PATCH] Allow windmove keys to be bound without prefix or modifiers Philip K.
2020-05-21 22:18 ` Juri Linkov
2020-05-22 18:26 ` Philip K.
2020-05-22 18:26 ` Philip K.
2020-05-22 19:15 ` Drew Adams
2020-05-23 22:12 ` Juri Linkov
2020-06-26 19:46 ` Philip K.
2020-06-27 23:53 ` Juri Linkov
2020-06-28 8:30 ` Philip K.
2020-06-28 23:37 ` Juri Linkov
2020-08-05 18:05 ` Lars Ingebrigtsen
2020-08-05 23:40 ` Juri Linkov
2020-08-06 9:28 ` Philip K.
2020-08-06 23:43 ` Juri Linkov
2020-08-07 10:53 ` Philip K.
2020-08-08 23:54 ` Juri Linkov
2021-05-12 20:38 ` Lars Ingebrigtsen
2021-05-12 21:27 ` Philip Kaludercic
2021-05-22 20:29 ` Philip Kaludercic
2021-05-22 21:09 ` Philip Kaludercic
2021-05-23 6:49 ` Eli Zaretskii
2021-05-23 12:36 ` Philip Kaludercic
2021-05-25 5:12 ` Lars Ingebrigtsen
2021-05-25 7:25 ` Philip Kaludercic
2021-05-25 9:53 ` Philip Kaludercic
2021-05-25 11:16 ` Arthur Miller
2021-05-25 11:42 ` Philip Kaludercic
2021-05-25 13:31 ` Arthur Miller
2021-05-25 14:39 ` Philip Kaludercic
2021-05-25 11:36 ` Arthur Miller
2021-05-25 11:46 ` Philip Kaludercic
2021-05-25 13:58 ` Arthur Miller
2021-05-25 19:13 ` Lars Ingebrigtsen
2021-05-25 19:16 ` Lars Ingebrigtsen
2021-05-25 19:25 ` Philip Kaludercic
2021-05-25 20:18 ` Juri Linkov
2021-05-25 21:45 ` Philip Kaludercic
2021-05-26 21:35 ` Juri Linkov
2021-05-27 11:09 ` Philip Kaludercic
2021-05-30 22:11 ` Juri Linkov
2021-05-31 8:50 ` Philip Kaludercic
2021-05-31 20:15 ` Juri Linkov
2021-05-31 21:27 ` Philip Kaludercic
2021-06-03 20:36 ` Juri Linkov
[not found] <20200515175844.18941.61355@vcs0.savannah.gnu.org>
[not found] ` <20200515175845.997EC20999@vcs0.savannah.gnu.org>
2020-05-15 18:38 ` Deleting old `:version` from defcustoms (was: master b76cdd0: Delete libraries obsolete since 23.1 and 23.2) Stefan Monnier
2020-05-15 20:58 ` Stefan Kangas
2020-08-07 15:42 ` [PATCH] Remove obsolete fast-lock and lazy-lock libraries (was: Re: Deleting old `:version` from defcustoms) Stefan Kangas
2020-08-08 2:19 ` [PATCH] Remove obsolete fast-lock and lazy-lock libraries Stefan Monnier
2020-05-16 13:18 ` Delete variables obsolete since Emacs 23 Stefan Kangas
2020-05-16 15:49 ` Paul Eggert
2020-05-17 2:52 ` Stefan Monnier
2020-05-17 11:39 ` Dmitry Gutov
2020-08-08 0:28 ` Stefan Kangas
2020-08-14 11:11 ` Stefan Kangas
2020-08-14 15:42 ` Stefan Kangas
2020-08-14 18:56 ` Drew Adams
2020-08-14 19:00 ` Lars Ingebrigtsen
2020-08-14 19:14 ` Drew Adams
2020-08-14 19:55 ` Ulrich Mueller
2020-08-14 23:37 ` Stefan Kangas
2020-08-15 1:28 ` Drew Adams
2020-08-15 12:51 ` Stefan Monnier
2020-08-15 19:54 ` Drew Adams
2020-08-16 4:13 ` Richard Stallman
2020-08-16 5:30 ` Drew Adams
2020-08-16 13:46 ` Stefan Monnier
2020-08-17 3:23 ` Richard Stallman
2020-08-17 14:20 ` Drew Adams
2020-08-17 14:45 ` Gregory Heytings via Emacs development discussions.
2020-08-18 1:55 ` Jeff Norden
2020-08-18 4:53 ` Eli Zaretskii
2020-08-19 8:31 ` Gregory Heytings via Emacs development discussions.
2020-08-19 13:26 ` Drew Adams
2020-08-19 13:39 ` Stefan Monnier
2020-08-19 13:54 ` Gregory Heytings via Emacs development discussions.
2020-08-19 15:15 ` Eli Zaretskii
2020-08-20 0:33 ` Jeff Norden
2020-08-19 14:36 ` Eli Zaretskii
2020-08-18 16:14 ` Drew Adams
2020-08-18 4:06 ` Richard Stallman
2020-08-18 16:13 ` Drew Adams
2020-08-18 11:17 ` Lars Ingebrigtsen
2020-08-24 2:28 ` Stefan Kangas
2020-08-25 3:46 ` Richard Stallman
2020-08-25 4:06 ` Drew Adams
2020-08-26 1:57 ` Richard Stallman
2020-08-26 8:59 ` Gregory Heytings via Emacs development discussions.
2020-08-26 13:22 ` Stefan Kangas
2020-08-27 2:51 ` Richard Stallman
2020-08-27 3:51 ` Stefan Kangas
2020-08-26 17:39 ` Drew Adams
2020-08-26 18:16 ` Stefan Monnier
2020-09-04 17:04 ` Stefan Kangas
2020-09-05 12:39 ` Lars Ingebrigtsen
2020-09-11 20:01 ` Stefan Kangas
2020-05-17 3:18 ` Deleting old `:version` from defcustoms (was: master b76cdd0: Delete libraries obsolete since 23.1 and 23.2) Stefan Kangas
2020-05-17 15:18 ` Eli Zaretskii
2020-05-17 16:59 ` Deleting old `:version` from defcustoms Stefan Monnier
2019-04-21 19:30 bug#35367: 26.2; `dired-copy-how-to-fn' and HOW-TO arg of `dired-create-files' Drew Adams
2019-07-09 14:21 ` Lars Ingebrigtsen
2019-07-11 5:51 ` Mike Kupfer
2019-07-11 14:04 ` Lars Ingebrigtsen
2019-07-11 14:18 ` Drew Adams
2019-07-12 3:20 ` Mike Kupfer
2019-07-12 3:33 ` Drew Adams
2022-01-22 14:43 ` Lars Ingebrigtsen
[not found] <mailman.5042.1543777897.1284.help-gnu-emacs@gnu.org>
2018-12-04 9:04 ` using setq to create lists based on other lists Barry Margolin
2018-12-04 13:56 ` Stefan Monnier
2018-12-05 1:07 ` Robert Thorpe
2018-12-05 2:32 ` Drew Adams
2018-12-05 6:45 ` Jean-Christophe Helary
2018-12-05 8:00 ` Marcin Borkowski
2018-12-05 8:11 ` Jean-Christophe Helary
2018-12-05 14:57 ` Drew Adams
[not found] ` <mailman.5218.1544021892.1284.help-gnu-emacs@gnu.org>
2018-12-05 16:59 ` Barry Margolin
[not found] ` <mailman.5186.1543978155.1284.help-gnu-emacs@gnu.org>
2018-12-05 16:50 ` Barry Margolin
[not found] ` <mailman.5145.1543931778.1284.help-gnu-emacs@gnu.org>
2018-12-05 16:47 ` Barry Margolin
[not found] <mailman.7307.1515801433.27995.help-gnu-emacs@gnu.org>
2018-01-13 0:43 ` info-find-source Emanuel Berg
2018-01-13 3:43 ` info-find-source Robert Thorpe
2018-01-13 5:23 ` info-find-source Marcin Borkowski
2018-01-13 16:31 ` info-find-source Drew Adams
2018-01-14 7:03 ` info-find-source Marcin Borkowski
2018-01-16 23:10 ` info-find-source Drew Adams
2018-01-13 15:50 ` info-find-source Drew Adams
[not found] ` <mailman.7314.1515821013.27995.help-gnu-emacs@gnu.org>
2018-01-14 2:57 ` info-find-source Emanuel Berg
2018-01-14 7:00 ` info-find-source Marcin Borkowski
[not found] ` <mailman.7369.1515913231.27995.help-gnu-emacs@gnu.org>
2018-01-15 4:17 ` info-find-source Emanuel Berg
2018-01-15 18:54 ` info-find-source Marcin Borkowski
[not found] ` <mailman.7435.1516042498.27995.help-gnu-emacs@gnu.org>
2018-01-15 19:55 ` info-find-source Emanuel Berg
2018-01-16 23:58 ` info-find-source Robert Thorpe
2018-01-19 6:22 ` info-find-source Marcin Borkowski
[not found] ` <mailman.7609.1516342943.27995.help-gnu-emacs@gnu.org>
2018-01-19 7:12 ` info-find-source Emanuel Berg
2018-01-19 20:31 ` info-find-source Marcin Borkowski
2018-01-19 21:05 ` info-find-source Drew Adams
[not found] ` <mailman.7653.1516395915.27995.help-gnu-emacs@gnu.org>
2018-01-19 22:19 ` info-find-source Emanuel Berg
2018-01-19 23:21 ` info-find-source Drew Adams
[not found] ` <mailman.7656.1516404112.27995.help-gnu-emacs@gnu.org>
2018-01-20 19:49 ` info-find-source Emanuel Berg
2018-01-20 20:18 ` info-find-source Eli Zaretskii
[not found] ` <<83bmhos2qd.fsf@gnu.org>
2018-01-20 23:50 ` info-find-source Drew Adams
2018-01-21 0:04 ` info-find-source Drew Adams
[not found] ` <mailman.7695.1516493072.27995.help-gnu-emacs@gnu.org>
2018-01-21 11:49 ` info-find-source Emanuel Berg
[not found] ` <mailman.7650.1516393881.27995.help-gnu-emacs@gnu.org>
2018-01-19 20:43 ` info-find-source Emanuel Berg
2018-01-13 5:17 ` info-find-source Marcin Borkowski
[not found] ` <mailman.7313.1515820700.27995.help-gnu-emacs@gnu.org>
2018-01-14 2:54 ` info-find-source Emanuel Berg
2018-01-15 18:52 ` info-find-source Marcin Borkowski
[not found] ` <mailman.7433.1516042345.27995.help-gnu-emacs@gnu.org>
2018-01-15 19:50 ` info-find-source Emanuel Berg
2017-11-11 9:17 Reload file from disk Florian Weimer
2017-11-11 10:29 ` Eli Zaretskii
2017-11-11 10:40 ` Eli Zaretskii
2017-11-11 10:54 ` Florian Weimer
2017-11-11 11:55 ` Eli Zaretskii
2017-11-11 13:45 ` Ken Olum
2017-11-11 14:11 ` Eli Zaretskii
2017-11-11 15:03 ` Ken Olum
2017-11-11 16:48 ` Drew Adams
2017-11-11 11:59 ` Andreas Schwab
2017-11-11 12:44 ` Noam Postavsky
2017-11-12 18:28 ` Joost Kremers
2017-11-13 17:24 ` Tom Tromey
2016-08-03 9:30 How to get back to a place in a buffer, or: what is a window configuration? Marcin Borkowski
2016-08-03 11:25 ` Kaushal Modi
2016-08-03 18:31 ` Marcin Borkowski
2016-08-03 14:42 ` Drew Adams
2016-08-03 18:42 ` Marcin Borkowski
2016-08-03 19:39 ` Drew Adams
2016-08-03 21:47 ` Robert Thorpe
2016-08-03 22:06 ` Drew Adams
2016-05-13 14:20 Overriding emacs key bindings xiongtk
2016-05-16 18:04 ` Eli Zaretskii
2016-05-16 21:15 ` xiongtk
2016-05-16 18:59 ` Emanuel Berg
2016-05-16 21:14 ` xiongtk
2016-05-16 23:29 ` Emanuel Berg
2016-05-17 1:55 ` Robert Thorpe
2016-05-17 2:41 ` Emanuel Berg
2016-05-17 4:07 ` Drew Adams
2016-05-17 3:25 ` Kaushal Modi
2016-05-17 4:07 ` Drew Adams
2016-05-17 4:15 ` Emanuel Berg
2016-05-17 20:38 ` Robert Thorpe
2016-05-17 4:07 ` Drew Adams
2016-05-18 1:42 ` Emacs conventions (was: Re: Overriding emacs key bindings) Emanuel Berg
2016-05-18 4:38 ` Drew Adams
2016-05-18 5:22 ` Emanuel Berg
2016-05-18 5:36 ` "First line is not a complete sentence" (was: Re: Emacs conventions (was: Re: Overriding emacs key bindings)) Emanuel Berg
[not found] ` <mailman.40.1463549841.6543.help-gnu-emacs@gnu.org>
2016-05-18 13:27 ` Joost Kremers
2016-05-19 4:32 ` Emanuel Berg
[not found] ` <mailman.37.1463546355.6543.help-gnu-emacs@gnu.org>
2016-05-18 14:31 ` Emacs conventions (was: Re: Overriding emacs key bindings) Barry Margolin
2016-05-19 4:38 ` Emanuel Berg
2016-05-17 4:44 ` Overriding emacs key bindings Marcin Borkowski
2016-05-17 20:37 ` Robert Thorpe
2016-05-18 2:21 ` Emanuel Berg
2016-05-18 20:34 ` Robert Thorpe
2016-05-19 1:33 ` Emanuel Berg
2016-05-18 17:52 ` Marcin Borkowski
2016-05-18 20:30 ` Robert Thorpe
2016-05-17 4:43 ` Marcin Borkowski
2016-05-18 1:51 ` Emanuel Berg
2016-05-17 4:49 ` Marcin Borkowski
2016-05-18 2:02 ` Emanuel Berg
2015-03-03 0:47 Opening a bookmark in the init file Robert Thorpe
2015-03-03 0:56 ` Drew Adams
2015-03-03 2:32 ` Robert Thorpe
2015-03-08 19:18 ` Robert Thorpe
2015-03-08 21:24 ` Drew Adams
2015-03-08 21:48 ` Robert Thorpe
2015-03-08 22:52 ` Drew Adams
2015-01-14 22:12 Info: how to get back from a footnote Marcin Borkowski
2015-01-15 2:42 ` Robert Thorpe
2015-01-15 3:11 ` Drew Adams
2015-01-15 5:51 ` Marcin Borkowski
2015-01-16 2:38 ` Robert Thorpe
[not found] <mailman.16504.1419019164.1147.help-gnu-emacs@gnu.org>
2014-12-29 4:21 ` Abbrevs for the most frequent elisp symbols Emanuel Berg
2014-12-29 11:24 ` Marcin Borkowski
2014-12-29 13:09 ` Robert Thorpe
2014-12-29 15:28 ` Drew Adams
2014-12-29 16:28 ` Robert Thorpe
2014-12-29 13:26 ` Stefan Monnier
2014-12-29 13:40 ` Marcin Borkowski
2014-12-29 14:57 ` Stefan Monnier
2014-12-29 15:49 ` Tom
[not found] ` <mailman.16844.1419852282.1147.help-gnu-emacs@gnu.org>
2015-01-03 2:25 ` Emanuel Berg
2015-01-04 0:19 ` Artur Malabarba
[not found] ` <mailman.17204.1420330787.1147.help-gnu-emacs@gnu.org>
2015-01-05 21:16 ` Emanuel Berg
2015-01-08 20:53 ` Artur Malabarba
2015-01-03 2:31 ` Emanuel Berg
2014-11-24 16:40 When do you prefer frames instead of windows? Raffaele Ricciardi
2014-11-24 17:20 ` Drew Adams
2014-11-25 8:03 ` Gian Uberto Lauri
2014-11-25 15:46 ` Drew Adams
2014-11-25 15:54 ` Gian Uberto Lauri
2014-11-25 8:33 ` When do you prefer windows instead of frames? Was: " H. Dieter Wilhelm
2014-11-25 15:46 ` Drew Adams
2014-11-25 18:40 ` MBR
2014-11-25 18:52 ` Drew Adams
2014-11-26 2:31 ` Yuri Khan
2014-12-19 16:08 ` Jude DaShiell
2014-11-25 8:52 ` Rainer M Krug
[not found] ` <mailman.14479.1416849631.1147.help-gnu-emacs@gnu.org>
2014-11-24 17:47 ` Barry Margolin
2014-11-24 18:06 ` Jai Dayal
2014-11-25 17:32 ` Joost Kremers
[not found] ` <<slrnm79f8k.a37.joost.m.kremers@j.kremers4.news.arnhem.chello.nl>
2014-11-25 18:09 ` Drew Adams
2014-11-24 19:10 ` MBR
2014-11-24 19:14 ` Drew Adams
2014-11-24 22:12 ` H. Dieter Wilhelm
[not found] ` <mailman.14497.1416867184.1147.help-gnu-emacs@gnu.org>
2014-11-25 0:59 ` Barry Margolin
2014-11-25 1:29 ` Robert Thorpe
2014-11-25 4:21 ` Drew Adams
2014-11-25 8:54 ` Rainer M Krug
2014-11-25 15:47 ` Drew Adams
2014-11-25 1:45 ` Yuri Khan
2014-11-25 9:27 ` Ralf Fassel
2014-11-25 15:47 ` Drew Adams
[not found] ` <mailman.14554.1416930453.1147.help-gnu-emacs@gnu.org>
2014-11-25 15:57 ` Ralf Fassel
2014-11-25 16:57 ` Drew Adams
[not found] ` <mailman.14564.1416934703.1147.help-gnu-emacs@gnu.org>
2014-11-25 17:16 ` Ralf Fassel
2014-11-25 18:09 ` Drew Adams
2014-11-25 22:08 ` Subhan Michael Tindall
2014-11-25 22:22 ` Drew Adams
[not found] ` <mailman.14600.1416953316.1147.help-gnu-emacs@gnu.org>
2014-11-26 9:34 ` Joost Kremers
2014-11-25 22:02 ` Subhan Michael Tindall
2014-11-26 5:02 ` Yuri Khan
2014-11-25 22:28 ` Bob Proulx
2014-11-25 22:54 ` Drew Adams
2014-11-26 8:12 ` Alan Schmitt
2014-11-26 13:42 ` H. Dieter Wilhelm
2014-11-28 13:51 ` Tom Davey
2014-11-28 15:39 ` Drew Adams
2014-11-26 16:37 ` Ken Goldman
2014-11-27 21:02 ` Chris F.A. Johnson
2014-07-23 21:37 when you gotta have a variable value for a symbol name Buchs, Kevin J.
2014-07-23 22:02 ` Drew Adams
[not found] ` <(message>
[not found] ` <from>
[not found] ` <Raffaele>
[not found] ` <Robert>
[not found] ` <Richard>
[not found] ` <Juri>
[not found] ` <Emanuel>
[not found] ` <Eli>
[not found] ` <Marcin>
[not found] ` <Drew>
[not found] ` <Adams>
[not found] ` <on>
[not found] ` <Fri>
[not found] ` <Tue>
[not found] ` <03>
[not found] ` <17>
[not found] ` <May>
[not found] ` <2020>
[not found] ` <23:56:00>
[not found] ` <17:07:29>
[not found] ` <-0800>
[not found] ` <01:18:18>
[not found] ` <04:01:05>
[not found] ` <2016>
[not found] ` <01:29:37>
[not found] ` <Sat>
[not found] ` <Sun>
[not found] ` <Wed>
[not found] ` <23>
[not found] ` <Jul>
[not found] ` <2014>
[not found] ` <15:02:38>
[not found] ` <-0700>
[not found] ` <17:40:42>
[not found] ` <2019>
[not found] ` <16:21:24>
[not found] ` <07:18:26>
[not found] ` <14>
[not found] ` <Jan>
[not found] ` <2015>
[not found] ` <02:32:50>
[not found] ` <2018>
[not found] ` <21:17:16>
[not found] ` <Thu>
[not found] ` <01>
[not found] ` <Mon>
[not found] ` <24>
[not found] ` <Nov>
[not found] ` <2017>
[not found] ` <29>
[not found] ` <Barry>
2014-07-24 21:57 ` Robert Thorpe
2014-07-25 0:06 ` Drew Adams
[not found] ` <mailman.5936.1406152985.1147.help-gnu-emacs@gnu.org>
2014-07-23 22:12 ` Pascal J. Bourguignon
[not found] <Your>
[not found] ` <message>
[not found] ` <of>
[not found] ` <"Tue>
[not found] ` <09>
[not found] ` <Oct>
[not found] ` <"Thu,>
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.