python.el cleanup

python.el cleanup

[Christoph Scholtes]

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

Find attached a patch to clean up the trunk's python.el in preparation
for merging in Fabian's new python mode.

Most of it (if not all) was added by Ken Manheimer's commits in revnos
84728 and 84779 when adding pdbtrack support, but as far as I can tell
none of it is really needed for pdbtrack. 

Christoph


[-- Attachment #2: Patch for python.el --]
[-- Type: text/x-patch, Size: 8718 bytes --]

=== modified file 'lisp/ChangeLog'
--- lisp/ChangeLog	2011-03-27 10:55:07 +0000
+++ lisp/ChangeLog	2011-03-29 02:20:59 +0000
@@ -1,3 +1,12 @@
+2011-03-29  Christoph Scholtes  <cschol2112@googlemail.com>
+
+	* progmodes/python.el (python-default-interpreter)
+	(python-python-command-args, python-jython-command-args)
+	(python-which-shell, python-which-args, python-which-bufname)
+	(python-file-queue, python-comint-output-filter-function)
+	(python-toggle-shells, python-shell): Remove obsolete defcustoms,
+	variables and functions.
+
 2011-03-27  Jan Djärv  <jan.h.d@swipnet.se>
 
 	* cus-start.el (all): Add boolean ns-auto-hide-menu-bar.

=== modified file 'lisp/progmodes/python.el'
--- lisp/progmodes/python.el	2011-01-26 08:36:39 +0000
+++ lisp/progmodes/python.el	2011-02-24 06:15:59 +0000
@@ -499,44 +499,6 @@
   :type 'integer)
 
 
-(defcustom python-default-interpreter 'cpython
-  "*Which Python interpreter is used by default.
-The value for this variable can be either `cpython' or `jpython'.
-
-When the value is `cpython', the variables `python-python-command' and
-`python-python-command-args' are consulted to determine the interpreter
-and arguments to use.
-
-When the value is `jpython', the variables `python-jpython-command' and
-`python-jpython-command-args' are consulted to determine the interpreter
-and arguments to use.
-
-Note that this variable is consulted only the first time that a Python
-mode buffer is visited during an Emacs session.  After that, use
-\\[python-toggle-shells] to change the interpreter shell."
-  :type '(choice (const :tag "Python (a.k.a. CPython)" cpython)
-		 (const :tag "JPython" jpython))
-  :group 'python)
-
-(defcustom python-python-command-args '("-i")
-  "*List of string arguments to be used when starting a Python shell."
-  :type '(repeat string)
-  :group 'python)
-
-(defcustom python-jython-command-args '("-i")
-  "*List of string arguments to be used when starting a Jython shell."
-  :type '(repeat string)
-  :group 'python
-  :tag "JPython Command Args")
-
-;; for toggling between CPython and JPython
-(defvar python-which-shell nil)
-(defvar python-which-args  python-python-command-args)
-(defvar python-which-bufname "Python")
-(make-variable-buffer-local 'python-which-shell)
-(make-variable-buffer-local 'python-which-args)
-(make-variable-buffer-local 'python-which-bufname)
-
 (defcustom python-pdbtrack-do-tracking-p t
   "*Controls whether the pdbtrack feature is enabled or not.
 
@@ -562,11 +524,6 @@
     (push '(python-pdbtrack-is-tracking-p python-pdbtrack-minor-mode-string)
 	  minor-mode-alist))
 
-;; Bind python-file-queue before installing the kill-emacs-hook.
-(defvar python-file-queue nil
-  "Queue of Python temp files awaiting execution.
-Currently-active file is at the head of the list.")
-
 (defcustom python-shell-prompt-alist
   '(("ipython" . "^In \\[[0-9]+\\]: *")
     (t . "^>>> "))
@@ -2584,20 +2541,6 @@
 
 ;; pdbtrack features
 
-(defun python-comint-output-filter-function (string)
-  "Watch output for Python prompt and exec next file waiting in queue.
-This function is appropriate for `comint-output-filter-functions'."
-  ;; TBD: this should probably use split-string
-  (when (and (string-match python--prompt-regexp string)
-	     python-file-queue)
-    (condition-case nil
-        (delete-file (car python-file-queue))
-      (error nil))
-    (setq python-file-queue (cdr python-file-queue))
-    (if python-file-queue
-	(let ((pyproc (get-buffer-process (current-buffer))))
-	  (python-execute-file pyproc (car python-file-queue))))))
-
 (defun python-pdbtrack-overlay-arrow (activation)
   "Activate or deactivate arrow at beginning-of-line in current buffer."
   (if activation
@@ -2742,45 +2685,6 @@
           (setq got buf)))
     got))
 
