Emacs and the Status Notification Specification

Emacs and the Status Notification Specification

[Tom Tromey]

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

The Status Notification Specification is a D-Bus spec for what are
sometimes called "systray icons".  It lets applications create systray
icons using just D-Bus, rather than the mix of different things required
by the older spec.

The spec itself is here:

    http://www.notmart.org/misc/statusnotifieritem/index.html

As far as I know, only KDE currently implements this spec.  However,
nothing prevents it from being implemented in other desktops.

Attached are 2 files to implement the spec for Emacs:

* status.el, the basic implementation
* erc-status.el, adding an icon for ERC.  The icon blinks when someone
  pings you, and clicking it switches to the appropriate buffer.

I'd like to check these in to Emacs.  However, I was uncertain where to
locate them, so I thought I would post here first.

I also have a similar file, emms-status.el, to add an icon for EMMS; and
a few bits of elisp to add something similar for the calendar (plus
calls to notifications.el for appointments...).  I can send those along
if anybody cares.

Tom


[-- Attachment #2: status.el --]
[-- Type: text/plain, Size: 10303 bytes --]

;;; status.el --- notification area support for Emacs.

;; Copyright (C) 2007, 2011 Tom Tromey <tromey@redhat.com>

;; Author: Tom Tromey <tromey@redhat.com>
;; Version: 0.3

;; This file is not (yet) part of GNU Emacs.
;; However, it is distributed under the same license.

;; 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, 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; see the file COPYING.  If not, write to the
;; Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
;; Boston, MA 02110-1301, USA.

;; Commentary:

;; This implements the client side of the Status Notifier Item
;; specification:

;; http://www.notmart.org/misc/statusnotifieritem/index.html

;; There are no user-visible features of this module, only features
;; for Emacs Lisp programs.  You may like to use erc-status.el, which
;; provides some nice notification area support for ERC.

(require 'dbus)
(eval-when-compile (require 'cl))

;; The next available status ID.  Internal.
(defvar status--id 0)

;; Structure representing a status icon.
;; For internal use only.
(defstruct (status (:conc-name status--))
  (service-name nil :read-only t)
  (icon "dialog-information")
  (attention-icon "dialog-warning")
  overlay-icon
  (tooltip-icon "dialog-information")
  (tooltip-title "")
  (tooltip-description "")
  (category :application :read-only t)
  (id nil :read-only t)
  (title "Emacs")
  (status :passive)
  activate-callback
  secondary-activate-callback)

;; Map category keywords to strings from the spec.
(defconst status--category-map
  '((:application . "ApplicationStatus")
    (:communication . "Communication")
    (:system . "SystemServices")
    (:hardware . "Hardware")))

;; Map status keywords to strings from the spec.
(defconst status--status-map
  '((:passive . "Passive")
    (:active . "Active")
    (:needs-attention . "NeedsAttention")))

;; Properties we don't currently expose to the user, together with
;; their values.  (We actually do expose "ToolTip", but it is handled
;; differently below.)
(defconst status--properties
  '(("AttentionIconPixmap" nil)
    ("IconPixmap" nil)
    ("OverlayIconPixmap" nil)
    ("ToolTip" nil)
    ("WindowId" 0)))

;; Properties we do expose to the user, together with the accessor to
;; use.
(defconst status--exposed-properties
  '(("AttentionIconName" status--attention-icon)
    ("IconName" status--icon)
    ("OverlayIconName" status--overlay-icon)
    ("Category" status--category)
    ("Id" status--id)
    ("Title" status--title)))

;; Called when the icon is activated; calls the user-specified
;; function.
(defun status--activate (status-icon x y)
  (let ((callback (status--activate-callback status-icon)))
    (if callback
	(funcall callback))
    :ignore))

;; Called when the icon gets a secondary activation event.  Calls the
;; user-specified function.
(defun status--secondary-activate (status-icon x y)
  (let ((callback (status--secondary-activate-callback status-icon)))
    (if callback
	(funcall callback))
    :ignore))

