Release plans

Release plans

[Chong Yidong]

Just a reminder: we will begin the feature freeze for Emacs 23.1 at the
end of this month.

The original plan was to merge CEDET in time for the freeze.  However,
this isn't going to happen because of a delay in legal paperwork;
hopefully, CEDET will be included in 23.2.

Emacs.app (the new Cocoa port) will be merged sometime this week.

As for Emacs 22.3, bugfixes made to the trunk should be backported,
where safe and appropriate, to the Emacs 22 branch.  This backporting of
fixes will carry on throughout the Emacs 23 testing period, so that both
the trunk and the branch can benefit from the bugfixing effort.  If
things work out, we can make the Emacs 22.3 minor release during the
Emacs 23 pretest.  If you see an existing bugfix in the trunk that you
think should go into the Emacs 22 branch, please email the commiter with
a reminder to check it into the branch (or email emacs-devel).

I'd like to request volunteers for going through the Emacs 23
documentation.  The Emacs manual and Emacs Lisp manual need to be
updated with the information in etc/NEWS.  If you would like to help,
please email me.

Finally, if you are a naughty person who has not added a proper entry to
etc/NEWS for your new code, please do it as soon as possible (or ask
someone for help).

Thanks.

Re: Release plans

[Juri Linkov]

> Just a reminder: we will begin the feature freeze for Emacs 23.1 at the
> end of this month.
>
> The original plan was to merge CEDET in time for the freeze.  However,
> this isn't going to happen because of a delay in legal paperwork;
> hopefully, CEDET will be included in 23.2.

I have doubts that CEDET can be included in Emacs 23 without adding
more features because some parts have to be rewritten to be more clean
(like replacing defadvices with Emacs native features etc.)

Emacs 23.1 has enough major features, so maybe it makes sense to include
CEDET in the next major release after 23.1 with more related Emacs features
(like tabbed UI and others), and advertise it as Emacs IDE.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Release plans

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

>> Just a reminder: we will begin the feature freeze for Emacs 23.1 at the
>> end of this month.
>>
>> The original plan was to merge CEDET in time for the freeze.  However,
>> this isn't going to happen because of a delay in legal paperwork;
>> hopefully, CEDET will be included in 23.2.
>
> I have doubts that CEDET can be included in Emacs 23 without adding
> more features because some parts have to be rewritten to be more clean
> (like replacing defadvices with Emacs native features etc.)

"delay in legal paperwork" is ringing all my alarm bells.  Paper work
that won't get done in a month is not likely to get done in a year.  I
don't see that dropping the ball now will make it easier to pick it up
next time round.

> Emacs 23.1 has enough major features, so maybe it makes sense to
> include CEDET in the next major release after 23.1 with more related
> Emacs features (like tabbed UI and others), and advertise it as Emacs
> IDE.

I'd really much prefer if we could get this over with.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Release plans

[Chong Yidong]

> Just a reminder: we will begin the feature freeze for Emacs 23.1 at the
> end of this month.

If anyone on this list has a patch that is still waiting for approval or
further comments, now would be a good time to ping.

Re: Release plans

[Thien-Thi Nguyen]

() Chong Yidong <cyd@stupidchicken.com>
() Mon, 21 Jul 2008 00:49:03 -0400

   now would be a good time to ping

Ping!  (I can't remember if this was accepted or not.)

thi

_______________________________________________
*** lisp/smerge-mode.el.~1.72~	2008-07-21 09:58:34.000000000 +0200
--- lisp/smerge-mode.el	2008-06-24 09:17:57.000000000 +0200
***************
*** 44,50 ****
  
  ;;; Code:
  
! (eval-when-compile (require 'cl))
  
  
  ;;; The real definition comes later.
--- 44,50 ----
  
  ;;; Code:
  
! (eval-when-compile (require 'cl) (require 'diff-mode))
  
  
  ;;; The real definition comes later.
***************
*** 77,87 ****
    :group 'smerge
    :type 'boolean)
  
- (defcustom smerge-auto-refine t
-   "Automatically highlight changes in detail as the user visits conflicts."
-   :group 'smerge
-   :type 'boolean)
- 
  (defface smerge-mine
    '((((min-colors 88) (background light))
       (:foreground "blue1"))
--- 77,82 ----
***************
*** 259,265 ****
  
  ;; Define smerge-next and smerge-prev
  (easy-mmode-define-navigation smerge smerge-begin-re "conflict" nil nil
!   (if smerge-auto-refine
        (condition-case nil (smerge-refine) (error nil))))
  
  (defconst smerge-match-names ["conflict" "mine" "base" "other"])
--- 254,260 ----
  
  ;; Define smerge-next and smerge-prev
  (easy-mmode-define-navigation smerge smerge-begin-re "conflict" nil nil
!   (if diff-auto-refine-mode
        (condition-case nil (smerge-refine) (error nil))))
  
  (defconst smerge-match-names ["conflict" "mine" "base" "other"])
*** lisp/diff-mode.el.~1.145~	2008-07-21 09:56:54.000000000 +0200
--- lisp/diff-mode.el	2008-07-21 10:02:30.000000000 +0200
***************
*** 91,101 ****
    :type 'boolean
    :group 'diff-mode)
  
- (defcustom diff-auto-refine t
-   "Automatically highlight changes in detail as the user visits hunks."
-   :type 'boolean
-   :group 'diff-mode)
- 
  (defcustom diff-mode-hook nil
    "Run after setting up the `diff-mode' major mode."
    :type 'hook
--- 91,96 ----
***************
*** 220,225 ****
--- 215,227 ----
    `((,diff-minor-mode-prefix . ,diff-mode-shared-map))
    "Keymap for `diff-minor-mode'.  See also `diff-mode-shared-map'.")
  
+ (define-minor-mode diff-auto-refine-mode
+   "Automatically highlight changes in detail as the user visits hunks.
+ When transitioning from disabled to enabled,
+ try to refine the current hunk, as well."
+   :group 'diff-mode :init-value t :lighter " Auto-Refine"
+   (when diff-auto-refine-mode
+     (condition-case-no-debug nil (diff-refine-hunk) (error nil))))
  
  ;;;;
  ;;;; font-lock support
***************
*** 528,534 ****
  ;; Define diff-{hunk,file}-{prev,next}
  (easy-mmode-define-navigation
   diff-hunk diff-hunk-header-re "hunk" diff-end-of-hunk diff-restrict-view
!  (if diff-auto-refine
       (condition-case-no-debug nil (diff-refine-hunk) (error nil))))
  
  (easy-mmode-define-navigation
--- 530,536 ----
  ;; Define diff-{hunk,file}-{prev,next}
  (easy-mmode-define-navigation
   diff-hunk diff-hunk-header-re "hunk" diff-end-of-hunk diff-restrict-view
!  (if diff-auto-refine-mode
       (condition-case-no-debug nil (diff-refine-hunk) (error nil))))
  
  (easy-mmode-define-navigation
*** etc/NEWS.~1.1798.~	2008-07-21 08:45:56.000000000 +0200
--- etc/NEWS	2008-07-21 10:03:32.000000000 +0200
***************
*** 579,585 ****
  
  *** diff-refine-hunk highlights word-level details of changes in a diff hunk.
  It's used automatically as you move through hunks, see
! diff-auto-refine.  It is bound to `C-c C-b'.
  
  *** diff-add-change-log-entries-other-window iterates through the diff
  buffer and tries to create ChangeLog entries for each change.
--- 579,585 ----
  
  *** diff-refine-hunk highlights word-level details of changes in a diff hunk.
  It's used automatically as you move through hunks, see
! diff-auto-refine-mode.  It is bound to `C-c C-b'.
  
  *** diff-add-change-log-entries-other-window iterates through the diff
  buffer and tries to create ChangeLog entries for each change.
***************
*** 784,790 ****
  *** sgml-electric-tag-pair-mode lets you simultaneously edit matched tag pairs.
  
  *** smerge-refine highlights word-level details of changes in conflict.
! It's used automatically as you move through conflicts, see smerge-auto-refine.
  
  *** talk.el has been extended for multiple tty support.
  
--- 784,791 ----
  *** sgml-electric-tag-pair-mode lets you simultaneously edit matched tag pairs.
  
  *** smerge-refine highlights word-level details of changes in conflict.
! It's used automatically as you move through conflicts, see
! smerge-auto-refine-mode.
  
  *** talk.el has been extended for multiple tty support.
  

Re: Release plans

[Chong Yidong]

Thien-Thi Nguyen <ttn@gnuvola.org> writes:

> Ping!  (I can't remember if this was accepted or not.)
>
> *** lisp/smerge-mode.el.~1.72~	2008-07-21 09:58:34.000000000 +0200
> --- lisp/smerge-mode.el	2008-06-24 09:17:57.000000000 +0200

Looks OK to me.  Go ahead and check it in.

Re: Release plans

[Thien-Thi Nguyen]

() Chong Yidong <cyd@stupidchicken.com>
() Mon, 21 Jul 2008 09:32:01 -0400

   Looks OK to me.  Go ahead and check it in.

OK, done.

thi

Re: Release plans

[Michael Albinus]

Chong Yidong <cyd@stupidchicken.com> writes:

>> Just a reminder: we will begin the feature freeze for Emacs 23.1 at the
>> end of this month.
>
> If anyone on this list has a patch that is still waiting for approval or
> further comments, now would be a good time to ping.

I have a small package in the queue, xesam.el. It provides an interface
to search engines, who support the Xesam API(1). I've tested it with
beagle(2) and strigi(3) as well as with the demo script from the
xesam-tools(4), which implements an access to yahoo. tracker(5),
pinot(6) and recoll(7) are also said to support Xesam; this I haven't
tested (yet).

The package is functional, although it might need some polishing. Are
there any objections to install it at lisp/net?

Best regards, Michael.

(1): <http://xesam.org/main>
(2): <http://beagle-project.org/About>
(3): <http://strigi.sourceforge.net/?q=general>
(4): <http://xesam.org/people/kamstrup/xesam-tools/>
(5): <http://www.gnome.org/projects/tracker/>
(6): <http://pinot.berlios.de/index.html>
(7): <http://www.recoll.org/>

Re: Release plans

[Chong Yidong]

Michael Albinus <michael.albinus@gmx.de> writes:

> I have a small package in the queue, xesam.el. It provides an interface
> to search engines, who support the Xesam API(1). I've tested it with
> beagle(2) and strigi(3) as well as with the demo script from the
> xesam-tools(4), which implements an access to yahoo. tracker(5),
> pinot(6) and recoll(7) are also said to support Xesam; this I haven't
> tested (yet).
>
> The package is functional, although it might need some polishing. Are
> there any objections to install it at lisp/net?

Go ahead, if you feel that it is ready for inclusion (and please include
a NEWS entry).

xesam.el (was: Release plans)

[Michael Albinus]

Chong Yidong <cyd@stupidchicken.com> writes:

> Michael Albinus <michael.albinus@gmx.de> writes:
>
>> I have a small package in the queue, xesam.el. It provides an interface
>> to search engines, who support the Xesam API(1). I've tested it with
>> beagle(2) and strigi(3) as well as with the demo script from the
>> xesam-tools(4), which implements an access to yahoo. tracker(5),
>> pinot(6) and recoll(7) are also said to support Xesam; this I haven't
>> tested (yet).
>>
>> The package is functional, although it might need some polishing. Are
>> there any objections to install it at lisp/net?
>
> Go ahead, if you feel that it is ready for inclusion (and please include
> a NEWS entry).

done.

Best regards, Michael.

Re: Release plans

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Mon, 21 Jul 2008 00:49:03 -0400
> 
> > Just a reminder: we will begin the feature freeze for Emacs 23.1 at the
> > end of this month.
> 
> If anyone on this list has a patch that is still waiting for approval or
> further comments, now would be a good time to ping.

I've been working off-list with Roland Winkler on adding two
primitives to Emacs that would allow proced.el to avoid using external
programs such as `ps' to implement Process Editor mode.  The GNU/Linux
part of the primitives is almost done; I need maybe one more weekend
to finish it and install the changes.  The MS-Windows implementation
will follow.

I hope I will be allowed to install these changes on the trunk.

Re: Release plans

[Richard M Stallman]

    I've been working off-list with Roland Winkler on adding two
    primitives to Emacs that would allow proced.el to avoid using external
    programs such as `ps' to implement Process Editor mode.

That is definitely a good contribution.

But if Emacs did not run on Windows, could you still have made
this contribution?  Or perhaps even more contribution?

Re: Release plans

[Eli Zaretskii]

> From: Richard M Stallman <rms@gnu.org>
> CC: cyd@stupidchicken.com, Roland.Winkler@physik.uni-erlangen.de,
> 	emacs-devel@gnu.org
> Date: Sat, 26 Jul 2008 17:33:58 -0400
> 
> But if Emacs did not run on Windows, could you still have made
> this contribution?  Or perhaps even more contribution?

Not really.

Re: Release plans

[Richard M Stallman]

    > But if Emacs did not run on Windows, could you still have made
    > this contribution?  Or perhaps even more contribution?

    Not really.

What if you did all your editing on a GNU/Linux machine?

In the first year of GNU development, before GNU Emacs, I didn't do
editing on Unix.  I edited on another machine where there was an Emacs,
and saved the files to the Unix machine where I tested them.
It wasn't very inconvenient even then.

Re: Release plans

[Eli Zaretskii]

> From: Richard M Stallman <rms@gnu.org>
> CC: cyd@stupidchicken.com, emacs-devel@gnu.org,
> 	Roland.Winkler@physik.uni-erlangen.de
> Date: Sun, 27 Jul 2008 13:14:45 -0400
> 
>     > But if Emacs did not run on Windows, could you still have made
>     > this contribution?  Or perhaps even more contribution?
> 
>     Not really.
> 
> What if you did all your editing on a GNU/Linux machine?

It won't matter.  My problem is a chronic lack of free time
(obviously, I cannot develop Emacs during my office hours), so I
mostly can do only simple Emacs jobs.  When there are exceptions, like
on public holidays, I have access to both Windows and GNU/Linux.
That's how I coded the Proced support, for example.

Re: Release plans

[Richard M Stallman]

    It won't matter.  My problem is a chronic lack of free time
    (obviously, I cannot develop Emacs during my office hours), so I
    mostly can do only simple Emacs jobs.

In that case, does the fact that Emacs runs on Windows
help you do these simple jobs?

Re: Release plans

[Eli Zaretskii]

> From: Richard M Stallman <rms@gnu.org>
> CC: emacs-devel@gnu.org
> Date: Mon, 28 Jul 2008 17:46:52 -0400
> 
>     It won't matter.  My problem is a chronic lack of free time
>     (obviously, I cannot develop Emacs during my office hours), so I
>     mostly can do only simple Emacs jobs.
> 
> In that case, does the fact that Emacs runs on Windows
> help you do these simple jobs?

It gives me more opportunities to look at problems that are not
specific to some platform.

Re: Release plans

[Richard M Stallman]

    > In that case, does the fact that Emacs runs on Windows
    > help you do these simple jobs?

    It gives me more opportunities to look at problems that are not
    specific to some platform.

Sure, but it also consumes some of your time on Windows support issues.
If you simply did your editing on the GNU/Linux machine, and did not
pay attention to Windows support, would your contributions to
the platform-independent capabilities of Emacs be less, or more?

Re: Release plans

[Eli Zaretskii]

> From: Richard M Stallman <rms@gnu.org>
> CC: emacs-devel@gnu.org
> Date: Tue, 29 Jul 2008 23:47:30 -0400
> 
> If you simply did your editing on the GNU/Linux machine, and did not
> pay attention to Windows support, would your contributions to
> the platform-independent capabilities of Emacs be less, or more?

It would probably be more, but only insignificantly so.

Anyway, this is purely academic question.

Re: Release plans

[Juri Linkov]

>> > Just a reminder: we will begin the feature freeze for Emacs 23.1 at the
>> > end of this month.
>>
>> If anyone on this list has a patch that is still waiting for approval or
>> further comments, now would be a good time to ping.
>
> I've been working off-list with Roland Winkler on adding two
> primitives to Emacs that would allow proced.el to avoid using external
> programs such as `ps' to implement Process Editor mode.  The GNU/Linux
> part of the primitives is almost done; I need maybe one more weekend
> to finish it and install the changes.  The MS-Windows implementation
> will follow.
>
> I hope I will be allowed to install these changes on the trunk.

And we also need more time to finish and install code for multiple input
methods and a better locale system for the upcoming Unicode release.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Release plans

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

> And we also need more time to finish and install code for multiple
> input methods and a better locale system for the upcoming Unicode
> release.

And how long do you estimate this would take?  If too long, this will
simply have to wait for the next cycle.

Re: Release plans

[Juri Linkov]

>> And we also need more time to finish and install code for multiple
>> input methods and a better locale system for the upcoming Unicode
>> release.
>
> And how long do you estimate this would take?  If too long, this will
> simply have to wait for the next cycle.

I suppose not more than two weeks.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Release plans

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

>>> And we also need more time to finish and install code for multiple
>>> input methods and a better locale system for the upcoming Unicode
>>> release.
>>
>> And how long do you estimate this would take?  If too long, this will
>> simply have to wait for the next cycle.
>
> I suppose not more than two weeks.

I think it may be better to keep this for 23.2, but please do write up
the patch anyway; it'll be easier to decide once we have something to
look at.

Re: Release plans

[Stefan Monnier]

> I think it may be better to keep this for 23.2, but please do write up

Indeed, it doesn't matter much anyway: it is not a crucial fonctionality
(and it already works right now), so there's no strong reason to push it
for 23.1.  At the same time, proced.el is new in Emacs-23, so we can be
a bit more permissive w.r.t late additions in that it won't be
a regression compared to Emacs-22 anyway.


        Stefan

Re: Release plans

[Roland Winkler]

On Sat Jul 26 2008 Eli Zaretskii wrote:
> > From: Chong Yidong <cyd@stupidchicken.com>
> > Date: Mon, 21 Jul 2008 00:49:03 -0400
> > 
> > > Just a reminder: we will begin the feature freeze for Emacs 23.1 at the
> > > end of this month.
> > 
> > If anyone on this list has a patch that is still waiting for approval or
> > further comments, now would be a good time to ping.
> 
> I've been working off-list with Roland Winkler on adding two
> primitives to Emacs that would allow proced.el to avoid using external
> programs such as `ps' to implement Process Editor mode.  The GNU/Linux
> part of the primitives is almost done; I need maybe one more weekend
> to finish it and install the changes.  The MS-Windows implementation
> will follow.
> 
> I hope I will be allowed to install these changes on the trunk.

I must greatly apologize because I need to say that I have not yet
been able to finalize the part of proced.el that will be able to use
Eli's primitives. Right now I am traveling (once more) and I cannot
do any programming. I'll return on Aug 11 when I will finish my part
with very high priority (i.e., not later than the end of that week).
Will that be acceptable?

Roland

Re: Release plans

[Eli Zaretskii]

> Date: Sat, 26 Jul 2008 10:39:08 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: Roland Winkler <Roland.Winkler@physik.uni-erlangen.de>, emacs-devel@gnu.org
> 
> I've been working off-list with Roland Winkler on adding two
> primitives to Emacs that would allow proced.el to avoid using external
> programs such as `ps' to implement Process Editor mode.  The GNU/Linux
> part of the primitives is almost done; I need maybe one more weekend
> to finish it and install the changes.  The MS-Windows implementation
> will follow.

The GNU/Linux implementation is now done and installed.  I didn't yet
write the documentation for the ELisp manual, but I assume this is not
urgent, since the code freeze does not affect the docs.

P.S. The GNU/Linux implementation uses /proc filesystem to get at the
list of processes and the attributes of a process.  While I know that
other Unix systems support /proc, I don't have access to them, and
thus cannot verify that the code works on them, especially since I'm
quite sure the details vary.  So for now the /proc method is only
enabled for GNU/Linux; users of other Unices will have to extend the
code for their systems.

Re: Release plans

[Eli Zaretskii]

> Date: Sat, 02 Aug 2008 20:34:40 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> CC: cyd@stupidchicken.com, Roland.Winkler@physik.uni-erlangen.de,
> 	emacs-devel@gnu.org
> 
> > Date: Sat, 26 Jul 2008 10:39:08 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: Roland Winkler <Roland.Winkler@physik.uni-erlangen.de>, emacs-devel@gnu.org
> > 
> > I've been working off-list with Roland Winkler on adding two
> > primitives to Emacs that would allow proced.el to avoid using external
> > programs such as `ps' to implement Process Editor mode.  The GNU/Linux
> > part of the primitives is almost done; I need maybe one more weekend
> > to finish it and install the changes.  The MS-Windows implementation
> > will follow.
> 
> The GNU/Linux implementation is now done and installed.

The MS-Windows implementation is also installed.

Re: Release plans

[Juanma Barranquero]

On Sat, Aug 9, 2008 at 20:29, Eli Zaretskii <eliz@gnu.org> wrote:

> The MS-Windows implementation is also installed.

It is expected that system-process-attributes returns a non-nil list
for nonexistent processes?

ELISP> (system-process-attributes -1)
((group . "None")
 (egid . 513)
 (user . "SYSTEM")
 (euid . 18))

ELISP> (system-process-attributes (1+ (apply #'max (list-system-processes))))
((pmem . 0.4225325208687513)
 (rss . 4424)
 (vsize . 4228)
 (majflt . 3894)
 (group . "Ninguno")
 (egid . 513)
 (user . "Juanma")
 (euid . 1006))


   Juanma

Re: Release plans

[Eli Zaretskii]

> Date: Sat, 9 Aug 2008 20:34:40 +0200
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: cyd@stupidchicken.com, Roland.Winkler@physik.uni-erlangen.de, 
> 	emacs-devel@gnu.org
> 
> On Sat, Aug 9, 2008 at 20:29, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > The MS-Windows implementation is also installed.
> 
> It is expected that system-process-attributes returns a non-nil list
> for nonexistent processes?

No, it's a bug, of course (had in mind to handle this case, but
forgot).  Now fixed, thanks.

New `read-buffer-completion-ignore-case' variable? [was Re: Release plans]

[John Paul Wallington]

Chong Yidong <cyd@stupidchicken.com> writes:

>> Just a reminder: we will begin the feature freeze for Emacs 23.1 at the
>> end of this month.
>
> If anyone on this list has a patch that is still waiting for approval or
> further comments, now would be a good time to ping.

Rats.  I wish I had noticed this earlier:- I'm just catching up with
my emacs-devel backlog.  How about this patch?  I've been running with
it for awhile.  Maybe the default value should be t for Windows
systems?


2008-07-30  John Paul Wallington  <jpw@pobox.com>

        * minibuf.c (read_buffer_completion_ignore_case): New variable.
        (syms_of_minibuf): Declare and initialise it.
        (Fread_buffer): Bind `completion-ignore-case' to respect it.


Index: src/minibuf.c
===================================================================
RCS file: /sources/emacs/emacs/src/minibuf.c,v
retrieving revision 1.354
diff -u -r1.354 minibuf.c
--- src/minibuf.c       10 Jun 2008 18:41:01 -0000      1.354
+++ src/minibuf.c       30 Jul 2008 00:34:44 -0000
@@ -109,6 +109,9 @@
 /* Function to call to read a buffer name.  */
 Lisp_Object Vread_buffer_function;
 
+/* Nonzero means completion ignores case when reading buffer name.  */
+int read_buffer_completion_ignore_case;
+
 /* Nonzero means completion ignores case.  */
 
 int completion_ignore_case;
@@ -1178,17 +1181,25 @@
  If DEF is a list of default values, return its first element.
 If optional third arg REQUIRE-MATCH is non-nil,
  only existing buffer names are allowed.
-The argument PROMPT should be a string ending with a colon and a space.  */)
+The argument PROMPT should be a string ending with a colon and a space.
+
+See also `read-buffer-completion-ignore-case' and `read-buffer-function'. */)
      (prompt, def, require_match)
      Lisp_Object prompt, def, require_match;
 {
   Lisp_Object args[4];
+  Lisp_Object tem;
   unsigned char *s;
   int len;
+  int count = SPECPDL_INDEX ();
+    
 
   if (BUFFERP (def))
     def = XBUFFER (def)->name;
-
+  
+  specbind (Qcompletion_ignore_case,
+           read_buffer_completion_ignore_case ? Qt : Qnil);
+  
   if (NILP (Vread_buffer_function))
     {
       if (!NILP (def))
@@ -1218,9 +1229,9 @@
          prompt = Fformat (3, args);
        }
 
-      return Fcompleting_read (prompt, intern ("internal-complete-buffer"),
-                              Qnil, require_match, Qnil, Qbuffer_name_history,
-                              def, Qnil);
+      tem = Fcompleting_read (prompt, intern ("internal-complete-buffer"),
+                             Qnil, require_match, Qnil, Qbuffer_name_history,
+                             def, Qnil);
     }
   else
     {
@@ -1228,8 +1239,9 @@
       args[1] = prompt;
       args[2] = def;
       args[3] = require_match;
-      return Ffuncall(4, args);
+      tem = Ffuncall(4, args);
     }
+  return unbind_to (count, tem);
 }
 \f
 static Lisp_Object
@@ -2111,6 +2123,10 @@
               doc: /* If this is non-nil, `read-buffer' does its work by calling this function.  */);
   Vread_buffer_function = Qnil;
 
+  DEFVAR_BOOL ("read-buffer-completion-ignore-case", &read_buffer_completion_ignore_case,
+              doc: /* *Non-nil means when reading a buffer name completion ignores case.  */);
+  read_buffer_completion_ignore_case = 0;
+
   DEFVAR_LISP ("minibuffer-setup-hook", &Vminibuffer_setup_hook,
               doc: /* Normal hook run just after entry to minibuffer.  */);
   Vminibuffer_setup_hook = Qnil;

Re: New `read-buffer-completion-ignore-case' variable?

[Chong Yidong]

jpw@pobox.com (John Paul Wallington) writes:

> Rats.  I wish I had noticed this earlier:- I'm just catching up with
> my emacs-devel backlog.  How about this patch?

Looks OK.  Checked in.

Re: New `read-buffer-completion-ignore-case' variable?

[John Paul Wallington]

Chong Yidong <cyd@stupidchicken.com> writes:

> jpw@pobox.com (John Paul Wallington) writes:
>
>> Rats.  I wish I had noticed this earlier:- I'm just catching up with
>> my emacs-devel backlog.  How about this patch?
>
> Looks OK.  Checked in.

Thanks!

Re: Release plans

[Bastien]

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

Chong Yidong <cyd@stupidchicken.com> writes:

>> Just a reminder: we will begin the feature freeze for Emacs 23.1 at the
>> end of this month.
>
> If anyone on this list has a patch that is still waiting for approval or
> further comments, now would be a good time to ping.

A long time ago, Lennart proposed to integrate a library implementing an
easy way for resizing windows.  See email <47BF64AF.1000105@gmail.com>
on [emacs-devel] to jump back into this discussion.

I attach the last version I'm aware of (0.96) of Lennart's windsize.el
-- maybe this is not the latest version, Lennart can you confirm?

As I had a slightly different approach and I coded windresize.el:

  http://www.cognition.ens.fr/~guerry/u/windresize.el

Maybe one of these libraries could be part of Emacs at some point.

You might also want to have a look at register-list.el, which let the 
user get a list of the registers, delete and edit them:

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


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

;;; winsize.el --- Interactive window structure editing
;;
;; Author: Lennart Borgman <lennart dot borgman at gmail dot com >
;; Maintainer:
;; Created: Wed Dec 07 15:35:09 2005
;; Version: 0.96
;; Lxast-Updated: Sun Nov 18 02:14:52 2007 (3600 +0100)
;; Keywords:
;; Compatibility:
;;
;; Fxeatures that might be required by this library:
;;
;;   None
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Commentary:
;;
;; This file contains functions for interactive resizing of Emacs
;; windows.  To use it put it in your `load-path' and add the following
;; to your .emacs:
;;
;;     (require 'winsize)
;;     (global-set-key [(control x) ?+] 'resize-windows)
;;
;; For more information see `resize-windows'.
;;
;; These functions are a slightly rewritten version of the second part
;; of the second part my proposal for a new `balance-windows' function
;; for Emacs 22.  The rewrite is mostly a restructure to more easily
;; add new functions.  All functions and variables have been renamed.
;; The file was originally named bw-interactive.el.
;;
;; New ideas for functionality have been to a large part adopted from
;; the Emacs Devel mailing list.  Probably most of them originated from
;; Drew Adams and Bastien.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Change log:
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; This program 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 2, or (at your option)
;; any later version.
;;
;; This program 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 this program; see the file COPYING.  If not, write to the
;; Free Software Foundation, Inc., 59 Temple Place - Suite 330,
;; Boston, MA 02111-1307, USA.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; TODO: Change mouse pointer shape during resizing.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Code:


;;; Keymap, interactive functions etc

(defvar winsize-keymap nil
  "Keymap used by `resize-windows'.")

(defun winsize-make-keymap (let-me-use)
  "Build the keymap that should be used by `winsize-keymap'."
  (let ((map (make-sparse-keymap "Window Resizing")))
    (define-key map [menu-bar bw]
      (cons "Resize" (make-sparse-keymap "second")))
    (define-key map [menu-bar bw fit]
      '("Fit Window to Buffer" . fit-window-to-buffer))
    (define-key map [menu-bar bw fit]
      '("Shring Window to Buffer" . shrink-window-if-larger-than-buffer))
    (define-key map [menu-bar bw siblings]
      '("Balance Window Siblings" . winsize-balance-siblings))
    (define-key map [menu-bar bw balance]
      '("Balance Windows" . balance-windows))

    (define-key map [?+] 'balance-windows)
    (define-key map [?.] 'winsize-balance-siblings)
    (define-key map [?=] 'fit-window-to-buffer)
    (define-key map [?-] 'shrink-window-if-larger-than-buffer)

    (define-key map [(up)]    'winsize-move-border-up)
    (define-key map [(down)]  'winsize-move-border-down)
    (define-key map [(left)]  'winsize-move-border-left)
    (define-key map [(right)] 'winsize-move-border-right)

    (define-key map [(shift up)]    'winsize-move-other-border-up)
    (define-key map [(shift down)]  'winsize-move-other-border-down)
    (define-key map [(shift left)]  'winsize-move-other-border-left)
    (define-key map [(shift right)] 'winsize-move-other-border-right)

    (define-key map [(meta left)]   'winsize-to-border-or-window-left)
    (define-key map [(meta up)]     'winsize-to-border-or-window-up)
    (define-key map [(meta right)]  'winsize-to-border-or-window-right)
    (define-key map [(meta down)]   'winsize-to-border-or-window-down)

    (define-key map [?0] 'delete-window)
    (define-key map [?1] 'delete-other-windows)
    (define-key map [?2] 'split-window-vertically)
    (define-key map [?3] 'split-window-horizontally)
    (define-key map [?4] 'other-window)

    (define-key map [?!] 'winsize-save-window-configuration)
    (define-key map [?>] 'winsize-next-window-configuration)
    (define-key map [?<] 'winsize-previous-window-configuration)

    ;; Fix-me: These keys could also be set to nil
    (define-key map [mouse-1]                        'mouse-set-point)
    ;;(define-key map [down-mouse-1]                   'mouse-set-point)
    (define-key map [(mode-line) (down-mouse-1)]     'mouse-drag-mode-line)
    (define-key map [(vertical-line) (down-mouse-1)] 'mouse-drag-vertical-line)
    (define-key map [(vertical-scroll-bar) (mouse-1)] 'scroll-bar-toolkit-scroll)

    (define-key map [??] 'winsize-help)
    (define-key map [(control ?g)]     'winsize-quit)
    (define-key map [(control return)] 'winsize-stop-go-back)
    (define-key map [(return)]         'winsize-stop)
    (define-key map [t]                'winsize-stop-and-execute)

    (dolist (ks let-me-use)
      (if (and (not (vectorp ks))
               (not (stringp ks))
               (commandp ks))
          (let ((ks-list (where-is-internal ks)))
            (dolist (ks ks-list)
              (unless (lookup-key map ks)
                (define-key map ks nil))))
        (unless (lookup-key map ks)
          (define-key map ks nil))))

    (setq winsize-keymap map)))

(defun winsize-pre-command ()
  "Do this before every command.
Runs this in `pre-command-hook'.

Remember the currently used border sides for resizing. Also
remember position in message buffer to be able to see if next
command outputs some message.

For more information see `winsize-post-command'."
  (setq winsize-message-end (winsize-message-end))
  (setq winsize-border-hor (winsize-border-used-hor))
  (setq winsize-border-ver (winsize-border-used-ver)))

(defun winsize-post-command ()
  "Done after every command.
Run this in `post-command-hook'.

Check the border sides \(left/right, up/down) remembered in
`winsize-pre-command' and use the the same side if possible,
otherwise the opposite side if that is possible. \(This check is
of course not done if the last command changed the border side.)

The reason for selecting borders this way is to try to give the
user a coherent and easy picture of what is going on when
changing window or when window structure is changed.  \(Note that
the commands moving to another window or changing the window
structure does not have to belong to this package. Those commands
can therefore not select the border sides.)

Give the user feedback about selected window and borders.  Also
give a short help message unless last command gave some message."
  (unless juris-way
    (unless winsize-border-hor
      (winsize-select-initial-border-hor))
    (when winsize-border-hor
      (winsize-set-border winsize-border-hor t))
    (unless winsize-border-ver
     (winsize-select-initial-border-ver))
    (when winsize-border-ver
      (winsize-set-border winsize-border-ver t)))
  (winsize-tell-user))

(defun resize-windows ()
  "Start window resizing.
During resizing a window is selected.  You can move its
borders (by default with the arrow keys) and you can select other
borders or windows (by default with Meta-arrow keys).

You can also do other window operations, like splitting, deleting
and balancing the sizes.  The keybindings below describes the key
bindings during resizing:\\<winsize-keymap>

  `balance-windows'                      \\[balance-windows]
  `winsize-balance-siblings'             \\[winsize-balance-siblings]
  `fit-window-to-buffer'                 \\[fit-window-to-buffer]
  `shrink-window-if-larger-than-buffer'  \\[shrink-window-if-larger-than-buffer]


  `winsize-move-border-up'      \\[winsize-move-border-up]
  `winsize-move-border-down'    \\[winsize-move-border-down]
  `winsize-move-border-left'    \\[winsize-move-border-left]
  `winsize-move-border-right'   \\[winsize-move-border-right]

  `winsize-to-border-or-window-left'    \\[winsize-to-border-or-window-left]
  `winsize-to-border-or-window-up'      \\[winsize-to-border-or-window-up]
  `winsize-to-border-or-window-right'   \\[winsize-to-border-or-window-right]
  `winsize-to-border-or-window-down'    \\[winsize-to-border-or-window-down]

   Note that you can also use your normal keys for
   `forward-char', `backward-char', `next-line', `previous-line'
   and what you have on HOME and END to move in the windows. That
   might sometimes be necessary to directly select a
   window. \(You may however also use `other-window' or click
   with the mouse, see below.)

  `delete-window'                \\[delete-window]
  `delete-other-windows'         \\[delete-other-windows]
  `split-window-vertically'      \\[split-window-vertically]
  `split-window-horizontally'    \\[split-window-horizontally]
  `other-window'                 \\[other-window]

  `winsize-save-window-configuration'       \\[winsize-save-window-configuration]
  `winsize-next-window-configuration'       \\[winsize-next-window-configuration]
  `winsize-previous-window-configuration'   \\[winsize-previous-window-configuration]

  `mouse-set-point'   \\[mouse-set-point]

  `winsize-quit'               \\[winsize-quit]
  `winsize-stop-go-back'       \\[winsize-stop-go-back]
  `winsize-stop'               \\[winsize-stop]
  `winsize-stop-and-execute'   \\[winsize-stop-and-execute]

  `winsize-help'          \\[winsize-help]
  `describe-key'          \\[describe-key]
  `describe-key-briefly'  \\[describe-key-briefly]
  (All the normal help keys work, and it least those above will
  play well with resizing.)

Nearly all other keys exits window resizing and they are also
executed.  However, the key sequences in `winsize-let-me-use' and
dito for commands there are also executed without exiting
resizing.

The colors of the modelines are changed to those given in
`winsize-mode-line-colors' to indicate that you are resizing
windows.  To make this indication more prominent the text in the
selected window is marked with the face hold in the variable
`winsize-selected-window-face'.

As you select other borders or move to new a window the mouse
pointer is moved inside the selected window to show which borders
are beeing moved. The mouse jumps a little bit to make its
position more visible. You can turn this off by customizing
`winsize-make-mouse-prominent'.

Which borders initially are choosen are controlled by the
variable `winsize-autoselect-borders'.

** Example: Border selection, movements and windows.

  Suppose you have a frame divided into windows like in the
  figure below.  If window B is selected when you start resizing
  then \(with default settings) the borders marked with 'v' and
  'h' will be the ones that the arrow keys moves. To indicate
  this the mouse pointer is placed in the right lower corner of
  the selected window B.

    +----------+-----------+--------+
    |          |           v        |
    |          |           v        |
    |    A     |    _B_    v        |
    |          |           v        |
    |          |           v        |
    |          |         x v        |
    +hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh+
    |                    |          |
    |                    |          |
    |                    |          |
    |                    |          |
    |                    |          |
    |                    |          |
    +----------+---------+----------+

  Now if you press M-<left> then the picture below shows what has
  happened. Note that the selected vertical border is now the one
  between A and B. The mouse pointer has moved to the
  corresponding corner in the window B, which is still selected.

    +----------+-----------+--------+
    |          v           |        |
    |          v           |        |
    |    A     v    _B_    |        |
    |          v           |        |
    |          v           |        |
    |          v x         |        |
    +hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh+
    |                    |          |
    |                    |          |
    |                    |          |
    |                    |          |
    |                    |          |
    |                    |          |
    +----------+---------+----------+

  Press M-<left> once again. This gives this picture:

    +----------+-----------+--------+
    |          v           |        |
    |          v           |        |
    |   _A_    v     B     |        |
    |          v           |        |
    |          v           |        |
    |        x v           |        |
    +hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh+
    |                    |          |
    |                    |          |
    |                    |          |
    |                    |          |
    |                    |          |
    |                    |          |
    +----------+---------+----------+

  Note that the window A is now selected. However there is no
  border that could be moved to the left of this window \(which
  would otherwise be chosen now) so the border between A and B is
  still the one that <left> and <right> moves. The mouse has
  moved to A.

  If we now delete window A the new situation will look like
  this:

    +----------+-----------+--------+
    |                      |        |
    |                      |        |
    |         _B_          |        |
    |                      |        |
    |                      |        |
    |                    x |        |
    +hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh+
    |                    |          |
    |                    |          |
    |                    |          |
    |                    |          |
    |                    |          |
    |                    |          |
    +----------+---------+----------+



>>>> testing stuff >>>>
`help-mode-hook'
`temp-buffer-show-function'
`view-exit-action'
<<<<<<<<<<<<<<<<<<<<<<<
"
  (interactive)
  (setq winsize-resizing t)
  ;; Save old values:
  (unless winsize-old-temp-buffer-show-function
    (when (eq temp-buffer-show-function 'winsize-temp-buffer-show-function)
      (error "temp buffer show function is winsize value"))
    (when (eq temp-buffer-show-function 'winsize-temp-buffer-show-function-1)
      (error "temp buffer show function is winsize value -1"))
    (setq winsize-old-temp-buffer-show-function temp-buffer-show-function))
  (unless winsize-old-mouse-avoidance-mode
    (setq winsize-old-mouse-avoidance-mode mouse-avoidance-mode))
  ;; Setup help hooks etc:
  (setq temp-buffer-show-function 'winsize-temp-buffer-show-function)
  ;; Setup user feedback things:
  (mouse-avoidance-mode 'none)
  (winsize-set-mode-line-colors t)
  (winsize-create-short-help-message)
  (setq winsize-message-end (winsize-message-end))
  ;; Save config for exiting:
  (setq winsize-window-config-init (current-window-configuration))
  (setq winsize-window-at-entry (selected-window))
  (setq winsize-frame (selected-frame))
  ;; Setup keymap and command hooks etc:
  (winsize-setup-local-map)
  (winsize-add-command-hooks)
  (setq winsize-window-for-side-hor nil)
  (setq winsize-window-for-side-ver nil))


(defun winsize-setup-local-map ()
  "Setup an overriding keymap and use this during resizing.
Save current keymaps."
  ;; Fix-me: use copy-keymap for old?
  (unless winsize-old-overriding-terminal-local-map
    (setq winsize-old-overriding-terminal-local-map overriding-terminal-local-map))
  (setq overriding-terminal-local-map (copy-keymap winsize-keymap))
  (setq winsize-old-overriding-local-map-menu-flag overriding-local-map-menu-flag)
  (setq overriding-local-map-menu-flag t))

(defun winsize-restore-local-map ()
  "Restore keymaps saved by `winsize-setup-local-map'."
  (setq overriding-terminal-local-map winsize-old-overriding-terminal-local-map)
  (setq winsize-old-overriding-terminal-local-map nil)
  (setq overriding-local-map-menu-flag winsize-old-overriding-local-map-menu-flag)
  (setq winsize-old-overriding-local-map-menu-flag nil))


(defvar winsize-window-config-init nil
  "Hold window configuration from resizing start.")

(defvar winsize-window-config-help nil
  "Hold window configuration when help is shown.")

(defvar winsize-window-config-init-help nil
  "Hold window configuration from resizing start during help.")

(defun winsize-restore-after-help (buffer)
  "Restore window configuration after help.
Raise frame and reactivate resizing."
  (remove-hook 'temp-buffer-setup-hook 'winsize-help-mode-hook-function)
  (setq temp-buffer-show-function winsize-old-temp-buffer-show-function)
  ;; Get rid of the view exit action and the extra text in the help
  ;; buffer:
  (with-current-buffer (help-buffer)
    (setq view-exit-action winsize-old-view-exit-action)
    (setq winsize-old-view-exit-action nil)
    (let ((here (point-marker))
          (inhibit-read-only t))
      (goto-char (point-min))
      (forward-line 2)
      (delete-region (point-min) (point))
      (goto-char (point-max))
      (forward-line -2)
      (delete-region (point) (point-max))
      (goto-char here)))
  ;; Restart resizing, restoring window configurations:
  (when (select-frame winsize-help-frame)
    (raise-frame)
    (set-window-configuration winsize-window-config-help)
    (resize-windows)
    (setq winsize-window-config-init winsize-window-config-init-help)))

(defvar winsize-help-frame nil
  "The frame from which help was called.")

(defun winsize-help-mode-hook-function ()
  "Setup temp buffer show function to only run second step.
The first step, `winsize-temp-buffer-show-function', has already been run."
  (setq temp-buffer-show-function 'winsize-temp-buffer-show-function-1))

(defun winsize-temp-buffer-show-function (buffer)
  "First step of setup for showing help during resizing.
This step is run when showing help during resizing.

Save window configuration etc to be able to resume resizing. Stop
resizing. Delete other windows.

Run second step (`winsize-temp-buffer-show-function-1') and
arrange so that second step is run when following help links."
  (setq winsize-window-config-help (current-window-configuration))
  (setq winsize-window-config-init-help winsize-window-config-init)
  (setq winsize-help-frame (selected-frame))
  (winsize-stop)
  (delete-other-windows)
  (winsize-temp-buffer-show-function-1 buffer)
  (add-hook 'temp-buffer-setup-hook 'winsize-help-mode-hook-function))

(defun winsize-temp-buffer-show-function-1 (buffer)
  "Second step of setup for showing help during resizing.
This is run after the first step when accessing help during
resizing. It is also when following help links."
  (with-current-buffer buffer
    (let ((inhibit-read-only t)
          (buffer-read-only t) ;; It is reverted in `help-mode-finish'
          )
      (run-hooks 'temp-buffer-show-hook))
    (let ((here (point-marker))
          (str "*** Type q to return to window resizing ***"))
      (put-text-property 0 (length str) 'face 'highlight str)
      (goto-char (point-min))
      (insert str "\n\n")
      (goto-char (point-max))
      (insert "\n\n" str)
      (goto-char here)
      (setq buffer-read-only t))
    (unless winsize-old-view-exit-action
      (setq winsize-old-view-exit-action view-exit-action))
    (setq view-exit-action 'winsize-restore-after-help))
  (set-window-buffer (selected-window) buffer)
  (message "Type q to return to window resizing"))

;; Fix-me: Maybe take care of popup help too.
(defun winsize-help ()
  "Give help during resizing.
Save current window configuration and pause resizing."
  (interactive)
  (with-output-to-temp-buffer (help-buffer)
    (with-current-buffer (help-buffer)
      (insert "resize-windows is ")
      (describe-function-1 'resize-windows))))

(defun winsize-quit ()
  "Quit resing, restore window configuration at start."
  (interactive)
  (set-window-configuration winsize-window-config-init)
  (winsize-exit-resizing nil))

(defun winsize-stop-go-back ()
  "Exit window resizing.  Go back to the window started in."
  (interactive)
  (winsize-exit-resizing nil t))

(defun winsize-stop-and-execute ()
  "Exit window resizing and put last key on the input queue.
Select the window marked during resizing before putting back the
last key."
  ;; Fix-me: maybe replace this with a check of this-command in
  ;; post-command-hook instead?
  (interactive)
  (winsize-exit-resizing t))

(defun winsize-stop ()
  "Exit window resizing.
Select the window marked during resizing."
  (interactive)
  (winsize-exit-resizing nil))

(defun winsize-balance-siblings ()
  "Make current window siblings the same height or width.
It works the same way as `balance-windows', but only for the
current window and its siblings."
  (interactive)
  (balance-windows (selected-window)))

(defun winsize-to-border-or-window-left ()
  "Switch to border leftwards, maybe moving to next window.
If already at the left border, then move to left window, the same
way `windmove-left' does."
  (interactive) (winsize-switch-border 'left t))

(defun winsize-to-border-or-window-right ()
  "Switch to border rightwards, maybe moving to next window.
For more information see `winsize-to-border-or-window-left'."
  (interactive) (winsize-switch-border 'right t))

(defun winsize-to-border-or-window-up ()
  "Switch to border upwards, maybe moving to next window.
For more information see `winsize-to-border-or-window-left'."
  (interactive) (winsize-switch-border 'up t))

(defun winsize-to-border-or-window-down ()
  "Switch to border downwards, maybe moving to next window.
For more information see `winsize-to-border-or-window-left'."
  (interactive) (winsize-switch-border 'down t))


(defun winsize-move-border-left ()
  "Move border left, but select border first if not done."
  (interactive) (winsize-resize 'left nil))

(defun winsize-move-border-right ()
  "Move border right, but select border first if not done."
  (interactive) (winsize-resize 'right nil))

(defun winsize-move-border-up ()
  "Move border up, but select border first if not done."
  (interactive) (winsize-resize 'up nil))

(defun winsize-move-border-down ()
  "Move border down, but select border first if not done."
  (interactive) (winsize-resize 'down nil))


(defun winsize-move-other-border-left ()
  "Move border left, but select border first if not done."
  (interactive) (winsize-resize 'left t))

(defun winsize-move-other-border-right ()
  "Move border right, but select border first if not done."
  (interactive) (winsize-resize 'right t))

(defun winsize-move-other-border-up ()
  "Move border up, but select border first if not done."
  (interactive) (winsize-resize 'up t))

(defun winsize-move-other-border-down ()
  "Move border down, but select border first if not done."
  (interactive) (winsize-resize 'down t))


;;; Custom variables

(defcustom winsize-autoselect-borders t
  "Determines how borders are selected by default.
If nil hever select borders automatically (but keep them on the
same side while changing window).  If 'when-single select border
automatically if there is only one possible choice.  If t alwasy
select borders automatically if they are not selected."
  :type '(choice (const :tag "Always" t)
                 (const :tag "When only one possbility" when-single)
                 (const :tag "Never" nil))
  :group 'winsize)

(defcustom winsize-mode-line-colors (list t (list "green" "green4"))
  "Mode line colors used during resizing."
  :type '(list (boolean :tag "Enable mode line color changes during resizing")
               (list
                (color :tag "- Active window mode line color")
                (color :tag "- Inactive window mode line color")))
  :group 'winsize)

(defcustom winsize-mark-selected-window t
  "Mark selected window if non-nil."
  :type 'boolean
  :group 'winsize)

(defcustom winsize-make-mouse-prominent t
  "Try to make mouse more visible during resizing.
The mouse is positioned next to the borders that you can move.
It can however be hard to see if where it is.  Setting this to on
makes the mouse jump a few times."
  :type 'boolean
  :group 'winsize)

(defvar widget-command-prompt-value-history nil
  "History of input to `widget-function-prompt-value'.")

(define-widget 'command 'restricted-sexp
  "A Lisp function."
  :complete-function (lambda ()
		       (interactive)
		       (lisp-complete-symbol 'commandp))
  :prompt-value 'widget-field-prompt-value
  :prompt-internal 'widget-symbol-prompt-internal
  :prompt-match 'commandp
  :prompt-history 'widget-command-prompt-value-history
  :action 'widget-field-action
  :match-alternatives '(commandp)
  :validate (lambda (widget)
	      (unless (commandp (widget-value widget))
		(widget-put widget :error (format "Invalid command: %S"
						  (widget-value widget)))
		widget))
  :value 'ignore
  :tag "Command")

(defcustom winsize-let-me-use '(next-line ;;[(control ?n)]
                                previous-line ;;[(control ?p)]
                                forward-char ;;[(control ?f)]
                                backward-char ;;[(control ?b)]
                                [(home)]
                                [(end)]
                                ;; Fix-me: replace this with something
                                ;; pulling in help-event-list:
                                [(f1)]
                                execute-extended-command
                                eval-expression)
  "Key sequences or commands that should not be overriden during resize.
The purpose is to make it easier to switch windows.  The functions
`windmove-left' etc depends on the position when chosing the
window to move to."
  :type '(repeat
          (choice
           ;; Note: key-sequence must be before command here, since
           ;; the key sequences seems to match command too.
           key-sequence command))
  :set (lambda (sym val)
         (set-default sym val)
         (winsize-make-keymap val))
  :group 'winsize)

(defcustom winsize-selected-window-face 'winsize-selected-window-face
  "Variable holding face for marking selected window.
This variable may be nil or a face symbol."
  :type '(choice (const :tag "Do not mark selected window" nil)
                 face)
  :group 'winsize)

(defface winsize-selected-window-face
  '((t (:inherit 'secondary-selection)))
  "Face for marking selected window."
  :group 'winsize)

;;; Internals

;; These variables all holds values to be reset when exiting resizing:
(defvar winsize-old-mode-line-bg nil)
(defvar winsize-old-mode-line-inactive-bg nil)
(defvar winsize-old-overriding-terminal-local-map nil)
(defvar winsize-old-overriding-local-map-menu-flag nil)
(defvar winsize-old-temp-buffer-show-function nil)
(defvar winsize-old-mouse-avoidance-mode nil
  "Hold the value of `mouse-avoidance-mode' at resizing start.")
(defvar winsize-old-view-exit-action nil)
(make-variable-buffer-local 'winsize-old-view-exit-action)


(defvar winsize-resizing nil
  "t during resizing, nil otherwise.")

(defvar winsize-window-at-entry nil
  "Window that was selected when `resize-windows' started.")

(defvar winsize-frame nil
  "Frame that `resize-windows' is operating on.")

(defun winsize-exit-resizing (put-back-last-event &optional stay)
  "Stop window resizing.
Put back mode line colors and keymaps that were changed.

Upon exit first select window.  If STAY is non-nil then select
the window which was selected when `resize-windows' was called,
otherwise select the last window used during resizing.  After
that, if PUT-BACK-LAST-EVENT is non-nil, put back the last input
event on the input queue."
  (setq winsize-resizing nil)
  ;; Reset user feedback things:
  (mouse-avoidance-mode winsize-old-mouse-avoidance-mode)
  (setq winsize-old-mouse-avoidance-mode nil)
  (winsize-set-mode-line-colors nil)
  (winsize-mark-selected-window nil)
  ;; Remove all hooks etc for help:
  (when (eq winsize-old-temp-buffer-show-function 'winsize-temp-buffer-show-function)
    (error "winsize old temp buffer function is winsize value"))
  (when (eq winsize-old-temp-buffer-show-function 'winsize-temp-buffer-show-function-1)
    (error "winsize old temp buffer function is winsize value -1"))
  (setq temp-buffer-show-function winsize-old-temp-buffer-show-function)
  (setq winsize-old-temp-buffer-show-function nil)
  (remove-hook 'help-mode-hook 'winsize-help-mode-hook-function)
  (remove-hook 'temp-buffer-setup-hook 'winsize-help-mode-hook-function)
  ;; Restore keymap and command hooks:
  (winsize-restore-local-map)
  (winsize-remove-command-hooks)
  ;; Exit:
  (when stay (select-window winsize-window-at-entry))
  (message "Exited window resizing")
  (when (and put-back-last-event)
    ;; Add this to the input queue again:
    (isearch-unread last-command-event)))

(defun winsize-add-command-hooks ()
  (add-hook 'pre-command-hook 'winsize-pre-command)
  (add-hook 'post-command-hook 'winsize-post-command))

(defun winsize-remove-command-hooks ()
  (remove-hook 'pre-command-hook 'winsize-pre-command)
  (remove-hook 'post-command-hook 'winsize-post-command))


;;; Borders

(defvar winsize-window-for-side-hor nil
  "Window used internally for resizing in vertical direction.")

(defvar winsize-window-for-side-ver nil
  "Window used internally for resizing in horizontal direction.")

(defvar winsize-border-hor nil
  "Use internally to remember border choice.
This is set by `winsize-pre-command' and checked by
`winsize-post-command', see the latter for more information.

The value should be either nil, 'left or 'right.")

(defvar winsize-border-ver nil
  "Use internally to remember border choice.
This is set by `winsize-pre-command' and checked by
`winsize-post-command', see the latter for more information.

The value should be either nil, 'up or 'down.")

(defun winsize-border-used-hor()
  "Return the border side used for horizontal resizing."
  (let ((hor (when winsize-window-for-side-hor
               (if (eq (selected-window) winsize-window-for-side-hor)
                   'right
                 'left))))
    hor))

(defun winsize-border-used-ver()
  "Return the border side used for vertical resizing."
  (let ((ver (when winsize-window-for-side-ver
               (if (eq (selected-window) winsize-window-for-side-ver)
                   'down
                 'up))))
    ver))

(defun winsize-switch-border (dir allow-windmove)
  "Switch border that is beeing resized.
Switch to border in direction DIR.  If ALLOW-WINDMOVE is non-nil
then change window if necessary, otherwise stay and do not change
border."
  (let* ((window-in-that-dir (windmove-find-other-window
                              dir nil (selected-window))))
    (when (window-minibuffer-p window-in-that-dir)
      (setq window-in-that-dir nil))
    (if juris-way
        (if (not window-in-that-dir)
            (message "No window in that direction")
          (windmove-do-window-select dir nil))
      (if (not window-in-that-dir)
          (message "No window or border in that direction")
        (let* ((is-hor (memq dir '(left right)))
               (border-used (if is-hor
                                (winsize-border-used-hor)
                              (winsize-border-used-ver)))
               (using-dir-border (eq dir border-used)))
          (if using-dir-border
              (when allow-windmove
                (setq winsize-window-for-side-hor nil)
                (setq winsize-window-for-side-ver nil)
                (windmove-do-window-select dir nil)
                (message "Moved to new window"))
            (winsize-select-border dir)
            (message "Switched to border %swards" dir)))))))


(defun winsize-select-initial-border-hor ()
  "Select a default border horizontally."
  (if juris-way
      (winsize-set-border 'right t)
    (let ((has-left  (winsize-window-beside (selected-window) 'left))
          (has-right (winsize-window-beside (selected-window) 'right)))
      (cond
       ((not winsize-autoselect-borders) t)
       ((eq winsize-autoselect-borders 'when-single)
        (when (= 1 (length (delq nil (list has-left has-right))))
          (winsize-select-border 'right)))
       (t
        (winsize-select-border 'right))))))

(defun winsize-select-initial-border-ver ()
  "Select a default border vertically."
  (if juris-way
      (winsize-set-border 'up t)
    (let ((has-up  (winsize-window-beside (selected-window) 'up))
          (has-down (winsize-window-beside (selected-window) 'down)))
      (cond
       ((not winsize-autoselect-borders) t)
       ((eq winsize-autoselect-borders 'when-single)
        (when (= 1 (length (delq nil (list has-up has-down))))
          (winsize-select-border 'up)))
       (t
        (winsize-select-border 'up))))))

(defun winsize-select-border (dir)
  "Select border to be set for resizing.
The actually setting is done in `post-command-hook'."
  (cond
   ((memq dir '(left right))
    (setq winsize-border-hor dir))
   ((memq dir '(up down))
    (setq winsize-border-ver dir))
   (t (error "Bad DIR=%s" dir))))

(defun winsize-set-border (dir allow-other-side)
  "Set border for resizing."
  (let ((window-beside (winsize-window-beside (selected-window) dir))
        (horizontal (memq dir '(left right))))
    (unless window-beside
      (when allow-other-side
        (setq dir (winsize-other-side dir))
        (setq window-beside
              (winsize-window-beside (selected-window) dir))))
    (if horizontal
        (progn
          (setq winsize-border-hor nil)
          (setq winsize-window-for-side-hor nil))
      (setq winsize-border-ver nil)
      (setq winsize-window-for-side-ver nil))
    (when window-beside
      (let ((window-for-side (if (memq dir '(right down))
                                 (selected-window)
                               window-beside)))
        (if horizontal
            (setq winsize-window-for-side-hor window-for-side)
          (setq winsize-window-for-side-ver window-for-side))))))

(defcustom juris-way t
  ""
  :type 'boolean)

(defun winsize-resize (dir other-side)
  "Choose border to move.  Or if border is chosen move that border.
Used by `winsize-move-border-left' etc."
  (when juris-way
    (let ((bside (if (memq dir '(left right))
                     (if other-side 'left 'right)
                   (if other-side 'up 'down))))
      (winsize-set-border bside t)))
  (let* ((horizontal (memq dir '(left right)))
         (arg (if (memq dir '(left up)) -1 1))
         (window-for-side (if horizontal 'winsize-window-for-side-hor 'winsize-window-for-side-ver))
         (window-for-side-val (symbol-value window-for-side)))
    (if (not window-for-side-val)
        (winsize-select-border dir)
      (when (and winsize-resizing
                 (not (eq window-for-side-val 'checked)))
        (condition-case err
            (adjust-window-trailing-edge (symbol-value window-for-side) arg horizontal)
          (error (message "%s" (error-message-string err))))))))

(defun winsize-other-side (side)
  "Return other side for 'left etc, ie 'left => 'right."
  (cond
    ((eq side 'left) 'right)
    ((eq side 'right) 'left)
    ((eq side 'up) 'down)
    ((eq side 'down) 'up)
    (t (error "Invalid SIDE=%s" side))))

(defun winsize-window-beside (window side)
  "Return a window directly beside WINDOW at side SIDE.
That means one whose edge on SIDE is touching WINDOW.  SIDE
should be one of 'left, 'up, 'right and 'down."
  (require 'windmove)
  (let* ((windmove-wrap-around nil)
         (win (windmove-find-other-window side nil window)))
    (unless (window-minibuffer-p win)
      win)))


;;; Window configs

(defconst winsize-window-configuration-ring (make-ring 20)
  "Hold window configurations.")

(defun winsize-ring-rotate (ring forward)
  (when (< 1 (ring-length ring))
    (if forward
        (ring-insert ring (ring-remove ring nil))
      (ring-insert-at-beginning ring (ring-remove ring 0)))))

(defun winsize-ring-index (ring elem)
  (let ((memb (member elem (ring-elements ring))))
    (when memb
      (- (ring-length ring)
         (length memb)))))

(defun winsize-previous-window-configuration ()
  (interactive)
  (winsize-goto-window-configuration nil))

(defun winsize-next-window-configuration ()
  (interactive)
  (winsize-goto-window-configuration t))

(defun winsize-goto-window-configuration (forward)
  (let* ((curr-conf (current-window-configuration))
         (ring winsize-window-configuration-ring)
         (idx (winsize-ring-index ring curr-conf)))
    (if idx
        (progn
          (setq idx (if forward (1- idx) (1+ idx)))
          (set-window-configuration (ring-ref ring idx)))
      ;; Unfortunately idx often seems to be nil so we will have to
      ;; rotate the ring (or something similar).
      (winsize-ring-rotate ring forward)
      (set-window-configuration (ring-ref ring 0)))))

(defun winsize-save-window-configuration ()
  (interactive)
  (let* ((curr-conf (current-window-configuration))
         (ring winsize-window-configuration-ring))
    (if (winsize-ring-index ring curr-conf)
        (error "Current configuration was already stored")
      (ring-insert ring curr-conf)
      (message "Saved window config, use '<' or '>' to get it back"))))


;;; User feedback

(defun winsize-set-mode-line-colors (on)
  "Turn mode line colors on if ON is non-nil, otherwise off."
  (if on
      (progn
        (unless winsize-old-mode-line-inactive-bg
          (setq winsize-old-mode-line-inactive-bg (face-attribute 'mode-line-inactive :background)))
        (unless winsize-old-mode-line-bg
          (setq winsize-old-mode-line-bg (face-attribute 'mode-line :background)))
        (let* ((use-colors (car winsize-mode-line-colors))
               (colors (cadr winsize-mode-line-colors))
               (active-color (elt colors 0))
               (inactive-color (elt colors 1)))
          (when use-colors
            (set-face-attribute 'mode-line-inactive nil :background inactive-color)
            (set-face-attribute 'mode-line nil :background active-color))))
    (set-face-attribute 'mode-line-inactive nil :background winsize-old-mode-line-inactive-bg)
    (setq winsize-old-mode-line-inactive-bg nil)
    (set-face-attribute 'mode-line nil :background winsize-old-mode-line-bg)
    (setq winsize-old-mode-line-bg nil)))

(defvar winsize-short-help-message nil
  "Short help message shown in echo area.")

(defun winsize-create-short-help-message ()
  "Create short help message to show in echo area."
  (let ((msg ""))
    (mapc (lambda (rec)
            (let ((fun (elt rec 0))
                  (desc (elt rec 1))
                  (etc (elt rec 2)))
              (when (< 0 (length msg))
                (setq msg (concat msg ", ")))
              (setq msg (concat msg
                                desc
                                ":"
                                (key-description
                                 (where-is-internal fun winsize-keymap t))
                                (if etc " etc" "")))))
          '(
            (balance-windows "balance" nil)
            (winsize-move-border-left "resize" t)
            (winsize-to-border-or-window-left "border" nil)
            ))
    (setq msg (concat msg ", exit:RET, help:?"))
    (setq winsize-short-help-message msg)))

(defun winsize-move-mouse-to-resized ()
  "Move mouse to show which border(s) are beeing moved."
  (let* ((edges (window-edges (selected-window)))
         (L (nth 0 edges))
         (T (nth 1 edges))
         (R (nth 2 edges))
         (B (nth 3 edges))
         (x (/ (+ L R) 2))
         (y (/ (+ T B) 2)))
    (when (and winsize-window-for-side-hor
               (not (eq winsize-window-for-side-hor 'checked)))
      (setq x (if (eq (selected-window) winsize-window-for-side-hor) (- R 6) (+ L 2))))
    (when (and winsize-window-for-side-ver
               (not (eq winsize-window-for-side-ver 'checked)))
      (setq y (if (eq (selected-window) winsize-window-for-side-ver) (- B 2) (+ T 0))))
    (set-mouse-position (selected-frame) x y)))

(defvar winsize-selected-window-overlay nil)

(defun winsize-mark-selected-window (active)
  (when winsize-selected-window-overlay
    (delete-overlay winsize-selected-window-overlay)
    (setq winsize-selected-window-overlay nil))
  (when active
    (with-current-buffer (window-buffer (selected-window))
      (let ((ovl (make-overlay (point-min) (point-max))))
        (setq winsize-selected-window-overlay ovl)
        (overlay-put ovl 'window (selected-window))
        (overlay-put ovl 'pointer 'arrow)
        (overlay-put ovl 'priority 1000)
        (when winsize-selected-window-face
          (overlay-put ovl 'face winsize-selected-window-face))))))

(defvar winsize-message-end nil
  "Marker, maybe at end of message buffer.")

(defun winsize-message-end ()
  "Return a marker at the end of the message buffer."
  (with-current-buffer (get-buffer-create "*Messages*")
    (point-max-marker)))

(defvar winsize-move-mouse 1)

(defun winsize-move-mouse ()
  ;;(setq winsize-move-mouse (- winsize-move-mouse))
  (let* ((fxy (mouse-pixel-position))
         (f (car fxy))
         (x (cadr fxy))
         (y (cddr fxy))
         (m (mod winsize-move-mouse 2))
         (d (* (if (= 0 m) 1 -1) 1)))
    (set-mouse-pixel-position f (+ d x) (+ d y))
    (when (< 1 winsize-move-mouse)
      (setq winsize-move-mouse (1- winsize-move-mouse))
      (setq winsize-make-mouse-prominent-timer
            (run-with-timer 0.2 nil 'winsize-move-mouse)))))

(defvar winsize-make-mouse-prominent-timer nil)

(defun winsize-make-mouse-prominent-f (doit)
  (when (and winsize-make-mouse-prominent-timer
             (timerp winsize-make-mouse-prominent-timer))
    (cancel-timer winsize-make-mouse-prominent-timer))
  (when doit
    (setq winsize-move-mouse 3)
    (setq winsize-make-mouse-prominent-timer
          (run-with-idle-timer 0.1 nil 'winsize-move-mouse))))

(defun winsize-tell-user ()
  "Give the user feedback."
  (when winsize-mark-selected-window
    (winsize-mark-selected-window t))
  (unless juris-way
    (let ((move-mouse (not (member this-command
                                   '(mouse-drag-mode-line
                                     mouse-drag-vertical-line
                                     scroll-bar-toolkit-scroll)))))
      ;;(message "%s, move-mouse=%s" this-command move-mouse);(sit-for 2)
      (when move-mouse
        (winsize-move-mouse-to-resized))
      (when winsize-make-mouse-prominent
        (winsize-make-mouse-prominent-f move-mouse))))
  (when (= winsize-message-end (winsize-message-end))
    (message "%s" winsize-short-help-message)))


(provide 'winsize)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; winsize.el ends here

[-- Attachment #3: Type: text/plain, Size: 13 bytes --]


-- 
Bastien

Re: Release plans

[Chong Yidong]

Bastien <bastienguerry@googlemail.com> writes:

> A long time ago, Lennart proposed to integrate a library implementing an
> easy way for resizing windows.  See email <47BF64AF.1000105@gmail.com>
> on [emacs-devel] to jump back into this discussion.
>
> I attach the last version I'm aware of (0.96) of Lennart's windsize.el
> -- maybe this is not the latest version, Lennart can you confirm?
>
> As I had a slightly different approach and I coded windresize.el:
>
>   http://www.cognition.ens.fr/~guerry/u/windresize.el
>
> Maybe one of these libraries could be part of Emacs at some point.

Please ping again after the release.

Thanks.

Re: Release plans

[Lennart Borgman (gmail)]

Chong Yidong wrote:
> Bastien <bastienguerry@googlemail.com> writes:
> 
>> A long time ago, Lennart proposed to integrate a library implementing an
>> easy way for resizing windows.  See email <47BF64AF.1000105@gmail.com>
>> on [emacs-devel] to jump back into this discussion.
>>
>> I attach the last version I'm aware of (0.96) of Lennart's windsize.el
>> -- maybe this is not the latest version, Lennart can you confirm?

Yes, it is correct. I distribute it as part of the nXhtml package.

>> As I had a slightly different approach and I coded windresize.el:
>>
>>   http://www.cognition.ens.fr/~guerry/u/windresize.el
>>
>> Maybe one of these libraries could be part of Emacs at some point.
> 
> Please ping again after the release.
> 
> Thanks.

Will do.

Bastien, I guess we both dropped out because the ideas were getting too 
many and too wild. Can we continue after the release with the ideas we 
really feel fits?

Re: Release plans

[Bastien]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> Bastien, I guess we both dropped out because the ideas were getting too
> many and too wild. Can we continue after the release with the ideas we
> really feel fits?

Yes, sure.  I have a small TODO list for windresize.el, I'd happily hack
it a bit when I'm done with my current project.  Let's get back on this
in late september.

Best,

-- 
Bastien

Re: Release plans

[Jay Belanger]

> Just a reminder: we will begin the feature freeze for Emacs 23.1 at the
> end of this month.

A while back, I came across a note saying that any package that is
developed within Emacs shouldn't have it's own version numbering.  I've
looked in vain for that note, but have been unable to find it.  However,
Calc is now a fully owned subsidiary of Emacs, Inc., so is there any
reason why Calc should have its own version number?

Jay

Re: Release plans

[Chong Yidong]

Jay Belanger <jay.p.belanger@gmail.com> writes:

>> Just a reminder: we will begin the feature freeze for Emacs 23.1 at the
>> end of this month.
>
> A while back, I came across a note saying that any package that is
> developed within Emacs shouldn't have it's own version numbering.  I've
> looked in vain for that note, but have been unable to find it.  However,
> Calc is now a fully owned subsidiary of Emacs, Inc., so is there any
> reason why Calc should have its own version number?

Quite a few packages use their own version numbers.  I think some
maintainers find these helpful for, e.g., distinguishing between the
versions in the Emacs tree and those distributed seperately.

Re: Release plans

[Jay Belanger]

Chong Yidong <cyd@stupidchicken.com> writes:
...
>> A while back, I came across a note saying that any package that is
>> developed within Emacs shouldn't have it's own version numbering.  I've
>> looked in vain for that note, but have been unable to find it.  However,
>> Calc is now a fully owned subsidiary of Emacs, Inc., so is there any
>> reason why Calc should have its own version number?
>
> Quite a few packages use their own version numbers.  I think some
> maintainers find these helpful for, e.g., distinguishing between the
> versions in the Emacs tree and those distributed seperately.

But in this case, Emacs Calc is developed within Emacs.
Referring to Calc 2.2, for example, gives no indication of where to get
it, referring to Calc in Emacs 23.1 does.  (As does referring to Calc
2.2 in Emacs 23.1, but I don't see the point of the 2.2 here.)
As it is, since Emacs Calc is continually being modified but only
released when Emacs is released, the Emacs Calc version will simply be
bumped up for every Emacs release; that's not that big of a deal, but I
don't really see the point.

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
>
> XEmacs packages it separately, and will continue to do so for the
> foreseeable future.  Until y'all move to a tree-oriented VCS version
> numbers (and tags in the Calc portion of the tree) would be helpful in
> comparing what we got to upstream.

XEmacs Calc is a separate branch, and not even the version numbering is
kept in sync.  I don't see how the Emacs Calc version number is more
helpful than the Emacs version number when referring to Emacs Calc.
(I could be missing something, of course.)

Jay

Re: Release plans

[Stephen J. Turnbull]

Jay Belanger writes:

 > A while back, I came across a note saying that any package that is
 > developed within Emacs shouldn't have it's own version numbering.  I've
 > looked in vain for that note, but have been unable to find it.  However,
 > Calc is now a fully owned subsidiary of Emacs, Inc., so is there any
 > reason why Calc should have its own version number?

XEmacs packages it separately, and will continue to do so for the
foreseeable future.  Until y'all move to a tree-oriented VCS version
numbers (and tags in the Calc portion of the tree) would be helpful in
comparing what we got to upstream.

Re: Release plans

[Richard M Stallman]

    A while back, I came across a note saying that any package that is
    developed within Emacs shouldn't have it's own version numbering.

The reason I started asking people not to put version numbers in the
Lisp programs included in Emacs is that they tend to be time wasters.
But that problem happens mainly when the program's maintainer sends
patches for us to install.  But since you maintain Calc directly in
the Emacs repository, the only person whose time it costs is yours.
So you may as well do whatever you prefer about this.

Re: Release plans

[Bill Wohler]

Jay Belanger <jay.p.belanger@gmail.com> writes:

>> Just a reminder: we will begin the feature freeze for Emacs 23.1 at the
>> end of this month.
>
> A while back, I came across a note saying that any package that is
> developed within Emacs shouldn't have it's own version numbering.  I've
> looked in vain for that note, but have been unable to find it.  However,
> Calc is now a fully owned subsidiary of Emacs, Inc., so is there any
> reason why Calc should have its own version number?

It would be bad if MH-E was restricted to Emacs' releases. MH-E's
release schedule often has many releases between Emacs releases
(unfortunately, this cycle was an exception).

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD

Re: Release plans

[dhruva]

----- Original Message ----
> Date: Tue, 29 Jul 2008 23:47:30 -0400
> From: Richard M Stallman 
> Subject: Re: Release plans
> To: Eli Zaretskii 
> Cc: emacs-devel@gnu.org
> Message-ID: 
> Content-Type: text/plain; charset=ISO-8859-15
> 
>     > In that case, does the fact that Emacs runs on Windows
>     > help you do these simple jobs?
> 
>     It gives me more opportunities to look at problems that are not
>     specific to some platform.
> 
> Sure, but it also consumes some of your time on Windows support issues.
> If you simply did your editing on the GNU/Linux machine, and did not
> pay attention to Windows support, would your contributions to
> the platform-independent capabilities of Emacs be less, or more?

Emacs is a great editor (and much more). Just because it takes some extra effort to keep it running on a non free OS (which has a significant install base whether we like it or not), please do not consider dropping the port. At work, we do not have the freedom to chose the OS on which we like to work. Since I spend most of my coding time at work, I have to use windows port of Emacs however much I would love to use Emacs on GNU/Linux. I have popularized emacs quite a bit on windows at work, this would have increased the GNU awareness among people working on non-free platforms. Consider this as a GNU/FSF evangelizing through tools like Emacs. 

-dhruva



      Connect with friends all over the world. Get Yahoo! India Messenger at http://in.messenger.yahoo.com/?wm=n/

Re: Release plans

[Richard M Stallman]

To go on using Windows is a bad thing.  Using Emacs at work is
certainly a way of informing other people there about GNU.  But has it
opened up any possibility that you can stop using Windows there?  I
don't think so.  Is there any reason to think that will change in the
next year or two?  If not, then I think this path does not lead to the
goal.

Have you looked for other work where you can use a free operating system?

Re: Release plans

[Alan Mackenzie]

'Morning, Richard!

On Wed, Jul 30, 2008 at 09:59:40PM -0400, Richard M Stallman wrote:
> To go on using Windows is a bad thing.  Using Emacs at work is
> certainly a way of informing other people there about GNU.  But has it
> opened up any possibility that you can stop using Windows there?  I
> don't think so.  Is there any reason to think that will change in the
> next year or two?  If not, then I think this path does not lead to the
> goal.

> Have you looked for other work where you can use a free operating
> system?

We all agree that in an ideal world, we would be running free software
exclusively.  But we differ in the best way of approaching there from
here.

MS-Windows, like fossil-fuelled transportation, is something undesirable,
but difficult to avoid without separating from mainstream society.  If I
were to reject paid work involving MS-Windows and (proprietary) Unix, I
would need to find paid work outside of software development.  I'm not
prepared to go that far, and I don't think it's reasonable of you to
expect this from me and other people on the mailing list.  As far as I
can, I run only free software at home.  However my PC's BIOS is not free,
and neither is the software in my DSL router - yet.  Would you likewise
suggest I should not use DSL until fully free firmware becomes available?

Most of the places I work, the alternatives are (proprietary-OS
Proprietary-aplications) and (proprietary-OS free-applications).  I
advocate the latter, showing people what free software can do.  Sadly,
the freedom in free software doesn't excite most people - Emacs's
capabilities do, though.  So, for that matter, does a 5 line AWK program
as an alternative to stuffing a log file through Excel (a heavyweight
proprietary spreadsheet program).  Often, they show me cool features in
proprietary software, and sometimes I hack up equivalents in my .emacs.

If I were to reject work involving proprietary OS's, this wouldn't
advance free software at all.  The only people to notice would be the
people who expect me to pay their bills, and hopefully the Emacs
development team would notice my absence after my Internet line had been
cut off.  I suspect I am typical of most hackers here in that respect.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Richard M Stallman]

    MS-Windows, like fossil-fuelled transportation, is something undesirable,
    but difficult to avoid without separating from mainstream society.

They are not similar; avoiding Windows is far easier.  Please do not
exaggerate.

      If I
    were to reject paid work involving MS-Windows and (proprietary) Unix, I
    would need to find paid work outside of software development.

I was prepared to do that if necessary in 1984.  Fortunately I
did not have to.  Maybe you wouldn't either.

      As far as I
    can, I run only free software at home.  However my PC's BIOS is not free,

On fsf.org there are recommendations for PCs that run with a free BIOS.

    and neither is the software in my DSL router - yet.  Would you likewise
    suggest I should not use DSL until fully free firmware becomes available?

No, I expect that router does not count.  I'd expect users don't
install software at all in that, so it might as well be a circuit, and
we don't need to ask whether there is actually software inside it.

You are arguing against a straw man that didn't come from me.

      Sadly,
    the freedom in free software doesn't excite most people - Emacs's
    capabilities do, though.

Have you seen any cases where that eventually led a person to switch
from proprietary software to free software?

Re: Release plans

[Frank Schmitt]

Richard M Stallman <rms@gnu.org> writes:

>       Sadly,
>     the freedom in free software doesn't excite most people - Emacs's
>     capabilities do, though.
>
> Have you seen any cases where that eventually led a person to switch
> from proprietary software to free software?

Here!

Emacs (more precisely Gnus) was the first contact I made with free
software. I started using it not because it was free, but because it was
the most powerful newsreader I could find. Now I run a GNU/Linux based
free environment on my home PC, on my PC at work and I installed Linux
on the PCs of my mom (she never ever used proprietary software in her
whole life!) and my wife.

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: Release plans

[Miles Bader]

Hi;

I reworded your signature a bit, so that it fits exactly into four
80-character lines (using two-space sentence ends):

Have you ever considered how much text can fit in eighty columns?  Given that a
signature typically contains up to four lines of text, this space allows you to
attach a tremendous amount of valuable information to your messages.  Seize the
opportunity and don't waste your signature on bullshit that nobody cares about.

-Miles

-- 
The car has become... an article of dress without which we feel uncertain,
unclad, and incomplete.  [Marshall McLuhan, Understanding Media, 1964]

Re: Release plans

[Richard M Stallman]

    Emacs (more precisely Gnus) was the first contact I made with free
    software. I started using it not because it was free, but because it was
    the most powerful newsreader I could find. Now I run a GNU/Linux based
    free environment on my home PC, on my PC at work and I installed Linux
    on the PCs of my mom (she never ever used proprietary software in her
    whole life!) and my wife.

I am glad that Emacs can have this effect.
Did you first run it on Windows?

Re: Release plans

[Frank Schmitt]

Richard M Stallman <rms@gnu.org> writes:

>     Emacs (more precisely Gnus) was the first contact I made with free
>     software. I started using it not because it was free, but because it was
>     the most powerful newsreader I could find. Now I run a GNU/Linux based
>     free environment on my home PC, on my PC at work and I installed Linux
>     on the PCs of my mom (she never ever used proprietary software in her
>     whole life!) and my wife.
>
> I am glad that Emacs can have this effect.
> Did you first run it on Windows?

Yes, I did.

-- 
Have you ever considered how much text can fit in eighty columns?  Given that a
signature typically contains up to four lines of text, this space allows you to
attach a tremendous amount of valuable information to your messages.  Seize the
opportunity and don't waste your signature on bullshit that nobody cares about.

Re: Release plans

[Richard M. Stallman]

    > I am glad that Emacs can have this effect.
    > Did you first run it on Windows?

    Yes, I did.

Well then, Emacs on Windows has in at least one case brought someone
more or less all the way to freedom.  If this happens often, then it could
amount to a good reason to have Emacs run on Windows.

Re: Release plans

[Juanma Barranquero]

On Sun, Aug 3, 2008 at 03:33, Richard M. Stallman <rms@gnu.org> wrote:

> Well then, Emacs on Windows has in at least one case brought someone
> more or less all the way to freedom.  If this happens often, then it could
> amount to a good reason to have Emacs run on Windows.

You're setting a harsh standard for Emacs on Windows. Even GNU/Linux
fails to bring many people "all the way to freedom", because they
still use proprietary software (present in most distributions).

Of course the Windows port's impact is perhaps tiny, but, on the other
hand, is not like maintaining it is sapping the Emacs developers'
resource pool.

Excuse me if I'm wrong, but I read this thread as if you were thinking
of dropping Windows support on Emacs. I fail to see how that would
help freedom. It certainly wouldn't help mine.

  Juanma

Re: Release plans

[Richard M. Stallman]

I did not "set any standard" just now.  I am simply restating, and
applying, the goals of the GNU Project which I set in 1983.

Our goal is not "helping users" (i.e., giving them whatever they
happen to want).  Our goal is establishing freedom for computer users.

Leading people to escape from Windows is a positive result.
Making use of Windows more convenient is not.

Re: Release plans

[Juanma Barranquero]

On Mon, Aug 4, 2008 at 00:42, Richard M. Stallman <rms@gnu.org> wrote:

> Our goal is not "helping users" (i.e., giving them whatever they
> happen to want).  Our goal is establishing freedom for computer users.

That's a strawman. I've not talked about "helping users". The ability
to run Emacs on Windows does not give me "whatever [I] happen to
want". It gives me the four freedoms (run, study, copy, improve) with
respect to Emacs; that I'm running it on Windows is irrelevant. What
you're defending is a very long-term freedom-for-all at the cost of
restricting short-term freedom for those of us who can not, or want
not, to do the switch at once.

> Leading people to escape from Windows is a positive result.
> Making use of Windows more convenient is not.

When I use Emacs on GNU/Linux, I enjoy the freedom of Emacs; I don't
think of it as "making GNU/Linux more convenient"; if anything, Emacs
is making my life more convenient by giving me freedom. And the same
goes for Emacs on Windows.

With respect to your poll: I have not rejected Windows yet, so I'm
certainly using proprietary software. But, OTOH, if I had not found
Emacs on Windows I wouldn't be contributing to Emacs right now. Does
that count as a positive or as a negative in your view?

   Juanma

Re: Release plans

[Davi Leal]

Richard M. Stallman wrote:
> I did not "set any standard" just now.  I am simply restating, and
> applying, the goals of the GNU Project which I set in 1983.
>
> Our goal is not "helping users" (i.e., giving them whatever they
> happen to want).  Our goal is establishing freedom for computer users.

Only for computer users?

Please, could you confirm such 'computer' does not include network routers and 
bridges?  That is to say, routers and bridges which are based on GNU/Linux.

Re: Release plans

[Richard M. Stallman]

    Please, could you confirm such 'computer' does not include network routers and 
    bridges?

Whether a router counts as a computer (a programmable device) for the user
depends on certain facts (as I've already explained).
These may vary from one router to another, and may change in time
as the practices change.  If the router does functions as a computer
for the user, I will say that proprietary software inside it is unethical.
If it does not function as a computer for the user, then I will not
criticize proprietary software in it.  However, it is still
a good thing if the software is free.

What the GNU GPL requires is a different question.
The GNU GPL requirements apply to all distribution of copies.
There is no exception for copies included in devices that
don't function as computers for the user.

Re: Release plans

[Thomas Lord]

Richard M. Stallman wrote:
> I did not "set any standard" just now.  I am simply restating, and
> applying, the goals of the GNU Project which I set in 1983.
>
> Our goal is not "helping users" (i.e., giving them whatever they
> happen to want).  Our goal is establishing freedom for computer users.
>
> Leading people to escape from Windows is a positive result.
> Making use of Windows more convenient is not.
>   

Windows hardly matters anymore.

Windows is not growing much in functionality.  Meanwhile,
what functionality is so often "tied" to it is being whittled away
by programs that run on *any* operating system by sticking to
W3C standards (and closely related de facto standards).

In a sense, the writing is on the wall and the Emacs
*architecture* will inevitably win (although, probably not 
GNU Emacs itself, on the current trajectory):   Javascript
instead of Emacs lisp;  an in-memory, editable DOM object
instead of buffers;  mostly HTTP as the "universal system
call".

Eclipse has attracted a lot of users who, in its absence, would
likely have chosen Emacs.  It is a safe bet, in my opinion, that
what comes next that will "eclipse" Eclipse, will be a Javascript
program that can run in some "A-list browsers".

In this brave new world of W3C standards (and de facto standards
around those) -- the traditional operating system is all but irrelevant.
New programs (of the sort that typical "end-users" run) increasingly
tend to not depend at all on the underlying OS.   The traditional
OS is dead -- irrelevant.

Windows has peaked in terms of its strategic advantages.  It is
doomed to be (slowly) whittled away by new Emacs-architecture / web-
implementation applications.   Supporting or not supporting Windows
in a package like GNU Emacs makes nearly no difference in this
larger trend.   There's a lot of fretting over low stakes here, on this
list.

The more urgent issue concerns the emerging W3C-based world:
what will GNU have to offer there?

-t






>
>
>   

Re: Release plans

[Miles Bader]

Thomas Lord <lord@emf.net> writes:
> The more urgent issue concerns the emerging W3C-based world:
> what will GNU have to offer there?

Hopefully, an alternative...

-Miles

-- 
Quack, n. A murderer without a license.

Re: Release plans

[Thomas Lord]

Miles Bader wrote:
> Thomas Lord <lord@emf.net> writes:
>   
>> The more urgent issue concerns the emerging W3C-based world:
>> what will GNU have to offer there?
>>     
>
> Hopefully, an alternative...
>   

That's pithy but I don't actually get it.   Why call for an alternative?

-t

Re: Release plans

[Richard M. Stallman]

    Windows hardly matters anymore.

    Windows is not growing much in functionality...

Windows is important as a problem as long as it is non-free and
considerable numbers of people keep using it.  It is clear that when
you say it "hardly matters" you are thinking of some other criterion.

    The more urgent issue concerns the emerging W3C-based world:
    what will GNU have to offer there?

If you are talking about the practice of installing non-free software
into a browser, the only thing that is good to offer is the reminder
that you must refuse to do that.

Re: Release plans

[Thomas Lord]

Richard M. Stallman wrote:
>     Windows hardly matters anymore.
>
>     Windows is not growing much in functionality...
>
> Windows is important as a problem as long as it is non-free and
> considerable numbers of people keep using it.  It is clear that when
> you say it "hardly matters" you are thinking of some other criterion.
>   

I am not.

I am claiming that the influences which lead people to choose Windows
are waning, with or without GNU.    They are very strong, right now,
but they are as strong as they will ever get and are already starting to
diminish (with or without free software alternatives).

The battle is shifting and GNU should seek -- another chess analogy --
initiative on the new battleground.   Windows "hardly matters" because
there are now bigger fish to fry.

-t

Re: Release plans

[Richard M. Stallman]

    I am claiming that the influences which lead people to choose Windows
    are waning, with or without GNU.

The main such influence is various forms of social inertia, and that will wane
only to the extent that we win the war in this theater.

    The battle is shifting and GNU should seek -- another chess analogy --
    initiative on the new battleground.

Shifting is the wrong word, since the new theater does not replace the
old one.  I am thinking about the new one, and working on a proposal.

Re: Release plans

[Nic]

"Richard M. Stallman" <rms@gnu.org> writes:

>     > I am glad that Emacs can have this effect.
>     > Did you first run it on Windows?
>
>     Yes, I did.
>
> Well then, Emacs on Windows has in at least one case brought someone
> more or less all the way to freedom.  If this happens often, then it could
> amount to a good reason to have Emacs run on Windows.

Just wanted to say, this happened to me too.

For a while I was a sysadmin using GNU/linux extensively but having a
Windows desktop machine.

Using Emacs on Windows eventually led me to reject corporate IT and
just use my own laptop with GNU on it all the time. That was sometime
ago now but I don't see why that still wouldn't happen.

What actually made me move? I missed the things in Emacs that I could
do with the operating system when I was on a GNU OS. So it wasn't the
quality of the Emacs implementation on Windows, it was things like
being able to run pipelines and so forth from inside Emacs.

I have always thought that a more "modern developer" friendly Emacs
might make in-roads against things like eclipse and would help
increase users of free operating systems.

-- 
Nic Ferrier
http://www.woome.com - Enjoy the minute!

Re: Release plans

[Richard M. Stallman]

    I have always thought that a more "modern developer" friendly Emacs
    might make in-roads against things like eclipse and would help
    increase users of free operating systems.

It is a big job, and we've discussed parts of it,
but we need people to actually do it.

Re: Release plans

[Alan Mackenzie]

Hi again, Richard,

On Thu, Jul 31, 2008 at 06:01:38PM -0400, Richard M Stallman wrote:
>     MS-Windows, like fossil-fuelled transportation, is something
>     undesirable, but difficult to avoid without separating from
>     mainstream society.

> They are not similar; avoiding Windows is far easier.  Please do not
> exaggerate.

Avoiding Windows may well be far easier.  It is still difficult.

>       If I were to reject paid work involving MS-Windows and
>       (proprietary) Unix, I would need to find paid work outside of
>       software development.

> I was prepared to do that if necessary in 1984.  Fortunately I
> did not have to.  Maybe you wouldn't either.

Maybe I wouldn't.  The point I made is that I AM NOT PREPARED to do it.
The tenor of your post seems to be I should feel some sort of guilt, some
sort of personal inadequacy.  I don't and I won't.  I will, however,
continue to implement, advocate and advance free software, as best as I
can.  

>       As far as I can, I run only free software at home.  However my
>       PC's BIOS is not free,

> On fsf.org there are recommendations for PCs that run with a free BIOS.

Thanks!  I'll have a look there the next time I need a new PC.

[ .... ]

>       Sadly, the freedom in free software doesn't excite most people -
>       Emacs's capabilities do, though.

> Have you seen any cases where that eventually led a person to switch
> from proprietary software to free software?

Well, that's not a binary thing.  Seeing Emacs has caused people to use
free software more, and to use more free software.  Many projects I've
been on have run on a Windows or Unix company network, but have used GCC,
GNU Make, bash, and friends to build the product.  I've introduced quite
a few people to Emacs, the odd one or two to GAWK, ...., and they're
probably still using them.  One or two are probably using GNU/Linux on
their home PCs, too.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Richard M Stallman]

    > Have you seen any cases where that eventually led a person to switch
    > from proprietary software to free software?

    Well, that's not a binary thing.  Seeing Emacs has caused people to use
    free software more, and to use more free software.  Many projects I've
    been on have run on a Windows or Unix company network, but have used GCC,
    GNU Make, bash, and friends to build the product.  I've introduced quite
    a few people to Emacs, the odd one or two to GAWK, ...., and they're
    probably still using them.  One or two are probably using GNU/Linux on
    their home PCs, too.

More use of some free programs is a kind of partial success that falls
short of our goal.  All else being equal, it is better if Windows and Unix
users compile with GCC than if they compile with a proprietary compiler.
But that isn't our goal, it just gets part way there.

That is why I asked if you have ever seen such cases lead to real success:
a person liberated from proprietary software?

Re: Release plans

[Alan Mackenzie]

'Afternoon, Richard!

On Sat, Aug 02, 2008 at 01:12:10AM -0400, Richard M Stallman wrote:
>     > Have you seen any cases where that eventually led a person to
>     > switch from proprietary software to free software?

>     Well, that's not a binary thing.  Seeing Emacs has caused people to
>     use free software more, and to use more free software.  Many
>     projects I've been on have run on a Windows or Unix company
>     network, but have used GCC, GNU Make, bash, and friends to build
>     the product.  I've introduced quite a few people to Emacs, the odd
>     one or two to GAWK, ...., and they're probably still using them.
>     One or two are probably using GNU/Linux on their home PCs, too.

> More use of some free programs is a kind of partial success that falls
> short of our goal.  All else being equal, it is better if Windows and Unix
> users compile with GCC than if they compile with a proprietary compiler.
> But that isn't our goal, it just gets part way there.

Borrowing notions from chess, you're talking about winning by direct
attack, possibly with brilliant sacrifices along the way, while I see
things more as a positional game, accumulating small advantages,
manoevring against enemy weaknesses.  You're Mikhail Tal, I'm José
Capablanca.  ;-)

The local administrations in Munich (where I use to live) and Vienna are
converting to G/L (which you know already).  Gcc/GNU Make/bash and
friends are well established for embedded systems development (where I
work).  Drip, drip, drip, free software is steadily establishing itself. 

Ten years ago, if you bought a PC, it would have had MS-Windows installed
on it, full stop.  Now, if you shop around, you can find PC's with
preinstalled GNU/Linux.  Soon, hopefully, you'll be getting asked what OS
(if any) you want on your new PC, and sometime after that (five, ten
years from now?) it'll have free software installed as a matter of
course, with proprietary alternatives available at extra cost.

> That is why I asked if you have ever seen such cases lead to real
> success: a person liberated from proprietary software?

Myself, perhaps?  The real liberation is in the becoming aware of what
proprietary software is and does, and having the confidence to avoid it.
Funnily enough, that is more difficult in a Unix environment, because the
software there works pretty well in general (even the bits (like ksh)
which aren't free).  With Windows, so much of the software is so icky
that you can't help but feel the itch to fix it - but of course you
can't.  Show mutt to somebody who emails with Lotus Notes, and you can
almost feel the "hey, I want that!".

I think it would "do you good" to spend a week using only proprietary
software on a Microsoft Windows system; I don't think you're aware of
just how sucky it is.  If you were, you'd realise that campaigning on the
basis of software quality in addition to freedom could be effective
indeed.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Lennart Borgman (gmail)]

Alan Mackenzie wrote:
> Borrowing notions from chess, you're talking about winning by direct
> attack, possibly with brilliant sacrifices along the way, while I see
> things more as a positional game, accumulating small advantages,
> manoevring against enemy weaknesses.  You're Mikhail Tal, I'm José
> Capablanca.  ;-)

I think I really learnt only one thing from chess: do not do any move 
for just one reason.

> I think it would "do you good" to spend a week using only proprietary
> software on a Microsoft Windows system; I don't think you're aware of
> just how sucky it is.  If you were, you'd realise that campaigning on the
> basis of software quality in addition to freedom could be effective
> indeed.

I do not think that is enough. You have to learn from your enemy. Learn 
from the strength your enemy has.

Re: Release plans

[Richard M. Stallman]

    Borrowing notions from chess, you're talking about winning by direct
    attack, possibly with brilliant sacrifices along the way, while I see
    things more as a positional game, accumulating small advantages,
    manoevring against enemy weaknesses.  You're Mikhail Tal, I'm José
    Capablanca.  ;-)

Your statement assumes both approaches can/do lead to victory.
That is precisely what I am not sure of.

One person posted here saying that running Emacs on Windows led him to
drop Windows for GNU/Linux.  In that case, the Windows support in
Emacs did lead to victory.  Perhaps it has done so in other cases too.
If so, maybe it is effective.

But just using Emacs and other free programs on Windows is not
victory.

Re: Release plans

[Alan Mackenzie]

Hi, Richard!

On Sat, Aug 02, 2008 at 09:33:20PM -0400, Richard M. Stallman wrote:
>     Borrowing notions from chess, you're talking about winning by
>     direct attack, possibly with brilliant sacrifices along the way,
>     while I see things more as a positional game, accumulating small
>     advantages, manoevring against enemy weaknesses.  You're Mikhail
>     Tal, I'm José Capablanca.  ;-)

> Your statement assumes both approaches can/do lead to victory.  That is
> precisely what I am not sure of.

Real chess players need to be able to play either strategy.  I don't see
why free software should restrict itself to one strategy.

> One person posted here saying that running Emacs on Windows led him to
> drop Windows for GNU/Linux.  In that case, the Windows support in Emacs
> did lead to victory.  Perhaps it has done so in other cases too.  If
> so, maybe it is effective.

> But just using Emacs and other free programs on Windows is not victory.

There will be no ultimate victory, as such, IMAO.  There will always be
users of restricted software, so long as such is available.  I think the
aim should be that the only people to use proprietary software should be
those who want to; free software should become the default.  As I've said
before, one of the barriers is this:

    <http://www.xkcd.com/456/>

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Richard M. Stallman]

    > Your statement assumes both approaches can/do lead to victory.  That is
    > precisely what I am not sure of.

    Real chess players need to be able to play either strategy.

That's because both stategies can win, in chess.
It is not clear that the same is true here.
That's the weakness of analogy as an argument:
the analogy does not show where its limits are.

    > But just using Emacs and other free programs on Windows is not victory.

    There will be no ultimate victory, as such, IMAO.  There will always be
    users of restricted software, so long as such is available.

You cannot see the future any more than I can, so stop spreading
defeatism.

Re: Release plans

[Thomas Lord]

Richard M. Stallman wrote:
>     Borrowing notions from chess, you're talking about winning by direct
>     attack, possibly with brilliant sacrifices along the way, while I see
>     things more as a positional game, accumulating small advantages,
>     manoevring against enemy weaknesses.  You're Mikhail Tal, I'm Jos?é
>     Capablanca.  ;-)
>
> Your statement assumes both approaches can/do lead to victory.
> That is precisely what I am not sure of.
>
> One person posted here saying that running Emacs on Windows led him to
> drop Windows for GNU/Linux.  In that case, the Windows support in
> Emacs did lead to victory.  Perhaps it has done so in other cases too.
> If so, maybe it is effective.
>
> But just using Emacs and other free programs on Windows is not
> victory.
>   

RMS, you spend a lot of effort thinking about what programs to
not write. (Just an observation.)


-t





>   

Re: Release plans

[Richard M. Stallman]

    RMS, you spend a lot of effort thinking about what programs to
    not write. (Just an observation.)

We can save a lot of work that way!

Re: Release plans

[Thomas Lord]

Richard M. Stallman wrote:
>     RMS, you spend a lot of effort thinking about what programs to
>     not write. (Just an observation.)
>
> We can save a lot of work that way!
>   


That's pithy but not obviously true.

An alternative strategy for saving work is to build better
tools for accomplishing more with less effort.   This alternative
requires thinking about what *to* build rather than what *to not*
build.

-t

Re: Release plans

[Richard M. Stallman]

    I think it would "do you good" to spend a week using only proprietary
    software on a Microsoft Windows system; I don't think you're aware of
    just how sucky it is.

If I did all my work in Emacs, as usual, I might not notice much difference.

			   If you were, you'd realise that campaigning on the
    basis of software quality in addition to freedom could be effective
    indeed.

I am sure it IS effective for convincing people to use GNU/Linux
when that is more convenient.  I want to convince people
to insist on freedom even when it is inconvenient.

Re: Release plans

[Alan Mackenzie]

Hi, again!

On Sat, Aug 02, 2008 at 09:33:21PM -0400, Richard M. Stallman wrote:
>     I think it would "do you good" to spend a week using only
>     proprietary software on a Microsoft Windows system; I don't think
>     you're aware of just how sucky it is.

> If I did all my work in Emacs, as usual, I might not notice much difference.

Er, "using only proprietary software ....".  The whole idea is that you
_would_ notice.  You know, use the whole works, Microsoft Word, Outlook
Express, Visual Studio (or, if you've been suffering from a lack of
vomitting in the recent past, Lotus Notes), Clear Case (a proprietary VCS
system), .......

To be honest, I wouldn't do that either if somebody suggested it to me.
But if you did try this, you might then be a bit more sympathetic to
those who percieve that type of software to be modern, efficient, and OK.

>     If you were, you'd realise that campaigning on the basis of
>     software quality in addition to freedom could be effective indeed.

> I am sure it IS effective for convincing people to use GNU/Linux when
> that is more convenient.  I want to convince people to insist on
> freedom even when it is inconvenient.

I see my task, miniscule though my personal contribution might be, to be
to make freedom convenient.  Several of my colleagues over the years have
told me they don't care about software freedom, they want the tools which
get their job done best.  You can't argue with that, it's consistent and
honest.  I think free software should cater to them, too.

I don't think many software people really do care that much about
freedom.  To make people value freedom over convenience, I think you'd
have to first convince them that any incovenience would be minor.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Richard M. Stallman]

    To be honest, I wouldn't do that either if somebody suggested it to me.
    But if you did try this, you might then be a bit more sympathetic to
    those who percieve that type of software to be modern, efficient, and OK.

I sympathize fully with appreciation of convenient software.
What I refuse to sympathize with is the failure to appreciate
freedom even more.

    I see my task, miniscule though my personal contribution might be, to be
    to make freedom convenient.  Several of my colleagues over the years have
    told me they don't care about software freedom, they want the tools which
    get their job done best.  You can't argue with that,

Yes we can.  We have done so for 25 years and we will continue to do so.

    it's consistent and
    honest.

It is foolish and dangerous.

	     I think free software should cater to them, too.

We cater to them to the extent it doesn't interfere with more
important goals, such as establishing a free society.

Re: Release plans

[Alan Mackenzie]

Hi, Richard!

On Mon, Aug 04, 2008 at 11:33:34AM -0400, Richard M. Stallman wrote:
>     To be honest, I wouldn't do that either if somebody suggested it to
>     me.  But if you did try this, you might then be a bit more
>     sympathetic to those who percieve that type of software to be
>     modern, efficient, and OK.

> I sympathize fully with appreciation of convenient software.  What I
> refuse to sympathize with is the failure to appreciate freedom even
> more.
 
Lots of people can't appreciate freedom because they don't understand it.
To a large extent, they're people who've never suffered constraint, or
haven't noticed it.  A mob of such people is dangerous indeed.
Education, sympathetic or not, is the best thing here.


>     I see my task, miniscule though my personal contribution might be,
>     to be to make freedom convenient.  Several of my colleagues over
>     the years have told me they don't care about software freedom, they
>     want the tools which get their job done best.  You can't argue with
>     that,

> Yes we can.  We have done so for 25 years and we will continue to do
> so.

OK, let's not quibble about semantic niceties.  There are people who will
stick to what's convenient, what "the law" tells them.  The only way to
persuade such people is to show them something convenient or legal.

>     it's consistent and honest.

> It is foolish and dangerous.

It's all four of these things.

> 	     I think free software should cater to them, too.

> We cater to them to the extent it doesn't interfere with more important
> goals, such as establishing a free society.

Sometimes I think you'd force freedom upon people.  ;-)

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Richard M. Stallman]

    OK, let's not quibble about semantic niceties.  There are people who will
    stick to what's convenient, what "the law" tells them.  The only way to
    persuade such people is to show them something convenient or legal.

There certainly are people who think that way -- but people's ideas
do sometimes change.  So we should not give up on that.

Aside from that, I'm all in favor of showing those people
something convenient or legal.  Just as long as this does
not obscure our message that software must be free.

Re: Release plans

[Davi Leal]

Richard M Stallman wrote:
>     As far as I
>     can, I run only free software at home.  However my PC's BIOS is not
>     free,
>
> On fsf.org there are recommendations for PCs that run with a free BIOS.
>
>     and neither is the software in my DSL router - yet.  Would you likewise
>     suggest I should not use DSL until fully free firmware becomes
>     available?
>
> No, I expect that router does not count.  I'd expect users don't
> install software at all in that, so it might as well be a circuit, and
> we don't need to ask whether there is actually software inside it.
>
> You are arguing against a straw man that didn't come from me.

So we are not forced to give a copy of the source code which is used inside 
the GNU/Linux based routers and bridges network appliances we rent to our 
customers?

Re: Release plans

[Richard M Stallman]

    > No, I expect that router does not count.  I'd expect users don't
    > install software at all in that, so it might as well be a circuit, and
    > we don't need to ask whether there is actually software inside it.
    >
    > You are arguing against a straw man that didn't come from me.

    So we are not forced to give a copy of the source code which is used inside 
    the GNU/Linux based routers and bridges network appliances we rent to our 
    customers?

That's a different question entirely, which is not what
I was talking about.  By criticizing something nobody said,
you are only sabotaging the discussion.

    Yes, you are right. Those are all good reasons to protest 
    against Apple.

    But none of these are particularly egregious examples of 
    “evil”

DRM is always evil.

	   — particularly since Apple has a history of going 
    out of its way to make the restrictions it imposes as light as 
    possible for its customers —

It's not true, but even if it were, it would not signify.  Apple
entered voluntarily into a deal with record companies to implement
DRM, and it shares in the profits from that deal, so it also shares
in the culpability.

Re: Release plans

[dhruva]

Hello,



----- Original Message ----
> From: Alan Mackenzie <acm@muc.de>
> To: Richard M Stallman <rms@gnu.org>
> Cc: dhruva <dhruva@ymail.com>; emacs-devel@gnu.org
> Sent: Thursday, 31 July, 2008 3:00:22 PM
> Subject: Re: Release plans
> If I were to reject work involving proprietary OS's, this wouldn't
> advance free software at all.  The only people to notice would be the
> people who expect me to pay their bills, and hopefully the Emacs
> development team would notice my absence after my Internet line had been
> cut off.  I suspect I am typical of most hackers here in that respect.

I completely agree with you. Let us accept that many companies develop software that runs on multiple operating systems. Some of us with windows background have to pitch in when there is requirement. I would love to work with the great GNU tools that I use on GNU/Linux on all platforms I am expected to work. Just imagine if I have to learn OS specific tools for doing regular development work, I would end up spending time learning the various tools instead of just using them to get the work done. Hence, the request to continue to make Emacs (and other GNU tools) available on a bunch of other OS (free or non free).
I work in India and I can say that we cannot demand to work only on a particular platform when you join a company. Especially in the application development, most companies want their applications to run on a whole lot of platforms. I am not a Linux kernel hacker to be able to get a good job where I can live and breath in GNU/Linux that can still pay my (and my family) bills. That is the unfortunate reality. 
 Just for records, though I develop on GNU/Linux, I still have to use M$ to access mails, ensure it builds and works on M$, for VPN and a bunch of other stuff for which the local IT offers support to M$ but not GNU/Linux! I have tried a couple of times to remove M$ and use on GNU/Linux but failed due to some internal tool not working on GNU/Linux and had to get back. It is sad but true. Same with the Mozilla Firefox browser. Some sites just do not work on Firefox (and Opera). To get the work done, you have to use IE or end up getting fired for not getting the job done.

-dhruva



      Unlimited freedom, unlimited storage. Get it now, on http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html/

Re: Release plans

[Richard M Stallman]

    Some sites just do not work on Firefox (and Opera). To get the
    work done, you have to use IE or end up getting fired for not
    getting the job done.

At some point we have to stop ceding to that pressure and overcome it
instead.  You are surrendering to it, but the GNU Project must not do
so.

Re: Release plans

[dhruva]

Hello,



----- Original Message ----
> From: Alan Mackenzie <acm@muc.de>
> To: Richard M. Stallman <rms@gnu.org>
> Cc: dhruva@ymail.com; emacs-devel@gnu.org
> Sent: Tuesday, 5 August, 2008 12:38:30 AM
> Subject: Re: Release plans
> 
> Hi, Richard!
> 
> On Mon, Aug 04, 2008 at 11:33:34AM -0400, Richard M. Stallman wrote:
> >     To be honest, I wouldn't do that either if somebody suggested it to
> >     me.  But if you did try this, you might then be a bit more
> >     sympathetic to those who percieve that type of software to be
> >     modern, efficient, and OK.
> 
> > I sympathize fully with appreciation of convenient software..  What I
> > refuse to sympathize with is the failure to appreciate freedom even
> > more.
> 
> Lots of people can't appreciate freedom because they don't understand it.
> To a large extent, they're people who've never suffered constraint, or
> haven't noticed it.  A mob of such people is dangerous indeed.
> Education, sympathetic or not, is the best thing here.
> 

From my limited understanding of the complex free/freedom in software, it attracts only the real hackers. Not everyone wants access to the source code when they cannot modify it. Not everyone is a hacker and cannot be a master in all tools and applications. I would love to use free software where I know enough to be able to make the changes I want and contribute back to the community. In areas where I know nothing but have to use something to get my work done, I really look for the simplest to deploy, use and cost effective (in the same order). From the philosophical perspective, I do understand and accept that embracing free software in spite of a functionally better proprietary alternative is good for the community. Practically, I doubt whether that is sustainable in the long term when it keeps coming in the way of getting my job done.
IMHO, what we need is real good organized paid support to free software where I can demand support for a feature I have paid. A slightly less restrictive licensing to paid users wanting to develop proprietary software using the free software. More corporates would then use free source than what is happening currently. At work (in corporates), people are just scared to use free source under GPL! Therefore, they keep using more proprietary software and building on top of it. Is it possible for FSF/GNU to setup something for paid users? I hope something comes out in the near future. Pushing free software in corporates would be a big step forward and that will attract larger user (and hopefully contributors) base.

-dhruva



      Unlimited freedom, unlimited storage. Get it now, on http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html/

Re: Release plans

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Aug 05, 2008 at 08:23:36AM +0530, dhruva wrote:
> Hello,

[...]

> IMHO, what we need is real good organized paid support to free software
[...]
> source than what is happening currently. At work (in corporates),
> people are just scared to use free source under GPL! Therefore, they
> keep using more proprietary software and building on top of it. Is it
> possible for FSF/GNU to setup something for paid users? I hope something
> comes out in the near future. Pushing free software in corporates would
> be a big step forward and that will attract larger user (and hopefully
> contributors) base.

Au contraire -- I've managed to convince several customers that GPL is
actually *good for them* (I work on medium-to-small projects):

(1) They actually become *less* dependent on myself. The project lives
on if there are other people besides myself interested in its outcome

(2) If there is another commercial entity interested in this baby, my
customer will eventually reap the benefits of them improving it.

(some customers remain sceptical even in front of those arguments,
alas).

Remember: it's especially the *user* the GPL caters to. 

Note that I favour the GPL on philosophical/ideological grounds. Still
it has a lot to offer to the customers on practical grounds.

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIl9pdBcgs9XrR2kYRAoVYAJ9tsfD6fPRo3pZQYgN0rltP+ACxIgCfdel5
lN08rkHj2jZkJtayYlTFeIw=
=8f+o
-----END PGP SIGNATURE-----

Re: Release plans

[Richard M. Stallman]

    From my limited understanding of the complex free/freedom in
    software, it attracts only the real hackers.

I have met many people who support the free software movement as a
political issue even though they are not programmers.  Perhaps
your experience is limited to a narrow segment of society.

    Not everyone wants
    access to the source code when they cannot modify it. 

Some people do not see the deeper and larger consequences
of free software, so they think about the question purely
in terms of what they personally can or will do.
This is a common tendency in our society, which encourages
it because it makes people pliable for business.  People
with these ideas, if not good programmers themselves, may not
realize how important the four freedoms are to everyone.

I explain this issue in my speeches about free software.

Our mission is to teach them to value these freedoms -- not
follow their failure to do so.

Re: Release plans

[A Soare]

>     Windows hardly matters anymore.
> 
>     Windows is not growing much in functionality...
> 
> Windows is important as a problem as long as it is non-free and
> considerable numbers of people keep using it.  It is clear that when
> you say it "hardly matters" you are thinking of some other criterion.

I have never known in all my life a person using windows that thought to use emacs. All persons that I knew and wanted to (learn lisp)/(use emacs) used linux or MAC OSX.

So a considerable number of peuple use Windows, but (almost) never Emacs in Windows.




____________________________________________________

Avant de prendre le volant, repérez votre itinéraire et visualisez le trafic ! http://itineraire.voila.fr/itineraire.html

Re: Release plans

[Lennart Borgman (gmail)]

A Soare wrote:
>>     Windows hardly matters anymore.
>>
>>     Windows is not growing much in functionality...
>>
>> Windows is important as a problem as long as it is non-free and
>> considerable numbers of people keep using it.  It is clear that when
>> you say it "hardly matters" you are thinking of some other criterion.
> 
> I have never known in all my life a person using windows that thought to use emacs. All persons that I knew and wanted to (learn lisp)/(use emacs) used linux or MAC OSX.
> 
> So a considerable number of peuple use Windows, but (almost) never Emacs in Windows.


What is your thoughts about that? Is there something to learn from it? 
Is there something to investigate?

Re: Release plans

[Michael Ekstrand]

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

A Soare <alinsoar@voila.fr> writes:

>>     Windows hardly matters anymore.
>> 
>>     Windows is not growing much in functionality...
>> 
>> Windows is important as a problem as long as it is non-free and
>> considerable numbers of people keep using it.  It is clear that when
>> you say it "hardly matters" you are thinking of some other criterion.
>
> I have never known in all my life a person using windows that thought
> to use emacs. All persons that I knew and wanted to (learn lisp)/(use
> emacs) used linux or MAC OSX.
>
> So a considerable number of peuple use Windows, but (almost) never
> Emacs in Windows.

I suspect that differs considerably depending on the field you're in and
surveying.

At a U.S. university, I do see Emacs on Windows.  One of my professors
used it for demonstrating things from his laptop in lecture.  Other
professors use Emacs, and use Windows for some things (frequently their
laptops run Windows).  I'm not sure how much use they make of Emacs on
Windows (I haven't witnessed it), but they are users of both Windows and
Emacs.  Whoever used my lab laptop before I got my hands on it also had
Emacs installed on Windows.

- Michael

-- 
mouse, n: A device for pointing at the xterm in which you want to type.
Confused by the strange files?  I cryptographically sign my messages.
For more information see <http://www.elehack.net/resources/gpg>.

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: Release plans

[Richard M. Stallman]

    At a U.S. university, I do see Emacs on Windows.  One of my professors
    used it for demonstrating things from his laptop in lecture.  Other
    professors use Emacs, and use Windows for some things (frequently their
    laptops run Windows).

The real question here is what to do to convince them to stop
using Windows and run GNU/Linux instead.
 
We can speculate that running Emacs on Windows leads some people
to switch to GNU/Linux.  But imagined migration is not our goal;
what we need is for them to migrate in reality.

Re: Release plans

[Alex Ott]

Hello

>>>>> "RMS" == Richard M Stallman writes:
 RMS>     At a U.S. university, I do see Emacs on Windows.  One of my
 RMS> professors used it for demonstrating things from his laptop in
 RMS> lecture.  Other professors use Emacs, and use Windows for some things
 RMS> (frequently their laptops run Windows).

 RMS> The real question here is what to do to convince them to stop using
 RMS> Windows and run GNU/Linux instead.
 
 RMS> We can speculate that running Emacs on Windows leads some people to
 RMS> switch to GNU/Linux.  But imagined migration is not our goal; what we
 RMS> need is for them to migrate in reality.

From my experience - lot of software was developed only for Windows, and
there are no analogs in GNU world.  I had worked about 2 years under
Windows as Software Architect, as was no required modeling documenting
tools for Linux, but i also used Emacs to program prototypes.

If will no Emacs under windows, i will switch to other tools, and may be
leave emacs on other platform, as i need consistent environment over all
platforms, not only one

-- 
With best wishes, Alex Ott, MBA
http://alexott.blogspot.com/           http://xtalk.msk.su/~ott/
http://alexott-ru.blogspot.com/

Re: Release plans

[Miles Bader]

A Soare <alinsoar@voila.fr> writes:
> I have never known in all my life a person using windows that thought
> to use emacs. All persons that I knew and wanted to (learn lisp)/(use
> emacs) used linux or MAC OSX.

They do of course exist though.  The two classes that seem to be common
are:

  1) People that got used to emacs in another OS (in my experience
     usually old unix systems, e.g. sunos/solaris), and continue to use
     it in windows.  I suppose this number is dwindling.

  2) People that are influenced in some way by an emacs user.  E.g.,
     windows-using spouse/friend/... of emacs user.

Whether having these people use emacs windows advances the cause of free
software I dunno, but I suspect it does in the long run -- my
observation is that emacs, as a somewhat singular program, seems to keep
them aware of this "other" culture (the free software culture) when
otherwise they might simply not be.

Sadly, many people are not going to move away from windows quickly, but
I think it is useful to keep channels of communication open.

-Miles

-- 
Love, n. A temporary insanity curable by marriage or by removal of the patient
from the influences under which he incurred the disorder. This disease is
prevalent only among civilized races living under artificial conditions;
barbarous nations breathing pure air and eating simple food enjoy immunity
from its ravages. It is sometimes fatal, but more frequently to the physician
than to the patient.

Re: Release plans

[Lennart Borgman (gmail)]

Miles Bader wrote:
> Sadly, many people are not going to move away from windows quickly, but
> I think it is useful to keep channels of communication open.


You normally do not change OS. The main time for doing so is probably 
when buying a new computer.

I tried to make a double boot installation the last time. But this 
crashed my windows installation and after that I had not had time to try 
it out again.

So at least in my case the quality of GNU/Linux did matter for my choice 
at the moment.

RE: Release plans

[Drew Adams]

> They do of course exist though.  The two classes that seem to 
> be common are:
> 
>   1) People that got used to emacs in another OS (in my experience
>      usually old unix systems, e.g. sunos/solaris), and 
>      continue to use it in windows.  I suppose this number is
>      dwindling.
> 
>   2) People that are influenced in some way by an emacs user.  E.g.,
>      windows-using spouse/friend/... of emacs user.

There is another large class, and it is not dwindling much at the moment.

More and more, I see developers using a Windows laptop or desktop machine to
access a GNU/Linux machine remotely (e.g. through VNC), the latter machine often
being a VM.

This might be true only of large organizations that produce software (companies,
government,...), but I suspect that it is more general than that and becoming
more so. It is certainly true of Oracle, as one example.

Where I work:

The developers use Windows on their desktop/laptop (today) because that is what
everyone in the organization uses. They use the same tools as everyone else
(non-developers) for interacting and getting the organization's work done
together. And yes, this is a non-negligible part of what they do. Even a
developer's computer time is not all spent on development - far from it.

This includes all of the work that is not necessarily software development per
se. And it includes even much of the software development work in the larger
sense: project management, specs, product management, and so on. That work is
done using Windows desktop boxes for the most part, even if, under the covers,
the (typically Web) Windows clients interact with databases and other tools that
run on GNU/Linux. Software development in the stricter sense of coding, testing,
version control, and so on, is done on the remote GNU/Linux boxes.

Yes, to the extent that they can use Web clients for this work (and they can,
more and more), they could use only their GNU/Linux boxes for that, even if that
involves another layer of indirection (e.g. VNC). But they typically don't.
Perhaps this also has to do with less support on GNU for the office tools they
use to get this work done. Or perhaps it's just ignorance, or perhaps it's
bandwidth slowdown (e.g. VNC). I don't know. And perhaps this will change. But
today that work is done through Windows.

In sum, the developers use their remote and often virtual GNU/Linux machines for
software development, but they use Windows for everything else.

Emacs? Many use Emacs for their development on GNU/Linux. Many others use some
flavor of vi for that, and some use both Emacs and vi. What editor do they use
on Windows? My guess is that many use the same editor they use on GNU, but I
know that some use things like TextPad or even NotePad on Windows. I believe
that some who use Emacs all day long on GNU do not even know that they can also
use it on Windows. Those who do know take advantage of this and presumably
spread the word.

Some who use Emacs on both platforms take advantage of Tramp to access files on
their GNU/Linux machines from an Emacs session running on Windows. That is, if
they happen to be working on Windows in Emacs, they also do some of their work
on GNU directly from the same Emacs session, rather than pulling up VNC or
otherwise accessing the remote GNU machine. 

In general, they take advantage of the fact that Emacs runs everywhere, acts the
same everywhere, and can access remote files from anywhere. The combinations are
several, and I am sure that they are all used. Because it runs on multiple
platforms and allows remote use of different platforms to some extent, Emacs is
in some technical (not political) sense above and outside any choice of OS.

So yes, it is very useful to many _users_ of GNU that Emacs continue to run on
Windows. Whether that is important and useful to FSF is for FSF to decide. It's
obvious to me that Emacs on Windows benefits GNU/FSF greatly, but I won't try
further to convince anyone of that.

I would guess that there has been a gradual shift in development in many
software organizations to using GNU/Linux more and using Windows less, and this
is true for more than just the developers. It is a slow movement. The shift for
development per se is one thing, but I think the shift of computer use outside
development is largely due to increased support for remote work, better
bandwidth, and Web services. Not to mention cheap, blade-server GNU machines.

Better GNU support for the non-development use of computers would hasten the
move. When marketing and HR departments find it just as easy to do their work on
GNU, the battle will be won.

You will notice that most of the posts in this thread have taken the point of
view of an individual computer user, and most often of a developer. To answer
the question of which tools and processes get used in general and why, you need
to look beyond the individual to the social groups s?he is part of. People work
and play with others, and to do that they often use tools that the groups decide
are most appropriate.

Use of GNU/Linux has now moved beyond the hobbyist stage, thanks largely to
Linux and cheap PCs. Its adoption and use are no longer decided only by lone
hackers. Its growth is more and more determined by its utility to groups of
people working together, often large groups. Developers built GNU/Linux, but
they are no longer the only users.

Re: Release plans

[Richard M. Stallman]

    Yes, to the extent that they can use Web clients for this work (and they can,
    more and more), they could use only their GNU/Linux boxes for that, even if that
    involves another layer of indirection (e.g. VNC). 

If the web servers use standard protocols, they should be able to access
them with Firefox or Icecat.

						      But they typically don't.
    Perhaps this also has to do with less support on GNU for the office tools they
    use to get this work done. Or perhaps it's just ignorance, or perhaps it's
    bandwidth slowdown (e.g. VNC). I don't know. And perhaps this will change. But
    today that work is done through Windows.

We need to do something to make this change.  Since you observe this often,
how about if you make a regular practice of suggesting it, and record their
responses?

Re: Release plans

[Eli Zaretskii]

> From: A Soare <alinsoar@voila.fr>
> Date: Tue, 12 Aug 2008 14:21:03 +0200 (CEST)
> 
> 
> I have never known in all my life a person using windows that
> thought to use emacs.

I see them every day on my daytime job.

> So a considerable number of peuple use Windows, but (almost) never Emacs in Windows.

Not in my experience.

Re: Release plans

[A Soare]

> A Soare wrote:
> >>     Windows hardly matters anymore.
> >>
> >>     Windows is not growing much in functionality...
> >>
> >> Windows is important as a problem as long as it is non-free and
> >> considerable numbers of people keep using it.  It is clear that when
> >> you say it "hardly matters" you are thinking of some other criterion.
> > 
> > I have never known in all my life a person using windows that thought to use emacs. All persons that I knew and wanted to (learn lisp)/(use emacs) used linux or MAC OSX.
> > 
> > So a considerable number of peuple use Windows, but (almost) never Emacs in Windows.
> 
> 
> What is your thoughts about that? Is there something to learn from it? 
> Is there something to investigate?
> 

Quite so! Investing energy to develop it under Windows is (almost) loss of energy!

I know a few cases of _good_ programmers at google, microsoft, etc that never thought to use emacs.

The reason: Windows has nicer environments to write C++, Delphi, C# etc. (that is what they told me). I have never used Windows in all my life. I have been using linux for more that 15 years.

And since I have began to use emacs (2005), I use just emacs all the day. But at the beginning I did an effort to understand it. That is what peuple does not like : to make effort to understand something that they can have without energy.

Emacs and Linux is used just by peuple that wants to understand how things work.

Windows is used by peuple that want to gain money and to arrive quiqkly at their purpose.

From all my experience (all what I saw), windows interface for emacs is as important as the file ./etc/sex.6 in emacs' sources.




____________________________________________________

Avant de prendre le volant, repérez votre itinéraire et visualisez le trafic ! http://itineraire.voila.fr/itineraire.html

Re: Release plans

[Juanma Barranquero]

On Tue, Aug 12, 2008 at 15:11, A Soare <alinsoar@voila.fr> wrote:

> Emacs and Linux is used just by peuple that wants to understand how things work.
>
> Windows is used by peuple that want to gain money and to arrive quiqkly at their purpose.

Yeah, sure, of course.

    Juanma

Re: Release plans

[Johannes Weiner]

Hi,

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On Tue, Aug 12, 2008 at 15:11, A Soare <alinsoar@voila.fr> wrote:
>
>> Emacs and Linux is used just by peuple that wants to understand how things work.
>>
>> Windows is used by peuple that want to gain money and to arrive quiqkly at their purpose.
>
> Yeah, sure, of course.

There are exceptions and blaming it on money only is not right.

From my experience, I don't know anyone personally(!) who has found his
way around in Linux and switched back to Windows after it.  I know that
there are exceptions, but these people seem to be rare.

And these few people who switched back to Windows had no means to
understand how things work.  In fact, I had even more understanding of
their Windows than they had themselves, just because they didn't care.
Despite the fact that I have not used Windows myself for over 6 years
now.

So, my impression is, that most Windows users really have no intention
to learn how their tools work.  And they are not interested in
optimizing their workflow.

Again, there are exceptions.  I *know* there are people who know both
worlds and still are fine with working on Windows.  I suspect you,
Juanma, and Eli Zaretskii are such persons, please correct me if I am
wrong.

But the bulk of people behaves like I described, I think.

	Hannes

Re: Release plans

[Richard M. Stallman]

    >From my experience, I don't know anyone personally(!) who has found his
    way around in Linux and switched back to Windows after it.

I do not doubt your experience, but please note that the system they
switched to is not Linux.  Linux is a kernel, and has no commands or
user interface for them to find their way around in.  The system
you are thinking of is the GNU operating system, which we launched
in 1984 for the sake of freedom.

See http://www.gnu.org/gnu/the-gnu-project.html for the history
of GNU and Linux.

Re: Release plans

[Johannes Weiner]

Hi,

"Richard M. Stallman" <rms@gnu.org> writes:

>     >From my experience, I don't know anyone personally(!) who has found his
>     way around in Linux and switched back to Windows after it.
>
> I do not doubt your experience, but please note that the system they
> switched to is not Linux.  Linux is a kernel, and has no commands or
> user interface for them to find their way around in.  The system
> you are thinking of is the GNU operating system, which we launched
> in 1984 for the sake of freedom.
>
> See http://www.gnu.org/gnu/the-gnu-project.html for the history
> of GNU and Linux.

Your correction is appropriate.  I am sorry.  Yes, I really meant the
GNU system as users mostly don't even get to see the kernel anyway.

	Hannes

Re: Release plans

[Lennart Borgman (gmail)]

A Soare wrote:
> 
>> A Soare wrote:
>>>>     Windows hardly matters anymore.
>>>>
>>>>     Windows is not growing much in functionality...
>>>>
>>>> Windows is important as a problem as long as it is non-free and
>>>> considerable numbers of people keep using it.  It is clear that when
>>>> you say it "hardly matters" you are thinking of some other criterion.
>>> I have never known in all my life a person using windows that thought to use emacs. All persons that I knew and wanted to (learn lisp)/(use emacs) used linux or MAC OSX.
>>>
>>> So a considerable number of peuple use Windows, but (almost) never Emacs in Windows.
>>
>> What is your thoughts about that? Is there something to learn from it? 
>> Is there something to investigate?
>>
> 
> Quite so! Investing energy to develop it under Windows is (almost) loss of energy!

Yes, I understood that this is what you meant. But in what way did you 
reach this conclusion?


> I know a few cases of _good_ programmers at google, microsoft, etc that never thought to use emacs.
> 
> The reason: Windows has nicer environments to write C++, Delphi, C# etc. (that is what they told me).

Then how can it be good to develop Emacs under any operating system?


> That is what peuple does not like : to make effort to understand something that they can have without energy.

Don't you think that those programmers did invest quite a lot of effort 
in understanding the software they are using now?


> Emacs and Linux is used just by peuple that wants to understand how things work.

Do you say that there is no use for Emacs?


> Windows is used by peuple that want to gain money and to arrive quiqkly at their purpose.

Do you say that using Emacs makes it take long time to do things?


>>From all my experience (all what I saw), windows interface for emacs is as important as the file ./etc/sex.6 in emacs' sources.

Are you saying that this is the only part of Emacs that we should keep ;-)

Re: Release plans

[A Soare]

> 
> A Soare wrote:
> > 
> >> A Soare wrote:
> >>>>     Windows hardly matters anymore.
> >>>>
> >>>>     Windows is not growing much in functionality...
> >>>>
> >>>> Windows is important as a problem as long as it is non-free and
> >>>> considerable numbers of people keep using it.  It is clear that when
> >>>> you say it "hardly matters" you are thinking of some other criterion.
> >>> I have never known in all my life a person using windows that thought to use emacs. All persons that I knew and wanted to (learn lisp)/(use emacs) used linux or MAC OSX.
> >>>
> >>> So a considerable number of peuple use Windows, but (almost) never Emacs in Windows.
> >>
> >> What is your thoughts about that? Is there something to learn from it? 
> >> Is there something to investigate?
> >>
> > 
> > Quite so! Investing energy to develop it under Windows is (almost) loss of energy!
> 
> Yes, I understood that this is what you meant. But in what way did you 
> reach this conclusion?

By induction. I do not use Windows, and in linux I use emacs for lots of purposes.

> 
> 
> > I know a few cases of _good_ programmers at google, microsoft, etc that never thought to use emacs.
> > 
> > The reason: Windows has nicer environments to write C++, Delphi, C# etc. (that is what they told me).
> 
> Then how can it be good to develop Emacs under any operating system?

In Emacs under Linux for Linux!

> 
> 
> > That is what peuple does not like : to make effort to understand something that they can have without energy.
> 
> Don't you think that those programmers did invest quite a lot of effort 
> in understanding the software they are using now?

Friend and collegueas: yes, they had good marks at the faculty. They deposed much effort to learn.

> 
> 
> > Emacs and Linux is used just by peuple that wants to understand how things work.
> 
> Do you say that there is no use for Emacs?

In windows, yes, that is what I say. In Windows it is completely unuseful.

> 
> 
> > Windows is used by peuple that want to gain money and to arrive quiqkly at their purpose.
> 
> Do you say that using Emacs makes it take long time to do things?

It takes little time when you have already learned how to use it. The first time when you did a thing, you will never choose something different. Here is the point: the psychology. Peuple prefers never to make the first effort, and they prefer to use something to arrive quickly at the point.

> 
> 
> >>From all my experience (all what I saw), windows interface for emacs is as important as the file ./etc/sex.6 in emacs' sources.
> 
> Are you saying that this is the only part of Emacs that we should keep ;-)

Yes, Emacs in Linux is nice.




____________________________________________________

Avant de prendre le volant, repérez votre itinéraire et visualisez le trafic ! http://itineraire.voila.fr/itineraire.html

Re: Release plans

[martin rudalics]

>> Then how can it be good to develop Emacs under any operating system?
> 
> In Emacs under Linux for Linux!

Linux is _not_ an operating system.

Re: Release plans

[Johannes Weiner]

Hi,

martin rudalics <rudalics@gmx.at> writes:

>>> Then how can it be good to develop Emacs under any operating system?
>>
>> In Emacs under Linux for Linux!
>
> Linux is _not_ an operating system.

I suggest you read up the definition of `operating system'.  While the
original author probably meant a Linux kernel with a GNU environment,
your correction is pretty bogus.

	Hannes

Re: Release plans

[Lennart Borgman (gmail)]

A Soare wrote:
>>> Quite so! Investing energy to develop it under Windows is (almost) loss of energy!
>> Yes, I understood that this is what you meant. But in what way did you 
>> reach this conclusion?
> 
> By induction. I do not use Windows, and in linux I use emacs for lots of purposes.

So you mean that for you personal benefits there is no use in developing 
Emacs under Windows? ;-)

>>> I know a few cases of _good_ programmers at google, microsoft, etc that never thought to use emacs.
>>>
>>> The reason: Windows has nicer environments to write C++, Delphi, C# etc. (that is what they told me).
>> Then how can it be good to develop Emacs under any operating system?
> 
> In Emacs under Linux for Linux!

Did you mention any reason that I did not notice?

>>> That is what peuple does not like : to make effort to understand something that they can have without energy.
>> Don't you think that those programmers did invest quite a lot of effort 
>> in understanding the software they are using now?
> 
> Friend and collegueas: yes, they had good marks at the faculty. They deposed much effort to learn.

Thanks.

>>> Emacs and Linux is used just by peuple that wants to understand how things work.
>> Do you say that there is no use for Emacs?
> 
> In windows, yes, that is what I say. In Windows it is completely unuseful.

Then why is there a use for it under Linux? It seems like you are saying 
that software under Linux is inferior to the corresponding software 
under Windows and because of this Emacs can be useful on Linux.

If that is the case why is it Emacs we develop and not something better?

>>> Windows is used by peuple that want to gain money and to arrive quiqkly at their purpose.
>> Do you say that using Emacs makes it take long time to do things?
> 
> It takes little time when you have already learned how to use it.
 > The first time when you did a thing, you will never choose something 
different.
 > Here is the point: the psychology. Peuple prefers never to make the 
first effort,
 > and they prefer to use something to arrive quickly at the point.

Can we use that point to do something actively? Can we make Emacs better 
in a way that it satisfies those people's need? (Still not sacrifiying 
other things.)

>>> >From all my experience (all what I saw), windows interface for 
 >>> > emacs is as important as the file ./etc/sex.6 in emacs' sources.
>> Are you saying that this is the only part of Emacs that we should keep ;-)
> 
> Yes, Emacs in Linux is nice.

Why is the file etc/sex.6 so nice so that we should keep only that on 
Linux? ;-)

Re: Release plans

[Paul R]

The number and the skills of people using microsoft windows and
working at making emacs better everyday is highly sufficient to
consider the windows port of emacs to be paid back and now rewarding.

Those people now produce the same emacs lisp as any other emacs user.
I do not use windows, but I run their lisp, and I thank them for that.

Windows software certainly sucks by most aspects, starting with its
proprietary philosophy. Yet the emacs port, as well as some Windows
users, is of high quality.

-- 
  Paul

Re: Release plans

[Eli Zaretskii]

> From: A Soare <alinsoar@voila.fr>
> Date: Tue, 12 Aug 2008 15:37:22 +0200 (CEST)
> Cc: "Emacs   Dev  \[emacs-devel\]" <emacs-devel@gnu.org>
> 
> > Yes, I understood that this is what you meant. But in what way did you 
> > reach this conclusion?
> 
> By induction.

"Induction" as in "1 is a prime number, 2 is a prime number, 3 is a
prime number; so by induction, every number is prime."

Re: Release plans

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Yes, I understood that this is what you meant. But in what way did you 
>> > reach this conclusion?
>> 
>> By induction.
>
> "Induction" as in "1 is a prime number, 2 is a prime number, 3 is a
> prime number; so by induction, every number is prime."

This is not the complete story.

The Mathematician: Theorem: Every odd number >1 is prime. Proof: 3 is
prime, 5 is prime, 7 is prime. The theorem is demonstrated by induction.

The Physicist: 3 is prime, 5 is prime, 7 is prime, 9 (experimental
error), 11 is prime, 13 is prime.

The Engineer: 3 is prime, 5 is prime, 7 is prime, 9 is prime, ...

BTW, 1 is rarely considered a prime number. Furthermore: I say that it
is not a prime number!

Please argue against this.

Please do it. Really. We need to shift this thread to an off-topic realm
in order to shut it down.

-- 
Oscar

Re: Release plans

[Paul R]

On Tue, 12 Aug 2008 21:16:16 +0200, Óscar Fuentes <ofv@wanadoo.es> said:

Óscar> This is not the complete story.

Óscar> The Mathematician: Theorem: Every odd number >1 is prime.
Óscar> Proof: 3 is prime, 5 is prime, 7 is prime. The theorem is
Óscar> demonstrated by induction.

Óscar> The Physicist: 3 is prime, 5 is prime, 7 is prime,
Óscar> 9 (experimental error), 11 is prime, 13 is prime.

Óscar> The Engineer: 3 is prime, 5 is prime, 7 is prime, 9 is prime,
Óscar> ...

Some poster here: Theorem: Every even number >0 is prime.
                  Proof: 2 is prime. I don't know for the others
                         but I'm sure it's the same.

;)

-- 
  Paul

Re: Release plans

[A Soare]

> > That is what peuple does not like : to make effort to understand something that they can have without energy.
> 
> Don't you think that those programmers did invest quite a lot of effort 
> in understanding the software they are using now?

Yes, they did inverst lots of energy. But what was the purpose of their investment?

Evidently, in 99% of the cases, they wanted to have a good job to gain money.

To get a good job, they could pass of emacs.

That depends of the ideals of peuple. If you want to correctly choose the solution if it worth investing energy about developing emacs in windows, then you shuld investigate the mentality (the ideals, the value systems) of many peuple in many places in the world.



____________________________________________________

Avant de prendre le volant, repérez votre itinéraire et visualisez le trafic ! http://itineraire.voila.fr/itineraire.html

Re: Release plans

[A Soare]

> A Soare wrote:
> >>> Quite so! Investing energy to develop it under Windows is (almost) loss of energy!
> >> Yes, I understood that this is what you meant. But in what way did you 
> >> reach this conclusion?
> > 
> > By induction. I do not use Windows, and in linux I use emacs for lots of purposes.
> 
> So you mean that for you personal benefits there is no use in developing 
> Emacs under Windows? ;-)

I do not say that for _my_benefit_. I say that in general almost nobody use emacs in windows. There are exceptions, quite so. But I have never seen exceptions.


> 
> >>> I know a few cases of _good_ programmers at google, microsoft, etc that never thought to use emacs.
> >>>
> >>> The reason: Windows has nicer environments to write C++, Delphi, C# etc. (that is what they told me).
> >> Then how can it be good to develop Emacs under any operating system?
> > 
> > In Emacs under Linux for Linux!
> 
> Did you mention any reason that I did not notice?

Personally I always use emacs, and I need nothing else. I tell _exactly_ what I heard that the others say. For me it is not useful under windows, and I have never heard a windows user to use it.

> >>> Emacs and Linux is used just by peuple that wants to understand how things work.
> >> Do you say that there is no use for Emacs?
> > 
> > In windows, yes, that is what I say. In Windows it is completely unuseful.
> 
> Then why is there a use for it under Linux? It seems like you are saying 
> that software under Linux is inferior to the corresponding software 
> under Windows and because of this Emacs can be useful on Linux.

No, there is no contradiction in what I say.

I heard many programmers that they prefer use under GNU Linux others editors. The same reason: they want to gain money easy in my opinion.

What choose everybody depends only of his _education_. Of his values. If you tell soebody "Emacs is written profesionnaly and you can learn looking at its sources" does not have the same effect on every person. The majority of peuple will say (I quote a programmer from gooooogle ) : "Yes, emacs is nice, but I do not like emacs, because I want to gain money, and others programmers will copy-paste the open source projects, and they will steal me the projects" . And he never used emacs.

In linux there are others C/C++ development environments than emacs that can be used without effort.

This discution is enless: the best is to put a button on emacs' page and to ask peuple to vote if they need emacs under windows, and the reason why they do.

> If that is the case why is it Emacs we develop and not something better?

I heard many saying that there are better development. If you say "emacs is written in lisp, so it is very customisable" they will say "oui, mais je peux me passer d'emacs et me debrouiller facilement avec d'autres."

> 
> >>> Windows is used by peuple that want to gain money and to arrive quiqkly at their purpose.
> >> Do you say that using Emacs makes it take long time to do things?
> > 
> > It takes little time when you have already learned how to use it.
>  > The first time when you did a thing, you will never choose something 
> different.
>  > Here is the point: the psychology. Peuple prefers never to make the 
> first effort,
>  > and they prefer to use something to arrive quickly at the point.
> 
> Can we use that point to do something actively? Can we make Emacs better 
> in a way that it satisfies those people's need? (Still not sacrifiying 
> other things.)

This is like demanding to a cannibal "do you want to become a chretien"? Not taking into account a famous tribe of cannibals that died because they lost their native croyance in cannibalisme, the question whether the user want to use emacs does not depend on emacs. But on his values in which he is educated.

So my answer is: this is not a question for programmers, but for educators and family.

> 
> >>> >From all my experience (all what I saw), windows interface for 
>  >>> > emacs is as important as the file ./etc/sex.6 in emacs' sources.
> >> Are you saying that this is the only part of Emacs that we should keep ;-)
> > 
> > Yes, Emacs in Linux is nice.
> 
> Why is the file etc/sex.6 so nice so that we should keep only that on 
> Linux? ;-)

From my viewpoint, all the modules for windows are _not_ useful, i.e. they have the same usefulness as this file.




____________________________________________________

Avant de prendre le volant, repérez votre itinéraire et visualisez le trafic ! http://itineraire.voila.fr/itineraire.html

Re: Release plans

[Lennart Borgman (gmail)]

A Soare wrote:
>> A Soare wrote:
>>>>> Quite so! Investing energy to develop it under Windows is (almost) loss of energy!
>>>> Yes, I understood that this is what you meant. But in what way did you 
>>>> reach this conclusion?
>>> By induction. I do not use Windows, and in linux I use emacs for lots of purposes.
>> So you mean that for you personal benefits there is no use in developing 
>> Emacs under Windows? ;-)
> 
> I do not say that for _my_benefit_. I say that in general almost nobody use emacs in windows. There are exceptions, quite so. But I have never seen exceptions.

Thanks. So maybe I can say what I wanted to point out: You are 
exaggerating and extrapolating from personal experiences. That is of 
course fine sometimes, but not when you want to make conclusions.

I trust you when you say that you have not meat anyone using Emacs on 
Windows. However I am sure you have read about people doing that. And 
they all have their own reasons. Would it not be fair to include their 
reasons before making a conclusion?

>>>>> Emacs and Linux is used just by peuple that wants to understand how things work.
>>>> Do you say that there is no use for Emacs?
>>> In windows, yes, that is what I say. In Windows it is completely unuseful.
>> Then why is there a use for it under Linux? It seems like you are saying 
>> that software under Linux is inferior to the corresponding software 
>> under Windows and because of this Emacs can be useful on Linux.
> 
> No, there is no contradiction in what I say.

Are you sure? Didn't you say that the developers you know do not use 
Emacs on Windows because there are better software for their purpose on 
Windows? And didn't you mean that you trust them?

Why shouldn't we then develop software similar to that they use on 
Windows? It seems like you are hiding some parts of your answer from me ...

Of course I agree with you about making a better world, but I believe 
that sound reasoning is part of going forward in that direction.

>>>>> Windows is used by peuple that want to gain money and to arrive quiqkly at their purpose.
>>>> Do you say that using Emacs makes it take long time to do things?
>>> It takes little time when you have already learned how to use it.
>>  > The first time when you did a thing, you will never choose something 
>> different.
>>  > Here is the point: the psychology. Peuple prefers never to make the 
>> first effort,
>>  > and they prefer to use something to arrive quickly at the point.
>>
>> Can we use that point to do something actively? Can we make Emacs better 
>> in a way that it satisfies those people's need? (Still not sacrifiying 
>> other things.)
> 
> This is like demanding to a cannibal "do you want to become a chretien"?
 > Not taking into account a famous tribe of cannibals that died because 
they
> lost their native croyance in cannibalisme, the question whether the user
 > want to use emacs does not depend on emacs.
 > But on his values in which he is educated.

Don't you just throw away information here?

> So my answer is: this is not a question for programmers, but for educators and family.

Note: It looks like your mail program does something that Thunderbird 
does not expect at all. Thunderbird does not wrap the lines when 
commenting on your text. Do you know the reason? (It takes a lot of time 
that this does not work.)

Re: Release plans

[Alan Mackenzie]

Hi!

On Tue, Aug 12, 2008 at 04:34:49PM +0200, A Soare wrote:

> I say that in general almost nobody use emacs in windows. There are
> exceptions, quite so. But I have never seen exceptions.

In the field I work in (embedded systems), our targets are very often
Unix-like OSs (e.g. QNX), our host systems are (nearly) always Windows,
and development itself is done either on Windows or on a Unix server.  In
this type of environment, cygwin is always installed, and Emacs on
Windows is popular, as is perl, bash, vi, .....; 

It has been known for programmers enamoured of the Windows OS to complain
quite loudly at the lack of a "decent editor" in Unix.  ;-)

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Richard M. Stallman]

    In the field I work in (embedded systems), our targets are very often
    Unix-like OSs (e.g. QNX), our host systems are (nearly) always Windows,

It is a shame to use Windows for that.  Why not switch to GNU/Linux?

Re: Release plans

[Alan Mackenzie]

Hi, Richard,

On Wed, Aug 13, 2008 at 02:26:36AM -0400, Richard M. Stallman wrote:
>     In the field I work in (embedded systems), our targets are very
>     often Unix-like OSs (e.g. QNX), our host systems are (nearly)
>     always Windows,

> It is a shame to use Windows for that.  Why not switch to GNU/Linux?

It's a great shame.  Why not switch?  Because the host system is a
massive company Windows network, much more like a mainframe than a stand
alone PC.  Things like Email and Word processing (with yucky formats) are
done on it.  And backing up files.  For such a company, software
development is merely one department, and not even the most important.
Switching to GNU is possible in principle, but it's difficult,
time-consuming and expensive.  The city administration in Munich is doing
this, for example.  Probably, some medium to large size compaies are,
too.

But yes, it's a great shame.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Richard M. Stallman]

    Switching to GNU is possible in principle, but it's difficult,
    time-consuming and expensive.

Doing things that are difficult and/or time-consuming and/or expensive
in order to escape from proprietary software is precisely the way
to show people that freedom matters.  That is how you lead.  Developing
GNU was also difficult and time-consuming, and some aspects have been
expensive.

Re: Release plans

[Alan Mackenzie]

Hi, Richard!

On Thu, Aug 14, 2008 at 01:19:22AM -0400, Richard M. Stallman wrote:
>     Switching to GNU is possible in principle, but it's difficult,
>     time-consuming and expensive.

> Doing things that are difficult and/or time-consuming and/or expensive
> in order to escape from proprietary software is precisely the way to
> show people that freedom matters.  That is how you lead.  Developing
> GNU was also difficult and time-consuming, and some aspects have been
> expensive.
 
Hey, you snipped too much of the context, you rascal!  The effort I was
talking about was that of a large company, with all the bureaucracy and
inertia that goes with it.  These large companies aren't much concerned
about freedom, unless it is their own.  They might not even be legally
permitted in some jurisdictions to bother much about freedom.

Other people and groups are advancing free software by emphasising free
software's high quality.  Yet you don't recognise their efforts as
legitimate, even though they increase the use of free software, and hence
freedom itself.  I find this puzzling, and I know I'm not alone.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Johannes Weiner]

Hi,

Alan Mackenzie <acm@muc.de> writes:

> Hi, Richard!
>
> On Thu, Aug 14, 2008 at 01:19:22AM -0400, Richard M. Stallman wrote:
>>     Switching to GNU is possible in principle, but it's difficult,
>>     time-consuming and expensive.
>
>> Doing things that are difficult and/or time-consuming and/or expensive
>> in order to escape from proprietary software is precisely the way to
>> show people that freedom matters.  That is how you lead.  Developing
>> GNU was also difficult and time-consuming, and some aspects have been
>> expensive.
>  
> Hey, you snipped too much of the context, you rascal!  The effort I was
> talking about was that of a large company, with all the bureaucracy and
> inertia that goes with it.  These large companies aren't much concerned
> about freedom, unless it is their own.  They might not even be legally
> permitted in some jurisdictions to bother much about freedom.
>
> Other people and groups are advancing free software by emphasising free
> software's high quality.  Yet you don't recognise their efforts as
> legitimate, even though they increase the use of free software, and hence
> freedom itself.  I find this puzzling, and I know I'm not alone.

Freedom should never stand over software quality and usability.  The
same way as security should never do that.  If your security model is to
take the power off your machines you will have a worse solution that one
with higher risk.

Richard, if your argument is really that it is _good_ to have
time-consuming software in order to demonstrate by using it that you
care so much about freedom that you stop solving your problems
efficiently, then I am really sorry for you.

Primarily, software is problem-solving.  If your software comes in a
flavor that doesn't restrict user's freedom, this is really nice.

If you cripple software for freedom's sake, you have driven the purpose
of software ad absurdum.

	Hannes

Re: Release plans

[Alfred M. Szmidt]

   Freedom should never stand over software quality and usability.

Freedom must always stand over software quality and usability, without
it we cannot improve the software in question.

   Primarily, software is problem-solving.  If your software comes in
   a flavor that doesn't restrict user's freedom, this is really nice.

It is a prerequisite that software is free to be able to solve
problems; if the software is not free, then you cannot solve anything.

   If you cripple software for freedom's sake, you have driven the
   purpose of software ad absurdum.

Nobody implied that one should cripple software for freedoms sake.
Nor did rms argue that it is good to have badly written free software.
But it is better to have badly written free software than having well
written non-free software.  We can fix the former, but not the later.

Re: Release plans

[Johannes Weiner]

Hi,

"Alfred M. Szmidt" <ams@gnu.org> writes:

>    Freedom should never stand over software quality and usability.
>
> Freedom must always stand over software quality and usability, without
> it we cannot improve the software in question.

Not when your definition of freedom forbids certain improvements.

>    Primarily, software is problem-solving.  If your software comes in
>    a flavor that doesn't restrict user's freedom, this is really nice.
>
> It is a prerequisite that software is free to be able to solve
> problems; if the software is not free, then you cannot solve anything.

This is flat out wrong.  Software is written for a purpose.  Windows
does its job, whether it does it good or bad and whether you like the
philosophy or not.  It is not free and it solves the problem it was
written for.

>    If you cripple software for freedom's sake, you have driven the
>    purpose of software ad absurdum.
>
> Nobody implied that one should cripple software for freedoms sake.
> Nor did rms argue that it is good to have badly written free software.
> But it is better to have badly written free software than having well
> written non-free software.  We can fix the former, but not the later.

We can fix the former if our definition of freedom allows us to.  This
was the whole point of my previous email, in fact.

Emacs has still no support to load shared libraries during runtime and
IIRC it was rejected back then due to political reasons.  I call this
crippling.

	Hannes

Re: Release plans

[Alan Mackenzie]

Hi, Johannes,

On Thu, Aug 14, 2008 at 12:04:36PM +0200, Johannes Weiner wrote:
> Hi,

> We can fix the former if our definition of freedom allows us to.  This
> was the whole point of my previous email, in fact.

> Emacs has still no support to load shared libraries during runtime and
> IIRC it was rejected back then due to political reasons.  I call this
> crippling.

Well, for a piece of software that is crippled, Emacs works remarkably
well.  If only non-crippled software could run as fast.

I think the lack of provision of binary libraries is more of a legal
thing than a political one.  It would allow people to extend Emacs with
non-free code, and it would be problematic to prevent them distributing
their enslaved versions of Emacs.  I agree with Richard that this would
be undesirable in the extreme.  Linux has taken the opposite attitude:
that extending Linux with non-free modules is OK.  This has not been free
of problems.

If there were a way of licensing Emacs so that only free libraries could
be attached to it, this would be done.

What sort of libraries do you want to use from Emacs anyway?

> 	Hannes

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Johannes Weiner]

Hi Alan,

Alan Mackenzie <acm@muc.de> writes:

> Hi, Johannes,
>
> On Thu, Aug 14, 2008 at 12:04:36PM +0200, Johannes Weiner wrote:
>> Hi,
>
>> We can fix the former if our definition of freedom allows us to.  This
>> was the whole point of my previous email, in fact.
>
>> Emacs has still no support to load shared libraries during runtime and
>> IIRC it was rejected back then due to political reasons.  I call this
>> crippling.
>
> Well, for a piece of software that is crippled, Emacs works remarkably
> well.  If only non-crippled software could run as fast.

Uh, crap, that came over wrong.  I was never to claim that Emacs works
bad.  I just know there are features that would further improve it.

> I think the lack of provision of binary libraries is more of a legal
> thing than a political one.  It would allow people to extend Emacs with
> non-free code, and it would be problematic to prevent them distributing
> their enslaved versions of Emacs.
>
> I agree with Richard that this would
> be undesirable in the extreme.  Linux has taken the opposite attitude:
> that extending Linux with non-free modules is OK.  This has not been free
> of problems.

I am very sensitive when it comes to such decisions.  Because when you
try to prevent idiots from being idiots, you will also restrict people
that could do great work with the potential features.

The primary thing about Linux modules is, well, that you can load
modules.  This gives you power to do really clever stuff.

Whether one loads proprietary modules into the kernel is a personal
decision and I don't like deciding for other people.

I argue with people loading these modules and tell them why I consider
it stupid but the decision should be their own.

Neither the Linux kernel, nor I as a free user who chooses not to load
proprietary bullcrap into it, have been harmed by the kernel's mechanism
to load said bullcrap.

If it restricts people, than because of their own free decision to
restrict themselves.  That is not a reason to leave the mechanism out
alltogether.  You can also not blame car manufacturers for building
devices that might help a person to kill itself by driving against a
tree as a way of suicide.

People will do that on occasion, this is not a reason to forbid cars for
all others that get a good job done by utilizing it.

And having a mechanims that would be very helpful but also makes it
potentially a bit easier to do stupid things is better than not having
this mechanism.  I also refer to the recently discussed emacs package
manager.

> If there were a way of licensing Emacs so that only free libraries could
> be attached to it, this would be done.

Linux prevents certain APIs from being used by non-free modules.  And
modules have to explicitely identify themselves as GPL-licensed to be
able to use GPL-only symbols.

IANAL but perhaps a mechanism for Emacs that requires modules to
announce themselves as GPL'd software would be enough?

> What sort of libraries do you want to use from Emacs anyway?

I would be interested in having OTR support for jabber.el.  So my choice
is between implementing the OTR protocol in elisp or linking the emacs
binary against libotr.

I consider both solutions bad by design.  The optimal solution would be
for jabber.el to issue (require 'libotr) and have Emacs doing the right
thing.

	Hannes

Re: Release plans

[Tassilo Horn]

On Thursday 14 August 2008 13:07:35 Johannes Weiner wrote:

Hi Hannes,

> Neither the Linux kernel, nor I as a free user who chooses not to load
> proprietary bullcrap into it, have been harmed by the kernel's
> mechanism to load said bullcrap.

That needs not to be true.  Take the nvidia drivers as an example.  If
the kernel wouldn't allow this driver to be loaded, we might have a
better free driver today.  Who knows?

The same applies to the intel wireless drivers, which require some
proprietary firmware.  If something works, the attraction of
implementing a free alternative fades away.

Of course you can argue the other way round, too.  Would GNU/Linux be
where it is today if no proprietary drivers allowed most features of the
computer to be used?

Bye,
Tassilo

Re: Release plans

[Johannes Weiner]

Hi Tassilo,

Tassilo Horn <tassilo@member.fsf.org> writes:

> On Thursday 14 August 2008 13:07:35 Johannes Weiner wrote:
>
> Hi Hannes,
>
>> Neither the Linux kernel, nor I as a free user who chooses not to load
>> proprietary bullcrap into it, have been harmed by the kernel's
>> mechanism to load said bullcrap.
>
> That needs not to be true.  Take the nvidia drivers as an example.  If
> the kernel wouldn't allow this driver to be loaded, we might have a
> better free driver today.  Who knows?

It seems to solve itself evolutionary.  nvidia sucks so bad at keeping
up with the kernel api, left aside frequent, undebuggable oopsen, that I
know quite some people who's subsequent video card has been an ATI card
just because there are now free drivers available.

I myself have an nvidia card due to historic reasons which I can not
fully utilize because I decided to not use the nvidia driver.  But as
soon I have enough money for an upgrade, I will sure as hell get a video
card that is supported by free drivers.  And in my case, this is not
only a technical decision.

When someone asks me for help with their kernel becoming unstable after
loading proprietary modules, I explain them that it's neither the
kernels fault, nor the module-vendors fault.  It's the person's fault
who made the decision.

Noone `subjugated' a user of the proprietary nvidia module.  Only their
own stupidity.

> The same applies to the intel wireless drivers, which require some
> proprietary firmware.  If something works, the attraction of
> implementing a free alternative fades away.

I consider ath5k and the ati drivers proving the opposite.  I think
Richard has yet another wireless card that works with free drivers.

I actually see a trend in free drivers evolving.

> Of course you can argue the other way round, too.  Would GNU/Linux be
> where it is today if no proprietary drivers allowed most features of the
> computer to be used?

I don't know.  But are there so many proprietary modules at all?  I
believe there are by far more free modules than non-free ones for the
kernel.

And even if I would myself not do so, I would prefer a user running a
complete GNU/Linux system with one proprietary module loaded to get his
work done over him running a completely non-free environment.

You can still fight the remaining evil.  And I consider myself as a
proof that the figthing spirit is not lost just because there is a
working non-free module available.

	Hannes

Re: Release plans

[Richard M. Stallman]

    Of course you can argue the other way round, too.  Would GNU/Linux be
    where it is today if no proprietary drivers allowed most features of the
    computer to be used?

Where is GNU/Linux today?  Tens of millions of people use it, but most
of them use non-free software with it.  It's a lot of "success", but
we have a long way to go to reach a world of freedom.

Re: Release plans

[Alan Mackenzie]

Hi, again!

On Thu, Aug 14, 2008 at 01:07:35PM +0200, Johannes Weiner wrote:
> Hi Alan,

> Alan Mackenzie <acm@muc.de> writes:

> > I think the lack of provision of binary libraries is more of a legal
> > thing than a political one.  It would allow people to extend Emacs
> > with non-free code, and it would be problematic to prevent them
> > distributing their enslaved versions of Emacs.

> > I agree with Richard that this would be undesirable in the extreme.
> > Linux has taken the opposite attitude: that extending Linux with
> > non-free modules is OK.  This has not been free of problems.

> I am very sensitive when it comes to such decisions.  Because when you
> try to prevent idiots from being idiots, you will also restrict people
> that could do great work with the potential features.

Just to clarify my previous post, I do see that there are strong points
on both sides of this argument.  My personal view is that the coming into
effective existence of "enslaved" versions of Emacs through the loading
of binary libraries would outweigh the benefits.

> The primary thing about Linux modules is, well, that you can load
> modules.  This gives you power to do really clever stuff.

> Whether one loads proprietary modules into the kernel is a personal
> decision and I don't like deciding for other people.

The loadability of modules into the kernel has effects on the whole free
software community.  Somebody MUST decide this issue for other people,
possibly by default.  In these two cases, the decisions were taken by
Linus Torvalds and Richard Stallman.  It is entirely possible that both
were right.  Now I agree with you about it being a political thing.  ;-)

> I argue with people loading these modules and tell them why I consider
> it stupid but the decision should be their own.

The facility you want would allow people, in effect, to make proprietary
extensions to Emacs.  We could end up with a firm like Linspire saying
"our version of Emacs is superior because it can access files over the
<proprietary X> protocol, so why don't you buy a license for our superior
version of Linux instead of your lame Ubuntu or RedHat?".

I think that this possibility outweighs the benefit from being able to
load in something like the OTR libraries.  At the same time, I respect
your view to the contrary.

> > If there were a way of licensing Emacs so that only free libraries
> > could be attached to it, this would be done.

> Linux prevents certain APIs from being used by non-free modules.  And
> modules have to explicitly identify themselves as GPL-licensed to be
> able to use GPL-only symbols.

I didn't know that.  Thanks!

> IANAL but perhaps a mechanism for Emacs that requires modules to
> announce themselves as GPL'd software would be enough?

More specifically, as GPL3 software.

> > What sort of libraries do you want to use from Emacs anyway?

> I would be interested in having OTR support for jabber.el.  So my
> choice is between implementing the OTR protocol in elisp or linking the
> emacs binary against libotr.

> I consider both solutions bad by design.  The optimal solution would be
> for jabber.el to issue (require 'libotr) and have Emacs doing the right
> thing.

There are other choices.  You could, for example, write a module-loading
facility yourself, and thus distribute your own Emacs fork.  You'ld not
make yourself popular though, any more than the Lucid Emacs crowd did a
long time ago.

Or, you could simply adapt the OTR sources and build them into Emacs.
Well, you could if either the OTR author was prepared to release his
sources under GPL3, or RMS was prepared to accept GPL2 stuff into Emacs.
Hell will freeze over before the second of these happens.  ;-)

> 	Hannes

By the way, do you really live in an acid bath?  ;-)

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Johannes Weiner]

Hi, again again!

Alan Mackenzie <acm@muc.de> writes:

> Hi, again!
>
> On Thu, Aug 14, 2008 at 01:07:35PM +0200, Johannes Weiner wrote:
>> Hi Alan,
>
>> Alan Mackenzie <acm@muc.de> writes:
>
>> > I think the lack of provision of binary libraries is more of a legal
>> > thing than a political one.  It would allow people to extend Emacs
>> > with non-free code, and it would be problematic to prevent them
>> > distributing their enslaved versions of Emacs.
>
>> > I agree with Richard that this would be undesirable in the extreme.
>> > Linux has taken the opposite attitude: that extending Linux with
>> > non-free modules is OK.  This has not been free of problems.
>
>> I am very sensitive when it comes to such decisions.  Because when you
>> try to prevent idiots from being idiots, you will also restrict people
>> that could do great work with the potential features.
>
> Just to clarify my previous post, I do see that there are strong points
> on both sides of this argument.  My personal view is that the coming into
> effective existence of "enslaved" versions of Emacs through the loading
> of binary libraries would outweigh the benefits.

Okay.

>> The primary thing about Linux modules is, well, that you can load
>> modules.  This gives you power to do really clever stuff.
>
>> Whether one loads proprietary modules into the kernel is a personal
>> decision and I don't like deciding for other people.
>
> The loadability of modules into the kernel has effects on the whole free
> software community.  Somebody MUST decide this issue for other people,
> possibly by default.  In these two cases, the decisions were taken by
> Linus Torvalds and Richard Stallman.  It is entirely possible that both
> were right.  Now I agree with you about it being a political thing.
> ;-)

I see the main difference is that Torvalds choose to leave that decision
to the user by giving him the needed mechanisms to do crazy stuff.

Richard restricted the user from doing crazy stuff.

>> I argue with people loading these modules and tell them why I consider
>> it stupid but the decision should be their own.
>
> The facility you want would allow people, in effect, to make proprietary
> extensions to Emacs.  We could end up with a firm like Linspire saying
> "our version of Emacs is superior because it can access files over the
> <proprietary X> protocol, so why don't you buy a license for our superior
> version of Linux instead of your lame Ubuntu or RedHat?".

Yeah, this module license restriction comes to mind again.  But really,
this possibility has been there since XEmacs included the module loader
and noone cared to sell proprietary modules.

BUT!  If a proprietary module would be written for Emacs that solves a
problem no free alternative does so far and the functionality could be
of benefit to the users, this could be motivation to create a free
alternative.  At least that is what I think.  But that's just me, I
really love evolving technology :-)

> I think that this possibility outweighs the benefit from being able to
> load in something like the OTR libraries.  At the same time, I respect
> your view to the contrary.
>
>> > If there were a way of licensing Emacs so that only free libraries
>> > could be attached to it, this would be done.
>
>> Linux prevents certain APIs from being used by non-free modules.  And
>> modules have to explicitly identify themselves as GPL-licensed to be
>> able to use GPL-only symbols.
>
> I didn't know that.  Thanks!
>
>> IANAL but perhaps a mechanism for Emacs that requires modules to
>> announce themselves as GPL'd software would be enough?
>
> More specifically, as GPL3 software.

Yeah, of course.  The thing that you implement a cooperative loader,
more or less.  If the module doesn't say `hey, I am free software' on
load time, the loader could refuse to continue.

This works for Linux.  I mean, I don't know of situations where a module
claimed falsely to be under a free license while it was not, in order to
access GPL symbols or prevent the kernel from tainting itself.

But as said, it would be good to have some lawyer sort this out.

>> > What sort of libraries do you want to use from Emacs anyway?
>
>> I would be interested in having OTR support for jabber.el.  So my
>> choice is between implementing the OTR protocol in elisp or linking the
>> emacs binary against libotr.
>
>> I consider both solutions bad by design.  The optimal solution would be
>> for jabber.el to issue (require 'libotr) and have Emacs doing the right
>> thing.
>
> There are other choices.  You could, for example, write a module-loading
> facility yourself, and thus distribute your own Emacs fork.  You'ld not
> make yourself popular though, any more than the Lucid Emacs crowd did a
> long time ago.

Yes, it's the difference between theoretical freedom and reality.

Also, forking would mean leaving GNU Emacs behind, which I would prefer
not to :)

> Or, you could simply adapt the OTR sources and build them into Emacs.
> Well, you could if either the OTR author was prepared to release his
> sources under GPL3, or RMS was prepared to accept GPL2 stuff into Emacs.
> Hell will freeze over before the second of these happens.  ;-)

In my opinion the OTR sources don't have anything to do with the Emacs
core.  The idea of the el packages is that you lazy load code and have
it apart from the core.

The same is not possible for C code but it would be great to have that!

By the way, what prevents you from loading proprietary .elc files?

> By the way, do you really live in an acid bath?  ;-)

Jawohl!  It's actually a reference to a reeeeaaally bad piece of german
electronic dance music... `Join me in my bath of acid.  Witness your own
decay.  Boom Boom Boom Boom...'

	Hannes

Re: Release plans

[Alan Mackenzie]

Hi, again, again, again!

On Thu, Aug 14, 2008 at 03:15:00PM +0200, Johannes Weiner wrote:

> By the way, what prevents you from loading proprietary .elc files?

.elc files are compiled from .el files.  .el files, because they call
functions like `car', because they embed themselves in the standard Emacs
obarray, ..., are extensions to Emacs.  Therefore, they're subject
to the GPL.  Or something like that.

> > By the way, do you really live in an acid bath?  ;-)

> Jawohl!  It's actually a reference to a reeeeaaally bad piece of german
> electronic dance music... `Join me in my bath of acid.  Witness your
> own decay.  Boom Boom Boom Boom...'

Ah.  A bit like Johann Sebastian Bach.  Got you!  ;-)

> 	Hannes

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Johannes Weiner]

Hi, again, again, again, again!

Alan Mackenzie <acm@muc.de> writes:

> Hi, again, again, again!
>
> On Thu, Aug 14, 2008 at 03:15:00PM +0200, Johannes Weiner wrote:
>
>> By the way, what prevents you from loading proprietary .elc files?
>
> .elc files are compiled from .el files.  .el files, because they call
> functions like `car', because they embed themselves in the standard Emacs
> obarray, ..., are extensions to Emacs.  Therefore, they're subject
> to the GPL.  Or something like that.

Hm, I wonder if this cooperative loader could use the same trick.
I.e. make the module register itself and by using the registration
mechanism which is GPL software, the module becomes derivative work.  Or
something.

>> > By the way, do you really live in an acid bath?  ;-)
>
>> Jawohl!  It's actually a reference to a reeeeaaally bad piece of german
>> electronic dance music... `Join me in my bath of acid.  Witness your
>> own decay.  Boom Boom Boom Boom...'
>
> Ah.  A bit like Johann Sebastian Bach.  Got you!  ;-)

Huh, why JSB?  Bach was a good hacker.  The author of the piece in
question is, well, ... :)

	Hannes

Re: Release plans

[Stephen J. Turnbull]

Johannes Weiner writes:

 > I.e. make the module register itself and by using the registration
 > mechanism which is GPL software, the module becomes derivative
 > work.

According to the prevailing definition of "work", anything loaded into
the same process becomes part of a derivative work.  The FSF's legal
staff says that if a module cannot be used without the rest of the
program, the source as well is part of the same work.  So what you
want is already true.

The difference with the kernel is that (a) the kernel is not a
process, and (b) Linus has made the exception explicit.

What the kernel does is to require the module to call an API to assert
that it is GPLv2.  What that means is that it's an *intentional*
copyright violation if that is a lie.  Statutory damages on a
per-copy-distributed basis, possibly a criminal violation.  "I see
your 0.02 Euro, and raise one CAP budget." ;-)

Re: Release plans

[Gilaras Drakeson]

Hi,

When emacs refuses to load a GPL library I cannot help but to call the
situation an ugly bureaucracy. The bare minimum for GNU to be a
consistent operating system is to be able to dynamically load any GNU
library.

> By the way, what prevents you from loading proprietary .elc files?

Good point.

-- 
Gilaras

Re: Release plans

[Stephen J. Turnbull]

Alan Mackenzie writes:

 > The loadability of modules into the kernel has effects on the whole free
 > software community.

Yeah, it forces free people to make free choices.  This is a good
thing.

 > The facility you want would allow people, in effect, to make proprietary
 > extensions to Emacs.

That's FUD.  According to the FSF legal staff, it is illegal to
distribute non-GPLv3 modules intended for linking to Emacs.  This
restriction on dynamic loading doesn't change the legal status; it
just makes it cheaper for the FSF to fight would-be violators and wake
up those people who just don't bother to think about whether their
distributions are violations.

As Richard says, it's appropriate that the defenders of freedom pay an
extra cost to show they value freedom.  Emacs should get dynamically
loadable modules.  The kernel's strategy for require'ing GPL would
work here, too.

 > We could end up with a firm like Linspire saying "our version of
 > Emacs is superior because it can access files over the <proprietary
 > X> protocol,

It might cost the FSF to fight that, but they'd win.  Don't defend
freedom with FUD.  If they can't win, then you could distribute Emacs
as a .o with appropriate modules and have the user do the linking to
the same effect.  If the proprietary module is that attractive, you
can bet people would do it.

 > There are other choices.  You could, for example, write a module-loading
 > facility yourself, and thus distribute your own Emacs fork.  You'ld not
 > make yourself popular though, any more than the Lucid Emacs crowd did a
 > long time ago.

I resemble that remark, although I wasn't there at the time.  Is it
really worth offending those of us who choose to work on XEmacs when
the cases are not parallel at all?

The module-loading facility has long been available for both Emacs (as
3rd party patches, sorry, no URL offhand; maybe from the same source
as XEmacs/CHISE at Kyoto U?) and XEmacs (standard since 21.4).

Re: Release plans

[Richard M. Stallman]

    As Richard says, it's appropriate that the defenders of freedom pay an
    extra cost to show they value freedom.

What I said is that making a sacrifice for the sake of freedom
can have the useful effect of making other people start to think about
freedom.

Re: Release plans

[Alan Mackenzie]

Hello, Stephen!

On Fri, Aug 15, 2008 at 03:00:56AM +0900, Stephen J. Turnbull wrote:
> Alan Mackenzie writes:

>  > The loadability of modules into the kernel has effects on the whole
>  > free software community.

> Yeah, it forces free people to make free choices.  This is a good
> thing.

A bit like the availability of guns in a community does.

>  > The facility you want would allow people, in effect, to make
>  > proprietary extensions to Emacs.

> That's FUD.  According to the FSF legal staff, it is illegal to
> distribute non-GPLv3 modules intended for linking to Emacs.

Are you sure?  OK, yes you are.  Any chance of a reference?  Are you also
sure this applies to external libraries interacting over a clean thin
narrow openly specified interface, as contrasted to Elisp libraries which
burrow into the heart of Emacs?

> This restriction on dynamic loading doesn't change the legal status; it
> just makes it cheaper for the FSF to fight would-be violators and wake
> up those people who just don't bother to think about whether their
> distributions are violations.

> As Richard says, it's appropriate that the defenders of freedom pay an
> extra cost to show they value freedom.  Emacs should get dynamically
> loadable modules.  The kernel's strategy for require'ing GPL would work
> here, too.

>  > We could end up with a firm like Linspire saying "our version of
>  > Emacs is superior because it can access files over the <proprietary
>  > X> protocol,

> It might cost the FSF to fight that, but they'd win.  Don't defend
> freedom with FUD.

Hey, just because I'm mistaken (if I am) doesn't make me a fudder.

> If they can't win, then you could distribute Emacs as a .o with
> appropriate modules and have the user do the linking to the same
> effect.  If the proprietary module is that attractive, you can bet
> people would do it.

>  > There are other choices.  You could, for example, write a
>  > module-loading facility yourself, and thus distribute your own Emacs
>  > fork.  You'ld not make yourself popular though, any more than the
>  > Lucid Emacs crowd did a long time ago.

> I resemble that remark, although I wasn't there at the time.  Is it
> really worth offending those of us who choose to work on XEmacs when
> the cases are not parallel at all?

Sincere topologies.  Offense wasn't intended, it was just an ill
considered throw away comparison.

> The module-loading facility has long been available for both Emacs (as
> 3rd party patches, sorry, no URL offhand; maybe from the same source as
> XEmacs/CHISE at Kyoto U?) and XEmacs (standard since 21.4).

I didn't know that either.  I looked in the two canonical places on my
XEmacs 21.4.17, but didn't find it.  Any chance of a hint to type at C-h
f?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Stephen J. Turnbull]

Alan Mackenzie writes:
 > Hello, Stephen!
 > 
 > On Fri, Aug 15, 2008 at 03:00:56AM +0900, Stephen J. Turnbull wrote:
 > > Alan Mackenzie writes:
 > 
 > >  > The loadability of modules into the kernel has effects on the whole
 > >  > free software community.
 > 
 > > Yeah, it forces free people to make free choices.  This is a good
 > > thing.
 > 
 > A bit like the availability of guns in a community does.

A bit, yes, but the prevalance of that kind of exaggeration in this
community is precisely why I no longer think of myself as a "free
software advocate", though I do advocate software freedom.

 > >  > The facility you want would allow people, in effect, to make
 > >  > proprietary extensions to Emacs.
 > 
 > > That's FUD.  According to the FSF legal staff, it is illegal to
 > > distribute non-GPLv3 modules intended for linking to Emacs.
 > 
 > Are you sure?  OK, yes you are.

Actually, no.  I misspoke.  It is a violation of the GPL to distribute
something, like a Makefile, that is intended to cause a non-GPLvX-
compatible module to be to be linked to a GPLvX module.  I strongly
believe that would include a module being loaded by an Emacs-specific
dynamic loader, such as one that won't load if you don't call
hey_emacs_i_am_gpl_v(X).

I do believe that the FSF would maintain the original position above
(where "intended" is the key word and "-compatible needs to be
inserted appropriately), but I am not terribly sure of that.  In any
case, the restatement is what I need here.

 > Any chance of a reference?

For the restatement:

FSF vs. XEmacs.  We sought and received guidance from Richard on the
question of whether a Qt XEmacs could be distributed.  His answer was
yes on X11 platforms, no on Windows platforms, and provided that we
made it impossible to link Qt in the Cygwin and native NT builds.
(Unless the user patched our code, of course.)  It's in the XEmacs
archives, but you'd have to ask me as they're currently offline due to
a severe space crunch on our host.

FSF vs. Aladdin (Ghostscript).  It's in the ghostscript mailing list
archives, from several years back.  Searching for readline and
ghostscript probably will bring it up.  The FSF intimidated Aladdin
into removing two lines from its Makefile, on the grounds that they
showed the intention to link Aladdin Ghostscript to GNU readline, thus
making Aladdin Ghostscript a derivative of GNU readline.  Aladdin did
remove the code, under protest that there was no license violation
since they did not distribute GNU readline.

 > Are you also sure this applies to external libraries interacting
 > over a clean thin narrow openly specified interface, as contrasted
 > to Elisp libraries which burrow into the heart of Emacs?

First, that's not an "extension" in the usual sense of the word; to
really extend Emacs you need DEFUN.  But that's wordplay.

Show me the interface, and I'll tell you whether I think it applies.
If you mean something like the interface of libpng, sure, you could do
that and it wouldn't apply.  But any platform that provides a
proprietary version of libpng (for example) can already link it
statically.  This is not a distinction between dynamic and static
linking; if one prohibition can be enforced, so can the other.  Cost
will differ, that's all.

I don't think Emacs itself has any such "specified interfaces", and
all the modules I know of either call Emacs buffer functions or use
the DEFUN macro.

 > Hey, just because I'm mistaken (if I am) doesn't make me a fudder.

No offense intended; I say if it is a mistake it is FUD, but I'm
talking about the statement, not the speaker.  Just because a mistake
is FUD doesn't make one a fudder.  But fudders can pick it up and cite
it as the authority, so one should avoid it.

 > Sincere topologies.  Offense wasn't intended, it was just an ill
 > considered throw away comparison.

Your open sets are accepted, and in private mail David Kastrup
contributed somthing like "It's all parallel anyway; that's the point
of hyperbole."  (Which I failed to get until he explained it.<sigh>)
And I would not believe without strong evidence that you ever intended
offense.

 > > The module-loading facility has long been available for both Emacs (as
 > > 3rd party patches, sorry, no URL offhand; maybe from the same source as
 > > XEmacs/CHISE at Kyoto U?) and XEmacs (standard since 21.4).
 > 
 > I didn't know that either.  I looked in the two canonical places on my
 > XEmacs 21.4.17, but didn't find it.  Any chance of a hint to type at C-h
 > f?

It's probably not quite that standard; I believe you need to configure
--with-modules.  Look in M-x describe-installation for module
capability, and if it's there, C-h f load-module.  If not, you can see
the few that we've got in the modules/ directory of the source.

Re: Release plans

[Richard M. Stallman]

What is libotr?  What precisely is it license status?
There may be something here that I ought to do, once I understand
the facts.

Re: Release plans

[Johannes Weiner]

Hi,

"Richard M. Stallman" <rms@gnu.org> writes:

> What is libotr?

An encryption library that is mostly used by instant messengers.

> What precisely is it license status?

The Off-the-Record Messaging library (in the src directory) is
covered by the following (LGPL) license:

    Off-the-Record Messaging library
    Copyright (C) 2004-2008  Ian Goldberg, Chris Alexander, Nikita
    Borisov
                     <otr@cypherpunks.ca>

    This library is free software; you can redistribute it and/or
    modify it under the terms of version 2.1 of the GNU Lesser General
    Public License as published by the Free Software Foundation.

    This library 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
    Lesser General Public License for more details.

    There is a copy of the GNU Lesser General Public License in the
    COPYING.LIB file packaged with this library; if you cannot find it,
    write to the Free Software Foundation, Inc., 59 Temple Place, Suite
    330, Boston, MA 02111-1307  USA

The Off-the-Record Messaging Toolkit (in the toolkit directory) is
covered
by the following (GPL) license:

    Off-the-Record Messaging Toolkit
    Copyright (C) 2004-2008  Ian Goldberg, Chris Alexander, Nikita
    Borisov
                     <otr@cypherpunks.ca>

    This program is free software; you can redistribute it and/or modify
    it under the terms of version 2 of the GNU General Public License as
    published by the Free Software Foundation.

    This program 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.

    There is a copy of the GNU General Public License in the COPYING
    file
    packaged with this toolkit; if you cannot find it, write to the Free
    Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
    02111-1307  USA

> There may be something here that I ought to do, once I understand
> the facts.

	Hannes

Re: Release plans

[Richard M. Stallman]

Thanks.  It seems that there is nothing I need to do in regard to OTR,
even though it is unfortunate that the toolkit is available only under
GPL version 2.

Re: Release plans

[Alfred M. Szmidt]

   >    Freedom should never stand over software quality and usability.
   >
   > Freedom must always stand over software quality and usability, without
   > it we cannot improve the software in question.

   Not when your definition of freedom forbids certain improvements.

Free software does not forbid any kinds of improvment.  It explicitly
protects that right.

   Emacs has still no support to load shared libraries during runtime and
   IIRC it was rejected back then due to political reasons.  I call this
   crippling.

If a feature allows someone to subjugate the rights of a computer
user, then it is better not to implement it.  The Emacs maintainers
decided that this feature would do a greater disservice to users than
having it included, so they decided not to.  It is no different to
rejecting a feature because it does something annoying, you may call
it crippling, but it is just good managment of a project.

Re: Release plans

[Johannes Weiner]

Hi,

"Alfred M. Szmidt" <ams@gnu.org> writes:

>    >    Freedom should never stand over software quality and usability.
>    >
>    > Freedom must always stand over software quality and usability, without
>    > it we cannot improve the software in question.
>
>    Not when your definition of freedom forbids certain improvements.
>
> Free software does not forbid any kinds of improvment.  It explicitly
> protects that right.
>
>    Emacs has still no support to load shared libraries during runtime and
>    IIRC it was rejected back then due to political reasons.  I call this
>    crippling.
>
> If a feature allows someone to subjugate the rights of a computer
> user, then it is better not to implement it.

You always assume people are stupid.  Please don't do that, it really
offends me.

The only way a user can become enslaved is by not having a choice.  If
there are free alternatives and someone choses to use the non-free
version, this is not the fault of the non-free software but the users
own free decision.

> The Emacs maintainers decided that this feature would do a greater
> disservice to users than having it included, so they decided not to.
> It is no different to rejecting a feature because it does something
> annoying, you may call it crippling, but it is just good managment of
> a project.

First of all, I don't consider dictatorship a good management style.

Second, if that feature annoys someone BUT she has the possibility to
disable it, there is no problem with it.

Some people are annoyed by the transient mark, some are not.  Even if
all maintainers would find that feature annoying, it would be a good
thing to have it anyway for some people might find it useful.

	Hannes

Re: Release plans

[Alfred M. Szmidt]

   You always assume people are stupid.  Please don't do that, it
   really offends me.

I have no idea where you got that from.  I never made such an
assumption, I am quite naive when it comes to people, and think the
best of them.

   Some people are annoyed by the transient mark, some are not.  Even
   if all maintainers would find that feature annoying, it would be a
   good thing to have it anyway for some people might find it useful.

TTM doesn't have the side effect of alllowing someone to subjugate the
rights of a user, loadable modules do.  

Re: Release plans

[Johannes Weiner]

"Alfred M. Szmidt" <ams@gnu.org> writes:

>    You always assume people are stupid.  Please don't do that, it
>    really offends me.
>
> I have no idea where you got that from.  I never made such an
> assumption, I am quite naive when it comes to people, and think the
> best of them.

By saying the user is subjugated you place him under disability.  It's
not that someone would coerce you with death threats into using a
proprietary module for Emacs if it did support loading these things.

>    Some people are annoyed by the transient mark, some are not.  Even
>    if all maintainers would find that feature annoying, it would be a
>    good thing to have it anyway for some people might find it useful.
>
> TTM doesn't have the side effect of alllowing someone to subjugate the
> rights of a user, loadable modules do.  

Again, the user has the right to choose.  As I said, you might forbid
cars with the same argument, i.e. it could be harmful to the user.

Your basic assumption is that if someone writes non-free software, the
user would be totally helpless and enslaved by the author.  This is not
true!  The person would be in a position she chose to be in BY FREE
WILL.

	Hannes

Re: Release plans

[Alfred M. Szmidt]

   >    Some people are annoyed by the transient mark, some are not.
   >    Even if all maintainers would find that feature annoying, it
   >    would be a good thing to have it anyway for some people might
   >    find it useful.
   >
   > TTM doesn't have the side effect of alllowing someone to
   > subjugate the rights of a user, loadable modules do.

   Again, the user has the right to choose.  As I said, you might
   forbid cars with the same argument, i.e. it could be harmful to the
   user.

Nobody has forbidden anything.  The Emacs maintainers have simply
decided that the specific feature you want won't be included in Emacs,
nothing more.

   Your basic assumption is that if someone writes non-free software,
   the user would be totally helpless and enslaved by the author.
   This is not true!  The person would be in a position she chose to
   be in BY FREE WILL.

Non-free software users are indeed under the exclusive control of the
author, the author decides what they can do with the program.  The
only right thing from the user is to refuse to use the non-free
program.

Re: Release plans

[Stephen J. Turnbull]

Alfred M. Szmidt writes:

 > Non-free software users are indeed under the exclusive control of the
 > author, the author decides what they can do with the program.

Nonsense.  The user is not under the exclusive control of the author,
nor any control whatsoever.  The software is, of course, under
substantial control of the rightsholder.  The user, however, can
always stop using the program at any time, with their freedom fully
intact.

If their wallet is a bit slimmer, please call it "tuition".  But I
digress: this thread is about freedom, not economics.

Re: Release plans

[Richard M. Stallman]

    Your basic assumption is that if someone writes non-free software, the
    user would be totally helpless and enslaved by the author.  This is not
    true!  The person would be in a position she chose to be in BY FREE
    WILL.

Whether free will exists is a difficult philosophical question which
we have no need to tackle.  We can agree that making choices does
exist.  I think you are saying that these users would run the non-free
software by choice.

That may or may not be true.  Since the example is imaginary and only
vaguely specified, there is no basis to be sure what it would or would
not imply.  It is clearer to look at a real example about which we
really can know something.

Millions of people use Windows.  Why?  Partly because that's what came
on the machine, partly because they don't care, and partly by choice.
And when they do it by choice, why did they make that choice?  Partly
due to network effect, partly because that's what possible or real
employers use, partly because that's what the school taught them.
Perhaps some people actually like it.  Maybe they don't mind the
malicious features, or maybe they don't know about them, or maybe they
choose not to think about them.

But all those things are beside the point.  Windows subjugates the
user, and that's wrong even if people choose to be subjugated.

Re: Release plans

[Lennart Borgman (gmail)]

Richard M. Stallman wrote:
> Millions of people use Windows.  Why?  Partly because that's what came
> on the machine, partly because they don't care, and partly by choice.

It is a bit temptating to see this list as grasping all possibilties. I 
think that is a mistake.

I happened to watch the rise of ms windows. I was astonished and had a 
hard time to understand what was happening. No one of course can really 
tell the reason behind the success, but some things I noticed where:

- The advertising campaign from MS said to the user "you should decide 
what programs you have on your pc". Very smart. If you tried to tell 
users that there are better programs (there were!) then you just had to 
face that the user "wanted to decide".

- The free software world in my opinion did exactly the opposite. It 
said to the users "we know what is best for you" (because we are 
smarter). This is a psychological mistake. And it is not an easy one to 
cure.

- The unix vendor at that time had the best software. I tried to 
encourage them to make something that we could actually use in a company 
environment. The response I got was "we are best", "when the user 
understands they will chose us". Ok, they were best, but today the user 
can rather understand that windows is no longer technically inferior (at 
least not overall). So as I see it there were clearly something that the 
unix vendors did not understand: meeting the needs of the users and the 
companies. (The unix vendors did of course not make free software, but 
the grounds for free software is standards and that is why the unix 
vendors where important.)

- First ms focused on GUI aspects and usability. When I read messages 
from experts at ms on this subject I often found the messages 
surprisingly good. It looked to my like they did take it seriously - and 
that really requires much thought.

- The free software world seem sometimes to think that creativity 
regarding GUI is  making a new GUI. (MS rather integrated different 
aspects and made the interface uniform. And that was not made out of 
laziness, it was as I saw it after careful thought.)

- One of the strength that ms today has it that it has control (at least 
to some degree) over cooperation between different parts of its 
software). They can achieve that because they have everything under one 
umbrella and also have the man power to try to achieve it. Cooperation 
is a very, very difficult thing in my opinion. Complexity and scaling 
jumps in.

Re: Release plans

[Richard M. Stallman]

We were talking about why people keep using Windows.  Why Windows
became successful is a tangent, which I don't want to take up.  So I
will only comment on a couple of things you said about the free
software community.

    - The advertising campaign from MS said to the user "you should decide 
    what programs you have on your pc". Very smart. If you tried to tell 
    users that there are better programs (there were!) then you just had to 
    face that the user "wanted to decide".

    - The free software world in my opinion did exactly the opposite. It 
    said to the users "we know what is best for you" (because we are 
    smarter).

The whole free software world did not say one single thing.  That is
not what the GNU Project says.  Which part are you talking about?  It
could be that some people said that.  But I don't know that it is
true.

Without specifics, we cannot draw any conclusions.

    - First ms focused on GUI aspects and usability. When I read messages 
    from experts at ms on this subject I often found the messages 
    surprisingly good. It looked to my like they did take it seriously - and 
    that really requires much thought.

We have had to play catch-up in GUIs just as we did in the lower
levels of the system.  When Windows appeared, we did not even have
a complete working command line system.

Re: Release plans

[Richard M. Stallman]

    Emacs has still no support to load shared libraries during runtime and
    IIRC it was rejected back then due to political reasons.  I call this
    crippling.

"Crippling" would imply making Emacs unusable, which it clearly isn't.

The reason for my decision is to make sure that extension to Emacs are
free.  The aim is to maximize what users can do while remaining free.

Re: Release plans

[Sean O'Rourke]

"Richard M. Stallman" <rms@gnu.org> writes:

>     Emacs has still no support to load shared libraries during runtime and
>     IIRC it was rejected back then due to political reasons.  I call this
>     crippling.
>
> "Crippling" would imply making Emacs unusable, which it clearly isn't.

This is disingenuous.  A cripple can still get around town,
albeit awkwardly.  I think "crippling" as in "severely
problematic" is too extreme; this political problem is more like
a persistent, unscratchable itch: you can live with it, but it's
continuously irritating without encouraging you to improve your
physical condition.

What if we included shared library loading in GNU Emacs to see if
anyone tried to use it to abuse the GPL?  If so, we could remove
it, and let the abusers develop a fork.  Since the shared library
patch is already out there and there are no such forks, I doubt
there would be a problem.

Sean

Re: Release plans

[Michael Ekstrand]

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

Sean O'Rourke <sorourke@cs.ucsd.edu> writes:
> What if we included shared library loading in GNU Emacs to see if
> anyone tried to use it to abuse the GPL?  If so, we could remove
> it, and let the abusers develop a fork.  Since the shared library
> patch is already out there and there are no such forks, I doubt
> there would be a problem.

I also doubt it would be a problem.  Given the present development
climate, if someone is going to create a non-free "value-add" for a
development environment, I think that they are much more likely to do so
as an Eclipse plugin than as a non-free extension module for Emacs.  It
may not be a pleasant picture for widespread Emacs adoption, but it is
the state of things these days.

Thus, adding dynamic loading support would make Emacs more flexible for
its users, and I would be rather surprised if people actually abused
that feature to make non-free value-adds (other than the X/Refactory
folks possibly wanting to turn their product into an in-process dynamic
load).  The added possibilities are significant.  The libotr possibility
has been mentioned, and I could see cases for others.  Most immediately
coming to mind is an SQLite extension and accompanying nnsqlite Gnus
mail backend.

- Michael

-- 
mouse, n: A device for pointing at the xterm in which you want to type.
Confused by the strange files?  I cryptographically sign my messages.
For more information see <http://www.elehack.net/resources/gpg>.

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: Release plans

[Johannes Weiner]

Hi,

"Richard M. Stallman" <rms@gnu.org> writes:

>     Emacs has still no support to load shared libraries during runtime and
>     IIRC it was rejected back then due to political reasons.  I call this
>     crippling.
>
> "Crippling" would imply making Emacs unusable, which it clearly isn't.

A cripple is not naturally dead.  A cripple is limited compared to
others of the same kind or to it's theoretical potential.

> The reason for my decision is to make sure that extension to Emacs are
> free.  The aim is to maximize what users can do while remaining free.

So Stephen was wrong and it is incorrect that the law would forbid
loading GPL-incompatible modules this way?

I won't doubt your intentions here, I *know* that your primary goal is
the software's freedom.  But I question your way of achieving what you
are up to.  This is not meant impolite, I just like to think on my own.

We have the same goal: we both don't want Emacs to become non-free and
have it have the maximum functionality that is within the limits.

So I am interested in your views of the limits and why you think
runtime-loading of shared libraries is beyond these limits and
runtime-loading of byte-compiled .el files is not.

	Hannes

Re: Release plans

[Richard M. Stallman]

    So I am interested in your views of the limits and why you think
    runtime-loading of shared libraries is beyond these limits and
    runtime-loading of byte-compiled .el files is not.

Please stop putting words in my mouth.

Re: Release plans

[Johannes Weiner]

Hi,

"Richard M. Stallman" <rms@gnu.org> writes:

>     So I am interested in your views of the limits and why you think
>     runtime-loading of shared libraries is beyond these limits and
>     runtime-loading of byte-compiled .el files is not.
>
> Please stop putting words in my mouth.

I never did.

As you maintained Emacs and the state is `.elc - yes, .so - no', I
assumed this was your view.

And thanks for ignoring the rest of the email.  It's a good indicator
for me that it is better to just stop right here before wasting any more
time.

	Hannes

Re: Release plans

[Thomas Lord]

Richard M. Stallman wrote:
>     Emacs has still no support to load shared libraries during runtime and
>     IIRC it was rejected back then due to political reasons.  I call this
>     crippling.
>
> "Crippling" would imply making Emacs unusable, which it clearly isn't.
>
> The reason for my decision is to make sure that extension to Emacs are
> free.  The aim is to maximize what users can do while remaining free.
>   


How does not providing dynamic loading maximize what users can
do while remaining free?

If they could dynamically load free libraries, surely their capabilities
would be increased.

I think you mean that your goal is to help GNU Emacs loyalists
remain free even if it means you taking a blunt instrument to
what users can do with their freedom.

-t







>
>
>   

Re: Release plans

[Richard M. Stallman]

    How does not providing dynamic loading maximize what users can
    do while remaining free?

It protects against the danger of non-free C-level add-ons to Emacs.
It's the same principle as the GPL itself.

Re: Release plans

[joakim]

"Richard M. Stallman" <rms@gnu.org> writes:

>     How does not providing dynamic loading maximize what users can
>     do while remaining free?
>
> It protects against the danger of non-free C-level add-ons to Emacs.
> It's the same principle as the GPL itself.
>

What about implementing an interface in dynamically loadable modules
that that Emacs can use to determine if the module is GPL compliant?

Free libraries could easily add the interface, proprietary vendors would
highly unlikely add it. I think Linux kernel modules has something
similar.

I'm personally more interested in out-of-process interfaces for Emacs,
like Xembed, Corba etc, but I recognize that dynamic linking of modules
in Emacs would be useful for many tasks.

-- 
Joakim Verona

Re: Release plans

[Richard M. Stallman]

    Free libraries could easily add the interface, proprietary vendors would
    highly unlikely add it. I think Linux kernel modules has something
    similar.

The fact that non-free Linux modules continue to be distributed shows
that this method is not adequate to prevent them.  It also shows that
the danger is not imaginary.

Re: Release plans

[joakim]

"Richard M. Stallman" <rms@gnu.org> writes:

>     Free libraries could easily add the interface, proprietary vendors would
>     highly unlikely add it. I think Linux kernel modules has something
>     similar.
>
> The fact that non-free Linux modules continue to be distributed shows
> that this method is not adequate to prevent them.

The Linux kernel doesn't refuse to boot when it recognizes a non GPL
module being loaded. It justs informs you its "tainted".

Emacs should of course just refuse to use functions in modules that are
not GPL compliant, not just inform the user that the moral integrity of
Emacs has been corrupted.

> It also shows that the danger is not imaginary.

I agree completely. 

If this mechanism is implemented, though, I cant see this resulting in any
additional risk of running non-free software. It could, in fact, be a
model of how to eliminate risks of running non-free software.

-- 
Joakim Verona

Re: Release plans

[Richard M. Stallman]

    The Linux kernel doesn't refuse to boot when it recognizes a non GPL
    module being loaded. It justs informs you its "tainted".

    Emacs should of course just refuse to use functions in modules that are
    not GPL compliant, not just inform the user that the moral integrity of
    Emacs has been corrupted.

I don't think this is a solution, because it would be easy to patch out
the code that enforces that restriction.

Re: Release plans

[Tassilo Horn]

On Monday 18 August 2008 08:14:45 Richard M. Stallman wrote:

Hi Richard,

>     The Linux kernel doesn't refuse to boot when it recognizes a non
>     GPL module being loaded. It justs informs you its "tainted".
>
>     Emacs should of course just refuse to use functions in modules
>     that are not GPL compliant, not just inform the user that the
>     moral integrity of Emacs has been corrupted.
>
> I don't think this is a solution, because it would be easy to patch
> out the code that enforces that restriction.

But that register_me_i_am_gpl() function would be in emacs core.  As far
as I understand, if someone patches that function out, the resulting
emacs derivate would have to be GPLv3 as well.

Do you think that someone who would like to distribute non-free emacs
modules would really fork emacs, throw that mechanism out, release it as
GPLv3 and then provide his non-free modules for that fork?

I don't see how that would be much more convenient than forking the
current emacs without module loading support, apply the existing patch
for module loading, release this fork as GPLv3, and then provide the
non-free modules.

In any way, if someone wants to provide non-free modules, he has to fork
emacs.  But if we had support for loading modules, writing free modules
would be as simple as writing elisp extensions.  In my opinion that's a
win for emacs and the free software movement.

Please correct me if I'm wrong.

Bye,
Tassilo

Re: Release plans

[Stefan Monnier]

>     Emacs should of course just refuse to use functions in modules that are
>     not GPL compliant, not just inform the user that the moral integrity of
>     Emacs has been corrupted.

> I don't think this is a solution, because it would be easy to patch out
> the code that enforces that restriction.

Ironically, in the US you might argue that doing that in order to link
a non-GPL module is illegal because of the DMCA: it's trying to work
around a technical device that enforces the copyright.


        Stefan

Re: Release plans

[joakim]

"Richard M. Stallman" <rms@gnu.org> writes:

>     The Linux kernel doesn't refuse to boot when it recognizes a non GPL
>     module being loaded. It justs informs you its "tainted".
>
>     Emacs should of course just refuse to use functions in modules that are
>     not GPL compliant, not just inform the user that the moral integrity of
>     Emacs has been corrupted.
>
> I don't think this is a solution, because it would be easy to patch out
> the code that enforces that restriction.

Yes, indeed, but its also trivial to patch Emacs to run non-free
extensions today.

Is the real issue that the GPL doesnt inhibit soft linking of non-free
modules? I always assumed the GPL didnt allow for this. 

-- 
Joakim Verona

Re: Release plans

[Richard M. Stallman]

    Yes, indeed, but its also trivial to patch Emacs to run non-free
    extensions today.

It is not trivial for most people.

    Is the real issue that the GPL doesnt inhibit soft linking of non-free
    modules? I always assumed the GPL didnt allow for this. 

There is no clear simple answer to the question,
and that is why I don't want to run the risk.

Re: Release plans

[Johannes Weiner]

"Richard M. Stallman" <rms@gnu.org> writes:

>     Yes, indeed, but its also trivial to patch Emacs to run non-free
>     extensions today.
>
> It is not trivial for most people.

Most people don't need to study or modify the software they run either.
They will benefit from those who actually can and do so, though.

That doing that change is not trivial for most people is obvious.  But
most people also don't write their own compiler!

It's enough if there is one person writing a compiler.

It's enough if there is one person providing a patch to run non-free
extensions.

	Hannes

Re: Release plans

[Richard M. Stallman]

    It's enough if there is one person providing a patch to run non-free
    extensions.

Such all-or-nothing thinking isn't valid.  It is clear that if some
sort of add-on depends on people to patch Emacs, that obstacle will
discourage its adoption.  This will in turn discourage the development
of such add-ons.  That doesn't absolutely assure no one will develop
them, but does help.

Re: Release plans

[Johannes Weiner]

Hi Richard,

"Richard M. Stallman" <rms@gnu.org> writes:

>     It's enough if there is one person providing a patch to run non-free
>     extensions.
>
> Such all-or-nothing thinking isn't valid.  It is clear that if some
> sort of add-on depends on people to patch Emacs, that obstacle will
> discourage its adoption.  This will in turn discourage the development
> of such add-ons.  That doesn't absolutely assure no one will develop
> them, but does help.

Sure.  Then make that something more convenient.  Consider a
distribution of GNU Emacs that is prepatched with a module loader and
comes with an installation script that fetches the non-free library from
an URL.  Or something similar if this has legal issues.

Or don't distribute a fork but go for the library and executable wrapper
approach you can stack on top of a vanilla GNU Emacs, utilizing the
process interface.

My point is that even today you can implement something that extends
Emacs in non-free ways with rather low efforts and provide a product
that is easy to use.

I highly doubt that people who have the idea of distributing non-free
extensions to Emacs would wait until it grows a module loader.  It's not
needed.

But a module loader probably encourages hackers and not so much immoral
individuals/companies whos primary goal is to sell their software rather
than hacking the good hack.

Like I said, as a person keen on technical stuff I refuse to work around
limited interfaces but would prefer improving them.

If my goal is not a cool mechanism but getting my nonfree software
distributed, I don't need the module loader and can already do that.

	Hannes

Re: Release plans

[Tassilo Horn]

On Tuesday 19 August 2008 14:21:01 Richard M. Stallman wrote:

Hi!

>     Yes, indeed, but its also trivial to patch Emacs to run non-free
>     extensions today.
>
> It is not trivial for most people.

But it's trivial for everybody who is capable of writing such a non-free
module.  So let's say I want to distribute a non-free module (just an
example, I'm on the good side!).  In order to do that right now, I'd do
the following steps.

1. I fork emacs and put some dynamic module loading facility in it, and
   release the whole thing under GPLv3.  Because the patch already
   exists, that's not much work.

2. I provide my non-free module for my fork.

Now let's say emacs had a module loading facility, and each module would
have to register itself as being free in order to allow its loading.  If
I wanted to create a non-free module then, I had two possibilities.

- Falsely register my module as free and FSF and me will meet at court.
  (Is there a danger that a court will decide it's legal to register a
  module as free if it's not?)

- Fork emacs like above and put the registration code out.

So basically I can always provide non-free modules if I fork emacs.  The
costs for that are very low, no matter if emacs has or has no module
loading facility.

So let's now assume I want to provide a free module.  Currently (without
the module loader) I'd have to fork emacs, too.  But I'm a member of the
free software community, so I don't want to do that.  As a result I'll
try to work around the limitations with some ugly hacks like a command
line interface for the library I want to use.

So to summarize: For someone who wants to create a non-free module, the
costs are the same, no matter if emacs has or has no dynamic module
loading support.  For someone who wants to create a free module, the
availability of this feature in GNU Emacs is crucial.

The only danger I can see is that a module loader plus some nice, free
modules would push emacs reputation that high and create such an hype
that industry rediscoveres it as platform for their products.  Honestly,
before that happens the moon becomes a square! ;-)

And at last I want to point out some features SXEmacs has (which has a
full blown foreign function interface) which could be very useful.

  * Use emacs as X11 window manager (talk directly to XLib or xcb).

  * It supports all image formats the free ImageMagick library supports.

  * It has enhanced numbed types by binding to some free math library.

  * It has some direct bindings to various databases.

  * It downloads files by directly using libcurl.

Bye,
Tassilo

Re: Release plans

[Richard M. Stallman]

    - Falsely register my module as free and FSF and me will meet at court.
      (Is there a danger that a court will decide it's legal to register a
      module as free if it's not?)

I have not discussed this with lawyers, but I don't know of any law
that would prohibit it.  That's why I am reluctant to rely on such a
scheme.  If that sort of thing were clearly forbidden by copyright
law, I would find the method would be much more appealing.

Re: Release plans

[Gilaras Drakeson]

        The Linux kernel doesn't refuse to boot when it recognizes a non
        GPL module being loaded. It justs informs you its "tainted".

        Emacs should of course just refuse to use functions in modules
        that are not GPL compliant, not just inform the user that the
        moral integrity of Emacs has been corrupted.

    I don't think this is a solution, because it would be easy to patch
    out the code that enforces that restriction.

True, but we are not in a *much* better situation now, because if
releasing a patched Emacs is acceptable in the game, a large software
corporation can easily release a patch that enables loading of external
modules for Emacs.

I don't think this restriction could be enforced just by software.  Some
addendum to the license (maybe only specific to Emacs, GCC, and other
meta-applications if adding that to GPLv3+ is not easy) might prevent
loading of non GPLv3+ modules. Keeping the loader out of Emacs does not
count as a long term solution.

Gilaras

Re: Release plans

[Stephen J. Turnbull]

Richard M. Stallman writes:

 >     The Linux kernel doesn't refuse to boot when it recognizes a non GPL
 >     module being loaded. It justs informs you its "tainted".
 > 
 >     Emacs should of course just refuse to use functions in modules that are
 >     not GPL compliant, not just inform the user that the moral integrity of
 >     Emacs has been corrupted.
 > 
 > I don't think this is a solution, because it would be easy to patch out
 > the code that enforces that restriction.

I will remind you that that was good enough for XEmacs and Qt in your
opinion.  Circumstances may be different, but you should explain how.

If it's distributed only as a patch, who cares?  The patch that allows
dynamic loading is already available and quite self-contained IIRC,
we're in the same place already.

If it's a separate distribution with the patch preapplied and maybe
Emacs prebuilt, that is a fork.  The whole world knows what you think
of forks of Emacs, and how you treat the forkers.  I think that's
sufficient deterrent, and if it isn't enough, we can assume there's a
lot of value in the dynamic loader that people want pretty badly --
specifically, enough to overcome the inconvenience of patching in the
loader feature.

I really don't get this.  You are basically taking the open source
route here.  "People don't like to be free, so let's not tell them
about freedom -- let's make it relatively inconvenient to use
proprietary code."  Why not wait for the non-free modules, and then
publish a boycott list of such modules, give them a public dressing-
down, and in that way draw attention to the issue of freedom?

Re: Release plans

[Paul R]

Hi !

On Tue, 19 Aug 2008 02:13:47 +0900, "Stephen J. Turnbull" <stephen@xemacs.org> said:

SJT> I really don't get this. You are basically taking the open source
SJT> route here. "People don't like to be free, so let's not tell them
SJT> about freedom -- let's make it relatively inconvenient to use
SJT> proprietary code." Why not wait for the non-free modules, and
SJT> then publish a boycott list of such modules, give them a public
SJT> dressing- down, and in that way draw attention to the issue of
SJT> freedom?

Stephen is right. We should never respond to a "*possible* lack of
freedom for some hypotetical consenting users" with a solution that
implies an *evident* lack of (technical) freedom for all Emacs fellow
users.

Really, here the cure harms more than the disease.

-- 
  Paul

Re: Release plans

[Richard M. Stallman]

    I will remind you that that was good enough for XEmacs and Qt in your
    opinion.

What opinion are you talking about?  I do not in general approve of
the decisions of the XEmacs developers, and they don't wait on my
approval any more than I wait on yours.

Re: Release plans

[Stephen J. Turnbull]

Richard M. Stallman writes:
 >     I will remind you that that was good enough for XEmacs and Qt in your
 >     opinion.
 > 
 > What opinion are you talking about?

About 4 years ago I asked you about whether it was compatible with the
GPL to distribute an XEmacs with a Qt interface, given that (a) the
X11 version of Qt had been relicensed to GPL, but (b) the Windows
version was still under a non-free license.

You replied that it was compatible if the build system provided no
support for linking Qt on the Windows system, and configure (for
Cygwin) warned that Qt is a nonfree library and therefore not
supported on Windows.

 > I do not in general approve of the decisions of the XEmacs
 > developers, and they don't wait on my approval any more than I wait
 > on yours.

We are unwilling to be dominated by your authority.  We do consider
your opinions and expertise, however, and of course the FSF is the
largest rightsholder in XEmacs (my estimate, by lines of code).

Re: Release plans

[Richard M. Stallman]

    About 4 years ago I asked you about whether it was compatible with the
    GPL to distribute an XEmacs with a Qt interface, given that (a) the
    X11 version of Qt had been relicensed to GPL, but (b) the Windows
    version was still under a non-free license.

    You replied that it was compatible if the build system provided no
    support for linking Qt on the Windows system, and configure (for
    Cygwin) warned that Qt is a nonfree library and therefore not
    supported on Windows.

That sounds right, but it is a different issue.

Re: Release plans

[Stephen J. Turnbull]

Richard M. Stallman writes:

 >     How does not providing dynamic loading maximize what users can
 >     do while remaining free?
 > 
 > It protects against the danger of non-free C-level add-ons to
 > Emacs.

All a freedom-lover has to do to avoid those non-free add-ons is ...
avoid them.  How does a non-free add-on sneak in under my radar?  As
far as I can see, the possibility of remaining free is unaffected by
the presence or absence of a dynamic loader.

 > It's the same principle as the GPL itself.

As you like to say about copyright and patent, GPL and "no DSOs" are
two completely different things, so the same principles can't be
applied without careful justification.

The GPL prohibits certain freedom-inhibiting activities absolutely,
while leaving all value-in-use available to users.  But as I
understand it anything that can be done by dynamic linking (legally or
physically) can also be done by static linking, so it's not a
prohibition, merely an inconvenience, to potential violators.  On the
other hand, this restriction *does* detract from value-in-use.

Re: Release plans

[Thomas Lord]

Richard M. Stallman wrote:
>     How does not providing dynamic loading maximize what users can
>     do while remaining free?
>
> It protects against the danger of non-free C-level add-ons to Emacs.
> It's the same principle as the GPL itself.
>   


That doesn't answer the question.   You said something odd:
that not having a dynamic loading feature helps to maximize
what users can do in freedom.   That's false, though.   Having
a dynamic loading feature would let users do more, in freedom.

Suppose it were *certain* that non-free (but perfectly legal)
C-level add-ons to GNU Emacs would result from adding a
dynamic loading feature.   That isn't a good argument to not
add the feature and here is why:

It is equally certain that GNU Make is used
to build non-free programs.  It is equally certain that GCC is
used to compile non-free programs.  It is equally certain that
GNU Emacs is used to edit non-free programs.   It is historic
fact that one of the biggest areas in which free software projects
have succeeded in creating free software jobs is in maintaining
and extending a GNU/Linux platform for running non-free
programs.  It is a historic fact that those free (both senses) tools
have led to the creation of non-free programs that were otherwise
unlikely to be written.   The GNU project can not help but
abet the creation of non-free programs, as long as their are people
who want to create non-free programs.

If we accept that the consequence of non-free programs is
reason enough to reject a feature, we ought not write any software
at all!

On the other hand, it is *plausible* that a well designed dynamic
loading feature would lead to tiny "boom" in new free software
programs.   Third parties could release C-level, free software
extensions to GNU Emacs without any need for additional
coordination with the GNU Emacs maintainers.   There would be
opportunity for people to experiment more freely with C-level
extensions -- more chances to find new uses.   There would be a
new marketplace of technical ideas in which people are enriched
by exercising their software freedoms.

When people have cause to *exercise* their software freedoms
they come to understand those freedoms better.   They are more
likely to come to regard those freedoms as simply "natural" --
as a basic right.   If more people are busy exercising their software
freedoms, more people will be prepared to defend those freedoms.

Since it is plausible that a dynamic loading feature can lead to more
people exercising their software freedoms, and since a dynamic loader
makes decent sense technically and at an architectural level, there
are strong arguments *for* adding a dynamic loader.

An analogous analysis applies to tree print and read in GCC. 
Certainty that non-free uses will result hardly changes much of
anything and is not a strong argument against the feature.
Plausibility that the feature will lead to more free software
uses of GCC is a strong argument for the feature.

If you want to think about what software to NOT write in order
to save work, think about software architecture and maintainability
and stuff like that.   Maybe it is wise to NOT write program X because
writing Y instead is simpler.

But thinking about what NOT to write as some kind of tactic for
discouraging new non-free programs is ineffective unless we write
no programs at all!

It is better to think about what programs TO WRITE and to think
in terms of "combinatorics".   A good GNU system will contain
a maximal number of opportunities to write new programs, new
modules, new add-ons, etc.   The more that people *actually do*
with their software freedom, the more they will come to understand
and value their software freedom.

-t

Re: Release plans

[Alan Mackenzie]

'Evening, Thomas!

On Sat, Aug 16, 2008 at 02:04:11PM -0700, Thomas Lord wrote:
> Richard M. Stallman wrote:
> >    How does not providing dynamic loading maximize what users can
> >    do while remaining free?

> >It protects against the danger of non-free C-level add-ons to Emacs.
> >It's the same principle as the GPL itself.

> That doesn't answer the question.   You said something odd:
> that not having a dynamic loading feature helps to maximize
> what users can do in freedom.   That's false, though.   Having
> a dynamic loading feature would let users do more, in freedom.

[ .... ]

> When people have cause to *exercise* their software freedoms
> they come to understand those freedoms better.   They are more
> likely to come to regard those freedoms as simply "natural" --
> as a basic right.   If more people are busy exercising their software
> freedoms, more people will be prepared to defend those freedoms.

Yes, but.  I think you understand Richard's argument but are glossing
over it.  We're not just individuals - we live in a community, and our
exercise of our freedoms affects everybody else.  (If you're a political
libertarian, you probably need read no further. ;-)  You aren't
considering the effect on everybody else.

The ability to link binary libraries into Emacs means the ability to link
non-free binaries in (think Linux modules here), possibly with _very_
useful functionality, whose inclusion could screw up Emacs's freedom in a
significant way.  Five years from now, lots of people could be "freely"
chosing this "non-free" version.  This would be damaging to the aims of
the FSF.

Now I'm not saying this is an overwhelming argument.  I'm saying that
it must be weighed and balanced against the (substantial) benefits of
binary libraries.  Just as individual people's freedom to own guns must
be weighed against the right of the community not to have its members
shot.

My opinion on allowing binary libraries into Emacs is that its dangers
would be greater than the benefits it would allow.  I'm willing to be
persuaded I'm mistaken.

You should address this, instead of evading it as you have done up to
now.

> -t

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Stephen J. Turnbull]

Alan Mackenzie writes:
 > My opinion on allowing binary libraries into Emacs is that its dangers
 > would be greater than the benefits it would allow.  I'm willing to be
 > persuaded I'm mistaken.
 > 
 > You should address this, instead of evading it as you have done up to
 > now.

No, those of you who *assert without a shred of evidence* that there
are significant dangers should address that lack.  XEmacs, as well as
many GNU applications, allow loadable modules.  SXEmacs takes it a
step further: it provides a generic foreign function interface.  So if
there's a danger, you should be able to quote us the products we can
buy at Circuit City or download from www.DownWithFreedom.com.  The
amount of damage done by NVIDIA's drivers for the Linux kernel is
substantial -- but the damage to users is matched one-for-one by
damage to NVIDIA's reputation, and the damage to freedom is nil, as we
see people easily switching from NVIDIA products to ATI for the sake
of good/free drivers.

$250 for a new state-of-the-art video card?  That's not damage,
friends, that's *tuition*.

Where's the beef, for heaven's sake?

Re: Release plans

[Alan Mackenzie]

Hi, Stephen!

On Sun, Aug 17, 2008 at 07:43:03AM +0900, Stephen J. Turnbull wrote:
> Alan Mackenzie writes:
>  > My opinion on allowing binary libraries into Emacs is that its
>  > dangers would be greater than the benefits it would allow.  I'm
>  > willing to be persuaded I'm mistaken.

>  > You should address this, instead of evading it as you have done up
>  > to now.
 
> No, those of you who *assert without a shred of evidence* that there
> are significant dangers should address that lack.

That's a category error.  I wasn't talking about a scientific process
for which evidence can be weighed up.  I am rather asserting the
credible existence of a mechanism by which Emacs could become
essentially un-free.  The exercise of freedom of choice by the gormless
masses is an essential component of that mechanism.  Nasty deviousness.

Richard is a master of nasty deviousness, so the fact that he sees a
problem is reason in itself to take it seriously.  ;-)

The essential point is that if an un-free Emacs became established
through the mechanism of loading binary libraries, we could not easily
reverse it.

> XEmacs, as well as many GNU applications, allow loadable modules.
> SXEmacs takes it a step further: it provides a generic foreign
> function interface.  So if there's a danger, you should be able to
> quote us the products we can buy at Circuit City or download from
> www.DownWithFreedom.com.

No.  The fact that nothing has yet happened is not by itself evidence of
lack of danger.

I think you said recently that there's an obscure patch around which
allows binaries to be loaded into XEmacs (and maybe Emacs), rather than
the facility being built in to the official XEmacs.  (Forgive me if I've
misremembered here.)  That's very different from something being a core
feature, encouraged by the prime maintainers.

> Where's the beef, for heaven's sake?

I don't accept that that, by itself, is a valid way to proceed.  We need
to forsee and analyse things which haven't happened but could happen.

To emphasise, I'm not convinced that allowing binaries to be loaded into
Emacs would cause danger.  I'm not convinced it's safe, either.  But I
am convinced the move would be irreversible.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Stephen J. Turnbull]

Alan Mackenzie writes:

 > That's a category error.

I see no morphisms.  How can there be a category?

 > I wasn't talking about a scientific process for which evidence can
 > be weighed up.

Shouldn't you be?  Surely you know it is possible to quantify risk,
and analyze it scientifically?  Why do you ask that we on your
nightmares, or Richard's, to guide policy?

 > I am rather asserting the credible existence of a mechanism by
 > which Emacs could become essentially un-free.

Well, let me propose that it's irrelevant, because I assert the
credible existence of a mechanism involving loadable binaries by which
XEmacs will become so superior to Emacs that only people still using
Emacs are those willing to work two or more hours with Emacs when they
could get the job done with XEmacs.  No users, no unfreeness problem. ;-)

Are you beginning to see how untenable your position is?  In fact the
only thing it has going for it is

 > Richard is a master of nasty deviousness, so the fact that he sees a
 > problem is reason in itself to take it seriously.  ;-)

but that's genuinely ad hominem.

 > The essential point is that if an un-free Emacs became established
 > through the mechanism of loading binary libraries, we could not easily
 > reverse it.

Huh?  All you have to do is write the patch and announce a release.
Richard has done that before (the security patch a couple years ago).

A couple of corrections:

 > I think you said recently that there's an obscure patch around
 > which

The patch is to Emacs, and it's obscure only because it has been
refused inclusion in Emacs with extreme firmness, so that its
proponents gave up about five years ago.  In XEmacs 21.4 and later,
it's as simple as ./configure --with-modules.  In recent SXEmacs, I'm
not sure that --with-modules is still supported, but that's OK because
matters are even worse: .configure --with-ffi gives you a foreign
function interface which allows you to access data and functions in
any .so without any C-level hacking.

 > That's very different from something being a core feature,
 > encouraged by the prime maintainers.

Well, in XEmacs, the module loader *is* a core feature encouraged by
the maintainers.  It's not configured by default because demand is so
far low.  In SXEmacs, FFI is configured by many users because packages
are downloaded not by EFS as in XEmacs, but via a FFI interface to
libcurl implemented entire in Lisp.

Re: Release plans

[Alan Mackenzie]

Morning, Stephen!

On Mon, Aug 18, 2008 at 09:01:54AM +0900, Stephen J. Turnbull wrote:
> Alan Mackenzie writes:

>  > I wasn't talking about a scientific process for which evidence can
>  > be weighed up.

> Shouldn't you be?  Surely you know it is possible to quantify risk,
> and analyze it scientifically?

OK, but it is like the blowing up of a nuclear reactor, not a plane
crash.  You don't say "hey, no reactors of type XYZ have blown up,
therefore it's safe"; instead, you analyse the way it's made and run, and
probe for potential chains of failures.  With a plane crash, on the other
hand, you can say "a plane of type UVW only crashes every 100,000,000
flight hours, so you'll be OK.".

> Why do you ask that we on your nightmares, or Richard's, to guide
> policy?

I don't ask anyone to we on my nightmares.  ;-)  I think you missed a
word out.

[ .... ]

> Are you beginning to see how untenable your position is?

No.  It may well be that, after more rigorous analysis, loadable binaries
in Emacs might not be a problem.  But being wrong is a long way from
being untenable.

> In fact the only thing it has going for it is

>  > Richard is a master of nasty deviousness, so the fact that he sees a
>  > problem is reason in itself to take it seriously.  ;-)

> but that's genuinely ad hominem.

Yes, but it's not an a.h. attack.  It's an a.h. compliment.

>  > The essential point is that if an un-free Emacs became established
>  > through the mechanism of loading binary libraries, we could not
>  > easily reverse it.

> Huh?  All you have to do is write the patch and announce a release.
> Richard has done that before (the security patch a couple years ago).

"Huh?"?  Such a patch would do nothing to disestablish an established
un-free version.

> A couple of corrections:

>  > I think you said recently that there's an obscure patch around
>  > which

> The patch is to Emacs, and it's obscure only because it has been
> refused inclusion in Emacs with extreme firmness, so that its
> proponents gave up about five years ago.  In XEmacs 21.4 and later,
> it's as simple as ./configure --with-modules. ....

>  > That's very different from something being a core feature,
>  > encouraged by the prime maintainers.

> Well, in XEmacs, the module loader *is* a core feature encouraged by
> the maintainers.  It's not configured by default because demand is so
> far low.

Those two sentences seem to contradict eachother.  I can't find any
documentation for it in either of the manuals (XEmacs 21.4.17) or NEWS.
I even know it exists, and I've even got a solid search term ("loader"),
but I still can't find it.  That's hardly encouragement.

How much use has been made of this module loader in XEmacs?  What's it
been used for?

> In SXEmacs, FFI is configured by many users because packages
> are downloaded not by EFS as in XEmacs, but via a FFI interface to
> libcurl implemented entire in Lisp.

I've just had a look at the SXEmacs home page, having not previously been
aware of it.  I can't really see any reason for SXEmacs's existence.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Stephen J. Turnbull]

Alan Mackenzie writes:
 > Morning, Stephen!
 > 
 > On Mon, Aug 18, 2008 at 09:01:54AM +0900, Stephen J. Turnbull wrote:
 > > Alan Mackenzie writes:
 > 
 > >  > I wasn't talking about a scientific process for which evidence can
 > >  > be weighed up.
 > 
 > > Shouldn't you be?  Surely you know it is possible to quantify risk,
 > > and analyze it scientifically?
 > 
 > OK, but it is like the blowing up of a nuclear reactor, not a plane
 > crash.

Faulty analogy, until you provide a neutrino's weight of evidence that
any user's freedom to stop using the module is impaired.  The
difference between the nuke and the plane is that we know a nuke
accident endangers millions of people.  A plane crash can be avoided
by not getting on.  Similarly, any damage to my freedom that is
threatened by a proprietary module can be avoided by not using it.
Sneaking it in a distribution of Emacs is clearly a GPL violation.

 > > Why do you ask that we on your nightmares, or Richard's, to guide
 > > policy?
 > 
 > I don't ask anyone to we on my nightmares.  ;-)  I think you missed a
 > word out.

"Why do you ask that we *depend* on your nightmares, or Richard's, to
guide policy?"

 > > Are you beginning to see how untenable your position is?
 > 
 > No.  It may well be that, after more rigorous analysis, loadable binaries
 > in Emacs might not be a problem.  But being wrong is a long way from
 > being untenable.

Sigh.  All the analysis so far has been provided by me and Tom,
principally, with similar comments from others on the pro-DSO side.
You just repeat your assertions, and Stallman compliments your for
your clear statement of the issues.  Humbug!

 > > In fact the only thing it has going for it is
 > 
 > >  > Richard is a master of nasty deviousness, so the fact that he sees a
 > >  > problem is reason in itself to take it seriously.  ;-)
 > 
 > > but that's genuinely ad hominem.
 > 
 > Yes, but it's not an a.h. attack.  It's an a.h. compliment.

Attacks are often valid logically.  Ad hominem is a logical *fallacy*,
inadmissible in reasoned discouse.

 > >  > The essential point is that if an un-free Emacs became established
 > >  > through the mechanism of loading binary libraries, we could not
 > >  > easily reverse it.
 > 
 > > Huh?  All you have to do is write the patch and announce a release.
 > > Richard has done that before (the security patch a couple years ago).
 > 
 > "Huh?"?  Such a patch would do nothing to disestablish an established
 > un-free version.

Of course it does.  The old version was an unfree *GNU* Emacs.  The
new state of affairs is a free GNU Emacs, and an unfree *fork*.  If
you don't think that causes disestablishment, consider that no major
GNU/Linux distributor would be likely to continue to distribute the
fork as GNU Emacs; they'd make a separate package.  Users would get
their butts kicked as this addictive non-free app stops working with a
bizarre error message about `function load-module not found' as soon
as they upgraded Emacs.  And Richard would do what he did to the
Lucid people (what *they* did then is not relevant; I'll bet you none
of them would be willing to go through that again, is the point).

If that doesn't disestablish the fork pretty quick, Emacs is at least
as far behind the fork as Emacs 18.59 was behind Lucid 19.1.  Pretty
unlikely.

The above is what *analysis* looks like.  Are you beginning to see how
untenable your position is yet?

 > Those two sentences seem to contradict eachother.  I can't find any
 > documentation for it in either of the manuals (XEmacs 21.4.17) or NEWS.
 > I even know it exists, and I've even got a solid search term ("loader"),
 > but I still can't find it.  That's hardly encouragement.

OK, so we don't *encourage* it, and we have some documentation bugs.
"Would you like to work on the bugs?"  It's still a standard feature,
supported and easily configured for those interested in it.

Alan, why don't you apply these picky-picky standards to your *own*
non-arguments?  You complain about how we try to avoid the issues,
although I don't see that we do.  I've explained, Tom has explained,
why we don't believe a "non-free Emacs" can become established.  But
you have a monster in the closet that simply disappears every time we
open the door.  Not one dirty footprint, no fur settling to the floor,
nothing.

You haven't even described what a "non-free Emacs" would look like.  I
mean for starters, the GPL guarantees that Emacs remains free.  So
people can just say no and keep their personal freedom.

And what is the difference between an Emacs that calls non-free code
via a binary module, and an Emacs that accesses files via TRAMP and
non-free SSH?  Should we remove process support from Emacs?

 > I've just had a look at the SXEmacs home page, having not previously been
 > aware of it.  I can't really see any reason for SXEmacs's existence.

Freedom.  Steve on the one side and me and Ben on the other had
different ideas about how to run a project, and what quality of code
and design should be allowed in.  ("Quality" here includes style etc,
it's not necessarily better or worse.)

Re: Release plans

[Alan Mackenzie]

Evening, Stephen!

On Tue, Aug 19, 2008 at 02:58:16AM +0900, Stephen J. Turnbull wrote:

> Faulty analogy, until you provide a neutrino's weight of evidence that
> any user's freedom to stop using the module is impaired.

I do not accept, as a criterion for freedom, that it is permissible to
consider a person's actions divorced from the effect on his neighbours.
We are not just individuals, we are each part of a community, in fact of
several communities.  If Joe gets saddled with a non-free Emacs, that
affects James who has a free one, and quite markedly.  That's just my
philosophy and my politics.  If you're going to challenge my arguments,
you're going to have to accept, even if only for the sake of argument,
these principles.  I think I made that clear last night, with my image of
lots of hypothetical Microsoft users who'd get saddled with an entirely
non-free Emacs.

> The difference between the nuke and the plane is that we know a nuke
> accident endangers millions of people.  A plane crash can be avoided by
> not getting on.

This is where we differ.  A plane crash hurts not just the people on
board, but the people the wreckage falls on.  Think of Lockerbie in 1988.

> Similarly, any damage to my freedom that is threatened by a proprietary
> module can be avoided by not using it.

The fallout will hit you.  That proprietary module will gunge up Emacs
development, damage Emacs's reputation, cause sysadmins to hate it
(they must field the rage from hackers) just as that aeroplane devastated
a street in Lockerbie.

Again, I'm thinking about the Community's freedom, not just yours as an
isolated individual.

>  > > Why do you ask that we on your nightmares, or Richard's, to guide
>  > > policy?

>  > I don't ask anyone to we on my nightmares.  ;-)  I think you missed a
>  > word out.

> "Why do you ask that we *depend* on your nightmares, or Richard's, to
> guide policy?"

I think I've made it clear that my "nightmares", as you call them, are
not positions I'm defending.  I put them forward only as a counter
(mainly) to Tom and to you, to show that bad things are possible, even if
not probable.

>  > No.  It may well be that, after more rigorous analysis, loadable
>  > binaries in Emacs might not be a problem.  But being wrong is a long
>  > way from being untenable.

> Sigh.  All the analysis so far has been provided by me and Tom,
> principally, with similar comments from others on the pro-DSO side.
> You just repeat your assertions, and Stallman compliments your for
> your clear statement of the issues.  Humbug!

Well, I don't think I'm calling people nasty names, and I'm not using
derogatory hyperbole/ambiguous terms like "nightmare", "defeatist", and
"untenable" to imply or half imply other people are idiots or incapable,
or to detract from calm factual discussion.

The analysis from you and Tom falls short of mathematical perfection.
Unless I'm mistaken, it focusses purely on the effects it would have on
knowledgeable automous hackers.  To me, it is thus incomplete, and thus
invalid.  In any case, I think the burden of proof lies on you, as a
proponent of change, not on me.

I think we differ because our axioms differ.  You and T regard only the
freedom of the informed automous hacker as important.  I (and possibly
RMS) see freedom for the entire community as important.  I think my
hypothetical bad case ("microsoft8.dll") from last night made that clear.
That such could be imposed on others is a bad thing for me.  Apparently
it bothers you not at all.

>  > >  > Richard is a master of nasty deviousness, so the fact that he
>  > >  > sees a problem is reason in itself to take it seriously.  ;-)

>  > > but that's genuinely ad hominem.

>  > Yes, but it's not an a.h. attack.  It's an a.h. compliment.

> Attacks are often valid logically.  Ad hominem is a logical *fallacy*,
> inadmissible in reasoned discouse.

<sigh>.  What I meant, and I think this was perfectly obvious, is that
Richard's copious experience of nasty deviousness in the real world, his
contacts with legal experts, his experience of and intuition in such
things, and so on, should incline the rest of us to respect his judgement
and caution.  Is that OK for you now? 

>  > >  > The essential point is that if an un-free Emacs became
>  > >  > established through the mechanism of loading binary libraries,
>  > >  > we could not easily reverse it.

>  > > Huh?  All you have to do is write the patch and announce a
>  > > release.  Richard has done that before (the security patch a
>  > > couple years ago).

>  > "Huh?"?  Such a patch would do nothing to disestablish an established
>  > un-free version.

> Of course it does.  The old version was an unfree *GNU* Emacs.  The
> new state of affairs is a free GNU Emacs, and an unfree *fork*.  If
> you don't think that causes disestablishment, .....

Sorry, this is just a pedantic squabble about the exact meaning of words.
"Establish" has more than one syllable, and that should have been a
warning sign for me not to use it.  Here's a clarification:

Should a non-free Emacs become widely installed ("established"), say GNU
Emacs hobbled by the "microsoft8.dll" I pictured last night, a newer
version of Emacs is unlikely to cause the number of installations of that
un-free version to fall rapidly to near zero (i.e., become
"disestablished").

> The above is what *analysis* looks like.  Are you beginning to see how
> untenable your position is yet?

I've nothing more to add in this particular bit of the conversation.

>  > Those two sentences seem to contradict eachother.  I can't find any
>  > documentation for it in either of the manuals (XEmacs 21.4.17) or
>  > NEWS.  I even know it exists, and I've even got a solid search term
>  > ("loader"), but I still can't find it.  That's hardly encouragement.

> OK, so we don't *encourage* it, and we have some documentation bugs.
> "Would you like to work on the bugs?"  It's still a standard feature,
> supported and easily configured for those interested in it.

Assuming that, somehow, they get to find out the feature exists.  If I
didn't know you better, I'd wonder if you weren't being economical with
the truth here.  It's your project, Stephen, so please give me a pointer
to something in XEmacs 21.4.17 which tells me how to link in an external
binary.  I'm interested in what this feature looks like.  And please tell
me how I should have become aware of it.  Or did the feature first appear
in 21.4.x, where x > 17?

> Alan, why don't you apply these picky-picky standards to your *own*
> non-arguments?  You complain about how we try to avoid the issues,
> although I don't see that we do.  I've explained, Tom has explained,
> why we don't believe a "non-free Emacs" can become established.  But
> you have a monster in the closet that simply disappears every time we
> open the door.  Not one dirty footprint, no fur settling to the floor,
> nothing.

For the third time, our basic axioms seem to differ.  I don't think you
see the point I'm making, and your analysis is oblivious to that point,
so I disregard it.  Maybe.

> You haven't even described what a "non-free Emacs" would look like.

That's unwarranted and manifestly false.  In my post last night, I drew a
picture of Emacs running on a future MS OS, where in order to get access
to its file system, you had to install the proprietary library
"microsoft8.dll".  This would have the side-effect, on the pretext of
"security", of disabling `defun' and only allowing signed (by MS) Lisp
libraries to be loaded.  This scenario would be essentially impossible
without Emacs linking into external binaries.  Tom, in his reply, simply
failed to address this central issue of my post.  An apology, please.

> I mean for starters, the GPL guarantees that Emacs remains free.  So
> people can just say no and keep their personal freedom.

Oh, so GPL's "guarantees" mean that everything's fine, and so we don't
need to worry about anything.  They are guarantees, after all.  Hmmm.

For the fourth time, I reject your axiom that the measure of freedom is
solely that of individual informed autonomous hackers.

> And what is the difference between an Emacs that calls non-free code
> via a binary module, and an Emacs that accesses files via TRAMP and
> non-free SSH?

The ability of a binary module to disable `defun' and prevent all but
digitally signed code from being loaded.

> Should we remove process support from Emacs?

No.  My question to you: what can an intimately linked binary module
achieve that calling something as a separate process couldn't?  Linking
to external binaries has been in XEmacs for some while.  What have people
done with it?  Could they have done the same by calling an external
program via an OS call?

Up to now, you and Tom have been asserting that calling external binaries
is critically important and very useful.  I don't recall seeing much
justification.  If I've missed it, a pointer would be appreciated.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Johannes Weiner]

Hi,

Alan Mackenzie <acm@muc.de> writes:

>> And what is the difference between an Emacs that calls non-free code
>> via a binary module, and an Emacs that accesses files via TRAMP and
>> non-free SSH?
>
> The ability of a binary module to disable `defun' and prevent all but
> digitally signed code from being loaded.

How about fset'ing defun to something new?

You still have not answered to what I said yesterday: This
microsoft8.dll `functionality' does not in any way rely on the feature
proposed here.

And if you would want to do Bad Things, what prevents you from calling a
non-free binary with Emacs' process interface?

See, I really believe in your points that this feature has the potential
to be abused.  But to me it is not obvious how it would open a _extra_
possibilities besides doing it more technically advanced.

The libotr bindings I have in mind would also work with the process
model.  Just hack up an executable that can be controlled by
command-line arguments to wire up your elisp stuff with libotr.

But frankly, I only have seen such irksome solutions by people with low
motives and little technical interest.  Look at how bad programs like
matlab are distributed: they dump themselves into /opt including all the
shared libaries they need while totally ignoring the rest of the system,
not giving a damn about standards.

So if I had other motives than technical cleverness and elegance, it
seems I would already be able to interact really close with non-free
software (not the ssh case but with an executable abstraction of a
non-free library!).

But I have no way right now to implement pluggable bindings in a sane
way that I would consider better than an ugly hack.

	Hannes

Re: Release plans

[Alan Mackenzie]

Hi, Johannes!

On Tue, Aug 19, 2008 at 01:27:19AM +0200, Johannes Weiner wrote:
> Hi,

> Alan Mackenzie <acm@muc.de> writes:

> >> And what is the difference between an Emacs that calls non-free code
> >> via a binary module, and an Emacs that accesses files via TRAMP and
> >> non-free SSH?

> > The ability of a binary module to disable `defun' and prevent all but
> > digitally signed code from being loaded.

> How about fset'ing defun to something new?

> You still have not answered to what I said yesterday: This
> microsoft8.dll `functionality' does not in any way rely on the feature
> proposed here.

I suppose not, strictly speaking.  From a publicity point of view, using
a Lisp library to disable Lisp is much more blatantly wrong than using a
binary "to enhance the security of an otherwise complete working system".
It would be easier (technically, and probably legally, too) to remove the
nastiness from a .elc file than a .dll one, whilst still leaving positive
features working.

> And if you would want to do Bad Things, what prevents you from calling a
> non-free binary with Emacs' process interface?

You mean getting other people to call your non-free binary, I think.  The
fact that it's a process-level interface prevents the binary from doing
much damage to the guts of Emacs.  Doesn't it?

> See, I really believe in your points that this feature has the
> potential to be abused.  But to me it is not obvious how it would open
> a _extra_ possibilities besides doing it more technically advanced.

> The libotr bindings I have in mind would also work with the process
> model.  Just hack up an executable that can be controlled by
> command-line arguments to wire up your elisp stuff with libotr.

How much more does the libotr library need than writing to its stdin and
reading from its stdout?

[ .... ]

> But I have no way right now to implement pluggable bindings in a sane
> way that I would consider better than an ugly hack.

OK.

> 	Hannes

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Johannes Weiner]

Hi, Alan!

Alan Mackenzie <acm@muc.de> writes:

> Hi, Johannes!
>
> On Tue, Aug 19, 2008 at 01:27:19AM +0200, Johannes Weiner wrote:
>> Hi,
>
>> Alan Mackenzie <acm@muc.de> writes:
>
>> >> And what is the difference between an Emacs that calls non-free code
>> >> via a binary module, and an Emacs that accesses files via TRAMP and
>> >> non-free SSH?
>
>> > The ability of a binary module to disable `defun' and prevent all but
>> > digitally signed code from being loaded.
>
>> How about fset'ing defun to something new?
>
>> You still have not answered to what I said yesterday: This
>> microsoft8.dll `functionality' does not in any way rely on the feature
>> proposed here.
>
> I suppose not, strictly speaking.  From a publicity point of view, using
> a Lisp library to disable Lisp is much more blatantly wrong than using a
> binary "to enhance the security of an otherwise complete working system".
> It would be easier (technically, and probably legally, too) to remove the
> nastiness from a .elc file than a .dll one, whilst still leaving positive
> features working.

It is certainly easier to reverse-engineer, I guess.

>> And if you would want to do Bad Things, what prevents you from calling a
>> non-free binary with Emacs' process interface?
>
> You mean getting other people to call your non-free binary, I think.  The
> fact that it's a process-level interface prevents the binary from doing
> much damage to the guts of Emacs.  Doesn't it?

It still damages your freedom.

I thought twice about appending `*SCNR*' to the previous sentence as it
was first meant as a satirical response in the RMS style.  You write up
arguments and all you get back is a totally generic, ignoring everything
you said, `this is bad[tm] for freedom[tm]'.

But after thinking more about it, yes, this should really be _your_
argument, too.

I really don't think it makes more harm compared to a nasty .elc because
Emacs has so much of its core accessible through Lisp.

And then, practically, it does not matter which way you damage freedom,
right?

As a user, you won't even realize the difference:

  apt-get install some-nonfree-emacs-extension

Whether this is a shared library that loads into Emacs, a precompiled
.elc that loads into Emacs or an .el wrapper and a non-free executable.

And all the user sees is this, in either case:

  (require 'nonfree-extension)
  (non-free-extension-mode 1)

And what I also consider important: you can modify every variable or
function binding from the Lisp side.  That means that you don't need to
go to the C level to be really harmful.  You can also just rebind every
core symbol and already modify Emacs' behaviour quite severely.

Save the old binding, rebind it and you have total control over
everything the user does.  You can decide whether you want to allow
garbage collection at the moment by rebinding GARBAGE-COLLECT and decide
according to the phase of the moon whether you pass on to #<subr
garbage-collect> or ignore the request.  I really wonder what you could
NOT do.

Emacs is already so powerful that I don't understand all the fuzz about
the shared library loader.  It would be nothing more than convenience.
But don't see it introducing any extra danger at all.

I probably repeat myself, sorry.

>> The libotr bindings I have in mind would also work with the process
>> model.  Just hack up an executable that can be controlled by
>> command-line arguments to wire up your elisp stuff with libotr.
>
> How much more does the libotr library need than writing to its stdin and
> reading from its stdout?

That's probably it.

	Hannes

Re: Release plans

[Stephen J. Turnbull]

Alan Mackenzie writes:
 > Evening, Stephen!
 > 
 > On Tue, Aug 19, 2008 at 02:58:16AM +0900, Stephen J. Turnbull wrote:
 > 
 > > Faulty analogy, until you provide a neutrino's weight of evidence that
 > > any user's freedom to stop using the module is impaired.
 > 
 > I do not accept, as a criterion for freedom, that it is permissible to
 > consider a person's actions divorced from the effect on his neighbours.

That's a very strange philosophy of freedom.  Freedom *means* that you
may do something without concern for interference from your government
or your neighbors.  That doesn't mean it's ethically right to do, of
course.  But you have to argue from a different ethical principle than
freedom.

 > That's just my philosophy and my politics.  If you're going to
 > challenge my arguments, you're going to have to accept, even if
 > only for the sake of argument, these principles.

But Alan, I have accepted your principles, except the one that says
anything you can imagine is probable enough to worry about.

And unfortunately, I can't challenge your arguments because you
haven't posted one (except that fallacious argument from the authority
of Richard Stallman).  You have only posted assertions.  I grant the
conceptual possibility that you assert, but I deny its importance.  I
claim it is both extremely unlikely to come to pass, and that we can
deal with the process of it arising in other ways.  And I've supported
both claims with concrete technical details and policy proposals.

 > This is where we differ.  A plane crash hurts not just the people on
 > board, but the people the wreckage falls on.  Think of Lockerbie in 1988.

I guess I should deduce that you are in favor of closing airports so
that planes will stop falling out of the sky on innocent people?  The
analogy is quite exact, you see.

 > The fallout will hit you.  That proprietary module will gunge up
 > Emacs development, damage Emacs's reputation, cause sysadmins to
 > hate it (they must field the rage from hackers) just as that
 > aeroplane devastated a street in Lockerbie.

I really don't see it.  Emacs developers won't touch the module,
requests for support will be directed to the vendor, and surely
vandalism/netrage by hackers is not to be attributed to Emacs but
rather to the hackers themselves.

What damage to Emacs's reputation do you envision?

 > Again, I'm thinking about the Community's freedom, not just yours as an
 > isolated individual.

I object to your implication that I care only about myself.

 > I think I've made it clear that my "nightmares", as you call them, are
 > not positions I'm defending.  I put them forward only as a counter
 > (mainly) to Tom and to you, to show that bad things are possible, even if
 > not probable.

Bad things are possible.  Stipulated.  As with closing airports to
prevent mid-flight crashes, some policies to ameliorate the possible
bad things are stupid; there are better ways to deal with them.  I
think GNU's refusal to allow dynamic loading in Emacs is such a stupid
policy, because there are better ways to address potential problems.

 > The analysis from you and Tom falls short of mathematical perfection.
 > Unless I'm mistaken, it focusses purely on the effects it would have on
 > knowledgeable automous hackers.

I don't speak for Tom, but my analysis falls short of perfection.  As
I say, you should apply such standard to yourself, as well.

And you are mistaken.  My analysis focusses purely on the *lack* of
freedom-destroying effects for *anybody*.  Once we have some effects
to talk about, I'll worry about whose ox is getting gored.

 > I think we differ because our axioms differ.

I think we differ because I've gone beyond axioms to offer concrete
analysis, and you haven't.

 > You and T regard only the freedom of the informed automous hacker
 > as important.

I am very offended.  I could not have imagined that you would stoop so
low.

 > I (and possibly RMS) see freedom for the entire community as
 > important.  I think my hypothetical bad case ("microsoft8.dll")
 > from last night made that clear.  That such could be imposed on
 > others is a bad thing for me.

I claim it cannot be imposed.  Please rebut.

 > Should a non-free Emacs become widely installed ("established"), say GNU
 > Emacs hobbled by the "microsoft8.dll" I pictured last night, a newer
 > version of Emacs is unlikely to cause the number of installations of that
 > un-free version to fall rapidly to near zero (i.e., become
 > "disestablished").

Depends on what you mean by "rapidly".  Overnight?  No.  In two or
three years?  Yes, I think that can be done, and that's fast enough.

 > For the third time, our basic axioms seem to differ.

They do.  However, for the sake of this discussion, I've adopted
yours.  Except for the axiom that "dynamic loading leads to unfree
Emacs", which I consider a proposition to be proved or disproved.

 > I don't think you see the point I'm making, and your analysis is
 > oblivious to that point, so I disregard it.  Maybe.

No.  I understand your point.  "Introducing a module loader could
cause Emacs to become non-free."  That's scary.

In the light of day, though, I don't believe it's going to happen.
Just like I don't believe there's a mass murderer waiting in the rear
seat of my car.  Possible, yes, and people have been killed by such.
But very very rare, and much better dealt with by locking the car than
by selling it.

OTOH, I do know that benefits (so far of modest size) will certainly
happen.  For example, you're the same Alan Mackenzie who's been
annoyed by the Emacs build process recently, right?  Wouldn't it be
nice if you could just disable the broken feature you don't like, or
even just not build that module and use yesterday's build of the
module with today's core?  How about if you are developing new C code,
and can change and reinitialize it in your running Emacs with a
turnaround of about 5 seconds on a reasonable machine?

Of course those conveniences don't stand up against the nightmarish
scenario of microsoft.dll.  Except that they are *certain*, based on
my personal experience with the feature, whereas IMO the scenario of
microsoft.dll becoming popular has *vanishing* probability, and even
if it does occur, I believe that it is nearly certain that we can
disestablish microsoft.dll.

 > > You haven't even described what a "non-free Emacs" would look like.
 > 
 > That's unwarranted and manifestly false.

I'm sorry, but what is "warranted" for me to say is *my* call, and
"manifestly false" would imply that you provided a description that a
reasonably intelligent person would see as plausible and something
that can be responded to in a reasonable way.  You haven't provided
any such thing, yet.  I discuss below why "microsoft8.dll" is
technically implausible, and I've provided a number of reasons to
believe it's managerially implausible, too.

 > In my post last night, I drew a picture of Emacs running on a
 > future MS OS, where in order to get access to its file system, you
 > had to install the proprietary library "microsoft8.dll".  This
 > would have the side-effect, on the pretext of "security", of
 > disabling `defun'

I can't find anything about disabling `defun', and that's not
plausible anyway.  All defun really does is establish a value for the
function cell (the primitive is defalias), and add some properties
like the documentation string.  You'd have to also disable funcall,
apply, and eval.  Really you'd probably have to replace both the Lisp
interpreter and the byte-code engine, and since there is no documented
API and semantics for those, the FSF would have no problem getting a
subpoena for Microsoft's source code if it was at all compatible.

 > and only allowing signed (by MS) Lisp libraries to be loaded.

Again, the technical difficulties of accomplishing this in GNU Emacs
are enormous.  Remember, GNU Emacs's security features were designed
by the guy who posted his password for somebody else's system in a
public place.

And who do you think would use such a thing?  Word users are used to
such restriction, but they'd piss their pants at the threat of being
saddled with Emacs.  I'd bet a majority of Emacs users, including all
gurus would refuse to use it, so there goes internal suppport.  Making
such a thing popular would require enormous resources put into support.

How could that be imposed?

 > This scenario would be essentially impossible without Emacs linking
 > into external binaries.

False.  It would be possible, and possibly cheaper, simply to build
such an Emacs-alike from scratch, as Richard himself did. This would
have the benefit that *all* of such an Emacs could be proprietary, too.

 > Tom, in his reply, simply failed to address this central issue of
 > my post.  An apology, please.

I'm not in a position to apologize on behalf of Tom.  I offer you my
apology, but it's not clear to me for what. I still don't see a
description of a (feasible) non-free Emacs nor one that can't be
achieved without a dynamic loader.  All you have is your assertion
that this is a real danger, and all I've done is point out
(repeatedly) that you are simply making bare assertions.

 > > I mean for starters, the GPL guarantees that Emacs remains free.  So
 > > people can just say no and keep their personal freedom.
 > 
 > Oh, so GPL's "guarantees" mean that everything's fine, and so we don't
 > need to worry about anything.

What do you think "for starters" means?  It's not a complete argument,
but you really do have to answer it since you have claimed that Emacs
itself would become non-free.  In the case of microsoft8.dll, the user
still has the source, they still have the right to redistribute Emacs,
etc.  So how has Emacs become non-free?

Even if the DLL is loaded in site-start, you can disable that.  (Well,
I can, in XEmacs.)

 > For the fourth time, I reject your axiom that the measure of freedom is
 > solely that of individual informed autonomous hackers.

It's not my axiom.  Please provide a quote of me asserting that axiom.

 > > And what is the difference between an Emacs that calls non-free code
 > > via a binary module, and an Emacs that accesses files via TRAMP and
 > > non-free SSH?
 > 
 > The ability of a binary module to disable `defun'

No need for a binary module: (fmakunbound 'defun).

 > and prevent all but digitally signed code from being loaded.

I don't know how to do this without taking over eval and the bytecode
engine.  That's going to be very difficult, even without worrying
about the fact that the only documentation of the semantics at that
level is the source, and thus the author of microsoft8.dll is very
vulnerable to a copyright infringement suit.

 > > Should we remove process support from Emacs?
 > 
 > No.  My question to you: what can an intimately linked binary module
 > achieve that calling something as a separate process couldn't?

Reload a patched C object into a running Emacs.

Manipulate Emacs data structures, and provide new ones.

Very little that a separate process can't, but it can do everything a
lot faster.

 > Linking to external binaries has been in XEmacs for some while.
 > What have people done with it?  Could they have done the same by
 > calling an external program via an OS call?

Look in the modules directory of XEmacs.  In the case of the Canna
module, no such command exists, so you need to link to Canna.
Although there's also a network protocol so you could use just Lisp.

 > Up to now, you and Tom have been asserting that calling external binaries
 > is critically important and very useful.

No, I haven't.  I've simply said I don't see enough risk, even given
the nightmarish consequences you envision, to outweigh the benefits I
see.

Re: Release plans

[Robert J. Chassell]

     > I do not accept, as a criterion for freedom, that it is
     > permissible to consider a person's actions divorced from the
     > effect on his neighbours.

    That's a very strange philosophy of freedom.

No, it depends on your culture.  The US, Great Britain, and to a large
extent, western Europe, think that.  But others (in the early 1990s,
Japan and Singapore, according to Charles Hampden-Turner and Alfons
Trompenaars, "The Seven Cultures of Capitalism") are more communitarian.
(You need both.  For example, one person will invent and many people
will innovate.)

Weirdly enough, over the past century or so, most independence movements
have favored communitarian culture, possibly because you cannot have
warriors or soldiers without such a culture.

    Freedom *means* that you may do something without concern for
    interference from your government or your neighbors.

That is individualist freedom.  I think it is good, but then I am
American and don't trust my government or any authority that is not
harmonizing.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Release plans

[Stephen J. Turnbull]

Robert J. Chassell writes:

 >     Freedom *means* that you may do something without concern for
 >     interference from your government or your neighbors.
 > 
 > That is individualist freedom.

Sure, but communitarian freedom has typically been espoused by leaders
who create a personality cult around them and brook little actual
dissent, etc.  Software freedom is *not* about a personality that
overshadows the rest of the community, is it?  Rather, it is a very
individualist freedom.

Re: Release plans

[Robert J. Chassell]

    Robert J. Chassell writes:

     >     Freedom *means* that you may do something without concern for
     >     interference from your government or your neighbors.
     > 
     > That is individualist freedom.

    Sure, but communitarian freedom has typically been espoused by
    leaders
    who create a personality cult around them and brook little actual
    dissent, etc. 

That is often true.  Same in software.

    Software freedom is *not* about a personality that overshadows the
    rest of the community, is it?  Rather, it is a very individualist
    freedom.

Copyright law has to do with copying between people.  It is not very
individualist except that it is supposed somewhat to protect smaller
people and corporations who can afford lawyers from bigger people and
corporations who can also afford lawyers.  The current copyright law and
its implementation may not be the best mechanism for dealing with easily
transferred goods, like computer programs, but it is all we have for
dealing with those who might steal from us.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc
References: <E1KTqBj-0005Or-Mu@fencepost.gnu.org>
    <48A5BAD7.8030302@emf.net>
    <E1KUJCN-000309-FC@fencepost.gnu.org> <48A740CB.4050404@emf.net>
    <20080816213508.GA8530@muc.de>
    <87hc9ka8eg.fsf@uwakimon.sk.tsukuba.ac.jp>
    <20080817073124.GA1294@muc.de>
    <87ljyv5gy5.fsf@uwakimon.sk.tsukuba.ac.jp>
    <20080818101802.GA2615@muc.de>
    <87bpzqqk7b.fsf@uwakimon.sk.tsukuba.ac.jp>
    <20080818210927.GD2615@muc.de>
    <87wsidnxqp.fsf@uwakimon.sk.tsukuba.ac.jp>
    <87ljytkwpk.fsf@rattlesnake.com>
    <878wusz0v9.fsf@uwakimon.sk.tsukuba.ac.jp>
In-reply-to: <878wusz0v9.fsf@uwakimon.sk.tsukuba.ac.jp>
    (stephen@xemacs.org)
To: emacs-devel@gnu.org
Subject: Re: Release plans
From: bob@rattlesnake.com (Robert J. Chassell)
--text follows this line--
    Robert J. Chassell writes:

     >     Freedom *means* that you may do something without concern for
     >     interference from your government or your neighbors.
     > 
     > That is individualist freedom.

    Sure, but communitarian freedom has typically been espoused by
    leaders who create a personality cult around them and brook little
    actual dissent, etc.

That is often true.  Same in software.

    Software freedom is *not* about a personality that overshadows the
    rest of the community, is it?  Rather, it is a very individualist
    freedom.

Copyright law has to do with copying between people.  It is not very
individualist except that it is supposed somewhat to protect smaller
people and corporations who can afford lawyers from bigger people and
corporations who can also afford lawyers.  The current copyright law and
its implementation may not be the best mechanism for dealing with easily
transferred goods, like computer programs, but it is all we have for
dealing with those who might steal from us.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Release plans

[Stephen J. Turnbull]

I wish you (and RMS) would get a real MUA.  VM is a good one for those
used to Rmail.  Fixing attributions:

I wrote:

 >     Sure, but communitarian freedom has typically been espoused by
 >     leaders who create a personality cult around them and brook
 >     little actual dissent, etc.

Robert J. Chassell writes:
 
 > That is often true.  Same in software.

You said it, not me.  Thank you.

 >     Software freedom is *not* about a personality that overshadows the
 >     rest of the community, is it?  Rather, it is a very individualist
 >     freedom.

 > Copyright law has to do with copying between people.

And software freedom is about removing hindrances to an individual's
copying, of which copyright and patent laws are (according to the free
software movement) the most important (ie, the ones we need to "do
something" about).

I don't understand what you're trying to say.  I don't mean to oppose
it, but rather indicate where I'm getting stuck.  Help?

Re: Release plans

[Robert J. Chassell]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

    > I wish you (and RMS) would get a real MUA. ... Fixing attributions
    > ...

According to my records, you wrote

    >  >     Sure, but communitarian freedom has typically been espoused
    >  >     by leaders who create a personality cult around them and
    >  >     brook little actual dissent, etc.

and I wrote

    > That is often true.  Same in software.

I know the latter is correct both in attribution and in content.  My
electronic mail says the former is correct, too.  The attributions look
correct both in my originals and in your copies as they were sent to me.
No need for a different mail user agent.

    >  >     Software freedom is *not* about a personality that
    >  >     overshadows the rest of the community, is it?  Rather, it
    >  >     is a very individualist freedom.

    > Copyright law has to do with copying between people.

I said the last about copyright law, too.  Again, its attribution looks
correct to me.

You wrote

    >     And software freedom is about removing hindrances to an
    >     individual's copying, ...

I agree.  Software copying is made possible in a free mannner by using
*current* laws, international treaties, and experience.

You also wrote

    >     I don't understand what you're trying to say. ...

I am saying that the current laws, international treaties, and
experience send us to the GNU Public License, version 3.  You may not
like the current laws and international treaties; I don't; technology
makes it easier to copy than before.  Unfortunately, the current laws
and international treaties exist and their backers are powerful.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Release plans

[Stephen J. Turnbull]

Robert J. Chassell writes:

 > I am saying that the current laws, international treaties, and
 > experience send us to the GNU Public License, version 3.  You may not
 > like the current laws and international treaties; I don't; technology
 > makes it easier to copy than before.  Unfortunately, the current laws
 > and international treaties exist and their backers are powerful.

And this is related to communitarian freedom ... how?

Re: Release plans

[Robert J. Chassell]

Robert J. Chassell writes:

     > I am saying that the current laws, international treaties, and
     > experience send us to the GNU Public License, version 3.  You may not
     > like the current laws and international treaties; I don't; technology
     > makes it easier to copy than before.  Unfortunately, the current laws
     > and international treaties exist and their backers are powerful.

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

    And this is related to communitarian freedom ... how?

Laws and international treaties have to do with other people.  They are
not individualistic in that sense.  When you make a decision involving
others, the consequences don't involve you alone.  A community has other
people in it.

You may prefer your community to be more individualistic -- I do with my
own -- but regardless, a community as other people in it.  It is a
matter of degree.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Release plans

[Thomas Lord]

It's kind of amazing to watch how the defense
of the dynamic loader ban has evolved.

First a philosophically dubious distinction between
individual and community freedom is posited.

Then that questionable distinction is projected onto
people's moral standing:  we are asked to believe that
there are those who care only about individual
freedom, not community, and asked to accept that
those people are just morally wrong.

Then members of the community at hand are
singled out and tarred and feathered as examples
of the miscreants who care not about community
freedom.   In particular, anyone who argues against
the FUD that leads to a dynamic loader ban is now
naive or bad or in some way or is otherwise morally
defective for failing to display proper concern for
"community freedom".

What Bob and others seem to have constructed
here is an argument for the dynamic loader ban
that can be summed up:

  Only bad people argue against the dynamic loader ban.
  Therefore, the ban is a good idea.

-t

Re: Release plans

[Stephen J. Turnbull]

Thomas Lord writes:

 > First a philosophically dubious distinction between
 > individual and community freedom is posited.

This was Bob Chassell.  That was *all* he really had to say.

 > Then that questionable distinction is projected onto
 > people's moral standing:  we are asked to believe that
 > there are those who care only about individual
 > freedom, not community, and asked to accept that
 > those people are just morally wrong.

This was Alan Mackenzie, but I don't think he would accept the idea of
community freedom as opposed to freedom for all members of the
community.

So not only have you changed the slant of their comments dramatically,
but you have also conflated two subthreads whose relation is not at
all clear, and which certainly do not stem from a coherent single
worldview, but rather accidentally juxtaposed opinions of different
individuals.

We (all) can and should do better than this.

 > What Bob and others seem to have constructed
 > here is an argument for the dynamic loader ban
 > that can be summed up:

[as an ad hominem attack.]  I don't see it, either.  I was certainly
offended by Alan's comments about ignoring the needs of some people in
the community, but I don't see it as a deliberate attack.

Re: Release plans

[Robert J. Chassell]

"Stephen J. Turnbull" <stephen@xemacs.org>, are you saying that
copyright law does not have to do with copying between people?

My part of this started after Johannes Weiner <hannes@saeurebad.de>
wrote

    > Whether one loads proprietary modules into the kernel is a
    > personal decision and I don't like deciding for other people.

and I wrote

    No; it is not a personal decision.  When you load proprietary
    modules, you are telling those who pay attention that you do not
    mind restricting yourself.

He did not understand what I meant, so I wrote

    You are not being personal when you make a decision involving others ...

"Stephen J. Turnbull" <stephen@xemacs.org> wrote, which I disagreed with 
with respect to the actual practice of law

     >     Freedom *means* that you may do something without concern for
     >     interference from your government or your neighbors. ...

The question is whether software copying studying, modifying, and
redistributing over the next generation will remain as legal or illegal
as it has in the past generation.  (Copyright law and treaties count in
lawful areas; I am presuming, perhaps erronously, that areas that ignore
that law when people are bribed millions of US dollars do not grow
much bigger in the next generation.  Generally speaking, free software
support companies lack the resources to bribe a huge amount.)

I agree it is important to emphasize the importance of software freedom,
to emphasize the costs, and to provide good software.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Release plans

[Stephen J. Turnbull]

Robert J. Chassell writes:

 > "Stephen J. Turnbull" <stephen@xemacs.org>, are you saying that
 > copyright law does not have to do with copying between people?

Since I have no clue what you might mean by "copying between people",
no, I'm not saying any such thing.

In the U.S., and I believe similarly for other jurisdictions,
copyright law regulates not only copying but distribution,
performance, and other such social activity.  Nevertheless, a specific
agent (the copyer or distributor) is identified as being restricted,
and IANAL but AFAIK receiving an illegal copy in good faith is not a
crime nor are you liable for civil damages (of course, you must give
up the copy on request of the rights holder).

 > "Stephen J. Turnbull" <stephen@xemacs.org> wrote, which I disagreed
 > with with respect to the actual practice of law

 >> Freedom *means* that you may do something without concern for
 >> interference from your government or your neighbors. ...

Er, when did you mention the "actual practice of law"?  I seem to have
missed it.

 > The question is whether software copying studying, modifying, and
 > redistributing over the next generation will remain as legal or illegal
 > as it has in the past generation.

Um, no, my question was "what does 'communitarian freedom' mean?" and
you still have made no visible attempt to answer it.

As for this new question you've introduced, none of those *acts* are
legal or illegal as such, so you seem a bit confused as to the actual
practice of law.  Rather, the right to perform those acts is reserved
to "owners", and they are by that token prohibited by law for others
until permission is granted.[1]

So what you are now asking is "will we expropriate existing exclusive
rights, and stop issuing them in the future", I guess?  I certainly
hope we don't expropriate them entirely, although I would like to see
the retroactive term extensions reversed as unconstitutional[2], and
future grants dramatically reduced or even eliminated.

By the way, although studying software is specified among the four
freedoms, it was never made illegal by copyright law, until the DMCA,
and there only a very restricted subset of software is illegal to
study.  It's just impossible to study it if you don't get a copy, and
acceptance of a EULA binding you not to study it is often a condition
required to acquire a copy.  But that is governed by contract law, not
copyright law.


Footnotes: 
[1]  However, for nearly all software applications I wish to use,
versions are available for which copying, modifying, and
redistributing are perpetually legal under copyright law because they
are covered by free software licenses.  My belief, and I suspect Tom's
is similar, is that the best way to extend that region of freedom is
to write more excellent software and distribute it under free
licenses.  Removing features from software is neither helpful to that
cause, nor is it likely to slow the growth of the non-free region.

[2]  My theory is that the Constitution explicitly says that these
franchises are intended "to encourage the useful arts", but any
putative encouragement must have happened before the original grant of
franchise---retroactive extensions are expropriating the public, pure
and simple, to no conceivable good (except the profit of owners).

Re: Release plans

[Robert J. Chassell]

    > Robert J. Chassell writes:
    >
    >  > "Stephen J. Turnbull" <stephen@xemacs.org>, are you saying that
    >  > copyright law does not have to do with copying between people?

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

    > Since I have no clue what you might mean by "copying between people",
    > no, I'm not saying any such thing.

Currently, law is made by humans.  In the future, it may be made by
artificial intelligences, extraterrestrials, or others, but currently,
it is made by people to handle some of their affairs both with each
other and with non-human nature.

    > In the U.S., and I believe similarly for other jurisdictions,
    > copyright law regulates not only copying but distribution,
    > performance, and other such social activity.

My question concerned copying.

    > Er, when did you mention the "actual practice of law"?  I seem to
    > have missed it.

I presumed we were talking about what might be copied and distributed.
That would be "actual practice".  Your question about 'communitarian
freedom' does not seem to have much to do with the "actual practice of
law" world wide.

    > As for this new question you've introduced, none of those *acts* are
    > legal or illegal as such, so you seem a bit confused as to the actual
    > practice of law.

As far as I know, in the United States and other countries that have
agreed to the modern replacements for the Berne Convention, every
expression is currently owned at origination by someone, an owner (in
other words, putting a copyright notice on the expression adds legal
power), and, except for good faith copying, you may not copy it without
permission.  The GNU General Public License takes this law and says that
the owner permits you to copy, study, modify, and distribute this code
in perpetuity.

    > By the way, although studying software is specified among the four
    > freedoms, it was never made illegal by copyright law, until the
    > DMCA, and there only a very restricted subset of software is
    > illegal to study.

People in general cannot readily study binary.  That is a practical
issue.

    > [2]  My theory is that the Constitution explicitly says that these
    > franchises are intended "to encourage the useful arts", ...

The Chinese constitution is not written in English; in any case,
copyright enforcement concerns both the treaties that the Chinese
government has signed and how much they are pushed.  Like the study of
binaries, this is a practical issue.

World wide, I think we should "encourage the useful arts".  I am
concerned about the degree to which and how to "encourage the useful
arts" currently.  Compliance is a practical matter.

--
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Release plans

[Stephen J. Turnbull]

Robert J. Chassell writes:

 >     > Robert J. Chassell writes:
 >     >
 >     >  > "Stephen J. Turnbull" <stephen@xemacs.org>, are you saying that
 >     >  > copyright law does not have to do with copying between people?
 > 
 > "Stephen J. Turnbull" <stephen@xemacs.org> writes:
 > 
 >     > Since I have no clue what you might mean by "copying between people",
 >     > no, I'm not saying any such thing.
 > 
 > Currently, law is made by humans.  In the future, it may be made by
 > artificial intelligences, extraterrestrials, or others, but currently,
 > it is made by people to handle some of their affairs both with each
 > other and with non-human nature.

I gather I've been trolled.  'bye!

Re: Release plans

[Robert J. Chassell]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
 
     > Since I have no clue what you might mean by "copying between people",
     > no, I'm not saying any such thing.
 
   > I gather I've been trolled.  'bye!

You should never write that you have no clue, unless, of course, you
really don't!

What about the practical issues, whether binary study is easy, and the
degree to which and how to gain compliance world wide for copyright law?

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Release plans

[Richard M. Stallman]

The decision on whether to include a dynamic linker in Emacs
does not directly affect users' freedom.  (It doesn't change the license.)
What is affects is which changes we facilitate and which changes we don't.

The case of XRefactory and its harmful effects on CEDET illustrate the
kind of harm I'm trying to avoid.  It also shows that we cannot
totally avoid such problems.  But opening a convenient door for making
them is likely to mean more of them.  I want to have less of them.

Re: Release plans

[Thomas Lord]

Richard M. Stallman wrote:
> The decision on whether to include a dynamic linker in Emacs
> does not directly affect users' freedom.  (It doesn't change the license.)
> What is affects is which changes we facilitate and which changes we don't.
>
> The case of XRefactory and its harmful effects on CEDET illustrate the
> kind of harm I'm trying to avoid.  It also shows that we cannot
> totally avoid such problems.  But opening a convenient door for making
> them is likely to mean more of them.  I want to have less of them.
>   


You picked a great example.

The absence of a dynamic loader makes it harder
to implement the more performance-intensive
parts of a modern IDE.

Therefore, the dynamic loader ban makes a free
software project like CEDET harder than it
needs to be.

That a modern IDE project for Emacs is so hard makes
the problem an attractive target for a proprietary software
company.   To the proprietary vendor, the difficulty of
writing the program in the first place is a barrier to entry
and will help protect future profits

In other words: the incentive to create the non-free
XRefractory comes, in part, from the ban on a dynamic
loader.

The ban has the exact opposite of the intended effect.

-t




>
>
>
>
>   

Re: Release plans

[Richard M. Stallman]

    In other words: the incentive to create the non-free
    XRefractory comes, in part, from the ban on a dynamic
    loader.

Your reasoning is confused, and the conclusion makes no sense.
My decision remains unchanged.

Re: Release plans

[Paul R]

On Wed, 27 Aug 2008 14:54:18 -0400, "Richard M. Stallman" <rms@gnu.org> said:

Thomas> In other words: the incentive to create the non-free
Thomas> XRefractory comes, in part, from the ban on a dynamic loader.

RMS> Your reasoning is confused, and the conclusion makes no sense. My
RMS> decision remains unchanged.

Thomas reasoning is :

1- There is NO ROOM for proprietary software when free software exists
   and meet all the users technical requirements. IOW, nowaday
   proprietary software only survives when it proves clear technical
   superiority over free software (or when it locks users with file
   formats, but that's not the point here)

2- Banning technical facilities like DLL from free software is likely
   to leave a clear advantage to proprietary software that use those
   facilities to provide the best technical solution.

Conclusion : banning DLL from emacs is likely to make it technicaly
inferior than alternatives, thus preventing users from using it, thus
reducing the global freedom of the community.

-- 
  Paul

Re: Release plans

[Richard M. Stallman]

    2- Banning technical facilities like DLL from free software is likely
       to leave a clear advantage to proprietary software that use those
       facilities to provide the best technical solution.

Refusing to support DLL does not give an advantage to non-free
software.  In particular, it does not give XRefractory an advantage
over CEDET.

Re: Release plans

[Thomas Lord]

Richard M. Stallman wrote:
>     2- Banning technical facilities like DLL from free software is likely
>        to leave a clear advantage to proprietary software that use those
>        facilities to provide the best technical solution.
>
> Refusing to support DLL does not give an advantage to non-free
> software.  In particular, it does not give XRefractory an advantage
> over CEDET.
>   


It gives an equal technical disadvantage to both but an
economic favor to XRefractory.   That economic favor to
XRefractory is an example of why people invest in proprietary
software entrepreneurship.

The declaration of intent to refuse (aka "ban") helps give
XRefractory a business plan (because the same ban makes life harder
for less speculatively funded competitors like CEDET).

-t

Re: Release plans

[Bruce Stephens]

Thomas Lord <lord@emf.net> writes:

> Richard M. Stallman wrote:
>>     2- Banning technical facilities like DLL from free software is likely
>>        to leave a clear advantage to proprietary software that use those
>>        facilities to provide the best technical solution.
>>
>> Refusing to support DLL does not give an advantage to non-free
>> software.  In particular, it does not give XRefractory an advantage
>> over CEDET.
>
> It gives an equal technical disadvantage to both but an
> economic favor to XRefractory.   That economic favor to
> XRefractory is an example of why people invest in proprietary
> software entrepreneurship.
>
> The declaration of intent to refuse (aka "ban") helps give
> XRefractory a business plan (because the same ban makes life harder
> for less speculatively funded competitors like CEDET).

Is this an abstract discussion or is it concretely about Emacs and
CEDET?  (I'm struggling to imagine what realistic benefit CEDET might
get from a dynamic extension to Emacs.  Maybe linking with SQLite?)

Surely XRefactory's big advantage over CEDET is use of an EDG-based
parser (which costs money)?  So in that sense the restrictions on how
the core gcc project develops (whether it can provide suitable dumps
of parse trees and the like) are more significant than restrictions on
Emacs?

Re: Release plans

[Lennart Borgman (gmail)]

Bruce Stephens wrote:
> Is this an abstract discussion or is it concretely about Emacs and
> CEDET?  (I'm struggling to imagine what realistic benefit CEDET might
> get from a dynamic extension to Emacs.  Maybe linking with SQLite?)

Linking to parsing libraries (but I am not sure which one there are).
That way greater control could be get, parsing could be stopped and
restarted with very little cost. It could be easier to save the data and
go deeper into the parsing (but that is just a guess).

I believe that for web development there often are free or at least
freely available for parsing.

Re: Release plans

[Thomas Lord]

Lennart Borgman (gmail) wrote:
> I believe that for web development there often are free or at least
> freely available for parsing.
>   

Speaking of parsing, that doesn't, quite, but what you
meant either "is" or "immediately suggests" a good idea:
an Emacs-based, schema-aware, validating XML
parser and XML database browser.   Very much like
an IDE with built-in parser, such tools want built-in
XML parsers (and validators) and it would be very
nice, performance-wise and semantics-wise, to be
able to address the database from lisp directly rather
than going through the serialization bottleneck to a
sub-process.

-t





>
>
>   

Re: Release plans

[Thien-Thi Nguyen]

() Thomas Lord <lord@emf.net>
() Fri, 29 Aug 2008 12:23:20 -0700

   it would be very nice, performance-wise and semantics-wise, to
   be able to address the database from lisp directly rather than
   going through the serialization bottleneck to a sub-process.

I think you've got it backwards; in any system involving Emacs (of
the current design), the serialization bottleneck is Emacs `eval'.
In this light, a subprocess is actually the most clean and (more
importantly) upwardly compatible way to scale performance.

If we wish to augment this extremely clean model:

  (1a) emacs
  (1b) emacs------------emacs           ; fork
  (1c) emacs--[serial]--subproc         ; exec

for performance purposes, then i suggest we concentrate on the
data structure for sharing info between emacs and the subproc,
rather than the control structure (i.e., dynamic loader).  More
precisely, i would like to see something like:

  (2a) emacs
  (2b) emacs--[sharable-buffer]         ; "sweep-porch"
  (2c) emacs---[shared-buffer]---emacs  ; "invite-kibitz" :-D

The second emacs (from 2c) can mux traditional children (1b, 1c)
as it sees fit, of course.

In Unix, the data structure for sharing info is a shared buffer,
but the protocol for manipulating that buffer is very limited.
Lots of fun ensued, anyway.  Emacs deserves no less.

thi

Re: Release plans

[Stefan Monnier]

>    it would be very nice, performance-wise and semantics-wise, to
>    be able to address the database from lisp directly rather than
>    going through the serialization bottleneck to a sub-process.

> I think you've got it backwards; in any system involving Emacs (of
> the current design), the serialization bottleneck is Emacs `eval'.

I'm not sure I understand what you mean.  In the case of something like
Semantic, if parsing in Elisp is too expensive or if you want to use
some existing C code to do the parsing, the bottleneck you'll have to
handle is that the external process can't directly access the buffer's
text, and it can be very costly to pass that text to the subprocess and
then process the returned value (which may look like a list of text
properties to add to various parts of the text).

A DLL could be significantly more efficient.  The difference can be as
large as "on-the-fly" vs "batch".


        Stefan

Re: Release plans

[Lennart Borgman (gmail)]

Stefan Monnier wrote:
>>    it would be very nice, performance-wise and semantics-wise, to
>>    be able to address the database from lisp directly rather than
>>    going through the serialization bottleneck to a sub-process.
> 
>> I think you've got it backwards; in any system involving Emacs (of
>> the current design), the serialization bottleneck is Emacs `eval'.
> 
> I'm not sure I understand what you mean.  In the case of something like
> Semantic, if parsing in Elisp is too expensive or if you want to use
> some existing C code to do the parsing, the bottleneck you'll have to
> handle is that the external process can't directly access the buffer's
> text, and it can be very costly to pass that text to the subprocess and
> then process the returned value (which may look like a list of text
> properties to add to various parts of the text).
> 
> A DLL could be significantly more efficient.  The difference can be as
> large as "on-the-fly" vs "batch".


It looks to me like the buffer string routines Thomas is working on
could perhaps make that easier to implement (in the DLL case of course).
But I guess you have thought much more about that, Thomas?

Re: Release plans

[Thomas Lord]

Lennart Borgman (gmail) wrote:
>
> It looks to me like the buffer string routines Thomas is working on
> could perhaps make that easier to implement (in the DLL case of course).
> But I guess you have thought much more about that, Thomas?
>   


Not deeply (because I'm confident on general principles).

Using functional strings that, behind the scenes, share state
and use mutation rather than copy/alter when they can -- that
pattern -- generally simplifies higher-level coroutine coding.
Beyond that I haven't worried about it and am instead fretting
over getting just the basics working, first.

A fun problem that I found a solution for and am currently
coding is the fragmentation problem.   The splay-tree-of-gap-buffers
allows strings to be arbitrarily fragmented.    However, low-level
I/O systems (e.g., DMA, L2 and L1 caches) like the fragments
to be various minimum sizes (cache lines, pages, etc.).   A fun
set of tricks to think about is how to manage the splay-tree-of-gap-buffers
such that the majority of string/buffer data winds up being in
roughly page-sized chunks, to minimize the amount of data-copying
needed and to maximize the effectiveness of caches.

It's a fun puzzle.

-t

Re: Release plans

[Thomas Lord]

Stefan Monnier wrote:
> A DLL could be significantly more efficient.  The difference can be as
> large as "on-the-fly" vs "batch".
>   

Exactly.  That's the gambit.

Thien-thi Nguyen's suggestion of shared buffers is a very
plausible dynamic loading API for such aims, if you ask me.
So you're both right (if you ask me).

-t




>
>         Stefan
>
>   

Re: Release plans

[Thien-Thi Nguyen]

() Stefan Monnier <monnier@IRO.UMontreal.CA>
() Fri, 29 Aug 2008 16:20:09 -0400

   I'm not sure I understand what you mean.  In the case of something like
   Semantic, if parsing in Elisp is too expensive or if you want to use
   some existing C code to do the parsing, the bottleneck you'll have to
   handle is that the external process can't directly access the buffer's
   text,

In the common case, that text is a file on the filesystem (which the
subprocess can access independently).  I would design things so that the
subprocess persists for the Emacs session and maintains its own state,
such as various project-specific symbol tables and a copy of the buffer.
Commands from Emacs would be along the lines of "sync-with-file",
"query-symbol", "query-parse-state", and so forth.  Results from the
query-FOO commands should typically be very low bandwidth.

So no, i don't think the bottleneck would be the buffer access (for this
design), because the subprocess does not really need to access the buffer.
Changes to the buffer that have not yet hit the filesystem can be
communicated by publishing some portion of `buffer-undo-list' (which is
also relatively lightweight).

   and it can be very costly to pass that text to the subprocess and
   then process the returned value (which may look like a list of text
   properties to add to various parts of the text).

Well...

   A DLL could be significantly more efficient.  The difference can be as
   large as "on-the-fly" vs "batch".

...i suppose i'll have to agree that all these "could be" scenarios are
possible.  My view is that given the requirement of external symbol tables
(and other state), the biggest win for both performance and maintainability
is to go asynchronous.  If you want async from a subprocess, no worries,
but if you want async in-process, you need to either design (and debug and
maintain) "ethreads", or make Emacs play nice w/ pthreads or quickthreads
or phase-of-the-moon-threads or whathaveyou.  Then, you need to make sure
every visitor treats your program counter w/ the respect it deserves.
That's a lot of thankless and brutish police work.

thi

Re: Release plans

[Thomas Lord]

Thien-Thi Nguyen wrote:
> So no, i don't think the bottleneck would be the buffer access (for this
> design), because the subprocess does not really need to access the buffer.
> Changes to the buffer that have not yet hit the filesystem can be
> communicated by publishing some portion of `buffer-undo-list' (which is
> also relatively lightweight).
>   

So, the sub-process basically contains a text editor
in this design, albeit one without redisplay code and
with an unusual, limited command set.   That need for
redundant code to make this thing work helps to prove
that, indeed, the absence of dynamic loading (including
just shared memory regions for buffers) creates make-work
to work around it.

I'm also skeptical about the performance claims here.
A full update involves changing the buffer, print + system
calls to inform the sub-process, system calls + read to
get back the results of the parse updates, and then the
actual text property updates.     For interactive typing
that can probably keep up on a modern machine but
for other stuff it can easily be a performance bottleneck.
(Still, even if it is not, it's doing it "the hard way".)


>    and it can be very costly to pass that text to the subprocess and
>    then process the returned value (which may look like a list of text
>    properties to add to various parts of the text).
>
> Well...
>
>    A DLL could be significantly more efficient.  The difference can be as
>    large as "on-the-fly" vs "batch".
>
> ...i suppose i'll have to agree that all these "could be" scenarios are
> possible.  My view is that given the requirement of external symbol tables
> (and other state), the biggest win for both performance and maintainability
> is to go asynchronous.  If you want async from a subprocess, no worries,
> but if you want async in-process, you need to either design (and debug and
> maintain) "ethreads", or make Emacs play nice w/ pthreads or quickthreads
> or phase-of-the-moon-threads or whathaveyou.  Then, you need to make sure
> every visitor treats your program counter w/ the respect it deserves.
> That's a lot of thankless and brutish police work.
>   

That seems exaggerated.   A hook in the interact loop that locked
a shared mem buffer briefly while asking for updates from an
incremental parser / ide-helper doesn't seem like it would be all that
hard to get right.

-t

Re: Release plans

[Thien-Thi Nguyen]

() Thomas Lord <lord@emf.net>
() Sat, 30 Aug 2008 16:07:51 -0700

   So, the sub-process basically contains a text editor
   in this design, albeit one without redisplay code and
   with an unusual, limited command set.

I suppose that's a fitting description.

   That need for redundant code to make this thing work helps to
   prove that, indeed, the absence of dynamic loading (including
   just shared memory regions for buffers) creates make-work to
   work around it.

I don't follow your logic, perhaps because you include
shared-memory buffers in dynamic loading (which is not what i
described), to make your point.  But that's ok; maybe we are
talking about different designs.

   For interactive typing
   that can probably keep up on a modern machine but
   for other stuff it can easily be a performance bottleneck.
   (Still, even if it is not, it's doing it "the hard way".)

Perhaps difficulty lies also in the eye of the beholder.

   That seems exaggerated.  A hook in the interact loop that
   locked a shared mem buffer briefly while asking for updates
   from an incremental parser / ide-helper doesn't seem like it
   would be all that hard to get right.

OK.

thi

Re: Release plans

[Thomas Lord]

Thien-Thi Nguyen wrote:
> () Thomas Lord <lord@emf.net>
> () Fri, 29 Aug 2008 12:23:20 -0700
>
>    it would be very nice, performance-wise and semantics-wise, to
>    be able to address the database from lisp directly rather than
>    going through the serialization bottleneck to a sub-process.
>
> I think you've got it backwards; 

Actually I don't but there is a linguistic problem between
you and I (a minor one).

You contrast my advocacy for a dynamic loader with what
you propose as an alternative.   I'll just quote in full here since
it's short:

> in any system involving Emacs (of
> the current design), the serialization bottleneck is Emacs `eval'.
> In this light, a subprocess is actually the most clean and (more
> importantly) upwardly compatible way to scale performance.
>
> If we wish to augment this extremely clean model:
>
>   (1a) emacs
>   (1b) emacs------------emacs           ; fork
>   (1c) emacs--[serial]--subproc         ; exec
>
> for performance purposes, then i suggest we concentrate on the
> data structure for sharing info between emacs and the subproc,
> rather than the control structure (i.e., dynamic loader).  More
> precisely, i would like to see something like:
>
>   (2a) emacs
>   (2b) emacs--[sharable-buffer]         ; "sweep-porch"
>   (2c) emacs---[shared-buffer]---emacs  ; "invite-kibitz" :-D
>
> The second emacs (from 2c) can mux traditional children (1b, 1c)
> as it sees fit, of course.
>   

One little catch, please.   If you are going to have (2c) then
you also implicitly have:

      (2c') emacs -- [shared buffer] -- any[*]

      [*] any program that knows the buffer data structure
      and sharing protocol

In other words, (2c) is one possible API for a dynamic loader in
Emacs.

I think a dynamic loading API based on shared buffers is a very
good idea, by the way.   That is probably a better way to do it than
just a cut-and-paste dlopen job from some other app.  A shared buffer
API is just as much an invitation to non-free add-ons as a dlopen
API, but the shared buffer API is probably (I'd agree with you, if
we're just kibbitzing) better for free software developers, better for
Emacs maintainers, etc.




> In Unix, the data structure for sharing info is a shared buffer,
> but the protocol for manipulating that buffer is very limited.
> Lots of fun ensued, anyway.  Emacs deserves no less.
>
>   

I think that there are leaks in that abstraction -- it's not quite as
minimal and contained as I think you suggest.

For example, buffer have buffer local variables and have lexical
environments that include global scope so, ideally, the entire Emacs
lisp address space is accessible from a shared buffer.   The actual
API has to achieve that API or compromise with some simplifications.
I would expect a compromise, for practical reasons.   It is an
interesting medium-sized research project to search for a sweet-spot
API for shared buffers.  By what metric should we be invited to measure
the compromise?  and then how is the compromise implemented?  and
how does it perform? and what is it good for?

-t





> thi
>
>
>
>   

Re: Release plans

[Thien-Thi Nguyen]

() Thomas Lord <lord@emf.net>
() Fri, 29 Aug 2008 15:53:50 -0700

   You contrast [...]
   If you are going to have (2c) then
   you also implicitly have:

        (2c') emacs -- [shared buffer] -- any[*]

        [*] any program that knows the buffer data structure
        and sharing protocol

   In other words, (2c) is one possible API for a dynamic loader in
   Emacs.

Instead of "contrast", you can look at shared buffers as the
strength- (and thus complexity- and maintenance-burden-)reduced
well-behaved little brother to the dynamic loader.  This is
because the focus is on sharing data, not the program counter.

   A shared buffer API is just as much an invitation to non-free
   add-ons as a dlopen API, but the shared buffer API is probably
   (I'd agree with you, if we're just kibbitzing) better for free
   software developers, better for Emacs maintainers, etc.

If you keep the protocol focused on data, then you stay out of the
scope of free software (modulo what GPLv3 brings to bear wrt
patents).  This is the primary {at,de}traction of this (and any
network-protocol-based) approach.

   I think that there are leaks in that abstraction -- it's not
   quite as minimal and contained as I think you suggest.
   [design issues]

OK.

   By what metric should we be invited to measure the compromise?
   and then how is the compromise implemented?  and how does it
   perform? and what is it good for?

These are good questions.  I don't know their answers.

thi

Re: Release plans

[Thomas Lord]

Bruce Stephens wrote:
> Is this an abstract discussion or is it concretely about Emacs and
> CEDET?  (I'm struggling to imagine what realistic benefit CEDET might
> get from a dynamic extension to Emacs.  Maybe linking with SQLite?)
>   

That's an interesting idea.   I was thinking about tools for incremental
parsing as an example.   Fast and good support for small databases
makes sense, too.

Other people mentioned other applications of a dynamic loader,
too, not necessarily IDE related (e.g., image manipulation, network
protocols, etc.)

In general, anytime you want the coroutine to use a lot of data
that normally sits in Emacs memory (e.g., buffer contents) -- and
you want that coroutine to randomly access that data or in other
ways have fast access to it -- a dynamic loader would be handy.

I don't claim, by the way, that a dynamic loader makes perfect
technical sense for GNU Emacs as it stands today.   It *might*
and it *might not*.  I do claim that that fears of non-free add-ons
aren't argument enough against a dynamic loader.  So, the discussion
is abstract in that sense, I guess.


> Surely XRefactory's big advantage over CEDET is use of an EDG-based
> parser (which costs money)?  So in that sense the restrictions on how
> the core gcc project develops (whether it can provide suitable dumps
> of parse trees and the like) are more significant than restrictions on
> Emacs?
>   

It could be.


Hmm.  There is an architecture to consider:  Imagine dynamically
loadable parsers for your favorite languages.   Might there be a
reasonable API design such that a single parsing tool can do both
incremental parsing / re-parsing and efficient straight-through parsing,
producing output (in the form of API calls or return values) suitable
for both building GCC trees and updating text properties and database
values in an IDE?

If so, can tools such as Bison be extended to support generation
of the incremental (re-) parsing parts (e.g., with suitable ways of
handling parse errors and recovery in an incremental context)?

The resulting "kit" of Emacs w/DL + GCC w/DL +  extended Bison
could be very fun to play with.

-t

Re: Release plans

[Richard M. Stallman]

    Surely XRefactory's big advantage over CEDET is use of an EDG-based
    parser (which costs money)?  So in that sense the restrictions on how
    the core gcc project develops (whether it can provide suitable dumps
    of parse trees and the like) are more significant than restrictions on

The FSF would be glad to have features in GCC for outputting
cross-reference information, if that is the best way to do this job.

One drawback of that approach for cross-references is that it tends
to fail to show that this code uses both foo and bar:

#ifdef HAVE_XYZ
  foo ();
#else /* not HAVE_XYZ */
  bar ();
#endif /* not HAVE_XYZ */

Re: Release plans

[Richard M. Stallman]

    The declaration of intent to refuse (aka "ban") helps give
    XRefractory a business plan (because the same ban makes life harder
    for less speculatively funded competitors like CEDET).

That's just speculation, and I don't find it convincing.

Re: Release plans

[Thomas Lord]

Richard M. Stallman wrote:
>     The declaration of intent to refuse (aka "ban") helps give
>     XRefractory a business plan (because the same ban makes life harder
>     for less speculatively funded competitors like CEDET).
>
> That's just speculation, and I don't find it convincing.
>   

Is that a pun?   I mean, if my comments are speculation
they are speculation about how people speculate...

The general principle I've expressed rests on pretty
uncontroversial assumptions:   feature bans help
protect a barrier to entry for anyone who manages to
work around them;  barriers to entry are one of the
key things that venture funders and similar investors
look for in software firms.  


-t





>
>
>   

Re: Release plans

[Thomas Lord]

Richard M. Stallman wrote:
>     In other words: the incentive to create the non-free
>     XRefractory comes, in part, from the ban on a dynamic
>     loader.
>
> Your reasoning is confused, and the conclusion makes no sense.
> My decision remains unchanged.
>   


My reasoning is not confused.  I'll restate it more plainly:

Consider a feature, X, which is desirable for practical purposes.

Consider a feature, Y, which is banned.

If the ban on Y makes X harder to implement, in the sense
of costing more in labor or money, then the economic incentive
to go into business selling a non-free implementation of X goes
up.

The reason that incentive goes up is because the cost of
going into business selling a non-free X goes up while the
demand for the practically useful X remains steady.

Now, someone with some money that they want to spend
writing new, non-free software looks at that and says
"I think I can do X, in spite of the ban on Y.  In fact,
given the work I did on my masters thesis, I think I can do
X cheaper than most people.   If I start selling a non-free X,
it will be a long time before some competitor comes along
either selling a non-free competitor to X or sharing a free
version of X.  It will be a long time because I'm almost the only one
with an effective idea of how to get around the ban on Y.
Therefore, I'll go into business selling proprietary X and count
my blessings for the banning of Y."

There are (and have long been) available to the GNU project
a kind of dichotomy of positive and negative strategies for
designing and implementing software.   On the positive side:
writing code that directly helps users' and developers' of
free software.  On the negative side, writing code or refusing
to write code -- either way -- so as to push back the goals of
non-free software developers.

Obviously the happiest cases are when the strategy can
use both simultaneously:  with one line of code written or
not written both help users and developers on the free side
and directly impede developers on the non-free side. 

The hard cases (apparently) are when the only choices
apparent are either only positive or only negative:  only
help free software users and developers directly, or
only directly interfere with non-free developer ambitions --
but not both.   The dynamic loader and GCC tree print/read
problems are in this category of "either but not both".

What I am pointing out to you is that those "either but not
both" cases are not very clear cut -- you don't actually have the
choice you think you have.   You *think* that the dynamic loader
ban impedes non-free Emacs add-ons but the abstract argument
above about X and Y and the specific real-world example of
XRefractory illustrate that, well, the dynamic loader ban may actually
make especially problematic non-free add-ons *more* likely.

So, what "strategy do you use for picking a strategy" when cases
like that arise -- cases of partial knowledge and easy mistakes like
that?

I say: stay positive and stick to what you know about making life
easier for free software users and developers and ignore any
(probably mistaken) hypotheticals about what non-free developers
might do.   The more capable free software users and developers
become, the faster the free software movement will snowball and
win -- at least that is the view that comes from confidence.

Remember that 30 years ago you were a hacker just out to
"improve the system" and any artificial legal hoo-haw that
got in the way just seemed stupid (at first) and then sinister
(leading to the movement).

Ok, so... don't go from that good position, way back then,
to a modern one where for some twisted reason you conclude
that you should decline to "improve the system" when you have
every right to.   Feature bans are antithetical to the hacker spirit that
gave rise to the free software movement.



-t


>
>
>   

Re: Release plans

[Alfred M. Szmidt]

   Remember that 30 years ago you were a hacker just out to "improve
   the system" and any artificial legal hoo-haw that got in the way
   just seemed stupid (at first) and then sinister (leading to the
   movement).

   Ok, so... don't go from that good position, way back then, to a
   modern one where for some twisted reason you conclude that you
   should decline to "improve the system" when you have every right
   to.  Feature bans are antithetical to the hacker spirit that gave
   rise to the free software movement.

Nobody has banned any feature.  The maintainers are simply stating
that such a patch would be rejected and why; just like they would
reject a patch that does not follow coding standards or introduces a
bug.

It would have been no different than rejecting a patch that would add
a login with passwords on ITS or file permissions...  People hacking
the system would have felt that it would not improve the system, as is
the case here.

Re: Release plans

[Thomas Lord]

Alfred M. Szmidt wrote:
>
> Nobody has banned any feature.  The maintainers are simply stating
> that such a patch would be rejected 


That is what I mean by "ban": a feature not permitted,
by the maintainers, to appear in a release of GNU Emacs.


> It would have been no different than rejecting a patch that would add
> a login with passwords on ITS or file permissions...  People hacking
> the system would have felt that it would not improve the system, as is
> the case here.
>   


That is a poor analogy on many levels.  Do you really wish
to defend it?

-t

Re: Release plans

[Richard M. Stallman]

    That is what I mean by "ban": a feature not permitted,
    by the maintainers, to appear in a release of GNU Emacs.

That word is misleading and hostile.  In effect, you are trying
to change my mind by insulting me.
you don't like.

My natural tendency is to dig in my heels.  However, I will try to
resist that and continue judging the issue as if you were not here.

Re: Release plans

[Thomas Lord]

Richard M. Stallman wrote:
>     That is what I mean by "ban": a feature not permitted,
>     by the maintainers, to appear in a release of GNU Emacs.
>
> That word is misleading and hostile. 

I doubt that -- I think it more likely that you have just attacked
me with defamation and answered my arguments with ad hominem --
but I do wonder which word you mean, how it is supposedly
misleading and hostile, and what a better word would be.


-t

Re: Release plans

[Alan Mackenzie]

On Wed, Aug 27, 2008 at 03:32:15PM -0700, Thomas Lord wrote:
> Richard M. Stallman wrote:

> >Your reasoning is confused, and the conclusion makes no sense.
> >My decision remains unchanged.

> My reasoning is not confused.  I'll restate it more plainly:

[ Snip 70 lines of the usual. ]

> Ok, so... don't go from that good position, way back then, to a modern
> one where for some twisted reason you conclude that you should decline
> to "improve the system" when you have every right to.   Feature bans
> are antithetical to the hacker spirit that gave rise to the free
> software movement.

Thomas, this is the Emacs developers' mailing list.  Basic courtesy is
the expected norm here, even when disagreeing strongly with somebody.

If you were to fix a bug, or start implementing a cool new feature - you
know, make some sort of contribution, no matter how small - it would be
really appreciated.

We don't need a Director of Marketing here.

> -t

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Thomas Lord]

Alan Mackenzie wrote:
> If you were to fix a bug, or start implementing a cool new feature - you
> know, make some sort of contribution, no matter how small - it would be
> really appreciated.
>   


I'm working on a new implementation of strings and buffers,
including support for undo, markers, properties, and overlays.
That's going well.

If it finishes well, then I might make a new implementation of
interact loops and redisplay primitives, add a dynamic loader,
and call it a day.   (After which I might work on a dynamically
loadable extension language interpreter.)

There is a fork in the road coming up, though.  I started on the
strings and buffers project for a different purpose, originally:  I
want them for an extended XML parser with SAX and DOM
models.   After I get strings and buffers working I'll have to consider
what to work on next out of the set: XML foo, Emacs interact loop,
or Emacs-style redisplay.   I'm not sure which I'll pick.

The new strings and buffers implementation is inspired by
several needs including but not limited to:

1) to have such as a stand-alone C library
2) to be useful for a lisp implementation without requiring all
    the baggage of a lisp implementation
3) to fix some performance problems that gap buffers have
4) to handle unicode very cleanly
5) to make string-handling C code easier to get right

The string representation is based on splay trees: a string
is a splay tree of gap buffers.   There are various invariants
(that I won't get into here) that make these trees more than
ordinary splay trees -- they are a new data structure (afaict).

The string representation is (semantically) functional: strings
are never modified.     Instead, strings share state (i.e., share
sub-trees) and linear styles of programming are rewarded (e.g.,
sometimes new strings are constructed by cheaply modifying
existing strings *if* there are no other references left to the unmodified
string).

Because strings are functional and share state, "undo" is pretty
trivial.   To snapshot the state of a buffer at some instant,
just make a copy of the string it contains.   That copy
will share state (so it is space efficient and cheap to create). 
That copy won't change (since the string representation is
functional).

The splay tree of gap buffers representation means that the
amortized cost of shifting characters from one side of the
conceptual gap to another (moving the point) is O(log n) (compared
to gap buffers which are O(n)).  At the
same time, the space inefficiency of the tree and time inefficiency
of scanning it are no worse than O(n) (in the length of the string) --
the same as gap buffers.   So the new data structure is at least
asymptotically faster.

Another interesting advantage of this string/buffer representation
is that it is very good at representing *sparse* buffers -- buffers that
are mostly just a string of a single character repeated, only in a few
places interrupted with others.    As a consequence, these new 
strings/buffers
can be used for non-traditional purposes, such as huge sparse bitsets, or
large hash tables.   (A buffer as a hash table?    Roughly speaking: compute
an N-bit hash value, then go to that line of the buffer -- that line of 
the buffer
contains the corresponding (possibly empty) hash bucket.   This 
splay-of-gap-buffers
thing can handle that quite efficiently -- O (log N) for the "goto step" 
with amortized
cost much lower if access patterns display locality.  It's not really 
*quite* that
simple for a fast hash table but it's close.)


This kind of project is very much Emacs related and, also, is slower
than just looking up a minor bug with a quick fix.  I like to get some 
orientation
to the terrain along the way, hence the bursts of verbosity (which, really,
aren't *that* much in the overall ebb and flow).

Oh, the meat of the new string data structure looks like it will weigh in
far under 5K lines of code -- the whole buffer support perhaps doubling it.
It's shaping up as pretty tight code that is pretty and simple to follow 
(another
of the goals).   The main logic for editing primitives and splaying look to
come in under 1K lines of code -- maybe 2K.

Thinking of the possible follow-on projects of interact loop, redisplay, and
dynamic loader:

Interact loops are easy enough and I can certainly make a "stackless"
version (so, no more "recursive minibuffers" hair).

Redisplay is the intimidating one, still, because it just looks hopelessly
tedious.   Conceptually easy, sure, but tedious and requiring too much code.
I'm still thinking about that part.

The combination of the buffers, interact loop, redisplay and loader would
be "an Emacs", stripped of lisp, but ready to dynamically load a lisp
(or any other language) interpreter.

Since you asked so nicely,
-t

Re: Release plans

[Richard M. Stallman]

    The string representation is based on splay trees: a string
    is a splay tree of gap buffers.   There are various invariants
    (that I won't get into here) that make these trees more than
    ordinary splay trees -- they are a new data structure (afaict).

It will not be easy to determine whether this is a better data
structure for Emacs, even given a full implementation of it.  Even if
we had Emacs working using this, it might be hard to tell whether that
was an improvement.  For instance, many operations might be faster in
some cases, and slower in other cases.
is an improvement.

I also worry that it will be harder for most developers to understand
and change -- or even to use.  For instance, making redisplay operate
on that data structure could be very hard for that reason.

I don't think we would want to implement undo by making a snapshot,
even if the data makes snapshots possible, because this would take up
a lot more space than the current undo data.  Snapshots might be useful
for something, but not for this.

Re: Release plans

[Thomas Lord]

Richard M. Stallman wrote:
>     The string representation is based on splay trees: a string
>     is a splay tree of gap buffers.   There are various invariants
>     (that I won't get into here) that make these trees more than
>     ordinary splay trees -- they are a new data structure (afaict).
>
> It will not be easy to determine whether this is a better data
> structure for Emacs, even given a full implementation of it.  Even if
> we had Emacs working using this, it might be hard to tell whether that
> was an improvement.  For instance, many operations might be faster in
> some cases, and slower in other cases.
>   

There is no need to make any decisions in advance.

I'm not worried about whether or not the code proves out
for GNU Emacs because I am certain I have plenty of uses
for it other than that.   It might well be good in Emacs.
The design is certainly influenced by Emacs' design and
experience.

It can be hard to compare things like this, I agree.



> I also worry that it will be harder for most developers to understand
> and change -- or even to use.  For instance, making redisplay operate
> on that data structure could be very hard for that reason.
>   

I don't see any reason that code would *need* to change.

It might be *desirable* to change redisplay code if simplifications
became possible, or interesting new capabilities.   I don't
see anything that would *need* to change there.



> I don't think we would want to implement undo by making a snapshot,
> even if the data makes snapshots possible, because this would take up
> a lot more space than the current undo data.  Snapshots might be useful
> for something, but not for this.
>   

You misunderstand how it works.   To illustrate:

    buffer_contents = [some big string];

    saved_undo_point = copy (buffer_contents);

    buffer_contents = insert (buffer_contents, "foobar");


After that code, there are two strings floating around:
buffer_contents and saved_undo_point.

The two strings differ by the insertion of "foobar" into
buffer_contents (or, if you like, the deletion of "foobar"
from saved_undo_point).

Internally, the two strings share most of their state.
The total amount of memory used is (roughly speaking)
the memory for saved_undo_point plus the memory
for just the string "foobar".

So, it is almost exactly the same space consumption
as an undo list.

(In reality, it's a little bit fancier than what is
described above in order to put an upper bound on
the amount of fragmentation of strings in memory.)

-t






>
>   

Re: Release plans

[Richard M. Stallman]

    > I also worry that it will be harder for most developers to understand
    > and change -- or even to use.  For instance, making redisplay operate
    > on that data structure could be very hard for that reason.
    >   

    I don't see any reason that code would *need* to change.

I think lots of the redisplay code operates directly on buffer
contents.  Other primitives too.

Re: Release plans

[Thomas Lord]

Richard M. Stallman wrote:
>     > I also worry that it will be harder for most developers to understand
>     > and change -- or even to use.  For instance, making redisplay operate
>     > on that data structure could be very hard for that reason.
>     >   
>
>     I don't see any reason that code would *need* to change.
>
> I think lots of the redisplay code operates directly on buffer
> contents.  Other primitives too.
>   


If you would, please point me to a specific line of code or two
that illustrates what you mean.  I was poking around in the code
before trying to answer you and I didn't spot anything that
looked problematic but I don't claim to know that code well,
either.


-t

Re: Release plans

[Richard M. Stallman]

current_column is one example of code that looks directly
at buffer contents.

I cannot give an example from xdisp.c because I cannot find the code
that actually looks at the buffer.  I don't remember the function name,
and I can't find the place it is called from either.

Re: Release plans

[Thomas Lord]

Richard M. Stallman wrote:
> current_column is one example of code that looks directly
> at buffer contents.
>   

I see.   And like regex.c it has special-case hair to cope with
the gap, etc.

FWIW I think this new data structure will be *easier* to
use and require less hair like that (but, proof is in the pudding
so we'll see when it's done).


> I cannot give an example from xdisp.c because I cannot find the code
> that actually looks at the buffer.  I don't remember the function name,
> and I can't find the place it is called from either.
>   

It looks to me like the display code has gotten gradually
more cleanly abstract over the years.    It still has all of the
considerable hair/tedium that seems to be intrinsic to the redisplay
problem but looks like it keeps a decent arm's length from
buffer internals.  It looks nicer than I remember it being
way back.

-t



>
>
>   

Re: Release plans

[Stefan Monnier]

> I don't think we would want to implement undo by making a snapshot,
> even if the data makes snapshots possible, because this would take up
> a lot more space than the current undo data.

I don't think it would necessarily take up significantly more memory.
In some cases it'll use up less memory.  OTOH it might make it difficult
to implement undo-elt-in-region.


        Stefan

Re: Release plans

[Thomas Lord]

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

Stefan Monnier wrote:
>> I don't think we would want to implement undo by making a snapshot,
>> even if the data makes snapshots possible, because this would take up
>> a lot more space than the current undo data.
>>     
>
> I don't think it would necessarily take up significantly more memory.
> In some cases it'll use up less memory.  OTOH it might make it difficult
> to implement undo-elt-in-region.
>   


Neat problem.  No, I hadn't thought about that case.

Is it the case that undo-elt-in-region exists for little or
nothing more than undo-in-region?    Because:

Markers are currently still stored in a list, right?
So inserts and deletes are linear in the number of
markers in a buffer, right?   (I thought I remembered
that changing long ago but looking at 22.1 source
I guess not.)

My plan is to keep markers in a tree in such a way that
inserts and deletes are log N in the number of markers,
and accessing a marker's position is log N in the number
of markers, but because this will be a self-adjusting tree
all those operations will be O(1) in the expected case where
changes display pretty good locality.

In other words: markers get a lot cheaper.

It *should* (in theory) be just fine for each undo-elt
to contain both string snapshot(s) and markers that
track the region effected.   That's easy to code and in
turn it makes undo-elt-in-region very easy to code.

That's an example of why I (so far) like this data
structure better than the current ones.   If markers get
significantly cheaper than they currently are, and
functional string edit operations get faster -- a lot of
code can be simpler.

-t





>
>         Stefan
>
>
>
>
>   


[-- Attachment #2: Type: text/html, Size: 2353 bytes --]

Re: Release plans

[Stefan Monnier]

>>> I don't think we would want to implement undo by making a snapshot,
>>> even if the data makes snapshots possible, because this would take up
>>> a lot more space than the current undo data.
>> I don't think it would necessarily take up significantly more memory.
>> In some cases it'll use up less memory.  OTOH it might make it difficult
>> to implement undo-elt-in-region.
> Neat problem.  No, I hadn't thought about that case.
> Is it the case that undo-elt-in-region exists for little or
> nothing more than undo-in-region?

AFAIK yes.

> Markers are currently still stored in a list, right?

Yes.

> My plan is to keep markers in a tree in such a way that
> inserts and deletes are log N in the number of markers,
> and accessing a marker's position is log N in the number
> of markers, but because this will be a self-adjusting tree
> all those operations will be O(1) in the expected case where
> changes display pretty good locality.

Not sure how you intend to do that (I considered exactly this kind of
change in the past, but could never come up with a solution that was
satisfactorily elegant).  The O(1) is not necessary, actually.
Anything close to O(log N) will be a welcome improvement.
IIUC XEmacs uses a gap-buffer kind of solution (i.e. not a list of
markers but an array of markers with a moving gap in the middle).

(I've tried splay-trees for text-properties, and the performance was not
noticeably different from the current mostly-balanced binary tree.
In particular it seems that either we don't get to see the O(1) behavior
because the locality is not as good as it seems, or the constant factor
makes up for the difference).

> It *should* (in theory) be just fine for each undo-elt
> to contain both string snapshot(s) and markers that
> track the region effected.   That's easy to code and in
> turn it makes undo-elt-in-region very easy to code.

But that would significantly increase the size of the undo log, I expect
(maybe not algorithmically, but by a non-negligible factor).

It's too bad, because of we ignore the undo-in-region, we don't need
undo info for each modification, we could just grab a snapshot in
undo-boundary.  That would be elegant (tho it's not like it matters:
changing the implementation of the undo data is trying to solve
a non-problem, really).


        Stefan

Re: Release plans

[Thomas Lord]

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

Stefan Monnier wrote:
> (I've tried splay-trees for text-properties, and the performance was not
> noticeably different from the current mostly-balanced binary tree.
> In particular it seems that either we don't get to see the O(1) behavior
> because the locality is not as good as it seems, or the constant factor
> makes up for the difference).
>   

Thanks for the anecdote.

I was kind of thinking that, worst case, that was exactly
what to expect and so then, yes, is expected log N good
for these purposes?  (And I decided, "probably", so I'm
coding....)

It'll be interesting to see.

I think I have an elegant way to do properties and
markers but since I haven't coded that part yet I
can't swear there isn't a devil in the details. 

Years ago I did something very close to what I
have in mind while working on Guile.   (For a while,
Guile had an (unreleased) buffer type, with text properties
and markers, and a redisplay engine for X11.  It was
doing OK and might have matured to what I'm thinking
of now but that work got interrupted and then bit-rotted
away.




>   
>> It *should* (in theory) be just fine for each undo-elt
>> to contain both string snapshot(s) and markers that
>> track the region effected.   That's easy to code and in
>> turn it makes undo-elt-in-region very easy to code.
>>     
>
> But that would significantly increase the size of the undo log, I expect
> (maybe not algorithmically, but by a non-negligible factor).
>   

I guess the way I would say it is that it will *noticably* increase
the size of the undo log (yes, by a constant factor).    And I would
guess that that's *noticably* not *significantly*.   We'll see.
The library is useful, either way.



> It's too bad, because of we ignore the undo-in-region, we don't need
> undo info for each modification, we could just grab a snapshot in
> undo-boundary.  That would be elegant (tho it's not like it matters:
> changing the implementation of the undo data is trying to solve
> a non-problem, really).
>   

The real problems are a desire for a *nice* unicode-and-text-properties-
capable string library with buffer-like capabilities.   I want that as a
library, first and foremost, not tied to just one program.


Thanks,
-t



>
>         Stefan
>
>   


[-- Attachment #2: Type: text/html, Size: 3198 bytes --]

Re: Release plans

[Stephen J. Turnbull]

Thomas Lord writes:

 > of markers, but because this will be a self-adjusting tree
 > all those operations will be O(1) in the expected case where
 > changes display pretty good locality.

I would advise you not to expect that case.  Experience in XEmacs
shows that some applications (the VM MUA in particular, but also the
old implementation of font-lock, dunno about jit-lock) like to run up
and down the buffer a lot.  AFAICS it's really important to have O(log
N) worst-case behavior.

Sorry I can't be much more precise about why this happens, I just know
that our algorithms that deal with extents (which we use to support
overlay-like behavior and text properties) are tuned for good locality
and lose badly in large buffers; they show up as time hogs in profiling.

It's possible it's something internal to the implementation of
extents, too, but I think a word to the wise is appropriate here.

Re: Release plans

[Thomas Lord]

Stephen J. Turnbull wrote:
> Thomas Lord writes:
>
>  > of markers, but because this will be a self-adjusting tree
>  > all those operations will be O(1) in the expected case where
>  > changes display pretty good locality.
>
> I would advise you not to expect that case. 

That's two of you now (saying that).   Ok, then, I'll assume the
worst (which should still be "good enough").


>  Experience in XEmacs
> shows that some applications (the VM MUA in particular, but also the
> old implementation of font-lock, dunno about jit-lock) like to run up
> and down the buffer a lot.  AFAICS it's really important to have O(log
> N) worst-case behavior.
>   
> Sorry I can't be much more precise about why this happens, I just know
> that our algorithms that deal with extents (which we use to support
> overlay-like behavior and text properties) are tuned for good locality
> and lose badly in large buffers; they show up as time hogs in profiling.
>
>   

I looked at (an old version of?) the XEmacs internals manual.

It says extents are implemented as a pair of gap buffers.  It also talks
about the concept of cached stacks of events -- e.g., a cache
of the list of extents at a given point from which the extents over
a nearby point can be quickly computed.

I don't know if that's current.

The gap buffer and extent-stack cache would fit your
description of "optimized for locality" and would exhibit
the (performance) failure mode you describe under
access patterns about like you describe ("[running] up and down
the buffer").   In that access pattern, you're frequently
moving lots of data across the gap and if you're jumping around
at all during this traversal then you're constantly getting
cache misses or unwanted cache hits for the extent stack.

The splay tree of gap buffers should do considerably better
with those access patterns.  That's the theory, anyway:

The new data structure has an operation equivalent
to "move the gap" (so, e.g., insertions just write to
a linear piece of memory) however gap motion
is O(log N) buffer size in terms of operations and
O(1) for the amount of text that has to move.  Marker
updates, getting the position of a marker, and getting
back a list of text properties over a given point are all
O(log N) -- O(1) with good locality.

When I say "locality" I'm using that more loosely than
it is used when talking about ordinary gap buffers.
With ordinary gap buffers, the optimized case is a
lot of action near one point at a buffer, then an
infrequent motion far away, then lots of closely
placed action.    When I say "locality" I mean to
include (a) cases where the action at a given time
forms a dense set, even if that set is scattered;  (b)
linear access patterns.     By "dense set" I mean that
programs can be simultaneously modifying, say,
5 widely separated areas of the buffer in a multiplexed
way -- every modification is probably close to a recent
modification (so the set is dense) but every modification
is also probably far from the *most* recent modification
(so the set is scattered).  By "linear access" I mean cases
where code is scanning forwards or backwards.



> It's possible it's something internal to the implementation of
> extents, too, but I think a word to the wise is appropriate here.
>   

If extents are still the double gap buffer + extent stack
cache then I can see where you'd have problems like those
you describe.   In theory, this new thing does better in
those cases.

Thanks,
-t

Re: Release plans

[Stephen J. Turnbull]

Thomas Lord writes:

 > It says extents are implemented as a pair of gap buffers.

Well, yes and no.  The extent lists used by redisplay are implemented
as a pair of gap buffers; this allows O(log N) -- where N is always
the number of objects (here, extents) -- identification of the
display-order-maximal extent containing a buffer location, and also is
the correct order for redisplay to process extents so that redisplay
of an Emacs window can be O(number of buffer characters visible in
window).

However, extents themselves are full-fledged Lisp objects allocated on
the heap, and that is where position information is kept.  And it
turns out that in many common cases finding a particular extent is
O(N) (consider the case where the desired extent happens to cover the
whole buffer and the location is (point-max), while any extent *could*
have the desired property).

How does your splay tree scheme handle that?

 > It also talks about the concept of cached stacks of events -- e.g.,
 > a cache of the list of extents at a given point from which the
 > extents over a nearby point can be quickly computed.

With the caveat above, this is the current scheme.

 > The splay tree of gap buffers should do considerably better with
 > [the] access patterns [Steve described].  That's the theory,
 > anyway:

OK.

 > The new data structure has an operation equivalent
 > to "move the gap" (so, e.g., insertions just write to
 > a linear piece of memory) however gap motion
 > is O(log N) buffer size in terms of operations and
 > O(1) for the amount of text that has to move.  Marker
 > updates, getting the position of a marker, and

Urk.  Markers are not interesting AFAICS.  What needs to be efficient
is extents (whether text properties or overlays), because they carry
display properties and other things that may be referenced many times
in a pass over the buffer (eg, font-lock or building a parse tree).
What is difficult (for me, anyway) is extents.

 > getting back a list of text properties over a given point are all
 > O(log N) -- O(1) with good locality.

This last I'll want to see.  I suspect it will be expensive in space.

 > If extents are still the double gap buffer + extent stack
 > cache then I can see where you'd have problems like those
 > you describe.   In theory, this new thing does better in
 > those cases.

Well, we'll see.  I've found it quite easy to develop O(log N)
algorithms for markers.  But (except for redisplay, where the
two-sorted-list scheme is great), common operations on extents can
involve O(N) algorithms.

Re: Release plans

[Lennart Borgman (gmail)]

Thomas Lord wrote:
> Consider a feature, X, which is desirable for practical purposes.
> 
> Consider a feature, Y, which is banned.
> 
> If the ban on Y makes X harder to implement, in the sense
> of costing more in labor or money, then the economic incentive
> to go into business selling a non-free implementation of X goes
> up.
> 
> The reason that incentive goes up is because the cost of
> going into business selling a non-free X goes up while the
> demand for the practically useful X remains steady.
> 
> Now, someone with some money that they want to spend
> writing new, non-free software looks at that and says
> "I think I can do X, in spite of the ban on Y.  In fact,
> given the work I did on my masters thesis, I think I can do
> X cheaper than most people.   If I start selling a non-free X,
> it will be a long time before some competitor comes along
> either selling a non-free competitor to X or sharing a free
> version of X.  It will be a long time because I'm almost the only one
> with an effective idea of how to get around the ban on Y.
> Therefore, I'll go into business selling proprietary X and count
> my blessings for the banning of Y."


Are you sure that reasoning is valid as an argument here? There will for
example, as you even hint, be different economic incentives for
different people.

Re: Release plans

[Thomas Lord]

Lennart Borgman (gmail) wrote:
> Thomas Lord wrote:
>   
>> Consider a feature, X, which is desirable for practical purposes.
>>
>> Consider a feature, Y, which is banned. [....]
>>
>>     
>
> Are you sure that reasoning is valid as an argument here? There will for
> example, as you even hint, be different economic incentives for
> different people.
>
>   


Yes, I've seen it happen.

There are different incentives for different people, that's right.
So, the guy that goes into business selling non-free X because
he did a masters thesis that made it uniquely easy for him to
implement X -- THAT GUY --  that guy is the main (type of)
guy around whom start-ups are formed.

That unique advantage for "that guy" is only half of what makes
the business, though.   The other two halves are that other people
will find other things easier to do than implement X and that other
people want X.

The "hat trick" -- the perfect three points for a non-free software
start-up -- are:  (1) a program X that it is easy for me to write;  (2)
where X is hard for YOU to write;  (3) and people want X for
practical purposes.

"That guy" for whom X is easy is rare but, in a sufficiently
large crowd, he is practically guaranteed to exist: so (1) is
almost a free point.  

There are a lot of possible values of X that people might want so
(3) is practically a free point.

The only touch bit is (2):  X has to be hard for (most) *other*
people to write.   And that's where the questions about banning
feature Y come in.    Banning Y can only help "that guy" with (2).

You should see how the industry of deep packet inspection appliance
vendors has unfolded, for example.   It is exactly this pattern of
start-ups and non-free software.

You can also do the thought experiment of imagining an (unachievable)
world in which any program you could possibly want was, somehow,
cheap and easy to write.   Non-free software business models would not
thrive in such a world, not like they do now (mostly).

We can't every perfectly get to that world but we can get a lot closer
than we are -- and feature bans are a retreat from that objective.

-t

Re: Release plans

[Lennart Borgman (gmail)]

Thomas Lord wrote:
> Lennart Borgman (gmail) wrote:
>> Thomas Lord wrote:
>>  
>>> Consider a feature, X, which is desirable for practical purposes.
>>>
>>> Consider a feature, Y, which is banned. [....]
>>>
>>>     
>>
>> Are you sure that reasoning is valid as an argument here? There will for
>> example, as you even hint, be different economic incentives for
>> different people.
>>
>>   
> 
> 
> Yes, I've seen it happen.

Sure.

> The "hat trick" -- the perfect three points for a non-free software
> start-up -- are:  (1) a program X that it is easy for me to write;  (2)
> where X is hard for YOU to write;  (3) and people want X for
> practical purposes.
> 
> "That guy" for whom X is easy is rare but, in a sufficiently
> large crowd, he is practically guaranteed to exist: so (1) is
> almost a free point. 

And of course it is also guaranteed that there are quite a few in the
group (1) ...

> There are a lot of possible values of X that people might want so
> (3) is practically a free point.

Don't you have to have buyers too?

That is a pretty important point in my opinion since actually
implementing and polishing an idea so that it meets the end user is
quite labor intensive. And this point may change the scene quite a lot.

> The only touch bit is (2):  X has to be hard for (most) *other*
> people to write.   And that's where the questions about banning
> feature Y come in.    Banning Y can only help "that guy" with (2).

Perhaps you are right, but I am not sure. More specific examples might help.

However looking at the economic incentives and possibilities is
necessary and good. One way I have often wondered about is trying to
raise money from governements for developing free software. They are
probably large enough to directly benefit from it (in cost benefit
terms) if suitable projects can be found.

But then there must be people who are willing and able to write
attractive software for them.

> You can also do the thought experiment of imagining an (unachievable)
> world in which any program you could possibly want was, somehow,
> cheap and easy to write.   Non-free software business models would not
> thrive in such a world, not like they do now (mostly).

I am not sure. The overall picture have to be taken into account. (That
is part of the nature of power. It happens because it takes things into
account - in perhaps an unconscious way.)

> We can't every perfectly get to that world but we can get a lot closer
> than we are -- and feature bans are a retreat from that objective.
> 
> -t
> 
> 
> 

Re: Release plans

[joakim]

"Richard M. Stallman" <rms@gnu.org> writes:

> The decision on whether to include a dynamic linker in Emacs
> does not directly affect users' freedom.  (It doesn't change the license.)
> What is affects is which changes we facilitate and which changes we don't.
>
> The case of XRefactory and its harmful effects on CEDET illustrate the
> kind of harm I'm trying to avoid.  It also shows that we cannot
> totally avoid such problems.  But opening a convenient door for making
> them is likely to mean more of them.  I want to have less of them.

I would like to add two things I find missing from this discussion.

- Things can change over time
- People can change over time with helpful education

I had trouble understanding the dynamic linker ban ten years ago, but I
now understand the relevance of it at the time. I've learned something
from this.

Today I would claim that limiting Emacs technical abilities hurts Emacs
ability to be used as an educational tool for the value of software
freedom. I claim this because I belive people need somewhere acessible
to start learning.

When I started using Emacs it was because of its technical merits. It
was available on all the proprietary platforms I used. Only later did I
discover the value of freedom, and Emacs helped me with this.

Emacs still has great technical merit of course, but its not imediately
obvious to newcommers. In order to make it more obvious, heres a short
list of things I think would help:

- Merge CEDET, and improve it so great IDE functionality can be had
  fairly easily
- Merge ECB so IDE like code browsing tools becomes available
- Make it possible to write more beautiful elisp. I'm not a lisp expert
  but even I find it painful that writing recursive functions is made
  hard due to the lack of tail-optimization. It should be fun to code
  elisp.
- provide different levels of chrome out of the box. One skin would be
  bling-bling with all facilities enabled, transparent windows etc, and
  another one would be monk mode with nearly nothing.



-- 
Joakim Verona

Re: Release plans

[Richard M. Stallman]

    - Merge CEDET, and improve it so great IDE functionality can be had
      fairly easily
    - Merge ECB so IDE like code browsing tools becomes available

I am in favor of these goals.

    - Make it possible to write more beautiful elisp. I'm not a lisp expert
      but even I find it painful that writing recursive functions is made
      hard due to the lack of tail-optimization. It should be fun to code
      elisp.

Yes and no.  To make tail-recursion work would be nice.
However, USING it in the code of Emacs could be a bad thing,
because it often makes the code harder to understand.
All in all, it is better to write a loop.

    - provide different levels of chrome out of the box. One skin would be
      bling-bling with all facilities enabled, transparent windows etc, and
      another one would be monk mode with nearly nothing.

I am for it if users like it.

Re: Release plans

[Alan Mackenzie]

Hi, Stephen,

On Tue, Aug 19, 2008 at 06:46:22PM +0900, Stephen J. Turnbull wrote:

> But Alan, I have accepted your principles, except the one that says
> anything you can imagine is probable enough to worry about.

> And unfortunately, I can't challenge your arguments because you
> haven't posted one .....

What, exactly, are we getting so worked up about, then?

> .... (except that fallacious argument from the authority of Richard
> Stallman).

That's a mischaracterisation of what I've said.  I respect his opinion
not because of his "authority", but because of his experience of the
murky place where legality, politics, and software meet, and my own near
total lack of it.

> You have only posted assertions.  I grant the conceptual possibility
> that you assert, but I deny its importance.

OK, thanks!

> I claim it is both extremely unlikely to come to pass, and that we can
> deal with the process of it arising in other ways.  And I've supported
> both claims with concrete technical details and policy proposals.

>  > This is where we differ.  A plane crash hurts not just the people on
>  > board, but the people the wreckage falls on.  Think of Lockerbie in 1988.

> I guess I should deduce that you are in favor of closing airports so
> that planes will stop falling out of the sky on innocent people?  The
> analogy is quite exact, you see.

Now who's drawing wild conclusions?

>  > The fallout will hit you.  That proprietary module will gunge up
>  > Emacs development, damage Emacs's reputation, cause sysadmins to
>  > hate it (they must field the rage from hackers) just as that
>  > aeroplane devastated a street in Lockerbie.

> I really don't see it.  Emacs developers won't touch the module,
> requests for support will be directed to the vendor, and surely
> vandalism/netrage by hackers is not to be attributed to Emacs but
> rather to the hackers themselves.

In a nice rational world that might be the case.  In the world we know,
it'd be "Emacs = hassle = problems, let's just ditch it."

> What damage to Emacs's reputation do you envision?

It's reputation for being a highly effective reliable working program
which causes trouble neither for its users nor sysadmins.

>  > Again, I'm thinking about the Community's freedom, not just yours as an
>  > isolated individual.

> I object to your implication that I care only about myself.

OK.  I got this notion from what you have written in your posts, see
below.

>  > I think I've made it clear that my "nightmares", as you call them,
>  > are not positions I'm defending.  I put them forward only as a
>  > counter (mainly) to Tom and to you, to show that bad things are
>  > possible, even if not probable.

> Bad things are possible.  Stipulated.  As with closing airports to
> prevent mid-flight crashes, some policies to ameliorate the possible
> bad things are stupid; there are better ways to deal with them.

Right.  So do you agree the present issue is a matter of analysis and
judgement, weighing up risks and benefits?  For example, it is (or used
to be) sensible to close airports during thick fog.

> I think GNU's refusal to allow dynamic loading in Emacs is such a
> stupid policy, because there are better ways to address potential
> problems.

That is clear.

>  > The analysis from you and Tom falls short of mathematical
>  > perfection.  Unless I'm mistaken, it focusses purely on the effects
>  > it would have on knowledgeable automous hackers.

> I don't speak for Tom, but my analysis falls short of perfection.  As
> I say, you should apply such standard to yourself, as well.

> And you are mistaken.  My analysis focusses purely on the *lack* of
> freedom-destroying effects for *anybody*.  Once we have some effects
> to talk about, I'll worry about whose ox is getting gored.

A little while ago, I opined that it is more important to be free than to
be aware of that freedom.  I don't think your analysis has covered those
Emacs users who are free by virtue of that use, but are unaware of it.
They could lose freedom, possibly without realising it, if any of the Bad
Things we're talking about happen.

>  > I think we differ because our axioms differ.

> I think we differ because I've gone beyond axioms to offer concrete
> analysis, and you haven't.

>  > You and T regard only the freedom of the informed automous hacker
>  > as important.

> I am very offended.  I could not have imagined that you would stoop so
> low.

That wasn't intended to offend, and I'm sorry it did.  I was trying to
get some sort of handle on why two highly intelligent, normally genial,
hackers, are having such a bad tempered exchange.  Please consider this
extract from your email in this thread:
    
    Message-ID: <878wuw7wji.fsf@uwakimon.sk.tsukuba.ac.jp>
    Date: Sun, 17 Aug 2008 01:29:53 +0900

    Richard M. Stallman writes:

     >     How does not providing dynamic loading maximize what users can
     >     do while remaining free?
     >
     > It protects against the danger of non-free C-level add-ons to
     > Emacs.

Stephen: All a freedom-lover has to do to avoid those non-free add-ons is ...
     avoid them.

Further, in your post before your last one, you wrote:

Stephen: I mean for starters, the GPL guarantees that Emacs remains free.
     So people can just say no and keep their personal freedom.


That sentence "All a freedom-lover has to do ...." suggested to me that
you only considered the effect on "freedom-lovers" (what I called
"informed autonomous hackers") important.  The sentence "So people can
just say no and keep their personal freedom." reinforces this impression,
in that it disregards those who can't just say no.  I think Richard was
concerned about protecting users who would be less able to avoid non-free
add-ons, for whatever reason.

These sentences of yours still suggest to me that you don't regard the
freedom of the non-informed, or non-autonomous hacker with very much
importance.  Please comment on this.

>  > I (and possibly RMS) see freedom for the entire community as
>  > important.  I think my hypothetical bad case ("microsoft8.dll") from
>  > last night made that clear.  That such could be imposed on others is
>  > a bad thing for me.

> I claim it cannot be imposed.  Please rebut.

I can't, at least, not at the level I think you want.  It would need more
expertise on and more interest in things like licensing, copyright, ...
than I've got.  Anyhow, I'm not the person that needs to be persuaded.

>  > Should a non-free Emacs become widely installed ("established"), say
>  > GNU Emacs hobbled by the "microsoft8.dll" I pictured last night, a
>  > newer version of Emacs is unlikely to cause the number of
>  > installations of that un-free version to fall rapidly to near zero
>  > (i.e., become "disestablished").

> Depends on what you mean by "rapidly".  Overnight?  No.  In two or
> three years?  Yes, I think that can be done, and that's fast enough.

I don't think it could.

>  > For the third time, our basic axioms seem to differ.

> They do.  However, for the sake of this discussion, I've adopted
> yours.  Except for the axiom that "dynamic loading leads to unfree
> Emacs", which I consider a proposition to be proved or disproved.

The bit I think you're neglecting is the free "for whom?".

>  > I don't think you see the point I'm making, and your analysis is
>  > oblivious to that point, so I disregard it.  Maybe.

> No.  I understand your point.  "Introducing a module loader could
> cause Emacs to become non-free."  That's scary.

Again, non-free "for whom?".  If you'ld've made specific reference to
people who couldn't or wouldn't take action against non-free add ons
themselves, I'd accept you'd understood my point.

> In the light of day, though, I don't believe it's going to happen.

I don't think it would happen either, for what it's worth.  

> OTOH, I do know that benefits (so far of modest size) will certainly
> happen.  For example, you're the same Alan Mackenzie who's been annoyed
> by the Emacs build process recently, right?  Wouldn't it be nice if you
> could just disable the broken feature you don't like, or even just not
> build that module and use yesterday's build of the module with today's
> core?  How about if you are developing new C code, and can change and
> reinitialize it in your running Emacs with a turnaround of about 5
> seconds on a reasonable machine?

Yes, it would indeed be nice.  If Emacs had been structured more
modularly, this would be easy.

>  > In my post last night, I drew a picture of Emacs running on a future
>  > MS OS, where in order to get access to its file system, you had to
>  > install the proprietary library "microsoft8.dll".  This would have
>  > the side-effect, on the pretext of "security", of disabling `defun'

> I can't find anything about disabling `defun', and that's not
> plausible anyway.

The sentence fragment ".... only allowing digitally signed LISP or binary
libraries to be COMPILED or loaded."  But that's not important.  The fact
is, a loaded binary module could disable any part of the Lisp
infrastructure.  It's a mere technical problem, not even that difficult.

> ..... the FSF would have no problem getting a subpoena for Microsoft's
> source code if it was at all compatible.

Maybe, maybe not.  Who wants to go there?  What would happen to Emacs in
the years the court case would drag over?

>  > and only allowing signed (by MS) Lisp libraries to be loaded.

> Again, the technical difficulties of accomplishing this in GNU Emacs
> are enormous.

Really?  A few defadvices in the right (wrong?) place would do the trick.

> Remember, GNU Emacs's security features were designed by the guy who
> posted his password for somebody else's system in a public place.

What was somebody saying about ad hominem attacks not all that long ago?

> How could that be imposed?

I don't think the module I depicted, microsoft8.dll, could be imposed.
It is just too extreme, too blatant.  A more subtle, insidious spoiler
module might be imposable.

>  > > I mean for starters, the GPL guarantees that Emacs remains free.
>  > > So people can just say no and keep their personal freedom.

>  > Oh, so GPL's "guarantees" mean that everything's fine, and so we
>  > don't need to worry about anything.

> What do you think "for starters" means?

It's a colloquial expression which means, anywhere I've lived, something
like "I have a number points I could make, any one of which will refute
your point, so I am going mention just one of them, in the hope you'll
not be so abstruse as to carry on a long fruitless argument which you'd
lose anyway.".

> It's not a complete argument, but you really do have to answer it since
> you have claimed that Emacs itself would become non-free.  In the case
> of microsoft8.dll, the user still has the source, they still have the
> right to redistribute Emacs, etc.  So how has Emacs become non-free?

Without the mischief module they can't access their files, since the OS
puts some sort of lock on the file system.  That module prevents any Lisp
code other than the standard distribution libraries from being compiled
or loaded, and will itself only run in an unmodified Emacs.  Emacs has
now become non-free for those users on that system.

> Even if the DLL is loaded in site-start, you can disable that.  (Well,
> I can, in XEmacs.)

Sure, assuming that the --no-site-start flag isn't removed from Emacs
(which anyone is free to do).

>  > > Should we remove process support from Emacs?

>  > No.  My question to you: what can an intimately linked binary module
>  > achieve that calling something as a separate process couldn't?

> Reload a patched C object into a running Emacs.

> Manipulate Emacs data structures, and provide new ones.

> Very little that a separate process can't, but it can do everything a
> lot faster.

>  > Linking to external binaries has been in XEmacs for some while.
>  > What have people done with it?  Could they have done the same by
>  > calling an external program via an OS call?

> Look in the modules directory of XEmacs.  In the case of the Canna
> module, no such command exists, so you need to link to Canna.
> Although there's also a network protocol so you could use just Lisp.

>  > Up to now, you and Tom have been asserting that calling external
>  > binaries is critically important and very useful.

> No, I haven't.  I've simply said I don't see enough risk, even given
> the nightmarish consequences you envision, to outweigh the benefits I
> see.

OK.  I think the benefits are moderate rather than profound.  David K.
mentioned the Lilypond info pages having images, and how it would be
helpful dynamically to load image libraries for them.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Stephen J. Turnbull]

Alan Mackenzie writes:

 > What, exactly, are we getting so worked up about, then?

Well, I've been perplexed by the "no dynamic loading" policy for about
a decade now.  I know that Richard is not going to give an answer
except that he's fearful, uncertain, and doubtful about dynamic
loading, and so has decided to avoid it.  I was hoping you might
provide some insight, but you're giving me the same line.  I'm very
frustrated by that.

 > Right.  So do you agree the present issue is a matter of analysis and
 > judgement, weighing up risks and benefits?

Of course I do.  I see small benefits (measured in terms of freedom,
as I understand it) and much smaller risks (ditto).  That's precisely
what I've been arguing all along, but you and Richard assert that
*any* risk is too large.

 > > No.  I understand your point.  "Introducing a module loader could
 > > cause Emacs to become non-free."  That's scary.
 > 
 > Again, non-free "for whom?".  If you'ld've made specific reference to
 > people who couldn't or wouldn't take action against non-free add ons
 > themselves, I'd accept you'd understood my point.

I don't think there are *any* people who *couldn't* take action[1],
and I don't understand why "wouldn't" is a problem in the context of
freedom.  There are two kinds of people who wouldn't, those who have
considered the consequences and decided they don't care, and those who
just don't care.  Either way, why isn't it their place to decide, and
our place to provide them with the information they need to make
informed judgments?

And I still don't see how they "lose" freedom or Emacs becomes unfree.
In the first place, they *gain* capabilities that they did not have
before.  True, those capabilities do not come with the four freedoms
attached, but what have they "lost"?  In the second, Emacs itself is
still free, the users have the four freedoms with respect to it.

 > >  > and only allowing signed (by MS) Lisp libraries to be loaded.
 > 
 > > Again, the technical difficulties of accomplishing this in GNU Emacs
 > > are enormous.
 > 
 > Really?  A few defadvices in the right (wrong?) place would do the trick.

(ad-stop-advice)

It really is not that easy.  And yes, since it's supposed to be a
security feature, you do have to deal with savvy users like me who
would be able to handle a defadvice of ad-stop-advice.  The whole
thing would get blown out of the water with a million CERT reports.

 > > Remember, GNU Emacs's security features were designed by the guy who
 > > posted his password for somebody else's system in a public place.
 > 
 > What was somebody saying about ad hominem attacks not all that long ago?

It's not really an ad hominem.  It's an *allusion*, to the fact that
*by design* Emacs has no security features, except to protect itself
from crashing, and a little bit for protecting passwords (but a couple
of defadvices would defeat that, too).


Footnotes: 
[1]  At least, they have other, much more dire problems, as Richard
has been at pains to point out to you.  You *can* be free, you just
don't want to badly enough.

Re: Release plans

[Alan Mackenzie]

Hi, Stephen!

On Mon, Aug 25, 2008 at 11:39:16PM +0900, Stephen J. Turnbull wrote:
> Alan Mackenzie writes:

>  > What, exactly, are we getting so worked up about, then?

> Well, I've been perplexed by the "no dynamic loading" policy for about
> a decade now.  I know that Richard is not going to give an answer
> except that he's fearful, uncertain, and doubtful about dynamic
> loading, and so has decided to avoid it.  I was hoping you might
> provide some insight, but you're giving me the same line.  I'm very
> frustrated by that.

Sorry.  The thing is, we're at the place where free software principles
become ironic, inconsistent and contradictory, even absurd.  Every
half-decent religion or philosopy, even science and maths, has suchlike,
so why should we expect free software to be any different?

Yes, we want software to be free, but no, we don't want people to use
this freedom in certain ways, ways which would inhibit the progress of
free software.  Something's got to give.  In a democracy, sometimes
people get elected who want to dismantle the democracy.  So you have a
constitution to protect it, and this usually works.  In maths, there is
the Axiom of Choice (which is obviously true) and Zorn's Lemma (which is
patently absurd), yet the two are logically equivalent.  Mathematicians
are fairly relaxed about absurdities and joke about them over an
afternoon cup of tea.

The "resolution" in free software is to soft-pedal, to hope that nobody
does anything too unfree, and to avoid giving them too much help and
encouragement.  A bit like politics, really.  So whilst making dynamic
modules part of "official" Emacs might not change what is possible, it
might well encourage what is legitimate, yet we don't want to happen;
it's a kind of touchy-feely thing.  That's my understanding, anyway - I
could be totally wrong.  On the particular issue of dynamic modules, I
don't feel I have the experience to judge the conflicting issues, so I
defer to Richard's.  I'm not sure what would happen if we made dynamic
loading a first-class feature, documented in the Elisp manual and NEWS,
as opposed to being downloadable in some obscure patch, not supported by
the main maintainers, assuming you've even heard of it.

Eric Ludlam mentioned a product called Xrefactory a couple of days ago.
It seems to be a refactoring tool based upon (X)Emacs.  Yes, this is
legitimate within the terms of the GPL, but isn't the sort of thing we
really want to encourage; it's not free, neither in the speech nor beer
sense.

[ .... ]

>  > > No.  I understand your point.  "Introducing a module loader could
>  > > cause Emacs to become non-free."  That's scary.

>  > Again, non-free "for whom?".  If you'ld've made specific reference to
>  > people who couldn't or wouldn't take action against non-free add ons
>  > themselves, I'd accept you'd understood my point.

> I don't think there are *any* people who *couldn't* take action[1],
> and I don't understand why "wouldn't" is a problem in the context of
> freedom.  There are two kinds of people who wouldn't, those who have
> considered the consequences and decided they don't care, and those who
> just don't care.  Either way, why isn't it their place to decide, and
> our place to provide them with the information they need to make
> informed judgments?

I think our basic philosophies just differ here.  I appreciate living in
a "free" society, yet if Nuremberg were once again subject to a military
invasion, would I accept a rifle and be willing to use it?  Probably not.
I gladly accept the freedom guaranteed by professional soldiers.  Just as
those soldiers protect those "who don't give a damn", I feel we should
protect the (software) freedom of those who, for whatever reason,
wouldn't protect their own.

> And I still don't see how they "lose" freedom or Emacs becomes unfree.
> In the first place, they *gain* capabilities that they did not have
> before.  True, those capabilities do not come with the four freedoms
> attached, but what have they "lost"?  In the second, Emacs itself is
> still free, the users have the four freedoms with respect to it.

Again, with Eric's example of Xrefactory, any hackers who buy that
product and incorporate it into their development process thereby lose
some of their freedom - their process has become tied to a product they
can't control - to some extent.  This is another one of these
contradictions about software freedom - by exercising freedom you
diminish it.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Lennart Borgman (gmail)]

Alan Mackenzie wrote:
> constitution to protect it, and this usually works.  In maths, there is
> the Axiom of Choice (which is obviously true) and Zorn's Lemma (which is
> patently absurd), yet the two are logically equivalent.  Mathematicians
> are fairly relaxed about absurdities and joke about them over an
> afternoon cup of tea.

No math please, that takes too much time ;-)

> Again, with Eric's example of Xrefactory, any hackers who buy that
> product and incorporate it into their development process thereby lose
> some of their freedom - their process has become tied to a product they
> can't control - to some extent.  This is another one of these
> contradictions about software freedom - by exercising freedom you
> diminish it.

I am not sure that conclusion is valid. You can think

"Ah, why should people have to buy that sort of software? Everyone can't
do that! I will write a free version of this! Hope someone else will
join ..."

Is not that what often happens?

Re: Release plans

[Stephen J. Turnbull]

Alan Mackenzie writes:

 > Yes, we want software to be free, but no, we don't want people to
 > use this freedom in certain ways, ways which would inhibit the
 > progress of free software.

I'm not sure I agree with this formulation, but it's not what I'm
talking about in this thread.

I'm talking about a specific decision which is based not on observing
people misusing freedom, not on the likelihood of people misusing
freedom in foreseeable ways, but rather on the conceptual possibility
that in some as-yet unforeseeable way somehow someday somebody might
possibly misuse freedom to a disastrous end.  Granted, Richard points
out that Linux did have problems with binary modules, but, um, the
result is egg on NVIDIA's face and in ATI's beer, and Linus explicitly
was neutral on the practice.  As Richard is wont to say about patents
and copyright, the cases are completely different and shouldn't be
grouped together.

 > Eric Ludlam mentioned a product called Xrefactory a couple of days
 > ago.  It seems to be a refactoring tool based upon (X)Emacs.  Yes,
 > this is legitimate within the terms of the GPL, but isn't the sort
 > of thing we really want to encourage; it's not free, neither in the
 > speech nor beer sense.

The reductio is obvious, isn't it?  Since any free software program
can be abused as part of a non-free software product, we should stop
all distribution of free software to the heathen.  That way we can be
sure of providing the minimum encouragement to abuse freedom.

Personally, I agree with Tom: we should be going all-out to encourage
use of free software, using three main tactics: (1) emphasizing the
importance of software freedom (eg, from a code-is-law basis), (2)
emphasizing the costs both in freedom and economic value of non-free
software, and (3) providing kick-ass software that everybody wants to
use.

Effectively discouraging non-free software is out of our control.
"Mr. Quixote, meet Mr. Windmill...."

 > I gladly accept the freedom guaranteed by professional soldiers.  Just as
 > those soldiers protect those "who don't give a damn", I feel we should
 > protect the (software) freedom of those who, for whatever reason,
 > wouldn't protect their own.

At the cost of the freedom of those who would *like* to use unfree
software: they have done the calculation on the costs of lock-in, and
like the answers they got.  I find your paternalism distasteful.

 > Again, with Eric's example of Xrefactory, any hackers who buy that
 > product and incorporate it into their development process thereby lose
 > some of their freedom - their process has become tied to a product they
 > can't control - to some extent.  This is another one of these
 > contradictions about software freedom - by exercising freedom you
 > diminish it.

This paradox has *nothing whatsoever* to do with software.  Freedom
means choice.  If everybody is free, everybody is making choices, and
this *imposes* uncertainty about those choices on others.  People
*dislike* uncertainty (eg, about when you're next going to have sex)
and so they *accept* constraints (marriage, to continue the metaphor).[1]

Some people are willing to accept the constraints of unfree software
constrained for commercial advantage.  Some people hate unfree
software so much that they impose constraints on the use of their
software by others, and claim that the net result is somehow an
increase in freedom when in fact there is a clear decrease in options
available to users.  I don't really see an ethical difference here.

Footnotes: 
[1]  Before you ask, and I have every reason to believe you will: No,
I do not believe that more regular sex is the only or even the main
reason people get married, nor do I believe that the strategy actually
works all that well.  I will assert that many of the reasons for
getting married do take the same form of a voluntary exchange of one's
own freedom for a commitment to stability from the partner.

Re: Release plans

[Alan Mackenzie]

Hi, Stephen,

On Tue, Aug 26, 2008 at 01:54:15PM +0900, Stephen J. Turnbull wrote:
> Alan Mackenzie writes:

>  > Yes, we want software to be free, but no, we don't want people to
>  > use this freedom in certain ways, ways which would inhibit the
>  > progress of free software.

> I'm not sure I agree with this formulation, but it's not what I'm
> talking about in this thread.

I think it is.  I think it's the abstract principle behind RMS's decision
not to put a binary module loader in Emacs.

If you don't like my formulation, how about reformulating it your own
way?

> I'm talking about a specific decision which is based not on observing
> people misusing freedom, not on the likelihood of people misusing
> freedom in foreseeable ways, but rather on the conceptual possibility
> that in some as-yet unforeseeable way somehow someday somebody might
> possibly misuse freedom to a disastrous end.

You might be right there.  Such a "conceptual possibility" existed wrt
patents in GPL2.  Microsoft and Novell exploited it to give special
"patent protection" (against unspecified MS patents) to direct Novell
customers only, in gross violation of the ideals of the GPL.  Rather
clumsily, they pulled the stunt as GPL3 was being developed.  I think
it's right to be very wary about exposing possible vulnerabilities to
proprietary competitors.  They will be actively seeking weak points to
exploit.

[ .... ]

>  > Eric Ludlam mentioned a product called Xrefactory a couple of days
>  > ago.  It seems to be a refactoring tool based upon (X)Emacs.  Yes,
>  > this is legitimate within the terms of the GPL, but isn't the sort
>  > of thing we really want to encourage; it's not free, neither in the
>  > speech nor beer sense.

> The reductio is obvious, isn't it?  Since any free software program can
> be abused as part of a non-free software product, we should stop all
> distribution of free software to the heathen.  That way we can be sure
> of providing the minimum encouragement to abuse freedom.

No, not at all.  The absurdum is what I pointed out yesterday, not what
you've just written: we restrict freedom to protect it against being used
to destroy itself.

[ .... ]

> Effectively discouraging non-free software is out of our control.
> "Mr. Quixote, meet Mr. Windmill...."

It is not.  There are few non-free extensions to Emacs, at least that I
have heard of.  With a binary module loader, there might well be more.

>  > I gladly accept the freedom guaranteed by professional soldiers.
>  > Just as those soldiers protect those "who don't give a damn", I feel
>  > we should protect the (software) freedom of those who, for whatever
>  > reason, wouldn't protect their own.

> At the cost of the freedom of those who would *like* to use unfree
> software: they have done the calculation on the costs of lock-in, and
> like the answers they got.

Yes, this is down in the irony and contradictions department of free
software.  But as you've noted, the lock-in is largely psychological:
there's nothing in the GPL to prevent anybody extending Emacs pretty much
however they want, and that includes adding a binary module loader -
providing the loaded modules wouldn't get too intimate with Emacs itself.

> I find your paternalism distasteful.

Yes, I expected that and I've no problem with it.  Likewise, I find
aspects of your personal philosophy distasteful too.  I look on it as a
source of fruitful debate, far better than the near slanging match we
were having just a few days ago.

[ .... ]

> Some people are willing to accept the constraints of unfree software
> constrained for commercial advantage.  Some people hate unfree software
> so much that they impose constraints on the use of their software by
> others, and claim that the net result is somehow an increase in freedom
> when in fact there is a clear decrease in options available to users.
> I don't really see an ethical difference here.

I think you're right.  That is down in the irony/contradiction/absurdity
region again, where the ethics can't help but being murky.

A while ago, I was arguing that Emacs being available on w32 was a good
thing - not from any highly principled position, just for purely
pragmatic reasons.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Stephen J. Turnbull]

Alan Mackenzie writes:
 > Hi, Stephen,
 > 
 > On Tue, Aug 26, 2008 at 01:54:15PM +0900, Stephen J. Turnbull wrote:
 > > Alan Mackenzie writes:
 > 
 > >  > Yes, we want software to be free, but no, we don't want people to
 > >  > use this freedom in certain ways, ways which would inhibit the
 > >  > progress of free software.
 > 
 > > I'm not sure I agree with this formulation, but it's not what I'm
 > > talking about in this thread.
 > 
 > I think it is.  I think it's the abstract principle behind RMS's decision
 > not to put a binary module loader in Emacs.

Please don't tell me what I'm talking about.  Let me clarify: I don't
mean to disagree that it's the abstract principle behind the decision,
so it's not what I'm talking about.

 > If you don't like my formulation, how about reformulating it your own
 > way?

It's a different thread, and not relevant to Emacs at all, since I
don't contest your assertion that it is (part of) the basis for
decision.

 > > Effectively discouraging non-free software is out of our control.
 > > "Mr. Quixote, meet Mr. Windmill...."
 > 
 > It is not.  There are few non-free extensions to Emacs, at least that I
 > have heard of.

There are about a dozen of them that I've heard of (not illegal
because they are extensions to XEmacs used only internally to
corporations, the largest of which has about 500 users of the
corporate XEmacs), and there may be a few more when XEmacs converts to
GPLv3 (because some currently free extensions contain GPLv2-only code,
it will no longer be legal to distribute them).

 > With a binary module loader, there might well be more.

With a binary module loader, we might be able to develop them faster
and head off the proprietary versions---there might well be less.

 > >  > I gladly accept the freedom guaranteed by professional soldiers.
 > >  > Just as those soldiers protect those "who don't give a damn", I feel
 > >  > we should protect the (software) freedom of those who, for whatever
 > >  > reason, wouldn't protect their own.
 > 
 > > At the cost of the freedom of those who would *like* to use unfree
 > > software: they have done the calculation on the costs of lock-in, and
 > > like the answers they got.
 > 
 > Yes, this is down in the irony and contradictions department of free
 > software.  But as you've noted, the lock-in is largely
 > psychological:

Who's ignoring 6 billion people now?  Nothing in the GPL creates
lock-in, no, but 99.9999% of humanity doesn't have the skills!  So
they are locked in unless the market provides for them.

IMO, the free software distribution model offers very little to those
people in the way of hope that their needs will be met.  Jury's still
out, but I don't know any office-type users who prefer a working
Ubuntu to a working Windows.  Windows has more of the apps they want.
Some still choose the reliability etc of a GNU/Linux distro, but
they're painfully aware of being behind the curve in most application
areas.

Re: Release plans

[Alan Mackenzie]

Hi, Stephen,

On Wed, Aug 27, 2008 at 02:38:24PM +0900, Stephen J. Turnbull wrote:
> Alan Mackenzie writes:

>  > >  > Yes, we want software to be free, but no, we don't want people
>  > >  > to use this freedom in certain ways, ways which would inhibit
>  > >  > the progress of free software.

>  > > I'm not sure I agree with this formulation, but it's not what I'm
>  > > talking about in this thread.

>  > I think it is.  I think it's the abstract principle behind RMS's decision
>  > not to put a binary module loader in Emacs.

> Please don't tell me what I'm talking about.

Hey, I'm allowed to think, amn't I?  :-)

> Let me clarify: I don't mean to disagree that it's the abstract
> principle behind the decision, so it's not what I'm talking about.

>  > If you don't like my formulation, how about reformulating it your own
>  > way?

> It's a different thread, and not relevant to Emacs at all, since I
> don't contest your assertion that it is (part of) the basis for
> decision.

OK, thanks.

> There are about a dozen of them [non-free Emacs extensions] that I've
> heard of (not illegal because they are extensions to XEmacs used only
> internally to corporations, the largest of which has about 500 users of
> the corporate XEmacs), and there may be a few more when XEmacs converts
> to GPLv3 (because some currently free extensions contain GPLv2-only
> code, it will no longer be legal to distribute them).

"When" XEmacs -> GPL3?  I take it you've settled this, then.  By the way,
is there any way in the XEmacs website to get the history of individual
source files?  I couldn't find any when I looked today.

>  > With a binary module loader, there might well be more [non-free
>  > extensions to Emacs].

> With a binary module loader, we might be able to develop them faster
> and head off the proprietary versions---there might well be less.

Possibly.  But there's no way to test this safely.  It's got to be judged
by insight and guesswork.

[ .... ]

> Who's ignoring 6 billion people now?  Nothing in the GPL creates
> lock-in, no, but 99.9999% of humanity doesn't have the skills!  So
> they are locked in unless the market provides for them.

Look, Stephen, I've probably given you the impression over my last few
posts that I was merely winding you up, trolling you.  If so, I'm sorry
about that; everything I've written was sincerely meant.

However, I can't myself guarantee to be consistent in these essentially
contradictory things.  In fact, I'm as confused about them as most
people here, and that has probably shown.

Whom I take issue with is the people here who've insisted that the
immediate practical benefits of a dynamic loader are the only issues to
consider.  I don't feel qualified to judge the pros and cons of this
feature, but I do feel I'm ahead of those who don't even see there's
anything to judge.  No, not you!

And I take very grave exception to those who cast snide and unfounded
aspersions of evasiveness and deceit on the people who've put the work
in.  This isn't you either, but they know who they are.

> IMO, the free software distribution model offers very little to those
> people in the way of hope that their needs will be met.  Jury's still
> out, but I don't know any office-type users who prefer a working Ubuntu
> to a working Windows.  Windows has more of the apps they want.  Some
> still choose the reliability etc of a GNU/Linux distro, but they're
> painfully aware of being behind the curve in most application areas.

Yes.  Sadly.  At the moment.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Lennart Borgman (gmail)]

Alan Mackenzie wrote:
>> IMO, the free software distribution model offers very little to those
>> people in the way of hope that their needs will be met.  Jury's still
>> out, but I don't know any office-type users who prefer a working Ubuntu
>> to a working Windows.  Windows has more of the apps they want.  Some
>> still choose the reliability etc of a GNU/Linux distro, but they're
>> painfully aware of being behind the curve in most application areas.
> 
> Yes.  Sadly.  At the moment.

My impression is also that a consistent user interface matters a lot
because it makes it much easier to learn a new application.

Re: Release plans

[Sean Sieger]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

    My impression is also that a consistent user interface matters a lot
    because it makes it much easier to learn a new application.

Forgive me if I have misread your comment as comparative, but if I am on
the right track, the user interfaces of say Ubuntu GNU/Linux and its
office suite are no less consistent than those of Microsoft Windows XP
and its office suite---not in my limited experience.

Re: Release plans

[Stephen J. Turnbull]

Alan Mackenzie writes:

 > Hey, I'm allowed to think, amn't I?  :-)

Of course, but when it comes to what I'm talking about, please think
what I tell you to.[1]  :-)

 > "When" XEmacs -> GPL3?  I take it you've settled this, then.

We really don't have much choice, since most Lisp is maintained by
third parties, and Emacs is just 'nano' on steroids without all the
Lisp.  We've got some legal i's to dot and t's to cross, and we need
to think about how to deal with backward compatibility, which we care
about even though GNU does not.  But it's definitely coming.

 > By the way, is there any way in the XEmacs website to get the
 > history of individual source files?  I couldn't find any when I
 > looked today.

Not at the website per se, but there's ViewCVS at
http://cvs.xemacs.org/ for the packages and 21.4, and there's probably
a Mercurial equivalent at http://hg.debian.org/xemacs/ for 21.5.

 > > With a binary module loader, we might be able to develop them faster
 > > and head off the proprietary versions---there might well be less.
 > 
 > Possibly.  But there's no way to test this safely.  It's got to be judged
 > by insight and guesswork.

I disagree.  Watch XEmacs and SXEmacs.  The flag-carrying battleship
is safe, but there are a few cruisers out there engaged with the
opponent.

 > > Who's ignoring 6 billion people now?  Nothing in the GPL creates
 > > lock-in, no, but 99.9999% of humanity doesn't have the skills!  So
 > > they are locked in unless the market provides for them.
 > 
 > Look, Stephen, I've probably given you the impression over my last few
 > posts that I was merely winding you up, trolling you.

No, not at all.  And in any case it's surely mutual; at least on my
side there were quite incorrect expectations about what you know, and
have thought carefully about.

 > If so, I'm sorry about that; everything I've written was sincerely
 > meant.

No apology is needed.

 > > IMO, the free software distribution model offers very little to those
 > > people in the way of hope that their needs will be met.  Jury's still
 > > out, but I don't know any office-type users who prefer a working Ubuntu
 > > to a working Windows.  Windows has more of the apps they want.  Some
 > > still choose the reliability etc of a GNU/Linux distro, but they're
 > > painfully aware of being behind the curve in most application areas.
 > 
 > Yes.  Sadly.  At the moment.

Sadly, I think we are now at the point where we need to put a period.
We've come to agreement on the questions, but don't have answers that
satisfy all the relevant decision makers.

Yet.  See ya!

Footnotes: 
[1]  This is a reference to an actual response by a Japanese career
bureaucrat to a question at a press conference.  *I*'m not serious but
I couldn't resist, as I just arrived back here Through the Looking
Glass and am not *not* NOT enjoying the bureaucracy, although the food
is wonderful.

Re: Release plans

[Thien-Thi Nguyen]

() "Stephen J. Turnbull" <stephen@xemacs.org>
() Tue, 26 Aug 2008 13:54:15 +0900

   Some people hate unfree software so much that they impose
   constraints on the use of their software by others, and claim
   that the net result is somehow an increase in freedom when in
   fact there is a clear decrease in options available to users.

This characterization doesn't cleanly apply in this case; i'd like
to point out that the ban on the addition of dynamic loading to
Emacs is not an imposition on all Emacs users, only on those users
who hack Emacs and write to its repo.

All other users are not so constrained.

FWIW, i stand w/ the ban mostly due to personal ineptitude: i
can't imagine (though i've tried) any coroutine that could not be
supervised through a repl to a subprocess.  Moreover, i believe
everything useful moves to a network protocol eventually.  This
includes not just functionality, but methodology.  Now that DVCs
are on the rise, it's no big deal to flourish your Emacs without
having to "write to its repo".

thi

Re: Release plans

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Aug 27, 2008 at 05:57:14PM +0200, Thien-Thi Nguyen wrote:

[...]

> FWIW, i stand w/ the ban mostly due to personal ineptitude: i
> can't imagine (though i've tried) any coroutine that could not be
> supervised through a repl to a subprocess [...]

Just to tickle your imagination: envision an Emacs with a proper FFI:
browse (interactively) the entry points of a shared object (say,for
example libsndfile) and call them (interactively) from the repl...

Of course, you always can interpose gdb ;-)

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFItZ3oBcgs9XrR2kYRApaBAJ9rSwhwGeXzidrziubE54g0kgoV0QCfY3Jr
AfdPAROvG367fIG3x3EP3dE=
=Jmmi
-----END PGP SIGNATURE-----

Re: Release plans

[Stephen J. Turnbull]

tomas@tuxteam.de writes:

 > Just to tickle your imagination: envision an Emacs with a proper FFI:
 > browse (interactively) the entry points of a shared object (say,for
 > example libsndfile) and call them (interactively) from the repl...

Don't imagine it.  Look at it:  http://www.sxemacs.org/.

Re: Release plans

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Aug 28, 2008 at 03:09:17PM +0900, Stephen J. Turnbull wrote:
> tomas@tuxteam.de writes:
> 
>  > Just to tickle your imagination: envision an Emacs with a proper FFI:
[...]
> Don't imagine it.  Look at it:  http://www.sxemacs.org/.

Thanks for the pointer.

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFItl5iBcgs9XrR2kYRAkgYAJ90AHRxXZpIbHDS0G1PwYPhyc1EGgCfbhjC
nN1KTB7mS+P4QN4yCYyZaFw=
=+VOl
-----END PGP SIGNATURE-----

Re: Release plans

[Alan Mackenzie]

Good morning, Tomás!

On Wed, Aug 27, 2008 at 08:33:12PM +0200, tomas@tuxteam.de wrote:
> On Wed, Aug 27, 2008 at 05:57:14PM +0200, Thien-Thi Nguyen wrote:

> [...]

> > FWIW, i stand w/ the ban mostly due to personal ineptitude: i
> > can't imagine (though i've tried) any coroutine that could not be
> > supervised through a repl to a subprocess [...]

> Just to tickle your imagination: envision an Emacs with a proper FFI:
> browse (interactively) the entry points of a shared object (say,for
> example libsndfile) and call them (interactively) from the repl...

What's an FFI?

> Of course, you always can interpose gdb ;-)

Oh, good!

> Regards
> -- tomás

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Aug 28, 2008 at 07:25:04AM +0000, Alan Mackenzie wrote:
> Good morning, Tomás!

Good morning, Alan

> What's an FFI?

That's jargn for "foreign function interface". It's a natively
implemented dynamic loader (in our hypothetical case it would be
implemented in Emacs Lisp). The nice thing about that is that it's more
hackable -- you don't have to write a C library with your app in mind,
sticking to some protocol (think extending Perl or Python), but you
can attach to any existing library (provided you know its interface,
of course).

Another way to express it would be that the host language (Lisp)
"speaks" the platform's native protocol.

I think the term originates from the Lisp community, but I don't know
for sure.

> > Of course, you always can interpose gdb ;-)
> 
> Oh, good!

Now this would be a fun project (tongue-in-cheek ;-P

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFItmBuBcgs9XrR2kYRAt4lAJ92zxi91rFlH9emKQkEeqKgnBHGFwCfYV/Y
hIuUNRNLM0QgBDkNc1O/7q4=
=TNHO
-----END PGP SIGNATURE-----

Re: Release plans

[Stephen J. Turnbull]

Thien-Thi Nguyen writes:

 > This characterization doesn't cleanly apply in this case; i'd like
 > to point out that the ban on the addition of dynamic loading to
 > Emacs is not an imposition on all Emacs users, only on those users
 > who hack Emacs and write to its repo.

This is sufficiently important that Richard has devoted some thought
and an explicit ban to the problem.  If other users were similarly
problematic, I would suppose that he would have considered adding it
to the GPL, or so.

 > FWIW, i stand w/ the ban mostly due to personal ineptitude: i
 > can't imagine (though i've tried) any coroutine that could not be
 > supervised through a repl to a subprocess.  Moreover, i believe
 > everything useful moves to a network protocol eventually.

Thank you for making this point; it is true in my opinion, too.

However, I think of dynamic loading not as adding more features to
Emacs, but rather pushing features out of Emacs.  The modules I
personally work on at the moment are things like libcurl and neon,
which provide fast, robust access to network protocols, *maintained by
somebody else*.  I've also used them in the past (libcanna) to push
junky, hard-to-maintain, but popular, code out of core.

This strategy has been quite successful for Python.

 > This includes not just functionality, but methodology.  Now that
 > DVCs are on the rise, it's no big deal to flourish your Emacs
 > without having to "write to its repo".

True, but in the GNU Project it is considered anti-social to do that.
That is basically what Lucid did, and look at what that led to.

Re: Release plans

[Thomas Lord]

Stephen J. Turnbull wrote:
> Alan Mackenzie writes:
>
>  > The analysis from you and Tom falls short of mathematical perfection.
>  > Unless I'm mistaken, it focusses purely on the effects it would have on
>  > knowledgeable automous hackers.
>
> I don't speak for Tom, but my analysis falls short of perfection.  As
> I say, you should apply such standard to yourself, as well.
>   

My analysis falls short of perfection as well, but by the
perfect amount, of course.

Seriously, Alan is being kind of read-only here.   Nothing
I've said limits attention to only the "effects [...] on
knowledgeable [autonomous] hackers."




>  > You and T regard only the freedom of the informed automous hacker
>  > as important.
>
> I am very offended.  I could not have imagined that you would stoop so
> low.
>   

Moreover, neither of us has written anything that suggests
we even consider "informed autonomous hackers" as a special
case.




>  > I don't think you see the point I'm making, and your analysis is
>  > oblivious to that point, so I disregard it.  Maybe.
>
> No.  I understand your point.  "Introducing a module loader could
> cause Emacs to become non-free."  That's scary.
>
> In the light of day, though, I don't believe it's going to happen.
>   

For the record, where Stephen and I take different tacks is
that Stephen argues that scary outcome is improbable.   I don't
bother (since it ultimately is just speculation).   Rather, I'm willing
to assume (without proof, and although I believe it unlikely) that
non-free add-ons will appear and be popular.    That is still no
argument against the feature, which ought to be judged by what
*free software* it can give rise to.


>  > Tom, in his reply, simply failed to address this central issue of
>  > my post.  An apology, please.
>
> I'm not in a position to apologize on behalf of Tom.  
I repeatedly stipulated that, sure, let's assume the "worst case"
outcome is certain (although we don't have any good reason to
believe that, really).


>  > Up to now, you and Tom have been asserting that calling external binaries
>  > is critically important and very useful.
>
> No, I haven't. 

I've said that it can be, if well designed.   I like some of the
use ideas Stephen is putting forward.  

Other use ideas: 

Link in a DOM library and add new lisp types for
that.

Link in database clients (MySQL?,  DB XML, Exist, etc.).

Link in incremental parsers for various programming languages
(for syntax directed editing modes).

Link in various scripting language interpreters.

etc.

It could well be that GNU Emacs is essentially moribund
no matter what is done (dynamic loader or no).  I certainly
can't predict with certainty that a dynamic loader would
be used or for what.   On general principles and by analogy
to the history of other systems (e.g., Apache), dynamic loaders
do get used, in clever ways, and help turn a lot of separate
programs into a recombinant toolkit of components.   Meanwhile,
they don't complicate the internals of a program very much
at all and are easy to maintain.

The biggest drawbacks to them are:

a) It complicates bug report handling to have to always
ask "What versions of which add-ons did you have loaded?"

b) Creating a stable, portable, useful API requires some
thought and doing a poor job of it is probably worse than
not doing the job at all.

-t






>  I've simply said I don't see enough risk, even given
> the nightmarish consequences you envision, to outweigh the benefits I
> see.
>
>
>
>
>   

Re: Release plans

[Richard M. Stallman]

      I grant the
    conceptual possibility that you assert, but I deny its importance.  I
    claim it is both extremely unlikely to come to pass, and that we can
    deal with the process of it arising in other ways.

No one can tell for certain.  The only relevant fact is that the problem
scenario did indeed occur for Linux.  Whether it would happen with
Emacs, none of us can determine.  I have decided not to take the risk.

Re: Release plans

[Stephen J. Turnbull]

Richard M. Stallman writes:

 >     I grant the conceptual possibility that you assert, but I deny
 >     its importance.  I claim it is both extremely unlikely to come
 >     to pass, and that we can deal with the process of it arising in
 >     other ways.

 > No one can tell for certain.  The only relevant fact is that the problem
 > scenario did indeed occur for Linux.

Linus invited binary modules, and eventually found it was a bad
thing.  You would not make that mistake; I don't think the
scenarios are the same.

 > Whether it would happen with Emacs, none of us can determine.

That is true.

 > I have decided not to take the risk.

That's a shame for Emacs, and for the free software community, in my
opinion.

Re: Release plans

[Richard M. Stallman]

      Similarly, any damage to my freedom that is
    threatened by a proprietary module can be avoided by not using it.

Not everyone will make the decision not to use it.
Depending on how convenient it is, lots of people might use it.
That would be a big change for the worse.

I have responded in order to explain my decision, but if you hope to
convince me to change my decision, you are going about it all wrong.
You cannot win me over by attacking or playing to an audience.

Re: Release plans

[Paul R]

Hello Richard,

On Tue, 19 Aug 2008 08:21:43 -0400, "Richard M. Stallman" <rms@gnu.org> said:
RMS> Not everyone will make the decision not to use it. Depending on
RMS> how convenient it is, lots of people might use it. That would be
RMS> a big change for the worse.

And depending on how inconvenient emacs is, lots of people might just
avoid it in favor of a fully-proprietary system.

OTOH, depending on how convenient the solution libre is, lots of
people might start using it.

You can read every figures concerning the recent rise of popularity
and usage of free software to the mass. The fact is that more and more
people are now liberated from the proprietary world by using free
software. Do you think it is because they suddently realized that
proprietary software was unethical ? I don't think so. They just
realized how much more convenient it was for them to use free
software.

I totally agree with you how sad it is, but Firefox, OpenOffice and
Ubuntu bring free software to many people, while GNUEmacs or gNewSense
can't really help to spread the word.

Ultimatly, you can't prevent other vendors to provide proprietary
solutions, so I think such a technical retriction to emacs will
only penalize emacs users (and more generaly free software users).

-- 
  Paul

Re: Release plans

[Richard M. Stallman]

    And depending on how inconvenient emacs is, lots of people might just
    avoid it in favor of a fully-proprietary system.

I think you are exaggerating, but it might happen sometimes.
But that would not alter the issue, unless it happens a lot.
We will not extend toleration to proprietary software
just to gain a little popularity.

     Do you think it is because they suddently realized that
    proprietary software was unethical ? I don't think so. They just
    realized how much more convenient it was for them to use free
    software.

Yes -- and unless we teach them to care about their freedom,
it won't be secure.  That is why we don't just compete with
proprietary software.  We fight against it.  We tell  the
public that proprietary software is evil, and our actions reflect
our principles.

Many users of free software do not share these basic ideas,
and want us to change the policies which follow from these ideas.
We never listen to them.

Re: Release plans

[Thomas Lord]

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

Alan Mackenzie wrote:
>  You aren't
> considering the effect on everybody else.
>   

That is the main thing that I *am* considering.


> The ability to link binary libraries into Emacs means the ability to link
> non-free binaries in (think Linux modules here), possibly with _very_
> useful functionality, whose inclusion could screw up Emacs's freedom in a
> significant way.  Five years from now, lots of people could be "freely"
> chosing this "non-free" version.  This would be damaging to the aims of
> the FSF.
>   

It is defeatism if you think that Emacs maintainers can't easily hack their
way out of such a situation or even if you think that that's a likely 
outcome.

 

> Now I'm not saying this is an overwhelming argument. 


I'm saying it's completely underwhelming.


>  I'm saying that
> it must be weighed and balanced against the (substantial) benefits of
> binary libraries.  Just as individual people's freedom to own guns must
> be weighed against the right of the community not to have its members
> shot.
>   

Stephen said it a different way.  I said it already.   There is no
"must be weighed and balanced" here.  Yes, that's what RMS would
have us believe -- that it is a judgment call and one that has to be
made centrally and who better to make it....

I argued that no judgment call is needed.   By generic reasoning --
just general common sense principles -- that feature X enables
non-free hacks is neutral: never an argument against feature X.  
That feature X enables many free software hacks is an argument
for X.

RMS has been exercising an authority for which there is no need
in deciding these "hard" cases.



> My opinion on allowing binary libraries into Emacs is that its dangers
> would be greater than the benefits it would allow.  I'm willing to be
> persuaded I'm mistaken.
>   

How did you become persuaded of the supposed "dangers" in the
first place?



> You should address this, instead of evading it as you have done up to
> now.
>
>   

Stephen's reply answered that bit well.

-t



>> -t
>>     
>
>   


[-- Attachment #2: Type: text/html, Size: 3266 bytes --]

Re: Release plans

[Alan Mackenzie]

Morning, Thomas!

On Sat, Aug 16, 2008 at 07:37:24PM -0700, Thomas Lord wrote:
> Alan Mackenzie wrote:
> > You aren't considering the effect on everybody else.

> That is the main thing that I *am* considering.

Not in its full compass.

> >The ability to link binary libraries into Emacs means the ability to link
> >non-free binaries in (think Linux modules here), possibly with _very_
> >useful functionality, whose inclusion could screw up Emacs's freedom in a
> >significant way.  Five years from now, lots of people could be "freely"
> >chosing this "non-free" version.  This would be damaging to the aims of
> >the FSF.

> It is defeatism if you think that Emacs maintainers can't easily hack
> their way out of such a situation or even if you think that that's a
> likely outcome.

"Defeatism".  That's a sort of ad hominem, which seems intended to
deflect from analysing whether something's true or not.  And no, it's
not defeatism.  We can hack our way out of software problems fairly
easily, that's what we do.  But you're kidding yourself in the extreme
if you think you can just hack your way out of a legal problem, or a
social problem.

> >Now I'm not saying this is an overwhelming argument. 

> I'm saying it's completely underwhelming.

Yes, but you're doing it by shouting loudly, disparaging people by
calling them "defeatists", and evading others' arguments rather than
facing them head on.  My last post was an attempt to get you to analyse
these arguments.

> > I'm saying that it must be weighed and balanced against the
> > (substantial) benefits of binary libraries.  Just as individual
> > people's freedom to own guns must be weighed against the right of
> > the community not to have its members shot.

> Stephen said it a different way.  I said it already.   There is no
> "must be weighed and balanced" here.  Yes, that's what RMS would
> have us believe -- that it is a judgment call and one that has to be
> made centrally and who better to make it....

RMS is battle hardened with bitter experience behind him.  He's possibly
the only one of us with any useful feel for legalities.  There is nobody
better to make the final judgement.

> I argued that no judgment call is needed.   By generic reasoning --
> just general common sense principles -- that feature X enables
> non-free hacks is neutral: never an argument against feature X.  That
> feature X enables many free software hacks is an argument for X.

I've heard your argument and I accept it as far as it goes, but it
doesn't go far enough.  You're oblivious to some of the wider issues -
responding to these with words like "defeatism" isn't useful discussion.

> >My opinion on allowing binary libraries into Emacs is that its
> >dangers would be greater than the benefits it would allow.  I'm
> >willing to be persuaded I'm mistaken.

> How did you become persuaded of the supposed "dangers" in the first
> place?

By carefully paying attention to what people have been saying and
thinking about it.

> >You should address this, instead of evading it as you have done up to
> >now.

> Stephen's reply answered that bit well.

No, _YOU_ should address this.  Show, by careful discussion, that you
have understood what is being said, and give quality argument against
it.

> -t

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Thomas Lord]

Alan Mackenzie wrote:

 > The ability to link binary libraries into Emacs means the
 > ability to link non-free binaries in (think Linux modules
 > here), possibly with _very_ useful functionality, whose
 > inclusion could screw up Emacs's freedom in a significant way.
 > Five years from now, lots of people could be "freely" chosing
 > this "non-free" version.  This would be damaging to the aims
 > of the FSF.


Lots of things might happen in the future.




 >> It is defeatism if you think that Emacs maintainers can't
 >> easily hack their way out of [popular, non-free Emacs
 >> add-ons] or even if you think that that's a likely outcome.

 > "Defeatism".  That's a sort of ad hominem,

No, it is not.

"Defeatism" means a mode of strategic or tactical reasoning in
which it is assumed that the only choices are between various
losses.  The assumption in the dynamic loading decision is that
either GNU Emacs loses by not having a dynamic loader, or GNU
Emacs loses by having non-free, C-level add-ons catch on.
Defeatism is a kind of "planning to lose" and if defeatism is
the only reasoning applied then it is self-fulfilling: loss of
some kind is assured.



 > which seems intended to deflect from analysing whether
 > something's true or not.

In contrast, THAT is an ad hominem.

You see, you ascribed intent ("intended") to the speaker.  In
particular, you ascribed malicious intent ("deflect").  And you
used this to argue against what the speaker was saying.

THAT is an ad hominem attack.


 >  And no, it's not defeatism.  We can hack our way out of
 > software problems fairly easily, that's what we do.  But
 > you're kidding yourself in the extreme if you think you can
 > just hack your way out of a legal problem, or a social
 > problem.

I'm afraid I get a bit lost in the theoretical abstractions of
possible future legal and social problems.  Here is what I see:

A dynamic loader *might* lead to non-free, C-level add-ons.

A dynamic loader *might* then lead to non-free add-ons that
become very popular.

A dynamic loader (well designed) *will* lead to opportunities to
write valuable free software C-level add-ons.  Therefore it
*might* lead to free software add-ons being written and some of
those *might* become very popular.

Conversely, no dynamic loader means no add-ons, either free or
non-free.  No dynamic loader means *certainty* that GNU will not
enjoy the benefits of having a dynamic loader in Emacs.  No
dynamic loader means *certainty* that no non-free add-ons will
be created.

If the free and non-free software worlds are regarded as
opposing armies, the GNU army's choice is to either inflict a
loss on both sides (no dynamic loader -- the defeatist strategy)
or afford both sides a possible win (possible free and non-free
add-ons).

I happen to believe that there is *power* in freedom.  If both
the free and non-free army is given the chance to create
add-ons, the free army (if it plays intelligently) can obtain
more benefit from the opportunity in the long run.  The same
advantage, offered to both sides, is worth more to the free
side.



 >> I'm saying it's completely underwhelming.

 > Yes, but you're doing it by shouting loudly, disparaging
 > people by calling them "defeatists",


Actually, you made that up.  You falsely accused me of making an
ad hominem attack.  You then made an ad hominem attack against
me.  Now, here, you are making another ad hominem attack against
me.



 > and evading others' arguments rather than facing them head on.
 > My last post was an attempt to get you to analyse these
 > arguments.

I did and concluded that they are defeatist arguments.  See
above.


 >> Stephen said it a different way.  I said it already.  There
 >> is no "must be weighed and balanced" here.  Yes, that's what
 >> RMS would have us believe -- that it is a judgment call and
 >> one that has to be made centrally and who better to make
 >> it....

 > RMS is battle hardened with bitter experience behind him.
 > He's possibly the only one of us with any useful feel for
 > legalities.  There is nobody better to make the final
 > judgement.

Why is any "final judgement" needed over this question?

It's only a judgment call *if* you believe that the consequence
of non-free add-ons can possibly be reason enough to avoid a
feature.  If you reject that defeatism, then no judgment (of
that sort) is needed here: the question of whether or not to
have a dynamic loader in GNU Emacs can hinge entirely and
appropriately on its utility to free software developers and
users.


 > I've heard your argument and I accept it as far as it goes,
 > but it doesn't go far enough.  You're oblivious to some of the
 > wider issues - responding to these with words like "defeatism"
 > isn't useful discussion.

The "wider issues" (the purported social consequences, the
chances that GNU Emacs will get effectively 'taken over' by
non-free add-ons, etc) are beyond analysis.  Nobody knows what
will really happen.  There's a lot of hot air going around on
those wider issues but I don't think it adds up to much.

We know with absolute certainty, though, that adding a dynamic
loading feature to GNU Emacs will let people write and share
free software add-ons to GNU Emacs.  All else being equal, I
think it is safe to call that outcome a "win" for software
freedom.

We can assume, with absolute conservatism, that non-free add-ons
*will* result and *will* become popular.  No reason to believe
it but let's assume it.  Let's assume the worst case imagined.  What then?

Short answer: "We'll have to think of something."

Longer answer: We'll have to think of something but we'll also
be in an enriched circumstance.  We'll be enriched because we
have the option to write free software GNU Emacs add-ons.  We'll
be enriched because we didn't waste time arguing against a
feature with defeatist reasoning.

As a rule of thumb, we shouldn't inflict losses on ourselves
(such as not having a dynamic loader) unless there is very
clearly no other choice.  Otherwise, we should always hack *as
if we are certainly going to win software freedom for everyone*.

Assuming we will win software freedom for everyone, the question
of whether or not to add a dynamic loader is a question of:
"Will the free users of GNU systems, and the free developers of
GNU systems, benefit from the feature?"  (The answer to that one
seems a no-brainer!)



 >> How did you become persuaded of the supposed "dangers" in the
 >> first place?

 > By carefully paying attention to what people have been saying
 > and thinking about it.


 From "Elephant Talk" (King Crimson)

  Talk, its only talk
  Arguments, agreements, advice, answers,
  Articulate announcements
  Its only talk

  Talk, its only talk
  Babble, burble, banter, bicker bicker bicker
  Brouhaha, boulderdash, ballyhoo
  Its only talk
  Back talk

  Talk talk talk, its only talk
  Comments, cliches, commentary, controversy
  Chatter, chit-chat, chit-chat, chit-chat,
  Conversation, contradiction, criticism
  Its only talk
  Cheap talk

  Talk, talk, its only talk
  Debates, discussions
  These are words with a d this time
  [....]


Ok, I'm not really that nihilist about it but there is a lot of
hot air going around imagining the consequences of a feature
like dynamic loading or imagining how Emacs influences Windows
users or imagining how a "typical worker" can influence his
workplace to switch away from windows or......  Enough Already!
Too much "making stuff up" and guesswork.   I'm sure everyone's
contributions are not *random* -- there is some relation to reality there --
but collectively the discussion is just aimless, hopelessly abstract,
way to hypothetical, and so doomed to go in tiny circles.

That hot air is mostly very elaborate fantasizing and it has
been going on for 20 years.  Meanwhile, we have 20 years of
actual history to compare to it.  For all of GNU's efforts to
discourage the development of proprietary software one of our
largest economic achievements has been contributions to the
GNU/Linux platform that was a key catalyst to two dot com
bubbles and an explosion of companies developing non-free
software to run on the GNU/Linux platform.  To be sure, nobody
wrote a non-free front-end to GCC using the (banned) tree
print/read functionality.  Nobody wrote a non-free C-level
add-on to GNU Emacs using the (banned) dynamic loading facility.
Yet, those tools and the shell tools are the glue that binds the
main components of the LAMP stack: one of the largest growth
platforms for proprietary software in years and years.

The way to defeat non-free software in the market is to hone the
corpus of available free software so that, when developing new
software and new software products, it is always "faster,
cheaper, better, and profitable" to develop new programs as free
software programs.  Everytime we "ban" a feature from the GNU
system because of a defeatist perception of risk, we retreat
from the goal of making it economically natural to write new
programs as free software programs.  That is, we retreat from the
goal of software freedom for everyone.


-t

Re: Release plans

[Alan Mackenzie]

On Sun, Aug 17, 2008 at 10:42:28AM -0700, Thomas Lord wrote:
> Alan Mackenzie wrote:

> > The ability to link binary libraries into Emacs means the
> > ability to link non-free binaries in (think Linux modules
> > here), possibly with _very_ useful functionality, whose
> > inclusion could screw up Emacs's freedom in a significant way.
> > Five years from now, lots of people could be "freely" chosing
> > this "non-free" version.  This would be damaging to the aims
> > of the FSF.

> Lots of things might happen in the future.

Now you're playing verbal games with me.  <sigh>

> >> It is defeatism if you think that Emacs maintainers can't
> >> easily hack their way out of [popular, non-free Emacs
> >> add-ons] or even if you think that that's a likely outcome.

> > "Defeatism".  That's a sort of ad hominem,

> No, it is not.

No, of course not.  It's one of those handy little words which can always
be defended as rational and objective, yet at the same time give a very
good impression of an ad hominem attack and have the same effect.  It can
be used to appear to be exceptionally rude, yet without exposing the
writer to general censure.  Except, of course, you're not being rude
here, you're just being objective and rational, which is very reassuring.

> "Defeatism" means a mode of strategic or tactical reasoning in which it
> is assumed that the only choices are between various losses.  The
> assumption in the dynamic loading decision is that either GNU Emacs
> loses by not having a dynamic loader, or GNU Emacs loses by having
> non-free, C-level add-ons catch on.  Defeatism is a kind of "planning
> to lose" and if defeatism is the only reasoning applied then it is
> self-fulfilling: loss of some kind is assured.

"Defeat" is utter loss; it's when your king is in checkmate, when when
the whistle blows after 90 minutes your opponents have scored more goals,
when the enemy troups have routed your army and destroyed your strategy
to the point where the only sensible action is to surrender.

The inability to use dynamically loaded binaries in Emacs is like none of
these things.  It's an inconvenience, possibly minor, possibly major.
But it is _nothing_ like the utter rout implied by the word "defeatism".

> > which seems intended to deflect from analysing whether something's
> > true or not.

> In contrast, THAT is an ad hominem.

Of course it is.  You were just being rational and objective.  Thanks for
clarifying that.  My apologies.

> >  And no, it's not defeatism.  We can hack our way out of software
> >  problems fairly easily, that's what we do.  But you're kidding
> >  yourself in the extreme if you think you can just hack your way out
> >  of a legal problem, or a social problem.

> I'm afraid I get a bit lost in the theoretical abstractions of
> possible future legal and social problems.

I've noticed this.  That's why I'm trying to help you visualise these in
a more concrete, more accessible fashion.

> Here is what I see:

> A dynamic loader *might* lead to non-free, C-level add-ons.

> A dynamic loader *might* then lead to non-free add-ons that
> become very popular.

> A dynamic loader (well designed) *will* lead to opportunities to
> write valuable free software C-level add-ons.  Therefore it
> *might* lead to free software add-ons being written and some of
> those *might* become very popular.

> Conversely, no dynamic loader means no add-ons, either free or
> non-free.  No dynamic loader means *certainty* that GNU will not
> enjoy the benefits of having a dynamic loader in Emacs.  No
> dynamic loader means *certainty* that no non-free add-ons will
> be created.

Here is what you don't see, or at least refuse to consider: a non-free
add-on which becomes popular could be used maliciously to remove freedom
from Emacs.  Seen through your spectacles, every user is free to chose to
use that add-on or not, so there's no problem.  I'm making one last
effort in the post to help you see where you are wrong (see below).  If
this doesn't help, there's no sense in continuing the conversation.

> If the free and non-free software worlds are regarded as opposing
> armies, the GNU army's choice is to either inflict a loss on both sides
> (no dynamic loader -- the defeatist strategy) or afford both sides a
> possible win (possible free and non-free add-ons).

That's a wierd way of looking at things, which I don't agree with either
in detail or in the broad sweep.  The continuing absence of a dynamic
loader does not impose a loss on both "sides", or even any side.  It
merely makes it inconvenient to integrate certain inessential[*]
functionality into Emacs.

[*] inessential = "not composing the essence of", which is not identical
to "unimportant".

> I happen to believe that there is *power* in freedom.  If both the free
> and non-free army is given the chance to create add-ons, the free army
> (if it plays intelligently) can obtain more benefit from the
> opportunity in the long run.  The same advantage, offered to both
> sides, is worth more to the free side.

I don't think you understand power and its mechanisms, such as dominance,
deceit, lies, disinformation, demagoguery, deviousness, blackmail,
ridicule, manipulation, .... at all.  Richard most assuredly does, which
is why I am happy to trust his judgement on this matter.

[ .... ]

> > RMS is battle hardened with bitter experience behind him.  He's
> > possibly the only one of us with any useful feel for legalities.
> > There is nobody better to make the final judgement.

> Why is any "final judgement" needed over this question?

"Final" as in being the last person in the chain of command, the one who
is finally responsible.  Not "final" as in fixed once and for evermore.

> It's only a judgment call *if* you believe that the consequence of
> non-free add-ons can possibly be reason enough to avoid a feature.

I do believe this, so does Richard, and I expect a lot of other people do
too.

[ .... ]

> We can assume, with absolute conservatism, that non-free add-ons *will*
> result and *will* become popular.  No reason to believe it but let's
> assume it.  Let's assume the worst case imagined.  What then?

> Short answer: "We'll have to think of something."

Maybe that's how the Trojan leader fielded the misgivings of his
underlings as they were dragging the magically materialised horse through
their city walls.

> Longer answer: We'll have to think of something but we'll also be in an
> enriched circumstance.  We'll be enriched because we have the option to
> write free software GNU Emacs add-ons.  We'll be enriched because we
> didn't waste time arguing against a feature with defeatist reasoning.

What don't you understand about this:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;  microsoft8.dll
;;
;;  Copyright (C) Microsoft, 2013.
;;
;;  This binary library extends Emacs, giving it transparent access to all
;;  directories and files in the .NYET environment, together with convenient
;;  access from Emacs to your Email, calendar, etc.
;;
;;  To protect the security of your .NYET system, this library also guards
;;  against malware by only allowing digitally signed LISP or binary libraries
;;  to be compiled or loaded.  All libraries you may need to run Emacs have
;;  been duly signed.
;;
;;  microsoft8.dll MUST be loaded before any other Emacs extensions.  The
;;  system administrator is recommended to load this library at the top of his
;;  site's site-start.el file.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

?  Nobody is forced to load this library.  But I hope you can see now
that it would be a big problem nonetheless.

> -t

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Johannes Weiner]

Hi,

Alan Mackenzie <acm@muc.de> writes:
> What don't you understand about this:
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> ;;
> ;;  microsoft8.dll
> ;;
> ;;  Copyright (C) Microsoft, 2013.
> ;;
> ;;  This binary library extends Emacs, giving it transparent access to all
> ;;  directories and files in the .NYET environment, together with convenient
> ;;  access from Emacs to your Email, calendar, etc.
> ;;
> ;;  To protect the security of your .NYET system, this library also guards
> ;;  against malware by only allowing digitally signed LISP or binary libraries
> ;;  to be compiled or loaded.  All libraries you may need to run Emacs have
> ;;  been duly signed.
> ;;
> ;;  microsoft8.dll MUST be loaded before any other Emacs extensions.  The
> ;;  system administrator is recommended to load this library at the top of his
> ;;  site's site-start.el file.
> ;;
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>
> ?  Nobody is forced to load this library.  But I hope you can see now
> that it would be a big problem nonetheless.

register_gpl3_module ();

Now, how long do you think does it take to have the restrictions patched
out?

If this mechanism works out, we can stop argueing about personal views.
It will lead to nothing.

	Hannes

Re: Release plans

[Alfred M. Szmidt]

   > ?  Nobody is forced to load this library.  But I hope you can see now
   > that it would be a big problem nonetheless.

   register_gpl3_module ();

   Now, how long do you think does it take to have the restrictions patched
   out?

The elisp libraries where signed, recompiling will give you a
different signature, and .NYET will refuse to load it.

Re: Release plans

[Johannes Weiner]

Hi Alfred,

"Alfred M. Szmidt" <ams@gnu.org> writes:

>    > ?  Nobody is forced to load this library.  But I hope you can see now
>    > that it would be a big problem nonetheless.
>
>    register_gpl3_module ();
>
>    Now, how long do you think does it take to have the restrictions patched
>    out?
>
> The elisp libraries where signed, recompiling will give you a
> different signature, and .NYET will refuse to load it.

Hehe, you already stripped the context I was going to strip to emphasize
my point.  Because the very sentence you just wrote does not depend on
the feature of loading shared objects into emacs, so I don't think this
is a good argument for keeping it out.

	Hannes

Re: Release plans

[Thomas Lord]

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

Alan Mackenzie wrote:
> Now you're playing verbal games with me. 
>   

No, I'm not.


> No, of course not. ["Defeatism" is] one of those handy little words which can always
> be defended as rational and objective, yet at the same time give a very
> good impression of an ad hominem attack and have the same effect.  It can
> be used to appear to be exceptionally rude, yet without exposing the
> writer to general censure.  Except, of course, you're not being rude
> here, you're just being objective and rational, which is very reassuring.
>   

If we just use words in simple ways, communication with
near strangers over the Internet can work out.   If we always
look for hidden meanings or sly insults, communication is harder.


>   
>> "Defeatism" means a mode of strategic or tactical reasoning in which it
>> is assumed that the only choices are between various losses.  The
>> assumption in the dynamic loading decision is that either GNU Emacs
>> loses by not having a dynamic loader, or GNU Emacs loses by having
>> non-free, C-level add-ons catch on.  Defeatism is a kind of "planning
>> to lose" and if defeatism is the only reasoning applied then it is
>> self-fulfilling: loss of some kind is assured.
>>     
>
> "Defeat" is utter loss; 

No, it isn't.   You can see that it is not because of the existence
of two cliche phrases:  "defeat at battle" and "utter defeat".
"Defeat" means an "undoing" or a loss.

"Defeatism" is an assumption that loss of one kind or another
is inevitable, then a choice of action aimed to minimize loss.
"Defeatism" is a kind of "null upside investment strategy"
by which I mean that defeatism is the way of spending
to minimize loss, EVEN AT THE EXPENSE of possible
gain.    When lots of people adopt defeatist tactics in the
stock market, that's called a panic.



> it's when your king is in checkmate, when when
> the whistle blows after 90 minutes your opponents have scored more goals,
> when the enemy troups have routed your army and destroyed your strategy
> to the point where the only sensible action is to surrender.
>   

That's mostly in your head.   In a tragic context,
defeatism could refer to an inevitable and utter defeat
like that but the word "defeat" itself has much broader
meaning.



> The inability to use dynamically loaded binaries in Emacs is like none of
> these things.  It's an inconvenience, possibly minor, possibly major.
> But it is _nothing_ like the utter rout implied by the word "defeatism".
>   

I guess the question you are speculating about is how "important"
dynamic loading is.    I don't think either of us really knows but
I can guess too:

I'm really impressed by the roles dynamic loading has played
in the LAMP stack, particularly loading of modules into scripting
languages and loading of modules into Apache and other
web servers.

It makes sense, in retrospect, that it would be such an influential
feature.  It's a kind of combinatorics phenomenon.  If there are
M programs with dynamic loaders, and N dynamically loadable
libraries, then there are M*(2^N) possible run-time environments!
That's very flexible.   And what's more, because of the way
dynamic loading works, ANYONE can increment N without having
to bother any upstream maintainers or have patches accepted -- it's
always possible to add a new library.   The result of a dynamic loader
in the LAMP stack is a super-exponential explosion of possible
configurations of free software components and the the result of
that circumstance is the enormous success of the stack (and the
ongoing development of lots of components that "plug in" to it).

Would dynamic loading in GNU Emacs matter as much?
I'm sure nobody knows and that the answer depends largely
on the design of the dynamic loading mechanism.   Nevertheless,
the potential upside is huge, if the LAMP environment is any
indication.

The *cost* (in labor and other real expenses) of adding dynamic
loading is, I suspect, pretty low.    A crappy job of it should be
basically free.   A very good job of it should still be pretty
"cheap".   So, we're talking about a penny stock:   cheap to add
dynamic loading and a huge potential upside. 



> Here is what you don't see, or at least refuse to consider: a non-free
> add-on which becomes popular could be used maliciously to remove freedom
> from Emacs.  Seen through your spectacles, every user is free to chose to
> use that add-on or not, so there's no problem.  I'm making one last
> effort in the post to help you see where you are wrong (see below).  If
> this doesn't help, there's no sense in continuing the conversation.
>   


Your ".nyet" license?   So, the nightmare scenario is 10s of millions or 
more
of new Emacs users, but all "addicted" to the ".nyet" add-on?

That sounds to me like a battle won for free software.  Not a war won
but a major battle:   The next step is to whittle away at the advantages
of the ".nyet" add-on and then free GNU Emacs has 10s of millions or
more of new users.


> [*] inessential = "not composing the essence of", which is not identical
> to "unimportant".
>   

The combinatorics experience of the LAMP stack with
add-ons suggests that calling a dynamic loader "unimportant"
is at best premature.


>> I happen to believe that there is *power* in freedom.  If both the free
>> and non-free army is given the chance to create add-ons, the free army
>> (if it plays intelligently) can obtain more benefit from the
>> opportunity in the long run.  The same advantage, offered to both
>> sides, is worth more to the free side.
>>     
>
> I don't think you understand power and its mechanisms, such as dominance,
> deceit, lies, disinformation, demagoguery, deviousness, blackmail,
> ridicule, manipulation, .... at all.  Richard most assuredly does, which
> is why I am happy to trust his judgement on this matter.
>   

Uh, you might be surprised.

-t


[-- Attachment #2: Type: text/html, Size: 7502 bytes --]

Re: Release plans

[Richard M. Stallman]

    Here is what you don't see, or at least refuse to consider: a non-free
    add-on which becomes popular could be used maliciously to remove freedom
    from Emacs.  Seen through your spectacles, every user is free to chose to
    use that add-on or not, so there's no problem.

Even if the non-free add on does not go to the malicious lengths
of the microsoft8.dll scenario, it is still a problem for users'
freedom if it becomes popular.

Re: Release plans

[Thien-Thi Nguyen]

() Thomas Lord <lord@emf.net>
() Sun, 17 Aug 2008 10:42:28 -0700

   Everytime we "ban" a feature from the GNU system because of a
   defeatist perception of risk, we retreat from the goal of
   making it economically natural to write new programs as free
   software programs.  That is, we retreat from the goal of
   software freedom for everyone.

Perhaps you are right.  Perhaps Emacs is not the proper vehicle.

thi

Re: Release plans

[Richard M. Stallman]

    If the free and non-free software worlds are regarded as
    opposing armies, the GNU army's choice is to either inflict a
    loss on both sides (no dynamic loader -- the defeatist strategy)
    or afford both sides a possible win (possible free and non-free
    add-ons).

A win for non-free software is ipso facto a loss for our campaign to
eliminate non-free software.  When the non-free software in question
is an add-on for a free program, it tends to pervert the liberating
nature and message of that free program; that is another kind of loss
for us.  These are the potential kinds of harm that I am concerned to
avert.

Our community develops lots of free software, but which software it
develops is a matter of what many people are inspired to do.
We cannot count on the community to develop a free equivalent
of a nasty Emacs add-on in a short time, not if it is nontrivial.

Re: Release plans

[Thomas Lord]

Richard M. Stallman wrote:
>     If the free and non-free software worlds are regarded as
>     opposing armies, the GNU army's choice is to either inflict a
>     loss on both sides (no dynamic loader -- the defeatist strategy)
>     or afford both sides a possible win (possible free and non-free
>     add-ons).
>
> A win for non-free software is ipso facto a loss for our campaign to
> eliminate non-free software.  When the non-free software in question
> is an add-on for a free program, it tends to pervert the liberating
> nature and message of that free program; that is another kind of loss
> for us.  These are the potential kinds of harm that I am concerned to
> avert.
>
> Our community develops lots of free software, but which software it
> develops is a matter of what many people are inspired to do.
> We cannot count on the community to develop a free equivalent
> of a nasty Emacs add-on in a short time, not if it is nontrivial.
>
>   

I am willing to assume that if a dynamic loader is added
to Emacs that non-free add-ons will follow.  I'll allow that,
yes, that will diminish the "liberating nature and message"
of GNU Emacs regarded as an isolated program.

Nevertheless, there is a bigger fish to fry:

GNU Emacs is not an isolated program.  There are many
free software programs and libraries and GNU Emacs exists
along side those.

If we concentrate on adding features that allow programs to
be flexibly combined, the resulting GNU system will be a
flexible, powerful environment.   Conversely, if we neglect,
ban, or poorly execute such interconnection features, the GNU
system will be be little more than a set of mutually isolated
programs -- either there's a program that does what you need
or there isn't -- there's no way easy way to build the program
you need because even if the parts exist there's no easy way to
fit them together.

A modular GNU system with good interconnects -- a set of
programs and libraries that can be recombined many ways --
would itself have a "liberating nature and message" and one
much more powerful than GNU Emacs taken in isolation.

In trying to protect GNU Emacs in isolation, you are
giving up on the goal of creating a more profound
piece of free software.


-t

Re: Release plans

[René Kyllingstad]

* Richard M. Stallman:
>      If the free and non-free software worlds are regarded as
>      opposing armies, the GNU army's choice is to either inflict a
>      loss on both sides (no dynamic loader -- the defeatist strategy)
>      or afford both sides a possible win (possible free and non-free
>      add-ons).
>  
>  A win for non-free software is ipso facto a loss for our campaign to
>  eliminate non-free software.  When the non-free software in question
>  is an add-on for a free program, it tends to pervert the liberating
>  nature and message of that free program; that is another kind of loss
>  for us.  These are the potential kinds of harm that I am concerned to
>  avert.
>  
>  Our community develops lots of free software, but which software it
>  develops is a matter of what many people are inspired to do.
>  We cannot count on the community to develop a free equivalent
>  of a nasty Emacs add-on in a short time, not if it is nontrivial.

I'd like to get your comment on another side of this:

One problem the free software community is struggling with is
funding. Developing new software is time consuming.  It's made even harder
if a team is not working together in the same building, and only part-time.

If a company would put a lot of effort into creating a non-free Emacs
plug-in, the effort of coming up with the idea and finding out exactly how
it should work would be paid for by them.

Then it's a much easier job for the free software community to organize an
effort to implement the missing parts as free software, since it's clear to
everyone exactly what kind of features are being discussed.

It's hardly a new argument, I just haven't seen anyone acknowledging it in
this thread, and funding of free software is also a topic that interests me
very much.


-- René

Re: Release plans

[Richard M. Stallman]

    If a company would put a lot of effort into creating a non-free Emacs
    plug-in, the effort of coming up with the idea and finding out exactly how
    it should work would be paid for by them.

This is no reason to ogive permission for non-free software.

Re: Release plans

[Richard M. Stallman]

You expressed the issue very clearly.

Re: Release plans

[Richard M. Stallman]

    But it is better to have badly written free software than having well
    written non-free software.  We can fix the former, but not the later.

Exactly.  The idea of the free software movement is that we don't
give up our freedom just to "get a job done".

    Software is written for a purpose.  Windows
    does its job, whether it does it good or bad and whether you like the
    philosophy or not.  It is not free and it solves the problem it was
    written for.

If you define "the job" in purely practical terms, that response
follows logically.  There are users who can get their work done using
Windows.

It does not follow that the existence of Windows is a good thing or that
developing it was ethically acceptable.  Part of valuing freedom is that
you don't consider something a "solution" if it costs you freedom.

Re: Release plans

[Thomas Lord]

Richard M. Stallman wrote:
>     But it is better to have badly written free software than having well
>     written non-free software.  We can fix the former, but not the later.
>
> Exactly.  The idea of the free software movement is that we don't
> give up our freedom just to "get a job done".
>   

Then why was the GNU system bootstrapped on proprietary
systems?   And, aren't you creating a kind of ontological problem
there:  is it truly an increase in freedom to give up capability
in exchange for conditions?

It's a four-by-four decision matrix that people are talking about
in this thread:  poor-v.-good software on one axis, free-v.-proprietary
on the other.   Ranking the four choices is partially easy and
partially always contentious:   good/free trumps all other choices.
Every choice trumps poor/proprietary.   

The problem is that it is hard to compare good/proprietary
to poor/free in some absolute way.  NOT EVEN THE GNU
PROJECT always makes that choice the same way, whether
it was the use of proprietary platforms for bootstrapping or
the invention of LGPL.

The good/proprietary vs. poor/free question is eternal.  It always
invites looking at the larger context and the specifics of particular
situations.   There will never be consensus on it.

The freedom-fighting thing to do, if we place an absolute
value on freedom, is to work to avoid the good/proprietary
vs. poor/free choice: to avoid creating (or resting pat with)
poor/free software.

Let's look at two  cases:  (a) adding dynamic loading
to GNU Emacs;  (b) adding GCC features to dump and
read back the tree format intermediate form.  

Both of those features were historically rejected by the
GNU project on the grounds that they would make it too
easy to create proprietary derivatives of free software
programs.

I think those decisions by GNU were ethically questionable.
Both of them avoided making proprietary derivatives easier
to write but both ALSO pushed the free programs farther
towards "poor" and away from "good".   In other words,
both multiplied the number of times users would be confronted
by a "poor/free vs. good/proprietary" choice.

Those actions by GNU represent defeatism.  They carry an implicit
assumption that free software developers can't compete -- that
"good/free" is a practical impossibility.   A *confident*
GNU project, in contrast, would have noted "Oh, people
will probably use these to make proprietary derivatives.
Shrug.  Doesn't matter: these features will help Emacs and
GCC become very good and, importantly, much more
flexible -- so over time, they will help to deprive proprietary
software authors of any niches left to exploit.  So, do it: put
those features in."

The defeatism we got instead gives rise to an ethically questionable
absolutism:  it is OK, evidently, for the GNU project to
choose to use proprietary software to bootstrap itself but
we are told that if the GNU project no longer has to make
that choice then, therefore, anyone else making that choice
is morally wrong.   Yet, what gives GNU that special
privilege in morality?   If the details of "why compromise"
are circumstantial for GNU then they are circumstantial
for everyone.    Grand pronouncements about absolutely rejecting
proprietary software and just "working harder" smack of
hypocrisy, desperation, condescension,  and messianic
self-righteousness.

Adding to the apparent hypocrisy:  GNU concentrated
for years on the "poor/free is good enough" strategy
and at a certain point the Linux kernel came along and
shortly thereafter the modern GNU/Linux vendors arose.
As a rule, they (a) get the bulk of their money selling
a platform for running proprietary apps;  (b) combine
GNU/Linux with proprietary apps and other materials
to make their products hard to copy.   And, yet, the GNU
project seems to take this as a victory and point to these
vendors and their achievements as evidence of the
success of GNU!

To put it bluntly:   is the real goal here to make the
"good/free" choice widely available and easy to
understand?   or is the real goal to perpetuate the
opportunities to talk about the theoretical desirability
of having a "good/free" choice, someday, maybe?

As I said more succinctly, earlier:  RMS, you spend
a lot of time worrying about what programs to NOT
write.


>     Software is written for a purpose.  Windows
>     does its job, whether it does it good or bad and whether you like the
>     philosophy or not.  It is not free and it solves the problem it was
>     written for.
>
> If you define "the job" in purely practical terms, that response
> follows logically.  There are users who can get their work done using
> Windows.
>
> It does not follow that the existence of Windows is a good thing or that
> developing it was ethically acceptable.  Part of valuing freedom is that
> you don't consider something a "solution" if it costs you freedom.
>   

A fine example.   Please look at the overly abstract, overly
theorized, bordering on hypocrisy claim there:

     "You don't consider something a 'solution'
       if it costs you freedom."

Really?   Ever?

Not even when bootstrapping the GNU project?

How about during recovery operations from a natural
disaster?

How about to be able to afford an apartment and food?

Maybe it depends on the nature of the costs to freedom vs.
the rewards?   Maybe it depends on the circumstances and
the other degrees of freedom they afford?

Let's see... how do those old ethical quiz-game puzzles go?
You see a train speeding down the tracks, heading towards
a fork in the tracks.   On one fork, your loved one has their
foot stuck in the tracks and can't escape in time.  On the
other is a school-bus full of children, stalled -- evacuating
but they won't make it in time.   Your hand is on the
switch and you can send the train one way or the other....
What do you do?

The right answer, of course, is that you go to the administration
office and drop the philosophy course where the question
is posed, signing up for an engineering course instead.
Perhaps you'll figure out how to invent a more efficient
evacuation system for school buses or tracks that people
can't get stuck in so easily.

Persistent, ethically impossible choices are best addressed not
by exhortation towards one or another theory of how to make
them, but by engineering towards avoiding them.   Answers to
the questions about what (free) software to NOT write (in order
to avoid accidentally aiding proprietary software developers)
are not, in my opinion, contributions to the advance of the free
software movement.   The last 15 years or so of GNU history
makes a strong case for me.


-t



>
>
>
>   

Re: Release plans

[Richard M. Stallman]

    Then why was the GNU system bootstrapped on proprietary
    systems?

I thought about this issue and concluded that use of a non-free program
for the specific purpose of developing its free replacement.

You describe defensive measures as "defeatism".  I call it "prudence".
There are other confused and inaccurate assertions as well, but
I'm not going to play your game by responding to each of them.

Re: Release plans

[Alfred M. Szmidt]

Just to note, I wrote the following text:

       But it is better to have badly written free software than
       having well written non-free software.  We can fix the former,
       but not the later.

   Exactly.  The idea of the free software movement is that we don't
   give up our freedom just to "get a job done".

But not this:

       Software is written for a purpose.  Windows
       does its job, whether it does it good or bad and whether you like the
       philosophy or not.  It is not free and it solves the problem it was
       written for.

   If you define "the job" in purely practical terms, that response
   follows logically.  There are users who can get their work done using
   Windows.

   It does not follow that the existence of Windows is a good thing or that
   developing it was ethically acceptable.  Part of valuing freedom is that
   you don't consider something a "solution" if it costs you freedom.

Re: Release plans

[Stefan Monnier]

> Primarily, software is problem-solving.

Maybe that was the case in some distant past.  Nowadays, software runs
the world (quite literally).


        Stefan

Re: Release plans

[Richard M. Stallman]

    Hey, you snipped too much of the context, you rascal!  The effort I was
    talking about was that of a large company, with all the bureaucracy and
    inertia that goes with it.  

I was talking about switching your own computing to GNU/Linux, within
the company, not the bigger task of convincing the whole company to
change.  With that clarified, is my response more understandable?

    Other people and groups are advancing free software by emphasising free
    software's high quality. Yet you don't recognise their efforts as
    legitimate,

You have misunderstood my position.  I do not criticize them for
persuasively citing practical advantages.  If they oppose our efforts
at a deeper level, by endorsing the idea that freedom is not an
important issue, I do criticize that.

Re: Release plans

[Alan Mackenzie]

Hi, Richard!

On Thu, Aug 14, 2008 at 11:41:16PM -0400, Richard M. Stallman wrote:
>     Hey, you snipped too much of the context, you rascal!  The effort I was
>     talking about was that of a large company, with all the bureaucracy and
>     inertia that goes with it.  

> I was talking about switching your own computing to GNU/Linux, within
> the company, not the bigger task of convincing the whole company to
> change.  With that clarified, is my response more understandable?

Yes, indeed it is.  Sorry for the misunderstanding.

OK, to start with, most of my time at work needs access to the company
network, for things like Email (over proprietary protocols), access to
the VCS (often ClearCase (yuck!!)), sometimes "talk" programs,
spreadsheets used for reserving meeting rooms, that kind of thing.

I couldn't put GNU onto my desktop PC in the office, at least not
without being instantly dismissed.  If I were to bring in my own PC and
connect it to the company network, something similar would happen - such
is regarded as a security hazard, quite rightly.  I'm not sure there's
even any clients on GNU which speak the necessary proprietary protocols,
such as for Email.

The nearest I could get would be having my own PC alongside the office
one, exchanging files by USB stick.  How would this be any better, from
a freedom point of view, than running the w32 versions of the software
on the office PC?

>     Other people and groups are advancing free software by emphasising
>     free software's high quality. Yet you don't recognise their
>     efforts as legitimate,

> You have misunderstood my position.  I do not criticize them for
> persuasively citing practical advantages.  If they oppose our efforts
> at a deeper level, by endorsing the idea that freedom is not an
> important issue, I do criticize that.

Your word "endorsing" is one of those flexible, vague, open-ended words
that could mean almost anything.  Do these other people actually
campaign against software freedom?  Do they actually say "freedom is
unimportant", rather than just not mentioning it much?

I think it's more important for people actually to be free than to be
aware of it.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Stephen J. Turnbull]

Alan Mackenzie writes:

 > I think it's more important for people actually to be free than to be
 > aware of it.

Freedom is about choice; choice requires awareness of alternatives and
that you are able to choose them.  IMO, you cannot "actually be free"
without being aware of it.

Re: Release plans

[Thomas Lord]

Stephen J. Turnbull wrote:
> Alan Mackenzie writes:
>
>  > I think it's more important for people actually to be free than to be
>  > aware of it.
>
> Freedom is about choice; choice requires awareness of alternatives and
> that you are able to choose them.  IMO, you cannot "actually be free"
> without being aware of it.
>   

That's too simple.

Hopefully one's freedoms are larger in scope than one's awareness  can
fully grasp.   That is, we (hope to be) always more free than we can
ever know -- we always have only partial knowledge of our possible
choices.

Instead, we're free to do anything in the intersection of that those
choices we can *discover* from our current state with those
choices that are physically available to us.

Of course, even the question of "what choices can we *discover*"
doesn't have a static, classical answer.   For example, to discover
choice A might preclude discovering choice B and vice versa --
so, before we see either choice A or B, where are we exactly?
Free to A or free to B but not both in one sense.   In another
sense not free to A or B until we become aware of one or the
other.   Simplistic "rational actor" theories of "freedom" don't
cut it except as approximations.

All this highly abstract ethical theory is a cul de sac:  pretty
to drive around and have a look at but, then to get anywhere
else, you have to leave and find another street.

In a civic context, the question is simpler:  a condition
of liberty is one in which the civil order doesn't impose
an obstacle to a given choice or to discovering that choice.

The conclusion is the same, though, regarding dynamic
loading in GNU Emacs.  The civil order precludes doing
so.  Users are deprived of a freedom that could otherwise
be trivially afforded them by virtue of a deliberate effort
to achieve exactly that effect.



-t





>
>
>   

Re: Release plans

[Richard M. Stallman]

    The nearest I could get would be having my own PC alongside the office
    one, exchanging files by USB stick.  How would this be any better, from
    a freedom point of view, than running the w32 versions of the software
    on the office PC?

It would be MUCH better.  The more you can do on GNU/Linux
and reject Windows, the more of your life will be in freedom.

Also, your doing this would inspire others to think about the issue,
and that could open the door to further steps.  This is exactly the
sort of thing that can influence them to recognize that GNU/Linux is
at least as secure as Windows, move to protocols supported by free
software, and so on.  You should do it!

Re: Release plans

[Richard M. Stallman]

    Your word "endorsing" is one of those flexible, vague, open-ended words
    that could mean almost anything.  Do these other people actually
    campaign against software freedom?  Do they actually say "freedom is
    unimportant", rather than just not mentioning it much?

Many of them do.  Occasionally they directly oppose the ideals of
software freedom; Torvalds has done so.  More often, they do not
explicitly address the issue, but they say things which implicitly
assert that the most important values are powerful, reliable,
convenient software and that non-free software is acceptable.

    I think it's more important for people actually to be free than to be
    aware of it.

What I've learned is that people tend not remain free for long
unless they appreciate freedom and defend it.

Re: Release plans

[A Soare]

> >>> No, there is no contradiction in what I say.
> >> Are you sure? Didn't you say that the developers you know do not use 
> >> Emacs on Windows because there are better software for their purpose on 
> >> Windows? And didn't you mean that you trust them?
> > 
> > If you think at the definition of "good-better-best" from _their_
>  > viewpoint, there is no contradiction.
> 
> Yes, that is right. But are you not overlooking the possibility that the 
> software they use might be superior even if not making fast money is 
> your goal?

We are looping again. I told you: everything depends of education. No, from my viewpoint emacs is better. But in the same time I realise that from their viewpoint other editors are better. I tolerate their education.

> >> Note: It looks like your mail program does something that Thunderbird 
> >> does not expect at all. Thunderbird does not wrap the lines when 
> >> commenting on your text. Do you know the reason? (It takes a lot of time 
> >> that this does not work.)
>  >
> > I am sorry, I do not understand... :(
> 
> All the text in one paragraph stays on one long line that is not 
> wrapped. There is a commenting mark at the beginning of the line like here:
> 
> > Avant de prendre le volant, repérez votre itinéraire et visualisez le trafic ! http://itineraire.voila.fr/itineraire.html
> 

Now I see. Voila.






____________________________________________________

Avant de prendre le volant, repérez votre itinéraire et visualisez le trafic ! http://itineraire.voila.fr/itineraire.html

Re: Release plans

[Lennart Borgman (gmail)]

A Soare wrote:
>>>>> No, there is no contradiction in what I say.
>>>> Are you sure? Didn't you say that the developers you know do not use 
>>>> Emacs on Windows because there are better software for their purpose on 
>>>> Windows? And didn't you mean that you trust them?
>>> If you think at the definition of "good-better-best" from _their_
>>  > viewpoint, there is no contradiction.
>>
>> Yes, that is right. But are you not overlooking the possibility that the 
>> software they use might be superior even if not making fast money is 
>> your goal?
> 
> I told you: everything depends of education.
 > No, from my viewpoint emacs is better.
> But in the same time I realise that from their viewpoint other editors are better.
 > I tolerate their education.

But does not that mean that you say that your education is better? That 
you have learned something that they have not (yet)?

> Now I see. Voila.

It would be nice if you find a way to fix the line wrapping (and told 
the developers of the software that is malfunctioning of course).

Re: Release plans

[A Soare]

> > I told you: everything depends of education.
>  > No, from my viewpoint emacs is better.
> > But in the same time I realise that from their viewpoint other editors are better.
>  > I tolerate their education.
> 
> But does not that mean that you say that your education is better? That 
> you have learned something that they have not (yet)?

The word good-best-better is a kind of recursion in nature.

To solve the bugs, I must add to the definition:

 "best-better-good can be applied to objects that belong to the same space. One cannot compare 2 objects from different worlds using this word. In the Kant's language, one says that our mind cannot find a common category in order to apply this word to that category".

If you take care about this definition, the loop dissapears. It reduces to discrimination. If you go on with further this discussion, you make discrimination. Everything is relative to this world. A fish cannot say that he leaves better than a man, and vice versa.

> 
> > Now I see. Voila.
> 
> It would be nice if you find a way to fix the line wrapping (and told 
> the developers of the software that is malfunctioning of course).
> 

You did not understand. The web site where I have my pretty and most lovely mail account add this banner.




____________________________________________________

Avant de prendre le volant, repérez votre itinéraire et visualisez le trafic ! http://itineraire.voila.fr/itineraire.html

Re: Release plans

[Lennart Borgman (gmail)]

A Soare wrote:
>>> I told you: everything depends of education.
>>  > No, from my viewpoint emacs is better.
>>> But in the same time I realise that from their viewpoint other editors are better.
>>  > I tolerate their education.
>>
>> But does not that mean that you say that your education is better? That 
>> you have learned something that they have not (yet)?
> 
> The word good-best-better is a kind of recursion in nature.

Ok, it looked to me that you were trying to say that developing Emacs on 
windows was useless because of your view. That would be a very 
egocentric argument and not useful for conclusions about what to do.

You have probably explained why it is not useful in a way that I have 
missed.

> If you take care about this definition, the loop dissapears. It reduces to discrimination. If you go on with further this discussion, you make discrimination. Everything is relative to this world. A fish cannot say that he leaves better than a man, and vice versa.
> You did not understand. The web site where I have my pretty and most lovely mail account add this banner.

Maybe, but what i wanted to say was that you mail program does not work 
ok. So perhaps it would be best if you used some other mail program.

Re: Release plans

[Lennart Borgman (gmail)]

Lennart Borgman (gmail) wrote:
> A Soare wrote:
>>>> I told you: everything depends of education.
>>>  > No, from my viewpoint emacs is better.
>>>> But in the same time I realise that from their viewpoint other 
>>>> editors are better.
>>>  > I tolerate their education.
>>>
>>> But does not that mean that you say that your education is better? 
>>> That you have learned something that they have not (yet)?
>>
>> The word good-best-better is a kind of recursion in nature.
> 
> Ok, it looked to me that you were trying to say that developing Emacs on 
> windows was useless because of your view. That would be a very 
> egocentric argument and not useful for conclusions about what to do.
> 
> You have probably explained why it is not useful in a way that I have 
> missed.
> 
>> If you take care about this definition, the loop dissapears. It 
>> reduces to discrimination. If you go on with further this discussion, 
>> you make discrimination. Everything is relative to this world. A fish 
>> cannot say that he leaves better than a man, and vice versa.
>> You did not understand. The web site where I have my pretty and most 
>> lovely mail account add this banner.
> 
> Maybe, but what i wanted to say was that you mail program does not work 
> ok. So perhaps it would be best if you used some other mail program.

Or maybe it is rather a bug in Thunderbird client? I can see now that 
the lines gets wrapped in my reply, but I have trouble reading your 
message in Thunderbird when I am editing my reply.

This is quite annoying. Is there anyone who understand what is wrong?

Re: Release plans

[A Soare]

> > Maybe, but what i wanted to say was that you mail program does not work 
> > ok. So perhaps it would be best if you used some other mail program.
> 
> Or maybe it is rather a bug in Thunderbird client? I can see now that 
> the lines gets wrapped in my reply, but I have trouble reading your 
> message in Thunderbird when I am editing my reply.
> 
> This is quite annoying. Is there anyone who understand what is wrong?
> 
> 

I correct you just a remark: I wrote the message using OPERA!

http://www.opera.com/

____________________________________________________

Avant de prendre le volant, repérez votre itinéraire et visualisez le trafic ! http://itineraire.voila.fr/itineraire.html

Re: Release plans

[A Soare]

> > From: A Soare <alinsoar@voila.fr>
> > Date: Tue, 12 Aug 2008 14:21:03 +0200 (CEST)
> > 
> > 
> > I have never known in all my life a person using windows that
> > thought to use emacs.
> 
> I see them every day on my daytime job.
> 
> > So a considerable number of peuple use Windows, but (almost) never Emacs in Windows.
> 
> Not in my experience.
> 

I wanted just to express my *egocentric* experience.



____________________________________________________

Avant de prendre le volant, repérez votre itinéraire et visualisez le trafic ! http://itineraire.voila.fr/itineraire.html

Re: Release plans

[A Soare]

> > From: A Soare <alinsoar@voila.fr>
> > Date: Tue, 12 Aug 2008 15:37:22 +0200 (CEST)
> > Cc: "Emacs   Dev  \[emacs-devel\]" <emacs-devel@gnu.org>
> > 
> > > Yes, I understood that this is what you meant. But in what way did you 
> > > reach this conclusion?
> > 
> > By induction.
> 
> "Induction" as in "1 is a prime number, 2 is a prime number, 3 is a
> prime number; so by induction, every number is prime."
> 

In my case the initial hypothesis is true; the general case is false:

1. initial: X1 X2 ... Xn do not use Emacs

2. general: nobody uses Emacs



____________________________________________________

Avant de prendre le volant, repérez votre itinéraire et visualisez le trafic ! http://itineraire.voila.fr/itineraire.html

Re: Release plans

[Lennart Borgman (gmail)]

A Soare wrote:
> 
>>> From: A Soare <alinsoar@voila.fr>
>>> Date: Tue, 12 Aug 2008 15:37:22 +0200 (CEST)
>>> Cc: "Emacs   Dev  \[emacs-devel\]" <emacs-devel@gnu.org>
>>>
>>>> Yes, I understood that this is what you meant. But in what way did you 
>>>> reach this conclusion?
>>> By induction.
>> "Induction" as in "1 is a prime number, 2 is a prime number, 3 is a
>> prime number; so by induction, every number is prime."
>>
> 
> In my case the initial hypothesis is true; the general case is false:
> 
> 1. initial: X1 X2 ... Xn do not use Emacs
> 
> 2. general: nobody uses Emacs


Is not that extrapolation rather than induction? ;-)

Re: Release plans

[Eli Zaretskii]

> From: A Soare <alinsoar@voila.fr>
> Cc: "Emacs   Dev  [emacs-devel]" <emacs-devel@gnu.org>
> Date: Tue, 12 Aug 2008 20:41:17 +0200 (CEST)
> 
> > > From: A Soare <alinsoar@voila.fr>
> > > Date: Tue, 12 Aug 2008 15:37:22 +0200 (CEST)
> > > Cc: "Emacs   Dev  \[emacs-devel\]" <emacs-devel@gnu.org>
> > > 
> > > > Yes, I understood that this is what you meant. But in what way did you 
> > > > reach this conclusion?
> > > 
> > > By induction.
> > 
> > "Induction" as in "1 is a prime number, 2 is a prime number, 3 is a
> > prime number; so by induction, every number is prime."
> > 
> 
> In my case the initial hypothesis is true; the general case is false:
> 
> 1. initial: X1 X2 ... Xn do not use Emacs
> 
> 2. general: nobody uses Emacs

Because your n is too small, obviously.

Re: Release plans

[A Soare]

> > 
> > In my case the initial hypothesis is true; the general case is false:
> > 
> > 1. initial: X1 X2 ... Xn do not use Emacs
> > 
> > 2. general: nobody uses Emacs
> 
> 
> Is not that extrapolation rather than induction? ;-)

Maybe, I do not know. Induction is surely.




____________________________________________________

Avant de prendre le volant, repérez votre itinéraire et visualisez le trafic ! http://itineraire.voila.fr/itineraire.html

Re: Release plans

[Lennart Borgman (gmail)]

A Soare wrote:
>>> In my case the initial hypothesis is true; the general case is false:
>>>
>>> 1. initial: X1 X2 ... Xn do not use Emacs
>>>
>>> 2. general: nobody uses Emacs
>>
>> Is not that extrapolation rather than induction? ;-)
> 
> Maybe, I do not know. Induction is surely.

Maybe this is not the place for math education, but you are missing one 
piece to make it induction:

- There should be something that asserts that the condition holds also 
for next step.

It might happen even to you that you meat a person who uses Emacs on 
windows ...

Re: Release plans

[A Soare]

> > In my case the initial hypothesis is true; the general case is false:
> > 
> > 1. initial: X1 X2 ... Xn do not use Emacs
> > 
> > 2. general: nobody uses Emacs
> 
> Because your n is too small, obviously.
> 

Even for a great n, this reasonement would be wrong.




____________________________________________________

Avant de prendre le volant, repérez votre itinéraire et visualisez le trafic ! http://itineraire.voila.fr/itineraire.html

Re: Release plans

[christophe]

On Tue, Aug 12, 2008 at 4:53 PM,  <emacs-devel-request@gnu.org> wrote:
> Message: 6
> Date: Tue, 12 Aug 2008 08:37:48 -0700
> From: Thomas Lord <lord@emf.net>
> Subject: Re: Release plans
> To: Miles Bader <miles@gnu.org>
> Cc: Juanma Barranquero <lekktu@gmail.com>, ich@frank-schmitt.net,
>        rms@gnu.org,    emacs-devel@gnu.org
> Message-ID: <48A1AE4C.2000301@emf.net>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Miles Bader wrote:
>> Thomas Lord <lord@emf.net> writes:
>>
>>> The more urgent issue concerns the emerging W3C-based world:
>>> what will GNU have to offer there?
>>>
>>
>> Hopefully, an alternative...
>>
>
> That's pithy but I don't actually get it.   Why call for an alternative?
>

Maybe the lack of freedom in today's Web architecture. In his
dissertation, Roy T. Fielding describes REST as an architectural
style. According to him, «examples of architectural styles include the
"null style" (which has no constrains at all), pipe and filter,
client/server, distributed objects and — you guessed it — REST» (1).
As i said elsewhere, internet is by nature a decentralized network, so
distributed architectures will prevail sooner or later... While I
appreciate your analysis and share most of your points, i agree with
RMS about the lack of freedom in the design of the web...

A Quote from Mr. Paul Stacey:
«Peer-to-peer systems have existed since the first incarnation of the
Internet. In recent times the Internet has taken on a more
hierarchical form, power has been taken away from the individual and
placed in the hands of operators of large servers. However, with the
re-emergence of p2p the individual is gaining more freedom. End users
attached to the Internet now have the power to host and publish
content through the user of p2p technologies...»
(Stacey, Paul, "Peer-to-peer searching and sharing of electronic
documents" (2004). Masters. Paper 9.)
( http://arrow.dit.ie/engmas/9 )

Hope this can help.

christophe

(1) http://mauriziostorani.wordpress.com/2008/07/27/rest-representational-state-transfer-and-restful-web-services-concepts-and-examples/

Re: Release plans

[A Soare]

> >>> In my case the initial hypothesis is true; the general case is false:
> >>>
> >>> 1. initial: X1 X2 ... Xn do not use Emacs
> >>>
> >>> 2. general: nobody uses Emacs
> >>
> >> Is not that extrapolation rather than induction? ;-)
> > 
> > Maybe, I do not know. Induction is surely.
> 
> Maybe this is not the place for math education, but you are missing one 
> piece to make it induction:
> 
> - There should be something that asserts that the condition holds also 
> for next step.
> 
> It might happen even to you that you meat a person who uses Emacs on 
> windows ...
> 


Sure , you are right . A good thing for you to do is to read my code of indentation and to help me document it better before installing it.

http://lists.gnu.org/archive/html/emacs-devel/2008-08/msg00437.html

*****

From my knowledge, induction has 2 steps:

1. prove that initial cond. is true. and suppose that it is also true for some N

2. prove using these 2 propositions that it is also valid for N+1

I quote: http://fr.wikipedia.org/wiki/Induction


l'induction est étudiée en philosophie ; c'est une démarche intellectuelle familière qui consiste à procéder par inférence probable, c'est-à-dire à déduire des lois par généralisation des observations. Par exemple, en l'absence de toute connaissance scientifique en astronomie, la plupart des gens s'attendent à voir le Soleil se lever le lendemain matin. Au sein du travail scientifique, et à condition de bien en mesurer les limites, l'induction peut trouver sa place. Par exemple, l'accumulation d'études monographiques peut conduire à formuler, par généralisation, des propositions relatives au changement social. Mais il ne s'agit pas là d'inductivisme, car les chercheurs sont orientés dans leurs observations monographiques par une problématique théorique qui guide leur construction des faits.
En mathématiques, en logique et en informatique, l'induction complète, aujourd'hui très souvent abrégée en induction, est une autre façon de désigner la récurrence : aussi bien le raisonnement par récurrence que les définitions par récurrence.


L'induction en revanche génère du sens en passant des faits à la loi, du particulier au général.


____________________________________________________

Avant de prendre le volant, repérez votre itinéraire et visualisez le trafic ! http://itineraire.voila.fr/itineraire.html

Re: Release plans

[Lennart Borgman (gmail)]

A Soare wrote:
> A good thing for you to do is to read my code of indentation and to help me document it better before installing it.
> 
> http://lists.gnu.org/archive/html/emacs-devel/2008-08/msg00437.html

Sorry, I do not have time. I hope someone else have (but be prepared to 
wait for that).

> I quote: http://fr.wikipedia.org/wiki/Induction
> 
> l'induction est étudiée en philosophie ;

They use to say you have a big advantage if you can use your native 
language in discussions ... ;-)

Re: Release plans

[A Soare]

> It has been known for programmers enamoured of the Windows OS to complain
> quite loudly at the lack of a "decent editor" in Unix.  ;-)

I heard this many times too.

The users (i.e. programmers) will choose almost always estetic editors. So this ideal must be considered in order to keep peuple using it.

The great ideal of emacs should be that all its modules work well.

This idea is expressed in one word (sorry, in one image) by IAS seal:

http://www.ias.edu/midcom-serveattachmentguid-f05347fcb97955f36a78b35d9ae6a202/IAS_Logo_for_%20Simonyi_Color.jpg


____________________________________________________

Avant de prendre le volant, repérez votre itinéraire et visualisez le trafic ! http://itineraire.voila.fr/itineraire.html

Re: Release plans

[Mike Rowse]

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

I read this mailings list so I thought I might chip in on this discussion of Emacs on Windows. 

I have used Emacs on Windows. The reason that I did was that I found myself in a job where I had to use Windows (due to the building IT infrastructure). As it turned out there were a lot of jobs that I had to do that things like macros and small custom functions made a huge difference and saved me insane amounts of time. 

In fact now that I think about it, it was around this time that began to learn a lot more about Emacs (having used it at little here and there before hand). 

The current version may be all that is needed for these kinds of tasks though. 



I may just be the odd one out, but this seemed relevant to the discussion. 



Cheers
--------------------------------------------------------

On-line full-fee registration for Congress 2008 still open! Register now!
Visit: www.waccglobal.org/congress
 
Aun están abiertas las inscripciones para el Congreso 2008 en línea! Inscríbete ya!
Visita el sitio: www.waccglobal.org/congress
 
Inscription en-ligne (avec paiement complet) pour le Congrès 2008 est toujours ouverte ! Inscrivez-vous maintenant!
Visitez: www.waccglobal.org/congress
 
The World Association for Christian Communication is a UK Registered Charity (number 296073) and a Company registered in England and Wales (number 2082273) with its Registered Office at 36 Causton Street, London SW1P 4ST. It is an incorporated Charitable Organisation in Canada (number 83970 9524 RR0001) with its offices at 308 Main Street, Toronto ON, M4C 4X7.

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 3334 bytes --]

Re: Release plans

[Robert J. Chassell]

    > Whether one loads proprietary modules into the kernel is a personal
    > decision and I don't like deciding for other people.

No; it is not a personal decision.  When you load proprietary modules,
you are telling those who pay attention that you do not mind restricting
yourself.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Release plans

[Johannes Weiner]

Hi,

bob@rattlesnake.com (Robert J. Chassell) writes:

>     > Whether one loads proprietary modules into the kernel is a personal
>     > decision and I don't like deciding for other people.
>
> No; it is not a personal decision.  When you load proprietary modules,
> you are telling those who pay attention that you do not mind restricting
> yourself.

What has sentence a to do with sentence b?

	Hannes

Re: Release plans

[Robert J. Chassell]

    bob@rattlesnake.com (Robert J. Chassell) writes:

    >     > Whether one loads proprietary modules into the kernel is a personal
    >     > decision and I don't like deciding for other people.
    >
    > No; it is not a personal decision.  When you load proprietary modules,
    > you are telling those who pay attention that you do not mind restricting
    > yourself.

    What has sentence a to do with sentence b?

You are not being personal when you make a decision involving others --
perhaps you are thinking, `I am the one making the decision'.  That is
true.  But the consequences don't involve you alone.  You are telling
others that you accept this sort of restriction.  That is critical and
what I was trying to say.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Release plans

[Johannes Weiner]

Hi,

bob@rattlesnake.com (Robert J. Chassell) writes:

>     bob@rattlesnake.com (Robert J. Chassell) writes:
>
>     >     > Whether one loads proprietary modules into the kernel is a personal
>     >     > decision and I don't like deciding for other people.
>     >
>     > No; it is not a personal decision.  When you load proprietary modules,
>     > you are telling those who pay attention that you do not mind restricting
>     > yourself.
>
>     What has sentence a to do with sentence b?
>
> You are not being personal when you make a decision involving others --
> perhaps you are thinking, `I am the one making the decision'.  That is
> true.  But the consequences don't involve you alone.  You are telling
> others that you accept this sort of restriction.  That is critical and
> what I was trying to say.

Okay, if you make such a decision, you are automatically a role model
for others.

But whether you take that decision away from others is a philosophical
attitude.  I wouldn't choose to do so but I would also not trade
software power for potential harm the law already protects against, as
Stephen Turnbull explained it does.

IMHO, the better approach is a psychological one.  Yes, explain to
people why you consider it bad for them and their environment to do
certain things.  Education is good.  Spreading the understanding that it
is stupid and self- and others-harming to use proprietary software if
you think that this is the case and I am fine with that.  I share this
opinion, by the way, just to be clear, and I also explain this to people
using non-free software.

But I think leaving useful features (that are not restricting the user
in any way) out of the software is a bad decision.  Even worse when the
law would already protect from abuse.

And just to not go into a loop here again, I am aware that I could
theoretically fork GNU Emacs and implement the feature I want.  But I
care about GNU Emacs itself and I wouldn't spend so much time to explain
my standpoint if I didn't.

	Hannes