Reminder about feature freeze

Reminder about feature freeze

[Chong Yidong]

Just a reminder: the pretest is scheduled for late July, as discussed at
http://lists.gnu.org/archive/html/emacs-devel/2011-05/msg00953.html.

In order to ensure a smooth transition to the pretest, I encourage
everyone who has a pending patch that implements a new feature to commit
it, or ask to have it committed, ASAP.  If committing during July,
please discuss on emacs-devel first.

If you're aware of any languishing patch that ought to be included in
Emacs 24, please point it out.  Thanks.

Re: Reminder about feature freeze

[Juanma Barranquero]

On Tue, Jun 28, 2011 at 17:12, Chong Yidong <cyd@stupidchicken.com> wrote:

> In order to ensure a smooth transition to the pretest, I encourage
> everyone who has a pending patch that implements a new feature to commit
> it, or ask to have it committed, ASAP.  If committing during July,
> please discuss on emacs-devel first.

I'm currently rewritting emacs-lock.el to make it cleaner and add some
features inspired by Noah Friedman's protbuf.el; in particular, I want
it to separate the two kind of lockings it conflates: locking against
Emacs exiting, and locking against killing the buffer. (There will be
one interface, `emacs-lock-mode', but you will be able to ask for
either behavior or both, with a customizable default).

The issue was briefly discussed long ago (there's a thread "emacs-lock
enhancements" from 2009-09-22). I procratinated a bit ;-) and the
sudden pretest announcement took me a bit by surprise.

I expect to have a version ready to show and discuss in the next few
days. In any case, the impact of my changes is minimal, affecting only
emacs-lock.el, which does not seem to be a very used package at all.

    Juanma

Re: Reminder about feature freeze

[Deniz Dogan]

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

On 2011-06-28 17:12, Chong Yidong wrote:
> Just a reminder: the pretest is scheduled for late July, as discussed at
> http://lists.gnu.org/archive/html/emacs-devel/2011-05/msg00953.html.
>
> In order to ensure a smooth transition to the pretest, I encourage
> everyone who has a pending patch that implements a new feature to commit
> it, or ask to have it committed, ASAP.  If committing during July,
> please discuss on emacs-devel first.
>
> If you're aware of any languishing patch that ought to be included in
> Emacs 24, please point it out.  Thanks.
>

I have a pending patch (attached) from Andreas Rottman which I have yet 
to deal with.  He has signed the FSF papers and I guess that means that 
his patch should be fine to merge to trunk.

The patch adds support to rcirc for connecting to the same server on 
different ports, e.g. localhost:6667 and localhost:7000.  I am not sure 
I have time to test the patch properly before July so if anyone is 
willing to do so, feel free.

Thanks,
Deniz


[-- Attachment #2: rcirc-multiport.diff --]
[-- Type: text/plain, Size: 2236 bytes --]

From: Andreas Rottmann <a.rottmann@gmx.at>
Subject: Allow multiple rcirc connections to the same host

* lisp/net/rcirc.el (rcirc): When collecting the already-connected
  servers list, consider both hostname and port, instead of hostname
  only.  Also take the port into account on the messages displayed.
  (rcirc-connect): Include port number in "Connecting to" message.

---
 lisp/net/rcirc.el |   17 ++++++++---------
 1 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/lisp/net/rcirc.el b/lisp/net/rcirc.el
index f7f5f61..14b020a 100644
--- a/lisp/net/rcirc.el
+++ b/lisp/net/rcirc.el
@@ -473,20 +473,19 @@ If ARG is non-nil, instead prompt for connection parameters."
               (password (plist-get (cdr c) :password))
               (encryption (plist-get (cdr c) :encryption)))
 	  (when server
-	    (let (connected)
+	    (let ((contact (list server port))
+		  connected)
 	      (dolist (p (rcirc-process-list))
-		(when (string= server (process-name p))
+		(when (equal contact (process-contact p))
 		  (setq connected p)))
 	      (if (not connected)
 		  (condition-case e
 		      (rcirc-connect server port nick user-name
 				     full-name channels password encryption)
-		    (quit (message "Quit connecting to %s" server)))
-		(with-current-buffer (process-buffer connected)
-		  (setq connected-servers
-			(cons (process-contact (get-buffer-process
-						(current-buffer)) :host)
-			      connected-servers))))))))
+		    (quit (message "Quit connecting to %s:%d" server port)))
+		(setq connected-servers
+		      (cons (format "%s:%d" (car contact) (cadr contact))
+			    connected-servers)))))))
       (when connected-servers
 	(message "Already connected to %s"
 		 (if (cdr connected-servers)
@@ -515,7 +514,7 @@ If ARG is non-nil, instead prompt for connection parameters."
 (defun rcirc-connect (server &optional port nick user-name
                              full-name startup-channels password encryption)
   (save-excursion
-    (message "Connecting to %s..." server)
+    (message "Connecting to %s:%s..." server port)
     (let* ((inhibit-eol-conversion)
            (port-number (if port
 			    (if (stringp port)
-- 
tg: (b67be85..) t/rcirc-multiport (depends on: master)

Re: Reminder about feature freeze

[Glenn Morris]

Deniz Dogan wrote:

> I have a pending patch (attached) from Andreas Rottman which I have
> yet to deal with.  He has signed the FSF papers and I guess that means
> that his patch should be fine to merge to trunk.

Assuming he wrote it before June 1 (I imagine so), then yes (from a
legal point of view):

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5864#34

Re: Reminder about feature freeze

[Juanma Barranquero]

Here is my rewrite of emacs-lock.el. For simplicity, I'll refer to the
old code as old.el.

emacs-lock.el is a complete rewrite of old.el; according to my file
compare utility, there are about four matching non-comment lines, and
they include a compatibility defun and a (interactive) declaration. I
have added a back-compatible toggle-emacs-lock function and an alias
for the variable emacs-lock-from-exiting, but I haven't tried to be
100% compatible with old.el. The variable and the toggle function
together make most of the "public" interface of old.el, so it should
be enough for most users. In any case, I think old.el should be moved
to obsolete/ as old-emacs-lock.el, like we did with old-whitespace.el,
in case any user really wants to use the old code for whatever reason.

Features and differences between emacs-lock.el and old.el:

- emacs-lock-mode is now a minor mode.

- old.el special-cased telnet-mode and shell-mode, so buffers in these
modes could be "auto-unlocked" in case their inferior processes were
dead. I've added an alist where other modes can be added. The default
value, for compatibility with old.el, includes just these two modes.
This is limited to buffers with inferior processes; other buffers
cannot be auto-unlocked (it does not make much sense anyway).

- old.el used process sentinels and mode hooks to implement
auto-unlocking, which was IMO fragile (no thought was given to the
fact that a process can have just one sentinel, for example). I've
opted for the more simple method of marking the candidate buffers, and
checking that there are no live processes at the moment of killing or
exiting. It seems to work OK, thought it's possible that some
combination of user actions could make it fail. Time (and bug reports)
will tell.

- By default, emacs-lock-mode locks the buffer against exiting Emacs
and killing the buffer. That was old.el's behavior. However, if called
programmatically it is possible to request only one of these kinds of
lockings. Interactively, C-u M-x emacs-lock-mode can be used to select
the preferred locking mode. M-x emacs-lock-mode toggles the mode,
defaulting to `emacs-lock-default-locking-mode' the first time, and to
the most recently selected locking mode afterwards.

- emacs-lock.el is now unloadable.

- running emacs-lock in noninteractive mode should be a noop (the
relevant hooks are not set). Seems most logical, but I won't be
surprised if I'm proven wrong.

I think that's all. Hope I'm not late for the pretest ;-)

  Juanma