-(defun python-toggle-shells (arg)
-  "Toggles between the CPython and JPython shells.
-
-With positive argument ARG (interactively \\[universal-argument]),
-uses the CPython shell, with negative ARG uses the JPython shell, and
-with a zero argument, toggles the shell.
-
-Programmatically, ARG can also be one of the symbols `cpython' or
-`jpython', equivalent to positive arg and negative arg respectively."
-  (interactive "P")
-  ;; default is to toggle
-  (if (null arg)
-      (setq arg 0))
-  ;; preprocess arg
-  (cond
-   ((equal arg 0)
-    ;; toggle
-    (if (string-equal python-which-bufname "Python")
-	(setq arg -1)
-      (setq arg 1)))
-   ((equal arg 'cpython) (setq arg 1))
-   ((equal arg 'jpython) (setq arg -1)))
-  (let (msg)
-    (cond
-     ((< 0 arg)
-      ;; set to CPython
-      (setq python-which-shell python-python-command
-	    python-which-args python-python-command-args
-	    python-which-bufname "Python"
-	    msg "CPython"
-	    mode-name "Python"))
-     ((> 0 arg)
-      (setq python-which-shell python-jython-command
-	    python-which-args python-jython-command-args
-	    python-which-bufname "JPython"
-	    msg "JPython"
-	    mode-name "JPython")))
-    (message "Using the %s shell" msg)))
-
 ;; Python subprocess utilities and filters
 (defun python-execute-file (proc filename)
   "Send to Python interpreter process PROC \"execfile('FILENAME')\".
@@ -2801,71 +2705,6 @@
       (set-buffer curbuf))
     (process-send-string proc cmd)))
 
-;;;###autoload
-(defun python-shell (&optional argprompt)
-  "Start an interactive Python interpreter in another window.
-This is like Shell mode, except that Python is running in the window
-instead of a shell.  See the `Interactive Shell' and `Shell Mode'
-sections of the Emacs manual for details, especially for the key
-bindings active in the `*Python*' buffer.
-
-With optional \\[universal-argument], the user is prompted for the
-flags to pass to the Python interpreter.  This has no effect when this
-command is used to switch to an existing process, only when a new
-process is started.  If you use this, you will probably want to ensure
-that the current arguments are retained (they will be included in the
-prompt).  This argument is ignored when this function is called
-programmatically.
-
-Note: You can toggle between using the CPython interpreter and the
-JPython interpreter by hitting \\[python-toggle-shells].  This toggles
-buffer local variables which control whether all your subshell
-interactions happen to the `*JPython*' or `*Python*' buffers (the
-latter is the name used for the CPython buffer).
-
-Warning: Don't use an interactive Python if you change sys.ps1 or
-sys.ps2 from their default values, or if you're running code that
-prints `>>> ' or `... ' at the start of a line.  `python-mode' can't
-distinguish your output from Python's output, and assumes that `>>> '
-at the start of a line is a prompt from Python.  Similarly, the Emacs
-Shell mode code assumes that both `>>> ' and `... ' at the start of a
-line are Python prompts.  Bad things can happen if you fool either
-mode.
-
-Warning:  If you do any editing *in* the process buffer *while* the
-buffer is accepting output from Python, do NOT attempt to `undo' the
-changes.  Some of the output (nowhere near the parts you changed!) may
-be lost if you do.  This appears to be an Emacs bug, an unfortunate
-interaction between undo and process filters; the same problem exists in
-non-Python process buffers using the default (Emacs-supplied) process
-filter."
-  (interactive "P")
-  (require 'ansi-color) ; For ipython
-  ;; Set the default shell if not already set
-  (when (null python-which-shell)
-    (python-toggle-shells python-default-interpreter))
-  (let ((args python-which-args))
-    (when (and argprompt
-	       (called-interactively-p 'interactive)
-	       (fboundp 'split-string))
-      ;; TBD: Perhaps force "-i" in the final list?
-      (setq args (split-string
-		  (read-string (concat python-which-bufname
-				       " arguments: ")
-			       (concat
-				(mapconcat 'identity python-which-args " ") " ")
-			       ))))
-    (switch-to-buffer-other-window
-     (apply 'make-comint python-which-bufname python-which-shell nil args))
-    (set-process-sentinel (get-buffer-process (current-buffer))
-                          'python-sentinel)
-    (python--set-prompt-regexp)
-    (add-hook 'comint-output-filter-functions
-	      'python-comint-output-filter-function nil t)
-    ;; pdbtrack
-    (set-syntax-table python-mode-syntax-table)
-    (use-local-map python-shell-map)))
-
 (defun python-pdbtrack-toggle-stack-tracking (arg)
   (interactive "P")
   (if (not (get-buffer-process (current-buffer)))

Re: python.el cleanup

[Stefan Monnier]

> Find attached a patch to clean up the trunk's python.el in preparation
> for merging in Fabian's new python mode.

> Most of it (if not all) was added by Ken Manheimer's commits in revnos
> 84728 and 84779 when adding pdbtrack support, but as far as I can tell
> none of it is really needed for pdbtrack. 

Could you just clarify why they're considered obsolete (e.g. what would
the user use instead)?


        Stefan

Re: python.el cleanup

[Christoph Scholtes]

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

> Could you just clarify why they're considered obsolete (e.g. what would
> the user use instead)?

`python-shell' is not needed since Dave's mode already had
'run-python' to invoke the python interpreter. It offers no advantages
over run-python as far as I can tell except being able to toggle
between a Python and a Jython shell (see below for comments on that).

`python-comint-filter-function' is only called from `python-shell'.

`python-file-queue' is never populated anywhere, only read from
`python-comint filter-function'.

`python-default-interpreter' is only used by `python-shell' and not,
as advertised in its documentation, on first visiting a Python mode
buffer. 

`python-python-command-args' and `python-jython-command-args' are only
used in the `python-toggle-shell' function.

`python-which-shell', `python-which-args' and `python-which-bufname'
are used for toggling between the Python and Jython shell.

Finally, `python-toggle-shell'. I think, that we should provide a better
solution for this and therefore remove the current implementation. This
code came from python-mode.el, if I traced that back right.

Python interpreter selection should be universal and not only support Jython
and CPython, but also IronPyton, PyPy etc. I would like to implement a
better solution for this as soon as Fabian's changes are installed. I am
using IronPython quite a bit and it would be nice to be able to switch
flexibly between different interpreters.

Christoph

Re: python.el cleanup

[Andreas Röhler]

Am 30.03.2011 04:58, schrieb Christoph Scholtes:
> Stefan Monnier<monnier@iro.umontreal.ca>  writes:
>
>> Could you just clarify why they're considered obsolete (e.g. what would
>> the user use instead)?
>
> `python-shell' is not needed since Dave's mode already had
> 'run-python' to invoke the python interpreter. It offers no advantages
> over run-python as far as I can tell except being able to toggle
> between a Python and a Jython shell (see below for comments on that).
>
> `python-comint-filter-function' is only called from `python-shell'.
>
> `python-file-queue' is never populated anywhere, only read from
> `python-comint filter-function'.
>
> `python-default-interpreter' is only used by `python-shell' and not,
> as advertised in its documentation, on first visiting a Python mode
> buffer.
>
> `python-python-command-args' and `python-jython-command-args' are only
> used in the `python-toggle-shell' function.
>
> `python-which-shell', `python-which-args' and `python-which-bufname'
> are used for toggling between the Python and Jython shell.
>
> Finally, `python-toggle-shell'. I think, that we should provide a better
> solution for this and therefore remove the current implementation. This
> code came from python-mode.el, if I traced that back right.


Hi Christoph,

glad to see Emacs python facilities improve. As you mention 
python-mode.el, there are some remarks in python.el which I feel are not 
correct. If some solution predates historically another, there are 
usually some setbacks from being the first.

OTOH from my perspective python-mode.el has still some point in proceding.

Hopefully we may discuss the pro and cons to the benefit of users, which 
flavour they may choose finally. As you might have been remarked, its 
interwoven to an extend, you can seldom discern it clearly to the one or 
other origin.

BTW I'm not blaming the GNU's side. Just wanted to point at the issue so 
we might hopefully reduce the obstacles.

Cheers


Andreas

--
https://code.launchpad.net/~a-roehler/python-mode/python-mode-components
https://code.launchpad.net/s-x-emacs-werkstatt/




>
> Python interpreter selection should be universal and not only support Jython
> and CPython, but also IronPyton, PyPy etc. I would like to implement a
> better solution for this as soon as Fabian's changes are installed. I am
> using IronPython quite a bit and it would be nice to be able to switch
> flexibly between different interpreters.
>
> Christoph
>
>

Re: python.el cleanup

[Stefan Monnier]

>> Could you just clarify why they're considered obsolete (e.g. what would
>> the user use instead)?

[...explanation...]

OK, go ahead then,


        Stefan

Re: python.el cleanup

[Barry Warsaw]

[-- Attachment #1.1: Type: text/plain, Size: 1252 bytes --]

Thanks for CC'ing me.  I'm now subscribed to emacs-devel via Gmane.

On Mar 30, 2011, at 04:10 PM, Andreas Röhler wrote:

>glad to see Emacs python facilities improve. As you mention python-mode.el,
>there are some remarks in python.el which I feel are not correct. If some
>solution predates historically another, there are usually some setbacks from
>being the first.  OTOH from my perspective python-mode.el has still some
>point in proceding.  Hopefully we may discuss the pro and cons to the benefit
>of users, which flavour they may choose finally.

Yes, let's please try to converge Python support in Emacs as much as
possible.  I've heard there are now 4 Python modes, which if true, is really
not helping users.

All history aside, I applaud efforts to find ways to consolidate the modes,
keeping in mind the features and behavior users find important from each of
the flavors.  Andreas is doing the majority of the work on python-mode.el
these days, and we have a vibrant community on python-mode@python.org and an
active project on Launchpad.  I personally am much more of a user than
developer these days (too busy with other things Pythonic), but by no means
the only person using python-mode.el.

Cheers,
-Barry

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] python.el cleanup

[Christoph Scholtes]

Hi Andreas,

On 3/30/2011 8:10 AM, Andreas Röhler wrote:

> glad to see Emacs python facilities improve. As you mention
> python-mode.el, there are some remarks in python.el which I feel are not
> correct. If some solution predates historically another, there are
> usually some setbacks from being the first.

I am not sure which remarks you are referring to here.

> OTOH from my perspective python-mode.el has still some point in proceding.

I don't think anybody is saying otherwise.

> Hopefully we may discuss the pro and cons to the benefit of users, which
> flavour they may choose finally. As you might have been remarked, its
> interwoven to an extend, you can seldom discern it clearly to the one or
> other origin.

To me, it really doesn't matter where it originated from or who was 
first. If it works great, great, if it does not, let's improve it. The 
goal should be the best Python support for Emacs possible.

> BTW I'm not blaming the GNU's side. Just wanted to point at the issue so
> we might hopefully reduce the obstacles.

Here, I am also not sure what issue or obstacles you are referring to.

Christoph

Re: [Python-mode] python.el cleanup

[Andreas Röhler]

Am 03.04.2011 19:45, schrieb Christoph Scholtes:
> Hi Andreas,
>
> On 3/30/2011 8:10 AM, Andreas Röhler wrote:
>
>> glad to see Emacs python facilities improve. As you mention
>> python-mode.el, there are some remarks in python.el which I feel are not
>> correct. If some solution predates historically another, there are
>> usually some setbacks from being the first.
>
> I am not sure which remarks you are referring to here.

Hi Christoph,

reading for example:

;; That isn't covered by an FSF copyright assignment (?), unlike this
;; code, and seems not to be well-maintained for Emacs (though I've
;; submitted fixes).


>
>> OTOH from my perspective python-mode.el has still some point in
>> proceding.
>
> I don't think anybody is saying otherwise.
>
>> Hopefully we may discuss the pro and cons to the benefit of users, which
>> flavour they may choose finally. As you might have been remarked, its
>> interwoven to an extend, you can seldom discern it clearly to the one or
>> other origin.
>
> To me, it really doesn't matter where it originated from or who was
> first. If it works great, great, if it does not, let's improve it. The
> goal should be the best Python support for Emacs possible.
>
>> BTW I'm not blaming the GNU's side. Just wanted to point at the issue so
>> we might hopefully reduce the obstacles.
>
> Here, I am also not sure what issue or obstacles you are referring to.
>

Assume people will rather not be inclined to send bug reports, resp. 
fixes, if feeling quitted with remarks telling their own baby not being 
well maintained. That I would call an obstacle.


Andreas

> Christoph
>
>

Re: python.el cleanup

[Stefan Monnier]

> ;; That isn't covered by an FSF copyright assignment (?),

IIUC this is still the case (and historically it's the main reason why
it's not been included in Emacs).

> ;; unlike this ;; code, and seems not to be well-maintained for Emacs
> (though I've ;; submitted fixes).

Indeed, it is better to keep such comments elsewhere than in source code.


        Stefan

Re: python.el cleanup

[Barry Warsaw]

[-- Attachment #1.1: Type: text/plain, Size: 641 bytes --]

On Apr 03, 2011, at 08:55 PM, Andreas Röhler wrote:

>;; That isn't covered by an FSF copyright assignment (?), unlike this
>;; code, and seems not to be well-maintained for Emacs (though I've
>;; submitted fixes).

I've said before, but it's worth repeating.  While I still believe that at
some point I did sign a copyright assignment for my contributions to
python-mode.el, I also have absolutely no problem signing one again if for
whatever (unimportant) reason, the FSF does not have one on file from me.

Please, if necessary, just send me the paperwork.  I'm certain the FSF has my
contact information on file.

-Barry

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Re: [Python-mode] python.el cleanup

[Stefan Monnier]

>> ;; That isn't covered by an FSF copyright assignment (?), unlike this
>> ;; code, and seems not to be well-maintained for Emacs (though I've
>> ;; submitted fixes).

> I've said before, but it's worth repeating.  While I still believe that at
> some point I did sign a copyright assignment for my contributions to
> python-mode.el, I also have absolutely no problem signing one again if for
> whatever (unimportant) reason, the FSF does not have one on file from me.

The problem was with some of the other contributors, from what
I remember.


        Stefan

Re: [Python-mode] python.el cleanup

[Barry Warsaw]

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

On Apr 04, 2011, at 05:46 PM, Stefan Monnier wrote:

>>> ;; That isn't covered by an FSF copyright assignment (?), unlike this
>>> ;; code, and seems not to be well-maintained for Emacs (though I've
>>> ;; submitted fixes).
>
>> I've said before, but it's worth repeating.  While I still believe that at
>> some point I did sign a copyright assignment for my contributions to
>> python-mode.el, I also have absolutely no problem signing one again if for
>> whatever (unimportant) reason, the FSF does not have one on file from me.
>
>The problem was with some of the other contributors, from what
>I remember.

Is there a way to check specifically?  I'm sure we could get Skip, Tim, and
Ken to sign papers if necessary.

-Barry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Python-mode] python.el cleanup

[Glenn Morris]

Stefan Monnier wrote:

> The problem was with some of the other contributors, from what I remember.

For example, Andreas Roehler has issues with copyright assignments:

http://lists.gnu.org/archive/html/emacs-devel/2008-03/msg00029.html


Besides that, in 2008 an attempt was made to make a list of all the
contributors (it's presumably out-of-date now). The next step would be
for someone to figure out how much each person wrote. See

http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg02156.html
http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg02234.html
http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg02201.html

and related messages.

Re: python.el cleanup

[skip]

    >> The problem was with some of the other contributors, from what I
    >> remember.

    Barry> Is there a way to check specifically?  I'm sure we could get
    Barry> Skip, Tim, and Ken to sign papers if necessary.

I have also volunteered relatively recently (within the last couple months)
to wet sign again (which I did probably 10 years ago for the GNU folks).

Skip

Re: [Python-mode] python.el cleanup

[Andreas Röhler]

Am 05.04.2011 00:24, schrieb Glenn Morris:
> Stefan Monnier wrote:
>
>> The problem was with some of the other contributors, from what I remember.
>
> For example, Andreas Roehler has issues with copyright assignments:
>
> http://lists.gnu.org/archive/html/emacs-devel/2008-03/msg00029.html
>
>

So it is. My views didn't change since.


> Besides that, in 2008 an attempt was made to make a list of all the
> contributors (it's presumably out-of-date now). The next step would be
> for someone to figure out how much each person wrote.

Computing is about ideas, not about counting code-lines.

Even if a developer noticed a bug at the other side, which helped him to 
choose the right alternative, the other part is involved. Copyright in 
computing is such a nonsense, it's a shame pretending it.

But let's come to some mistakes more neareby:

- Stating someone signed the copyright-papers or not doesn't belong into 
the comment section of a code-file. That why I coming upon and the only 
reason so far.

- The problems of Emacs' Python edits don't result from the existence of 
two different development branches, where _all_ developers have some 
merits of every side, as pointed at above. The problems result rather 
from a lack of imagination what's needed to have an environment as state 
of the art.

So please, let's not jump into that eternal copyright loop. Let's go on 
bug-fixing and maybe building the environment afterwards.

Cheers

Andreas

--
https://code.launchpad.net/~a-roehler/python-mode/python-mode-components
https://code.launchpad.net/s-x-emacs-werkstatt/




>
> http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg02156.html
> http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg02234.html
> http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg02201.html
>
> and related messages.
>

Re: [Python-mode] python.el cleanup

[Stefan Monnier]

Please don't reply on this list.


        Stefan

>>>>> "Andreas" == Andreas Röhler <andreas.roehler@online.de> writes:

> Am 05.04.2011 00:24, schrieb Glenn Morris:
>> Stefan Monnier wrote:
>> 
>>> The problem was with some of the other contributors, from what I remember.
>> 
>> For example, Andreas Roehler has issues with copyright assignments:
>> 
>> http://lists.gnu.org/archive/html/emacs-devel/2008-03/msg00029.html
>> 
>> 

> So it is. My views didn't change since.


>> Besides that, in 2008 an attempt was made to make a list of all the
>> contributors (it's presumably out-of-date now). The next step would be
>> for someone to figure out how much each person wrote.

> Computing is about ideas, not about counting code-lines.

> Even if a developer noticed a bug at the other side, which helped him to
> choose the right alternative, the other part is involved. Copyright in
> computing is such a nonsense, it's a shame pretending it.

> But let's come to some mistakes more neareby:

> - Stating someone signed the copyright-papers or not doesn't belong into the
> comment section of a code-file. That why I coming upon and the only reason
> so far.

> - The problems of Emacs' Python edits don't result from the existence of two
> different development branches, where _all_ developers have some merits of
> every side, as pointed at above. The problems result rather from a lack of
> imagination what's needed to have an environment as state of the art.

> So please, let's not jump into that eternal copyright loop. Let's go on
> bug-fixing and maybe building the environment afterwards.

> Cheers

> Andreas

> --
> https://code.launchpad.net/~a-roehler/python-mode/python-mode-components
> https://code.launchpad.net/s-x-emacs-werkstatt/




>> 
>> http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg02156.html
>> http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg02234.html
>> http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg02201.html
>> 
>> and related messages.
>>