;; Create the status notifier item via D-Bus.  See the specification
;; to understand most of this.
(defun status--setup-service (status-icon)
  (dolist (item status--properties)
    (dbus-register-property :session (status--service-name status-icon)
			    "/StatusNotifierItem"
			    "org.kde.StatusNotifierItem"
			    (car item)
			    :read (cadr item)
			    t t))
  (dolist (item status--exposed-properties)
    (dbus-register-property :session (status--service-name status-icon)
			    "/StatusNotifierItem"
			    "org.kde.StatusNotifierItem"
			    (car item)
			    :read (funcall (cadr item) status-icon)
			    t t))
  (dbus-register-property :session (status--service-name status-icon)
			  "/StatusNotifierItem"
			  "org.kde.StatusNotifierItem"
			  "Status"
			  :read (cdr (assq (status--status status-icon)
					   status--status-map))
			  t t)
  (dbus-register-method :session (status--service-name status-icon)
			"/StatusNotifierItem"
			"org.kde.StatusNotifierItem"
			"Activate"
			`(lambda (&rest args) (apply
					       #'status--activate
					       ,status-icon
					       args))
			t)
  (dbus-register-method :session (status--service-name status-icon)
			"/StatusNotifierItem"
			"org.kde.StatusNotifierItem"
			"SecondaryActivate"
			`(lambda (&rest args) (apply
					       #'status--secondary-activate
					       ,status-icon
					       args))
			t)

  (dbus-register-service :session (status--service-name status-icon))

  ;; Register the item with the watcher.
  (dbus-call-method-asynchronously :session "org.kde.StatusNotifierWatcher"
				   "/StatusNotifierWatcher"
				   "org.kde.StatusNotifierWatcher"
				   "RegisterStatusNotifierItem"
				   nil
				   (status--service-name status-icon)))

(defun status--update-dbus-property (icon property signal new-value
					  &rest extra-args)
  (dbus-register-property :session (status--service-name icon)
			  "/StatusNotifierItem"
			  "org.kde.StatusNotifierItem"
			  property
			  :read new-value)
  (apply #'dbus-send-signal
	 :session (status--service-name icon)
	 "/StatusNotifierItem"
	 "org.kde.StatusNotifierItem"
	 signal
	 extra-args))

(defun status-set-icon (icon new-value)
  "Set the icon displayed in the status area.
ICON is that status icon object.
NEW-VALUE is the Freedesktop-compliant name of the icon to display."
  (setf (status--icon icon) new-value)
  (status--update-dbus-property icon "IconName" "NewIcon" new-value))

(defun status-set-attention-icon (icon new-value)
  "Set the attention icon displayed in the status area.
ICON is that status attention icon object; the attention icon is
displayed when the status icon needs attention.  It defaults to the
ordinary icon.
NEW-VALUE is the Freedesktop-compliant name of the icon to display."
  (setf (status--attention-icon icon) new-value)
  (status--update-dbus-property icon "AttentionIconName" "NewAttentionIcon"
				new-value))

(defun status-set-overlay-icon (icon new-value)
  "Set the overlay icon displayed in the status area.
ICON is that status overlay icon object; the overlay icon carries extra
information to displayed over the status icon.  It defaults to nil.
NEW-VALUE is the Freedesktop-compliant name of the icon to display."
  (setf (status--overlay-icon icon) new-value)
  (status--update-dbus-property icon "OverlayIconName" "NewOverlayIcon"
				new-value))

(defun status-set-title (icon new-value)
  "Set the title of the status icon.
ICON is the status icon to modify.
NEW-VALUE is the new title."
  (setf (status--title icon) new-value)
  (status--update-dbus-property icon "Title" "NewTitle" new-value))

(defun status--compute-tooltip (icon)
  (list :struct
	(status--tooltip-icon icon)
	nil
	(status--tooltip-title icon)
	(status--tooltip-description icon)))

(defun status-set-tooltip-title (icon new-value)
  "Set the title of the status icon's tooltip.
ICON is the status icon to modify.
NEW-VALUE is the new tooltip title."
  (setf (status--tooltip-title icon) new-value)
  (status--update-dbus-property icon "ToolTip" "NewToolTip"
				(status--compute-tooltip icon)))

(defun status-set-tooltip-icon (icon new-value)
  "Set the icon of the status icon's tooltip.
ICON is the status icon to modify.
NEW-VALUE is the new tooltip icon; it must be a Freedesktop-compliant
icon name."
  (setf (status--tooltip-icon icon) new-value)
  (status--update-dbus-property icon "ToolTip" "NewToolTip"
				(status--compute-tooltip icon)))

(defun status-set-tooltip-description (icon new-value)
  "Set the description of the status icon's tooltip.
ICON is the status icon to modify.
NEW-VALUE is the new description.
The description may contain HTML markup."
  (setf (status--tooltip-description icon) new-value)
  (status--update-dbus-property icon "ToolTip" "NewToolTip"
				(status--compute-tooltip icon)))