;;; emacs-lock.el --- protect buffers against killing or exiting -*-
lexical-binding: t -*-

;; Copyright (C) 2011 Free Software Foundation, Inc

;; Author: Juanma Barranquero <lekktu@gmail.com>
;; Inspired by emacs-lock.el by Tom Wurgler <twurgler@goodyear.com>
;; Maintainer: FSF
;; Keywords: extensions, processes

;; 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 <http://www.gnu.org/licenses/>.

;;; Commentary:

;; This package defines a minor mode Emacs Lock to mark a buffer as
;; protected against accidental killing, or exiting Emacs, or both.
;; Buffers associated with inferior modes, like shell or telnet, can
;; be treated specially, by auto-unlocking them if their interior
;; processes are dead.

;;; Code:

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

(defgroup emacs-lock nil
  "Emacs-lock mode."
  :version "24.1"
  :group 'convencience)

(defcustom emacs-lock-default-locking-mode 'all
  "Default locking mode of Emacs-Locked buffers.
Its value is used as default for `emacs-lock-mode' (which see)
the first time that Emacs Lock mode is turned on in a buffer
without passing an explicit locking mode."
  :type '(choice
          (const :tag "Do not allow Emacs to exit" exit)
          (const :tag "Do not allow killing the buffer" kill)
          (const :tag "Do not allow killing the buffer or exiting Emacs" all)
          (const :tag "Do not lock the buffer" nil))
  :group 'emacs-lock
  :version "24.1")

;; Note: as auto-unlocking can lead to data loss, it would be better
;; to default to nil; but the value below is for compatibility with
;; the old emacs-lock.el.
(defcustom emacs-lock-unlockable-modes '((shell-mode . all)
                                         (telnet-mode . all))
  "Alist of auto-unlockable modes.
Each element is a pair (MAJOR-MODE . ACTION), where ACTION is
one of `kill', `exit' or `all'.  Buffers with matching major
modes are auto-unlocked for the specific action if their
inferior processes are not alive.  If this variable is t, all
buffers associated to inferior processes are auto-unlockable
for both actions (NOT RECOMMENDED)."
  :type '(choice
          (const :tag "All buffers with inferior processes" t)
          (repeat :tag "Selected modes"
           (cons :tag "Set auto-unlock for"
            (symbol :tag "Major mode")
            (radio
             (const :tag "Allow exiting" exit)
             (const :tag "Allow killing" kill)
             (const :tag "Allow both" all)))))
  :group 'emacs-lock
  :version "24.1")

(defvar emacs-lock-mode nil
  "If non-nil, the current buffer is locked.
It can be one of the following values:
 exit   -- Emacs cannot exit while the buffer is locked
 kill   -- the buffer cannot be killed, but Emacs can exit as usual
 all    -- the buffer is locked against both actions
 nil    -- the buffer is not locked")
(make-variable-buffer-local 'emacs-lock-mode)
(put 'emacs-lock-mode 'permanent-local t)

(defvar emacs-lock--old-mode nil
  "Most recent locking mode set on the buffer.
Internal use only.")
(make-variable-buffer-local 'emacs-lock--old-mode)
(put 'emacs-lock--old-mode 'permanent-local t)

(defvar emacs-lock--try-unlocking nil
  "Non-nil if current buffer should be checked for auto-unlocking.
Internal use only.")
(make-variable-buffer-local 'emacs-lock--try-unlocking)
(put 'emacs-lock--try-unlocking 'permanent-local t)

(defun emacs-lock-live-process-p (buffer-or-name)
  "Return t if BUFFER-OR-NAME is associated with a live process."
  (let ((proc (get-buffer-process buffer-or-name)))
    (and proc (process-live-p proc))))

(defun emacs-lock--can-auto-unlock (action)
  "Return t if the current buffer can auto-unlock for ACTION.
ACTION must be one of `kill' or `exit'.
See `emacs-lock-unlockable-modes'."
  (and emacs-lock--try-unlocking
       (not (emacs-lock-live-process-p (current-buffer)))
       (or (eq emacs-lock-unlockable-modes t)
           (let ((unlock (cdr (assq major-mode emacs-lock-unlockable-modes))))
             (or (eq unlock 'all) (eq unlock action))))))

(defun emacs-lock--exit-locked-buffer ()
  "Return the name of the first exit-locked buffer found."
  (save-current-buffer
    (catch :found
      (dolist (buffer (buffer-list))
        (set-buffer buffer)
        (unless (or (emacs-lock--can-auto-unlock 'exit)
                    (memq emacs-lock-mode '(nil kill)))
          (throw :found (buffer-name))))
      nil)))

(defun emacs-lock--kill-emacs-hook ()
  "Signal an error if any buffer is exit-locked.
Used from `kill-emacs-hook' (which see)."
  (let ((buffer-name (emacs-lock--exit-locked-buffer)))
    (when buffer-name
      (error "Emacs cannot exit because buffer %S is locked" buffer-name))))

(defun emacs-lock--kill-emacs-query-functions ()
  "Display a message if any buffer is exit-locked.
Returns a value appropriate for `kill-emacs-query-functions' (which see)."
  (let ((locked (emacs-lock--exit-locked-buffer)))
    (or (not locked)
        (progn
          (message "Emacs cannot exit because buffer %S is locked" locked)
          nil))))

(defun emacs-lock--kill-buffer-query-functions ()
  "Display a message if the current buffer is kill-locked.
Returns a value appropriate for `kill-buffer-query-functions' (which see)."
  (or (emacs-lock--can-auto-unlock 'kill)
      (memq emacs-lock-mode '(nil exit))
      (progn
        (message "Buffer %S is locked and cannot be killed" (buffer-name))
        nil)))

(defun emacs-lock--set-mode (mode arg)
  "Setter function for `emacs-lock-mode'."
  (setq emacs-lock-mode
        (cond ((memq arg '(all exit kill))
               ;; explicit locking mode arg, use it
               arg)
              ((equal current-prefix-arg '(4))
               ;; called with C-u M-x emacs-lock-mode, so ask the user
               (intern (completing-read "Locking mode: "
                                        '("all" "exit" "kill")
                                        nil t nil nil
                                        (symbol-name
                                         emacs-lock-default-locking-mode))))
              ((eq mode t)
               ;; turn on, so use previous setting, or customized default
               (or emacs-lock--old-mode emacs-lock-default-locking-mode))
              (t
               ;; anything else (turn off)
               mode))))

;;;###autoload
(define-minor-mode emacs-lock-mode
    "Toggle Emacs Lock mode in the current buffer.

With \\[universal-argument], ask for the locking mode to be used.
With other prefix ARG, turn mode on if ARG is positive, off otherwise.

Initially, if the user does not pass an explicit locking mode, it defaults
to `emacs-lock-default-locking-mode' (which see); afterwards, the locking
mode most recently set on the buffer is used instead.

When called from Elisp code, ARG can be any locking mode:

 exit   -- Emacs cannot exit while the buffer is locked
 kill   -- the buffer cannot be killed, but Emacs can exit as usual
 all    -- the buffer is locked against both actions

Other values are interpreted as usual."
  :init-value nil
  :lighter (""
            (emacs-lock--try-unlocking " l" " L")
            (:eval (format "ocked:%s" emacs-lock-mode)))
  :group 'emacs-lock
  :variable (emacs-lock-mode .
                             (lambda (mode)
                               (emacs-lock--set-mode mode arg)))
  (when emacs-lock-mode
    (setq emacs-lock--old-mode emacs-lock-mode)
    (setq emacs-lock--try-unlocking
          (or (and (eq emacs-lock-unlockable-modes t)
                   (emacs-lock-live-process-p (current-buffer)))
              (assq major-mode emacs-lock-unlockable-modes)))))

(unless noninteractive
  (add-hook 'kill-buffer-query-functions
'emacs-lock--kill-buffer-query-functions)
  ;; We set a hook in both kill-emacs-hook and
kill-emacs-query-functions because
  ;; we really want to use k-e-q-f to stop as soon as possible, but
don't want to
  ;; be caught by surprise if someone calls `kill-emacs' instead.
  (add-hook 'kill-emacs-hook 'emacs-lock--kill-emacs-hook)
  (add-hook 'kill-emacs-query-functions
'emacs-lock--kill-emacs-query-functions))

(defun emacs-lock-unload-function ()
  "Unload the Emacs Lock library."
  (catch :continue
    (dolist (buffer (buffer-list))
      (set-buffer buffer)
      (when emacs-lock-mode
        (if (y-or-n-p (format "Buffer %S is locked, unlock it? " (buffer-name)))
            (emacs-lock-mode -1)
          (message "Unloading of feature `emacs-lock' aborted.")
          (throw :continue t))))
    ;; continue standard unloading
    nil))

;;; Compatibility

(define-obsolete-variable-alias 'emacs-lock-from-exiting
'emacs-lock-mode "24.1")

(defun toggle-emacs-lock ()
  "Toggle `emacs-lock-from-exiting' for the current buffer."
  (interactive)
  (call-interactively 'emacs-lock-mode))
(make-obsolete 'toggle-emacs-lock 'emacs-lock-mode "24.1")

(provide 'emacs-lock)

;;; emacs-lock.el ends here

Re: Reminder about feature freeze

[Chong Yidong]

Juanma Barranquero <lekktu@gmail.com> writes:

> In any case, I think old.el should be moved to obsolete/ as
> old-emacs-lock.el, like we did with old-whitespace.el, in case any
> user really wants to use the old code for whatever reason.

OK.  (OT: though personally I'm not a big fan of the obsolete/
directory; in this day and age, it's trivial to find old library
versions without including them in the distribution.  We ought to think
about deleting some of the really obsolete stuff from there.)

> I think that's all. Hope I'm not late for the pretest ;-)

Not at all.  I looked through the code, and found no problems, though I
have not tested it.  Some minor comments are below.  Feel free to wait a
few days for others to weigh in; don't feel compelled to commit before
the end of the month.  Please include a NEWS entry.


> (defgroup emacs-lock nil
>   "Emacs-lock mode."
>   :version "24.1"
>   :group 'convencience)

Typo in "convenience".

> (defcustom emacs-lock-default-locking-mode 'all
>   "Default locking mode of Emacs-Locked buffers.
> Its value is used as default for `emacs-lock-mode' (which see)
                      ^ the
> the first time that Emacs Lock mode is turned on in a buffer
> without passing an explicit locking mode."

It would be better to document the meanings of `exit', `kill', etc. here
as well, even if it's a duplicate of the information in the docstring of
`emacs-lock-mode', so that users browsing the Customize group have the
information right in front of them.

> (defun emacs-lock--kill-emacs-query-functions ()
>   "Display a message if any buffer is exit-locked.
> Returns a value appropriate for `kill-emacs-query-functions' (which see)."

"Returns" should be "return".

Re: Reminder about feature freeze

[Juanma Barranquero]

On Thu, Jun 30, 2011 at 17:50, Chong Yidong <cyd@stupidchicken.com> wrote:

> OK.  (OT: though personally I'm not a big fan of the obsolete/
> directory; in this day and age, it's trivial to find old library
> versions without including them in the distribution.

I'm no fan either, but I think we don't want to inconvenience users if
we just obsoleted some package. Really old stuff should be removed, as
you suggest:

>  We ought to think
> about deleting some of the really obsolete stuff from there.)

and in fact Glenn has done it already (rnews.el, rnewspost.el,
x-menu.el, sc.el, for example).

Of the remaining, awk-mode, fast-lock, iso-acc, iso-insert, iso-swed,
keyswap, lazy-lock, options, scribe and swedish were all obsoleted in
22.1, released on 2007-06-02. That's four years and five releases ago.

> I looked through the code, and found no problems, though I
> have not tested it.

Well, I just found a minor bug with handling of C-u M-x
emacs-lock-mode, and I've fixed it in my copy. :-)

>  Some minor comments are below.  Feel free to wait a
> few days for others to weigh in; don't feel compelled to commit before
> the end of the month.

OK.

>  Please include a NEWS entry.

Yes, sure, and ChangeLog entries. I just didn't wanna write them
before knowing whether the package will be accepted ;-)

> Typo in "convenience".

Fixed.

>> Its value is used as default for `emacs-lock-mode' (which see)
>                      ^ the

Fixed.

> It would be better to document the meanings of `exit', `kill', etc. here
> as well, even if it's a duplicate of the information in the docstring of
> `emacs-lock-mode', so that users browsing the Customize group have the
> information right in front of them.

Done.

>> (defun emacs-lock--kill-emacs-query-functions ()
>>   "Display a message if any buffer is exit-locked.
>> Returns a value appropriate for `kill-emacs-query-functions' (which see)."
>
> "Returns" should be "return".

That's puzzling. In most docstrings I've seen, the first line uses
imperative, but the rest no. In fact, there are > 650 uses of
"Returns" in lisp/**/*.el.

But fixed anyway.

Thanks for you comments.

    Juanma

Re: Reminder about feature freeze

[Bastien]

Hi Chong,

Chong Yidong <cyd@stupidchicken.com> writes:

> Just a reminder: the pretest is scheduled for late July, as discussed at
> http://lists.gnu.org/archive/html/emacs-devel/2011-05/msg00953.html.
>
> In order to ensure a smooth transition to the pretest, I encourage
> everyone who has a pending patch that implements a new feature to commit
> it, or ask to have it committed, ASAP.  If committing during July,
> please discuss on emacs-devel first.

The Org team is working hard to release version 7.6.

If things go well, I will release it on sunday, then take another day 
to put this version (or 7.6.1 with small last minutes fixes) to Emacs
pretest.  

Let me know if that fits your agenda for the Emacs pretest release.

-- 
 Bastien

Re: Reminder about feature freeze

[Bastien]

Chong Yidong <cyd@stupidchicken.com> writes:

> In order to ensure a smooth transition to the pretest, I encourage
> everyone who has a pending patch that implements a new feature to commit
> it, or ask to have it committed, ASAP.

I'd like to submit to set of features for inclusion:

http://lumiere.ens.fr/~guerry/u/windresize.el

  A set of function to dynamically resize windows.
  I submitted this library long ago and thanks to Drew
  and RMS, I updated it to make it simple enough.

http://lumiere.ens.fr/~guerry/u/register-list.el

  A set of functions to display a list of registers and to 
  edit them -- this includes easy editing of rectangles.

  Maybe a simple version of this functions could be merged
  in register.el

Let me know if those libraries are of interest for Emacs.

-- 
 Bastien

Re: Reminder about feature freeze

[Chong Yidong]

Bastien <bzg@altern.org> writes:

> The Org team is working hard to release version 7.6.
>
> If things go well, I will release it on sunday, then take another day
> to put this version (or 7.6.1 with small last minutes fixes) to Emacs
> pretest.
>
> Let me know if that fits your agenda for the Emacs pretest release.

Yes, that will be great.  Thanks.

Re: Reminder about feature freeze

[Stefan Monnier]

> http://lumiere.ens.fr/~guerry/u/windresize.el

>   A set of function to dynamically resize windows.
>   I submitted this library long ago and thanks to Drew
>   and RMS, I updated it to make it simple enough.

Let's add it to GNU ELPA.

> http://lumiere.ens.fr/~guerry/u/register-list.el

>   A set of functions to display a list of registers and to 
>   edit them -- this includes easy editing of rectangles.

>   Maybe a simple version of this functions could be merged
>   in register.el

I guess adding it to register.el would be best, but given the time
frame, maybe better install register-list.el in GNU ELPA for now and
prepare a patch to register.el for 24.2.


        Stefan

Re: Reminder about feature freeze

[Stefan Monnier]

>> Just a reminder: the pretest is scheduled for late July, as discussed at
>> http://lists.gnu.org/archive/html/emacs-devel/2011-05/msg00953.html.
>> 
>> In order to ensure a smooth transition to the pretest, I encourage
>> everyone who has a pending patch that implements a new feature to commit
>> it, or ask to have it committed, ASAP.  If committing during July,
>> please discuss on emacs-devel first.

> The Org team is working hard to release version 7.6.

> If things go well, I will release it on sunday, then take another day 
> to put this version (or 7.6.1 with small last minutes fixes) to Emacs
> pretest.  
> Let me know if that fits your agenda for the Emacs pretest release.

Yes, that's fine.  Subsequent revisions will need to wait, tho.


        Stefan

Re: Reminder about feature freeze

[Jason Rumney]

Chong Yidong <cyd@stupidchicken.com> writes:

> OK.  (OT: though personally I'm not a big fan of the obsolete/
> directory; in this day and age, it's trivial to find old library
> versions without including them in the distribution.  We ought to think
> about deleting some of the really obsolete stuff from there.)

Maybe we should turn the obsolete directory into EOLPA (in the next version).

Re: Reminder about feature freeze

[Stefan Monnier]

>> OK.  (OT: though personally I'm not a big fan of the obsolete/
>> directory; in this day and age, it's trivial to find old library
>> versions without including them in the distribution.  We ought to think
>> about deleting some of the really obsolete stuff from there.)

> Maybe we should turn the obsolete directory into EOLPA (in the next version).

Good plan.


        Stefan

Re: Reminder about feature freeze

[Bastien]

Hi Stefan,

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Yes, that's fine.  Subsequent revisions will need to wait, tho.

Okay -- I've some compiler warning I'm not sure how to silent:

,----
| In org-switch-to-buffer-other-window:
| org.el:19041:23:Warning: `special-display-function' is an obsolete variable
|     (as of Emacs 24.1); use 2nd arg of `display-buffer' instead.
| org.el:19040:52:Warning: `special-display-regexps' is an obsolete variable (as
|     of Emacs 24.1); use 2nd arg of `display-buffer' instead.
| org.el:19040:23:Warning: `special-display-buffer-names' is an obsolete
|     variable (as of Emacs 24.1); use 2nd arg of `display-buffer' instead.
| org.el:19040:9:Warning: `pop-up-frames' is an obsolete variable (as of Emacs
|     24.1); use 2nd arg of `display-buffer' instead.
| Wrote /home/guerry/install/git/org-mode/lisp/org.elc
| emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))" -f batch-byte-compile lisp/org-agenda.el
`----

I don't know how to replace the variables by "the 2nd arg of
display-buffer".  Any hint?

Or maybe I can just ignore those warning for the time being 
and fix them between the pretest and the release?

Thanks,

-- 
 Bastien

Re: Reminder about feature freeze

[Bastien]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> http://lumiere.ens.fr/~guerry/u/windresize.el
>
>>   A set of function to dynamically resize windows.
>>   I submitted this library long ago and thanks to Drew
>>   and RMS, I updated it to make it simple enough.
>
> Let's add it to GNU ELPA.

http://elpa.gnu.org/ is a bit rough in terms of instructions 
on how to add something to GNU ELPA.

Shall I follow instructions from http://tromey.com/elpa/ for
the time being?

Or is there an bazaar branch I should commit things into?

Basic instructions would help here. 

>> http://lumiere.ens.fr/~guerry/u/register-list.el
>
>>   A set of functions to display a list of registers and to 
>>   edit them -- this includes easy editing of rectangles.
>
>>   Maybe a simple version of this functions could be merged
>>   in register.el
>
> I guess adding it to register.el would be best, but given the time
> frame, maybe better install register-list.el in GNU ELPA for now and
> prepare a patch to register.el for 24.2.

Okay, great.

Thanks in advance for quick instructions about ELPA.

-- 
 Bastien

Re: Reminder about feature freeze

[martin rudalics]

 > ,----
 > | In org-switch-to-buffer-other-window:
 > | org.el:19041:23:Warning: `special-display-function' is an obsolete variable
 > |     (as of Emacs 24.1); use 2nd arg of `display-buffer' instead.
 > | org.el:19040:52:Warning: `special-display-regexps' is an obsolete variable (as
 > |     of Emacs 24.1); use 2nd arg of `display-buffer' instead.
 > | org.el:19040:23:Warning: `special-display-buffer-names' is an obsolete
 > |     variable (as of Emacs 24.1); use 2nd arg of `display-buffer' instead.
 > | org.el:19040:9:Warning: `pop-up-frames' is an obsolete variable (as of Emacs
 > |     24.1); use 2nd arg of `display-buffer' instead.
 > | Wrote /home/guerry/install/git/org-mode/lisp/org.elc
 > | emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))" -f batch-byte-compile lisp/org-agenda.el
 > `----
 >
 > I don't know how to replace the variables by "the 2nd arg of
 > display-buffer".  Any hint?
 >
 > Or maybe I can just ignore those warning for the time being
 > and fix them between the pretest and the release?

I silenced these warnings a couple of days ago.  Are you sure this is
with a recent version of trunk?  Do they go away when you recompile
window.el before compiling org.el?

martin

Re: Reminder about feature freeze

[Chong Yidong]

Bastien <bzg@altern.org> writes:

> http://elpa.gnu.org/ is a bit rough in terms of instructions
> on how to add something to GNU ELPA.
>
> Shall I follow instructions from http://tromey.com/elpa/ for
> the time being?
>
> Or is there an bazaar branch I should commit things into?
>
> Basic instructions would help here.

You want to install the code into the elpa branch.  For detailed
instructions on checking out the elpa branch, see admin/notes/bugtracker
in the Emacs repository.  For instructions on how to make an elpa-style
package, see the Packaging node in the Elisp manual.

I will add a copy of the branch instructions to the webpage at
elpa.gnu.org; thanks for the pointer.

Re: Reminder about feature freeze

[Stefan Monnier]

> Or is there an bazaar branch I should commit things into?

Yup, there's the `elpa' branch in Emacs's Bzr repository for that.
Check the README as well as the ELPA documentation in the Emacs
Lisp manual.


        Stefan

Re: Reminder about feature freeze

[Richard Stallman]

    http://elpa.gnu.org/ is a bit rough in terms of instructions 
    on how to add something to GNU ELPA.

That host name will encourage lots of people to call it "elpa",
and that will cause the confusion I commented on before.


-- 
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: Reminder about feature freeze

[Richard Stallman]

    Yup, there's the `elpa' branch in Emacs's Bzr repository for that.
    Check the README as well as the ELPA documentation in the Emacs
    Lisp manual.

Does `elpa' here refer to Tom's collection of packages
which is called `elpa'?

-- 
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: Reminder about feature freeze

[Bastien]

Chong Yidong <cyd@stupidchicken.com> writes:

> Bastien <bzg@altern.org> writes:
>
>> http://elpa.gnu.org/ is a bit rough in terms of instructions
>> on how to add something to GNU ELPA.
>>
>> Shall I follow instructions from http://tromey.com/elpa/ for
>> the time being?
>>
>> Or is there an bazaar branch I should commit things into?
>>
>> Basic instructions would help here.
>
> You want to install the code into the elpa branch.  For detailed
> instructions on checking out the elpa branch, see admin/notes/bugtracker
> in the Emacs repository.  For instructions on how to make an elpa-style
> package, see the Packaging node in the Elisp manual.

Thanks to you and Stefan for the instructions.

I will take care of this.

-- 
 Bastien

Re: Reminder about feature freeze

[Bastien]

Hi Martin,

martin rudalics <rudalics@gmx.at> writes:

>> ,----
>> | In org-switch-to-buffer-other-window:
>> | org.el:19041:23:Warning: `special-display-function' is an obsolete variable
>> |     (as of Emacs 24.1); use 2nd arg of `display-buffer' instead.
>> | org.el:19040:52:Warning: `special-display-regexps' is an obsolete variable (as
>> |     of Emacs 24.1); use 2nd arg of `display-buffer' instead.
>> | org.el:19040:23:Warning: `special-display-buffer-names' is an obsolete
>> |     variable (as of Emacs 24.1); use 2nd arg of `display-buffer' instead.
>> | org.el:19040:9:Warning: `pop-up-frames' is an obsolete variable (as of Emacs
>> |     24.1); use 2nd arg of `display-buffer' instead.
>> | Wrote /home/guerry/install/git/org-mode/lisp/org.elc
>> | emacs -batch -q -no-site-file -eval "(setq load-path (cons
>> | (expand-file-name \"./lisp/\") (cons
>> | \"/usr/local/share/emacs/site-lisp\" load-path)))" -f
>> | batch-byte-compile lisp/org-agenda.el
>> `----
>>
>> I don't know how to replace the variables by "the 2nd arg of
>> display-buffer".  Any hint?
>>
>> Or maybe I can just ignore those warning for the time being
>> and fix them between the pretest and the release?
>
> I silenced these warnings a couple of days ago.  

Yes, on July 1st.

> Are you sure this is with a recent version of trunk?

The warnings correctly disappear with a recent build.

Thanks for this!

-- 
 Bastien

Re: Reminder about feature freeze

[Andrey Paramonov]

 > That host name will encourage lots of people to call it "elpa",
 > and that will cause the confusion I commented on before.

People do not confuse
mail.yandex.ru and mail.google.com

Why will they confuse
tromey.com/elpa and elpa.gnu.org ?

Best wishes,
Andrey Paramonov

Re: Reminder about feature freeze

[Bastien]

Hi Andrey,

Andrey Paramonov <paramon@acdlabs.ru> writes:

>> That host name will encourage lots of people to call it "elpa",
>> and that will cause the confusion I commented on before.
>
> People do not confuse
> mail.yandex.ru and mail.google.com

Because the most important part of the URLs here are "yandex" 
and "google".

> Why will they confuse
> tromey.com/elpa and elpa.gnu.org ?

Perhaps because the most significant part of the URLs here are 
"ELPA" in both cases.

My 2 cents,

-- 
 Bastien

Re: Reminder about feature freeze

[Tassilo Horn]

Andrey Paramonov <paramon@acdlabs.ru> writes:

>> That host name will encourage lots of people to call it "elpa",
>> and that will cause the confusion I commented on before.
>
> People do not confuse
> mail.yandex.ru and mail.google.com
>
> Why will they confuse
> tromey.com/elpa and elpa.gnu.org ?

Because in conversations people say that package X is available from
ELPA without mentioning if it's the official GNU ELPA, or Tom's ELPA
repository, or the marmalade ELPA repository where Phil hosts his
clojure stuff, or even another one.

Bye,
Tassilo

Re: Reminder about feature freeze

[Richard Stallman]

    Why will they confuse
    tromey.com/elpa and elpa.gnu.org ?

If people see those two names in one message, I think they will
recognize they are different.  But when people see "elpa.gnu.org" in
one message, and "ELPA" in a second message, they are likely to guess
that these are the same thing.



-- 
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: Reminder about feature freeze

[Richard Riley]

Andrey Paramonov <paramon@acdlabs.ru> writes:

>> That host name will encourage lots of people to call it "elpa",
>> and that will cause the confusion I commented on before.
>
> People do not confuse
> mail.yandex.ru and mail.google.com
>
> Why will they confuse
> tromey.com/elpa and elpa.gnu.org ?
>
> Best wishes,
> Andrey Paramonov
>

Because "elpa" is a term given to a library management feature. It is
obviously going to confuse people.

Re: Reminder about feature freeze

[Bastien]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> http://lumiere.ens.fr/~guerry/u/windresize.el
>
>>   A set of function to dynamically resize windows.
>>   I submitted this library long ago and thanks to Drew
>>   and RMS, I updated it to make it simple enough.
>
> Let's add it to GNU ELPA.

FWIW, There seems to be a problem right now with gnu.org and
savannah.gnu.org:

,----
| ssh: connect to host bzr.savannah.gnu.org port 22: No route to host
| bzr: ERROR: Connection closed: Unexpected end of message. Please check
| connectivity and permissions, and report a bug if problems persist. 
`----

-- 
 Bastien

Re: Reminder about feature freeze

[Glenn Morris]

Not sure what this has to do with the subject, but always check

http://identi.ca/group/fsfstatus

when you have issues with gnu services.

 "network outage for *.fsf.org and *.gnu.org due to planned router maintenance"

Re: Reminder about feature freeze

[Bastien]

Hi Glenn,

Glenn Morris <rgm@gnu.org> writes:

> Not sure what this has to do with the subject, but always check
>
> http://identi.ca/group/fsfstatus
>
> when you have issues with gnu services.

Thanks for the tip.

-- 
 Bastien

Re: Reminder about feature freeze

[Bastien]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> http://lumiere.ens.fr/~guerry/u/windresize.el
>
>>   A set of function to dynamically resize windows.
>>   I submitted this library long ago and thanks to Drew
>>   and RMS, I updated it to make it simple enough.
>
> Let's add it to GNU ELPA.

Done.

>> http://lumiere.ens.fr/~guerry/u/register-list.el
>
>>   A set of functions to display a list of registers and to 
>>   edit them -- this includes easy editing of rectangles.
>
>>   Maybe a simple version of this functions could be merged
>>   in register.el
>
> I guess adding it to register.el would be best, but given the time
> frame, maybe better install register-list.el in GNU ELPA for now

Done.

Thanks,

-- 
 Bastien

Re: Reminder about feature freeze

[Lars Magne Ingebrigtsen]

Glenn Morris <rgm@gnu.org> writes:

> Not sure what this has to do with the subject, but always check
>
> http://identi.ca/group/fsfstatus
>
> when you have issues with gnu services.
>
>  "network outage for *.fsf.org and *.gnu.org due to planned router maintenance"

I've now added the fsfstatus feed to Gwene, so you can point your news
reader to news.gwene.org and read the gwene.ca.identi.fsfstatus news
group to keep updated.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Reminder about feature freeze

[Deniz Dogan]

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

On 2011-06-28 17:12, Chong Yidong wrote:
> Just a reminder: the pretest is scheduled for late July, as discussed at
> http://lists.gnu.org/archive/html/emacs-devel/2011-05/msg00953.html.
>
> In order to ensure a smooth transition to the pretest, I encourage
> everyone who has a pending patch that implements a new feature to commit
> it, or ask to have it committed, ASAP.  If committing during July,
> please discuss on emacs-devel first.
>
> If you're aware of any languishing patch that ought to be included in
> Emacs 24, please point it out.  Thanks.
>

So as I understand it we are now in the feature freeze.  I have a minor 
addition (feature) for rcirc that I'd like to push.  It adds the option 
to fill according to window width or a user's custom function.  See the 
attachment.

Is it okay to push this to trunk?

Deniz Dogan

[-- Attachment #2: rcirc-window-width.patch --]
[-- Type: text/plain, Size: 1306 bytes --]

=== modified file 'lisp/net/rcirc.el'
--- lisp/net/rcirc.el	2011-08-04 00:58:07 +0000
+++ lisp/net/rcirc.el	2011-08-17 13:43:29 +0000
@@ -149,7 +149,9 @@
 maximum frame width."
   :type '(choice (const :tag "Value of `fill-column'")
 		 (const :tag "Full frame width" frame-width)
-		 (integer :tag "Number of columns"))
+		 (const :tag "Full window width" window-width)
+		 (integer :tag "Number of columns")
+		 (function :tag "Return value of function" function))
   :group 'rcirc)
 
 (defcustom rcirc-fill-prefix nil
@@ -2421,13 +2423,16 @@
     (let ((fill-prefix
 	   (or rcirc-fill-prefix
 	       (make-string (- (point) (line-beginning-position)) ?\s)))
-	  (fill-column (- (cond ((eq rcirc-fill-column 'frame-width)
-				 (1- (frame-width)))
-				(rcirc-fill-column
-				 rcirc-fill-column)
-				(t fill-column))
-			  ;; make sure ... doesn't cause line wrapping
-			  3)))
+	  (fill-column
+	   (cond ((eq rcirc-fill-column 'frame-width)
+		  (1- (frame-width)))
+		 ((eq rcirc-fill-column 'window-width)
+		  (1- (window-width)))
+		 ((fboundp rcirc-fill-column) ; custom function
+		  (funcall rcirc-fill-column sender response))
+		 (rcirc-fill-column    	; fix integer value
+		  rcirc-fill-column)
+		 (t fill-column))))
       (fill-region (point) (point-max) nil t))))
 \f
 ;;; handlers

Re: Reminder about feature freeze

[Dimitri Fontaine]

Deniz Dogan <deniz@dogan.se> writes:
> So as I understand it we are now in the feature freeze.  I have a minor
> addition (feature) for rcirc that I'd like to push.  It adds the option to

Allow to jump on your thread here. I have fixes for rcirc WHOIS
handling, and it's short enough not to require papers AFAIUI.

(defun rcirc-handler-generic-whois (command process sender args text)
  "generic rcirc handler for WHOIS related commands"
  (let ((nick (cadr args))
	(mesg (mapconcat 'identity (cddr args) " ")))
    (with-current-buffer (rcirc-get-buffer-create process nick)
      (rcirc-print process sender command nick mesg))))

(defun rcirc-install-whois-handlers ()
  "Install rcirc-handler-XXX for WHOIS related protocol messages"
  (dolist (cmd '(311 312 313 317 318 319 330))
    (let ((name (intern (format "rcirc-handler-%d" cmd))))
      (fset name `(lambda (process sender args text)
		   (rcirc-handler-generic-whois
		    ,(number-to-string cmd) process sender args text))))))

Currently rcirc is able to print a whois whenever you open a query to a
user, but not when a user opens a query to you — that open a new buffer
but it's quite impossible to have WHOIS printed here.  I call it a bug.

Once those two functions are installed, patching rcirc so that is
actually pre-fill a new query buffer with WHOIS information for a new
query being targeted to its users should be easy.

Regards,
-- 
dim

Re: Reminder about feature freeze

[Chong Yidong]

Deniz Dogan <deniz@dogan.se> writes:

> So as I understand it we are now in the feature freeze.  I have a
> minor addition (feature) for rcirc that I'd like to push.  It adds the
> option to fill according to window width or a user's custom function.
> See the attachment.
>
> Is it okay to push this to trunk?

I'd rather not make an exception for this kind of thing.  Anyway,
filling to window width sounds like it will cause problems if the buffer
gets shown in a different window; using something like visual-line-mode
might be better.

Re: Reminder about feature freeze

[Chong Yidong]

Dimitri Fontaine <dim@tapoueh.org> writes:

> Allow to jump on your thread here. I have fixes for rcirc WHOIS
> handling, and it's short enough not to require papers AFAIUI.
>
> (defun rcirc-handler-generic-whois (command process sender args text)
>   "generic rcirc handler for WHOIS related commands"
>   (let ((nick (cadr args))
> 	(mesg (mapconcat 'identity (cddr args) " ")))
>     (with-current-buffer (rcirc-get-buffer-create process nick)
>       (rcirc-print process sender command nick mesg))))
>
> (defun rcirc-install-whois-handlers ()
>   "Install rcirc-handler-XXX for WHOIS related protocol messages"
>   (dolist (cmd '(311 312 313 317 318 319 330))
>     (let ((name (intern (format "rcirc-handler-%d" cmd))))
>       (fset name `(lambda (process sender args text)
> 		   (rcirc-handler-generic-whois
> 		    ,(number-to-string cmd) process sender args text))))))
>
> Currently rcirc is able to print a whois whenever you open a query to a
> user, but not when a user opens a query to you — that open a new buffer
> but it's quite impossible to have WHOIS printed here.  I call it a bug.

Yes, this qualifies as a bug.  If either rcirc maintainer (Ryan or
Deniz) agrees with this change, it can be committed.

Re: Reminder about feature freeze

[Deniz Dogan]

On 2011-08-20 21:12, Chong Yidong wrote:
> Deniz Dogan<deniz@dogan.se>  writes:
>
>> So as I understand it we are now in the feature freeze.  I have a
>> minor addition (feature) for rcirc that I'd like to push.  It adds the
>> option to fill according to window width or a user's custom function.
>> See the attachment.
>>
>> Is it okay to push this to trunk?
>
> I'd rather not make an exception for this kind of thing.  Anyway,
> filling to window width sounds like it will cause problems if the buffer
> gets shown in a different window; using something like visual-line-mode
> might be better.
>

Yes, you are right, but currently people have the option to fill to 
frame width in this imperfect manner, so I figured it would be even more 
useful to fill to the window width.

Anyways, got it!  Thanks.

Re: Reminder about feature freeze

[Dimitri Fontaine]

ping?

Chong Yidong <cyd@stupidchicken.com> writes:

> Dimitri Fontaine <dim@tapoueh.org> writes:
>
>> Allow to jump on your thread here. I have fixes for rcirc WHOIS
>> handling, and it's short enough not to require papers AFAIUI.
>>
>> (defun rcirc-handler-generic-whois (command process sender args text)
>>   "generic rcirc handler for WHOIS related commands"
>>   (let ((nick (cadr args))
>> 	(mesg (mapconcat 'identity (cddr args) " ")))
>>     (with-current-buffer (rcirc-get-buffer-create process nick)
>>       (rcirc-print process sender command nick mesg))))
>>
>> (defun rcirc-install-whois-handlers ()
>>   "Install rcirc-handler-XXX for WHOIS related protocol messages"
>>   (dolist (cmd '(311 312 313 317 318 319 330))
>>     (let ((name (intern (format "rcirc-handler-%d" cmd))))
>>       (fset name `(lambda (process sender args text)
>> 		   (rcirc-handler-generic-whois
>> 		    ,(number-to-string cmd) process sender args text))))))
>>
>> Currently rcirc is able to print a whois whenever you open a query to a
>> user, but not when a user opens a query to you — that open a new buffer
>> but it's quite impossible to have WHOIS printed here.  I call it a bug.
>
> Yes, this qualifies as a bug.  If either rcirc maintainer (Ryan or
> Deniz) agrees with this change, it can be committed.
>

-- 
dim

Re: Reminder about feature freeze

[Deniz Dogan]

On 2011-08-20 21:14, Chong Yidong wrote:
> Dimitri Fontaine<dim@tapoueh.org>  writes:
>
>> Allow to jump on your thread here. I have fixes for rcirc WHOIS
>> handling, and it's short enough not to require papers AFAIUI.
>>
>> (defun rcirc-handler-generic-whois (command process sender args text)
>>    "generic rcirc handler for WHOIS related commands"
>>    (let ((nick (cadr args))
>> 	(mesg (mapconcat 'identity (cddr args) " ")))
>>      (with-current-buffer (rcirc-get-buffer-create process nick)
>>        (rcirc-print process sender command nick mesg))))
>>
>> (defun rcirc-install-whois-handlers ()
>>    "Install rcirc-handler-XXX for WHOIS related protocol messages"
>>    (dolist (cmd '(311 312 313 317 318 319 330))
>>      (let ((name (intern (format "rcirc-handler-%d" cmd))))
>>        (fset name `(lambda (process sender args text)
>> 		   (rcirc-handler-generic-whois
>> 		    ,(number-to-string cmd) process sender args text))))))
>>
>> Currently rcirc is able to print a whois whenever you open a query to a
>> user, but not when a user opens a query to you — that open a new buffer
>> but it's quite impossible to have WHOIS printed here.  I call it a bug.
>
> Yes, this qualifies as a bug.  If either rcirc maintainer (Ryan or
> Deniz) agrees with this change, it can be committed.
>

I don't agree that it qualifies as a bug.  What Dimitri has provided is 
just added functionality.  There is nothing that says that IRC clients 
should behave in this manner.  If you still think it can be committed, 
let me know.

Re: Reminder about feature freeze

[Chong Yidong]

Deniz Dogan <deniz@dogan.se> writes:

> I don't agree that it qualifies as a bug.  What Dimitri has provided
> is just added functionality.  There is nothing that says that IRC
> clients should behave in this manner.

OK then.  I suggest filing a bug if there isn't already one, to ensure
that the patch does not get forgotten.