(defun status-set-status (icon new-value)
  "Set the status of the status icon.
ICON is the status icon to modify.
NEW-VALUE is the new status; it must be one of the keywords:
  :passive          The application is in a passive state.
  :active           The application is in an active state.
  :needs-attention  The application needs attention from the user."
  (let ((string-value (cdr (assq new-value status--status-map))))
    (unless string-value
      (error "Invalid status for status-icon"))
    (setf (status--status icon) new-value)
    (status--update-dbus-property icon "Status" "NewStatus"
				  string-value string-value)))

(defun status-set-activate-callback (status-icon new-value)
  "Set the activation callback function for STATUS-ICON.
NEW-VALUE is a function which will be called when the icon is \"activated\"
\(usually this means clicked by the user).
If nil, no function will be called."
  (setf (status--activate-callback status-icon) new-value))

(defun status-set-secondary-activate-callback (status-icon new-value)
  "Set the activation callback function for STATUS-ICON.
NEW-VALUE is a function which will be called when the icon is
\"secondarily activated\" (usually this means middle-clicked by the user).
If nil, no function will be called."
  (setf (status--secondary-activate-callback status-icon) new-value))

;;;###autoload
(defun status-new (category id &rest args)
  "Create a new status icon and return it."
  (let* ((id status--id)
	 (service-name (concat "org.kde.StatusNotifierItem-"
			       (int-to-string (emacs-pid))
			       "-"
			       (int-to-string id)))
	 (result (apply #'make-status
			:service-name service-name
			:category (cdr (assq category
					     status--category-map))
			:id id
			args)))
    (setq status--id (1+ status--id))
    (status--setup-service result)
    result))

(defun status-delete (status-icon)
  "Destroy the status icon."
  (dbus-unregister-service :session (status--service-name status-icon)))

(provide 'status)

;;; status.el ends here

[-- Attachment #3: erc-status.el --]
[-- Type: text/plain, Size: 6490 bytes --]

;;; erc-status.el --- notification area support for ERC

;; Copyright (C) 2007, 2011 Tom Tromey <tromey@redhat.com>

;; Author: Tom Tromey <tromey@redhat.com>
;; Version: 0.2
;; Keywords: comm

;; This file is not (yet) part of GNU Emacs.
;; However, it is distributed under the same license.

;; 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, 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; see the file COPYING.  If not, write to the
;; Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
;; Boston, MA 02110-1301, USA.

;;; Commentary:

;; This provides nice support for the notification area to ERC.  In
;; particular it:
;; * Will blink the icon when you get a private message or are paged
;;   in a channel.
;; * Left-click on the blinking icon will show the appropriate channel
;;   buffer in some frame (which is then raised).  If there are
;;   multiple pages at once, it will show one and you can click again
;;   to go to the next one.
;; * Will show a menu of all the channels on the right button menu.
;;   (Though... this doesn't work and I haven't debugged it.)
;; * Will pop up notification bubbles when you connect to or
;;   disconnect from a server.
;; This is regular erc module named 'status'; you can enable it as you
;; would any other module.

;;; Change log:

;; 2011-06-23  rewrite for status notifier spec
;; 2007-02-15  raise frame on left click
;; 2007-02-13  make sure priv message added after auto-query
;; 2007-02-08  turn into an ERC module
;; 2007-02-08  another try at private messages
;; 2007-01-29  try to make private messages work.  show buffer on click

;; TO DO:
;; - make tool tip show some kind of real status ...?
;; - use a nicer icon
;; - menu?  (tried but it isn't working yet)
;; - integrate with auto-query a bit better
;; - let left click use specified frame or make a new frame?

(require 'status)
(require 'erc)
(require 'notifications)

;; The status icon object.
(defvar erc-status-status-icon nil)

;; List of ERC buffers that caused the status icon to blink.
(defvar erc-status-buffer-list nil)

(defun erc-status-remove-buffer (buffer)
  ;; If the list is not empty, and removing an element makes the list
  ;; empty, stop blinking.
  (and erc-status-buffer-list
       (not (setq erc-status-buffer-list (delq buffer erc-status-buffer-list)))
       (status-set-state erc-status-status-icon :active)))

(defun erc-status-add-buffer (buffer)
  (unless (erc-buffer-visible buffer)
    (status-set-state erc-status-status-icon :needs-attention)
    (unless (memq buffer erc-status-buffer-list)
      (setq erc-status-buffer-list (cons buffer
					 erc-status-buffer-list)))))

(defun erc-status-match-hook (match-type nick message)
  ;; Look for user's nick and make the icon blink.
  (if (eq match-type 'current-nick)
      (erc-status-add-buffer (current-buffer))))

(defun erc-status-buffer-killed ()
  ;; If one of our buffers was killed, remove it.
  (erc-status-remove-buffer (current-buffer)))

(defun erc-status-window-configuration-changed ()
  (let ((new-list))
    (dolist (buffer erc-status-buffer-list)
      (unless (erc-buffer-visible buffer)
	(setq new-list (cons buffer new-list))))
    (unless (setq erc-status-buffer-list new-list)
      (status-set-state erc-status-status-icon :active))))

(defun erc-status-disconnected (nick ip reason)
  (notifications-notify :title (concat "Disconnected: " reason)
			:app-name "ERC"
			:urgency 'normal))

(defun erc-status-after-connect (server nick)
  (notifications-notify :title (concat "Connected to " server " as " nick)
			:app-name "ERC"
			:urgency 'normal))

(defun erc-status-select-first-buffer ()
  "Switch to the first ERC buffer requiring your attention.
If there is no such buffer, do nothing."
  (when erc-status-buffer-list
    (switch-to-buffer (car erc-status-buffer-list))
    (raise-frame)))

\f

;; From: http://www.emacswiki.org/cgi-bin/wiki/ErcPageMe
;; Then modified to suit.

(defun erc-status-PRIVMSG (proc parsed)
  (let* ((nick (car (erc-parse-user (erc-response.sender parsed))))
	 (target (car (erc-response.command-args parsed)))
	 (msg (erc-response.contents parsed))
	 (query  (if (not erc-query-on-unjoined-chan-privmsg)
		     nick
		   (if (erc-current-nick-p target)
		       nick
		     target))))
    (when (and (erc-current-nick-p target)
	       (not (erc-is-message-ctcp-and-not-action-p msg)))
      ;; Note: assumes you are using auto-query.
      (erc-status-add-buffer (erc-get-buffer query proc))))
  ;; Always return nil.
  nil)

\f

(define-erc-module status nil
  "Notification area support for ERC."
  ;; Enable.
  ((unless erc-status-status-icon
     (setq erc-status-status-icon (status-new :communication "Emacs ERC"
					      :icon "user-available"))
     ;; (status-set-tooltip erc-status-status-icon
     ;; 			 "ERC - IRC client for Emacs")
     (status-set-activate-callback erc-status-status-icon
				   'erc-status-select-first-buffer))
   (add-hook 'erc-text-matched-hook 'erc-status-match-hook)
   (add-hook 'kill-buffer-hook 'erc-status-buffer-killed)
   (add-hook 'window-configuration-change-hook
	     'erc-status-window-configuration-changed)
   (add-hook 'erc-after-connect 'erc-status-after-connect)
   (add-hook 'erc-disconnected-hook 'erc-status-disconnected)
   ;; FIXME: Must come *after* erc-auto-query.  Some sort of
   ;; auto-query hook or the like would be good here.
   (add-hook 'erc-server-PRIVMSG-functions 'erc-status-PRIVMSG t))

  ;; Disable.
  ((when erc-status-status-icon
     (status-delete erc-status-status-icon)
     (setq erc-status-status-icon nil))
   (remove-hook 'erc-text-matched-hook 'erc-status-match-hook)
   (remove-hook 'kill-buffer-hook 'erc-status-buffer-killed)
   (remove-hook 'window-configuration-change-hook
		'erc-status-window-configuration-changed)
   (remove-hook 'erc-after-connect 'erc-status-after-connect)
   (remove-hook 'erc-disconnected-hook 'erc-status-disconnected)
   (remove-hook 'erc-server-PRIVMSG-functions 'erc-status-PRIVMSG)))

;;; erc-status.el ends here

Re: Emacs and the Status Notification Specification

[Ted Zlatanov]

On Thu, 23 Jun 2011 11:31:59 -0600 Tom Tromey <tromey@redhat.com> wrote: 

Tom> The Status Notification Specification is a D-Bus spec for what are
Tom> sometimes called "systray icons".  It lets applications create systray
Tom> icons using just D-Bus, rather than the mix of different things required
Tom> by the older spec.

Tom> Attached are 2 files to implement the spec for Emacs:

Tom> * status.el, the basic implementation
Tom> * erc-status.el, adding an icon for ERC.  The icon blinks when someone
Tom>   pings you, and clicking it switches to the appropriate buffer.

Tom> I'd like to check these in to Emacs.  However, I was uncertain where to
Tom> locate them, so I thought I would post here first.

This is somewhat related to the emacs-panel work I'm doing.  I propose
we either make a emacs-desktop ELPA package (on the GNU ELPA or
somewhere else) or we make a lisp/desktop/ directory in Emacs.  My
preference is for the former, so it can be used in XEmacs and in older
Emacs versions, and so its development is decoupled from the Emacs
releases.

On my side, I would contribute:

- iconset.el and iconset-silk.el: common icons and ways to use them

- emacs-panel.el: facilities for popup frames to set up something like
  the gnome-panel, plus some EWMH facilities like listing the desktop
  area, the desktops, and setting/getting the current desktop.  This is
  going to be under heavy development.

Michael Albinus has provided a notifications.el server, which I think
also makes sense in the emacs-desktop package.

Ted

Re: Emacs and the Status Notification Specification

[Philipp Haselwarter]

I think would be preferable to keep a desktop client and a desktop
server package. And then maybe provide a metapackage to bundle the two.


-- 
Philipp Haselwarter

Re: Emacs and the Status Notification Specification

[Ted Zlatanov]

On Fri, 24 Jun 2011 10:54:51 +0200 Philipp Haselwarter <philipp.haselwarter@gmx.de> wrote: 

PH> I think would be preferable to keep a desktop client and a desktop
PH> server package. And then maybe provide a metapackage to bundle the two.

They share lots of functionality, e.g. setting up special frames.  The
"server" is really another client that happens to provide some panel
functionality.  

As long as installing the package doesn't enable either the client or
the server side, I see no harm in keeping them together.

Ted

Re: Emacs and the Status Notification Specification

[Tom Tromey]

Tom> Attached are 2 files to implement the spec for Emacs:
Tom> * status.el, the basic implementation

... which is kind of broken, so I won't be installing it quite yet.

Ted> This is somewhat related to the emacs-panel work I'm doing.  I propose
Ted> we either make a emacs-desktop ELPA package (on the GNU ELPA or
Ted> somewhere else) or we make a lisp/desktop/ directory in Emacs.  My
Ted> preference is for the former, so it can be used in XEmacs and in older
Ted> Emacs versions, and so its development is decoupled from the Emacs
Ted> releases.

I'm not sure this will work.  This code uses some later dbus methods; I
had to upgrade to 24 to get it working.

Ted> Michael Albinus has provided a notifications.el server, which I think
Ted> also makes sense in the emacs-desktop package.

That is already in the core.

I am fine with a GNU ELPA package.
I will try to do that once I've debugged the other problems.
Or, if you still want a unified package -- first, why? -- and second,
perhaps you could set it up.

Tom

Re: Emacs and the Status Notification Specification

[Michael Albinus]

Tom Tromey <tromey@redhat.com> writes:

> The Status Notification Specification is a D-Bus spec for what are
> sometimes called "systray icons".  It lets applications create systray
> icons using just D-Bus, rather than the mix of different things required
> by the older spec.
>
> The spec itself is here:
>
>     http://www.notmart.org/misc/statusnotifieritem/index.html
>
> As far as I know, only KDE currently implements this spec.  However,
> nothing prevents it from being implemented in other desktops.

The spec defines the interfaces org.freedesktop.
{StatusNotifierItem,StatusNotifierWatcher,StatusNotifierHost}. You
implement org.kde.{StatusNotifierItem,StatusNotifierWatcher}. I guess,
this is because the freedesktop version is not available yet.

They seem to be identical wrt methods, signals and properties.
Therefore, I propose you register your objects for
org.freedesktop.StatusNotifier* and org.kde.StatusNotifier* interfaces
in parallel.

Besides the properties, it might also be a good idea to offer standard
interfaces like org.freedesktop.DBus.Introspectable and
org.freedesktop.DBus.ObjectManager.

(Hmm, dbus.el shall be extended for ofD.ObjectManager).

> Tom

Best regards, Michael.

Re: Emacs and the Status Notification Specification

[Michael Albinus]

Tom Tromey <tromey@redhat.com> writes:

> Ted> This is somewhat related to the emacs-panel work I'm doing.  I propose
> Ted> we either make a emacs-desktop ELPA package (on the GNU ELPA or
> Ted> somewhere else) or we make a lisp/desktop/ directory in Emacs.  My
> Ted> preference is for the former, so it can be used in XEmacs and in older
> Ted> Emacs versions, and so its development is decoupled from the Emacs
> Ted> releases.
>
> I'm not sure this will work.  This code uses some later dbus methods; I
> had to upgrade to 24 to get it working.

And XEmacs does not support DBus. SXEmacs has some very basic support,
but it is not compatible.

> Ted> Michael Albinus has provided a notifications.el server, which I think
> Ted> also makes sense in the emacs-desktop package.
>
> That is already in the core.

Nope. notifications.el was written by Julien Danjou, and it implements
the client side. I have published some few lines which could be extended
to a server implementation; this is not installed anywhere.

> Tom

Best regards, Michael.

Re: Emacs and the Status Notification Specification

[Richard Stallman]

Emacs development does not commit to making its code work in XEmacs.
We cooperate in a lot of easy ways, because there is no reason to
refuse that.  However, in large decisions, making our code run in
XEmacs is a non-goal.  Plenty of XEmacs code uses interfaces that
don't exist in Emacs.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: Emacs and the Status Notification Specification

[Stephen J. Turnbull]

Richard Stallman writes:

 > Emacs development does not commit to making its code work in XEmacs.
 > We cooperate in a lot of easy ways, because there is no reason to
 > refuse that.  However, in large decisions, making our code run in
 > XEmacs is a non-goal.  Plenty of XEmacs code uses interfaces that
 > don't exist in Emacs.

In all decisions, large and small, it is an XEmacs goal to support
interfaces that exist in Emacs.  So I apologize for the delay in
supporting dbus in XEmacs, but I agree with Richard: don't avoid
interfaces just because they don't yet exist in XEmacs.

Re: Emacs and the Status Notification Specification

[Ted Zlatanov]

On Fri, 24 Jun 2011 11:00:44 -0600 Tom Tromey <tromey@redhat.com> wrote: 

Tom> Attached are 2 files to implement the spec for Emacs:
Tom> * status.el, the basic implementation

Tom> ... which is kind of broken, so I won't be installing it quite yet.

Ted> This is somewhat related to the emacs-panel work I'm doing.  I propose
Ted> we either make a emacs-desktop ELPA package (on the GNU ELPA or
Ted> somewhere else) or we make a lisp/desktop/ directory in Emacs.  My
Ted> preference is for the former, so it can be used in XEmacs and in older
Ted> Emacs versions, and so its development is decoupled from the Emacs
Ted> releases.

Tom> I'm not sure this will work.  This code uses some later dbus methods; I
Tom> had to upgrade to 24 to get it working.

My point is that if it's an ELPA package, it can be easily used
(installed+activated) from XEmacs.  I don't mean we will write
specifically for XEmacs; the XEmacs users can submit patches and
improvements as needed.  Sorry if that was not clear.

Tom> I am fine with a GNU ELPA package.
Tom> I will try to do that once I've debugged the other problems.
Tom> Or, if you still want a unified package -- first, why? -- and second,
Tom> perhaps you could set it up.

It would make sense to have a meta-package that includes my stuff and
yours.

I think we'll end up with a common library, there are functions we will
both need.  But for now we can start with your package as a standalone
entity and I'll steal from it ;)

Thanks
Ted

Re: Emacs and the Status Notification Specification

[Richard Stallman]

    My point is that if it's an ELPA package, it can be easily used
    (installed+activated) from XEmacs.

That is true, but that is not a factor in our decision about whether
to put this in ELPA.  It is neither here nor there.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: Emacs and the Status Notification Specification

[Ted Zlatanov]

On Mon, 27 Jun 2011 19:02:50 -0400 Richard Stallman <rms@gnu.org> wrote: 

RS>     My point is that if it's an ELPA package, it can be easily used
RS>     (installed+activated) from XEmacs.

RS> That is true, but that is not a factor in our decision about whether
RS> to put this in ELPA.  It is neither here nor there.

Please call the GNU ELPA as such, or GELPA, or something besides just
"ELPA."  I remember we had this discussion before and I've tried to be
consistent, using "GNU ELPA" when I mean "GNU ELPA."

Here I specifically meant that it can be an ELPA-format package, meaning
it can be installed by package.el.  It can live anywhere, which is
even clearer in my original post:

Ted> This is somewhat related to the emacs-panel work I'm doing.  I propose
Ted> we either make a emacs-desktop ELPA package (on the GNU ELPA or
Ted> somewhere else) or we make a lisp/desktop/ directory in Emacs.  My
Ted> preference is for the former, so it can be used in XEmacs and in older
Ted> Emacs versions, and so its development is decoupled from the Emacs
Ted> releases.

So while I would like it to live in the GNU ELPA and will propose that
when the time comes, that's not connected to my preference for the ELPA
package format and the *Emacs portability it offers (not just XEmacs,
but also older versions of GNU Emacs).

Ted

Re: Emacs and the Status Notification Specification

[Richard Stallman]

    Please call the GNU ELPA as such, or GELPA, or something besides just
    "ELPA."  I remember we had this discussion before and I've tried to be
    consistent, using "GNU ELPA" when I mean "GNU ELPA."

The problem with "GNU ELPA" as a name is that people will tend to
think that "ELPA" is an abbreviation of it.  To avoid confusion, we
need a name that is not similar to "ELPA".

How about Remote Emacs Library?


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: Emacs and the Status Notification Specification

[Ted Zlatanov]

On Wed, 29 Jun 2011 19:14:35 -0400 Richard Stallman <rms@gnu.org> wrote: 

RS>     Please call the GNU ELPA as such, or GELPA, or something besides just
RS>     "ELPA."  I remember we had this discussion before and I've tried to be
RS>     consistent, using "GNU ELPA" when I mean "GNU ELPA."

RS> The problem with "GNU ELPA" as a name is that people will tend to
RS> think that "ELPA" is an abbreviation of it.  To avoid confusion, we
RS> need a name that is not similar to "ELPA".

RS> How about Remote Emacs Library?

We already tried to come up with some names.  I can't find the thread
but things like GELPA and such were proposed.

Regarding REL, it's not a bad name, but sounds a bit like RHEL, the
RedHat Enterprise Linux distribution.  So it could be confusing.

I'm out of ideas at this point...  I feel like I'm just nay-saying all
the suggestions, so please don't consider my opinion too carefully :)

Whatever the name, I'll try to use it consistently.

Thanks
Ted

Re: Emacs and the Status Notification Specification

[Juanma Barranquero]

2011/6/30 Ted Zlatanov <tzz@lifelogs.com>:

> Whatever the name, I'll try to use it consistently.

Call it FREE: Free and Remote Emacs Elisp ;-)

   Juanma


P.S.: No, I'm not serious. I think it's a lousy name.

Re: Emacs and the Status Notification Specification

[John Yates]

Remote Emacs eXtensions Library or REXL for short?

(It may contain non-Elisp files.)

/john

Re: Emacs and the Status Notification Specification

[Juanma Barranquero]

On Thu, Jun 30, 2011 at 16:58, John Yates <john@yates-sheets.org> wrote:

> (It may contain non-Elisp files.)

Did you miss the "I'm not serious" part? ;-)

    Juanma

Re: Emacs and the Status Notification Specification

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     Please call the GNU ELPA as such, or GELPA, or something besides just
>     "ELPA."  I remember we had this discussion before and I've tried to be
>     consistent, using "GNU ELPA" when I mean "GNU ELPA."
>
> The problem with "GNU ELPA" as a name is that people will tend to
> think that "ELPA" is an abbreviation of it.  To avoid confusion, we
> need a name that is not similar to "ELPA".
>
> How about Remote Emacs Library?

If we abandon ELPA as a term for archives of this type, we need also to
come up with a replacement name for archives of this type.

But "Emacs Lisp Package Archive" is the natural name to use when
referring to archives made using package.el, which internally refers
ubiquitously to "packages" and "archives".  So it would be preferable to
use ELPA as the generic name.

It would help if tromey.com/elpa/ would rebrand itself as "Tom's ELPA"
or something along those lines, instead of "the" ELPA as it currently
(understandably) does.  This will reduce confusion not only with the GNU
ELPA, but also the personal ELPAs that a few users are apparently
starting to set up.

Tom, WDYT?

Re: Emacs and the Status Notification Specification

[John Yates]

> Did you miss the "I'm not serious" part? ;-)

No. I rejected my first notion, Remote Emacs Elisp Library (REEL).  So
"(It may contain non-Elisp files.)" was more a parenthetical to self.

/john

Re: Emacs and the Status Notification Specification

[Richard Stallman]

    Regarding REL, it's not a bad name, but sounds a bit like RHEL, the
    RedHat Enterprise Linux distribution.  So it could be confusing.

RHEL is not mentioned terribly often in our discussions, and it is a
GNU/Linux distro, which is a very different kind of thing from a
library of Lisp packages.  I think the context will usually avoid
confusion.

Thus, this is a small flaw -- much smaller than the problem we are
trying to solve.  If our choice is GELPA or REL, we should definitely
use REL.

Or we could add "GNU" and make it GREL.  Is that better than REL?

REXL, suggested recently, is not bad.  Or GREXL?  GEXL?
Any of them would avoid this predictable confusion.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: Emacs and the Status Notification Specification

[Ted Zlatanov]

On Thu, 30 Jun 2011 20:18:28 -0400 Richard Stallman <rms@gnu.org> wrote: 

RS>     Regarding REL, it's not a bad name, but sounds a bit like RHEL, the
RS>     RedHat Enterprise Linux distribution.  So it could be confusing.

RS> RHEL is not mentioned terribly often in our discussions, and it is a
RS> GNU/Linux distro, which is a very different kind of thing from a
RS> library of Lisp packages.  I think the context will usually avoid
RS> confusion.

RS> Thus, this is a small flaw -- much smaller than the problem we are
RS> trying to solve.  If our choice is GELPA or REL, we should definitely
RS> use REL.

RS> Or we could add "GNU" and make it GREL.  Is that better than REL?

RS> REXL, suggested recently, is not bad.  Or GREXL?  GEXL?
RS> Any of them would avoid this predictable confusion.

My vote is for GELD:  GNU Emacs Lisp Depot.  Seriously.  But any of the
others are good too.

Ted

Re: Emacs and the Status Notification Specification

[David De La Harpe Golden]

On 01/07/11 02:46, Ted Zlatanov wrote:

> My vote is for GELD:  GNU Emacs Lisp Depot.  Seriously.  But any of the
> others are good too.
>

Emacs Unified Relatively Official Package Archive

Attempt no landings.

Re: Emacs and the Status Notification Specification

[Stefan Monnier]

> My vote is for GELD:  GNU Emacs Lisp Depot.  Seriously.  But any of the
> others are good too.

I like GNU ELPA and see no need to change it.


        Stefan

Re: Emacs and the Status Notification Specification

[Richard Stallman]

    I like GNU ELPA and see no need to change it.

It will predictably cause confusion, because many people won't know
that GNU ELPA and ELPA are different.

The joke names are funny, but this remains a serious issue:
we need to change one or the other.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: Emacs and the Status Notification Specification

[Ted Zlatanov]

On Fri, 01 Jul 2011 07:40:35 -0400 Richard Stallman <rms@gnu.org> wrote: 

RS>     I like GNU ELPA and see no need to change it.

RS> It will predictably cause confusion, because many people won't know
RS> that GNU ELPA and ELPA are different.

RS> The joke names are funny, but this remains a serious issue:
RS> we need to change one or the other.

I like Chong's approach of asking Tom Tromey to change his archive's name.
"GNU ELPA" is a really nice, logical, memorable name.  There's been no
confusion when I've used it.

Failing that, so far we have these alternatives (including jokes too):

EUROPA
GELD
GELPA
GEXL
GREL
GREXL
REEL
REL
REXL

Thanks
Ted

Re: Emacs and the Status Notification Specification

[Stefan Monnier]

> I like Chong's approach of asking Tom Tromey to change his archive's name.

If Tom is OK with it, that's even better, but being the originator of
the feature and name, he has every right to keep the name as is.
I'd hope he'd keep "ELPA" in any new name he might adopt.

> "GNU ELPA" is a really nice, logical, memorable name.  There's been no
> confusion when I've used it.

That's also my experience, which is why I don't think there's any need
to change it.


        Stefan

Re: Emacs and the Status Notification Specification

[Stefan Monnier]

>     I like GNU ELPA and see no need to change it.
> It will predictably cause confusion, because many people won't know
> that GNU ELPA and ELPA are different.

I'd be very surprised if that's the case.


        Stefan

Re: Emacs and the Status Notification Specification

[Richard Stallman]

    >     I like GNU ELPA and see no need to change it.
    > It will predictably cause confusion, because many people won't know
    > that GNU ELPA and ELPA are different.

    I'd be very surprised if that's the case.

In the context of GNU, anyone who sees "ELPA" and "GNU ELPA" will
assume that the former is short for the latter.  If the person has
recently paid attention to an explanation of the difference, he may
remember the difference, but otherwise he will naturally assume they
are the same.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/