Fwd: CEDET sync

Fwd: CEDET sync

[Lluís]

Hi there.

I'm testing some changes in EDE that Eric (the author od CEDET) did to automake
parsing in order to gracefully handle non-recursive automake projects.

Problem is, changes are in the CEDET CVS, and I'd like to port them to emacs'
bzr, as my current configuration is already specific to the Emacs' integrated
CEDET version.

So, instead of blindly porting changes from the EDE component, I thought it
might be useful to port the whole changes from CEDET, now that version 1.0pre7
has been recently released (I assume that such sync is out of the 23.2 time
frame, as it's too close).

Questions are:
    1) is anybody already doing such a sync?
    2) if not, from which date should I start synchronizing changes?

I'm not fully aware of which extra changes are required for the synchronization
(except for the long name -> subdirectory fix), so directions will be much
appreciated.


Thanks,
        Lluis

--
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth

Re: Fwd: CEDET sync

[Chong Yidong]

Lluís <xscript@gmx.net> writes:

> Questions are:
>     1) is anybody already doing such a sync?
>     2) if not, from which date should I start synchronizing changes?
>
> I'm not fully aware of which extra changes are required for the synchronization
> (except for the long name -> subdirectory fix), so directions will be much
> appreciated.

I planned to do a sync after the Emacs 23.2 release branch is made, but
you are welcome to do it if you like.

Re: Fwd: CEDET sync

[Lennart Borgman]

On Mon, Mar 1, 2010 at 7:59 PM, Chong Yidong <cyd@stupidchicken.com> wrote:
> Lluís <xscript@gmx.net> writes:
>
>> Questions are:
>>     1) is anybody already doing such a sync?
>>     2) if not, from which date should I start synchronizing changes?
>>
>> I'm not fully aware of which extra changes are required for the synchronization
>> (except for the long name -> subdirectory fix), so directions will be much
>> appreciated.
>
> I planned to do a sync after the Emacs 23.2 release branch is made, but
> you are welcome to do it if you like.


What is the reason for not doing it now?

Re: Fwd: CEDET sync

[Stefan Monnier]

>> Questions are:
>> 1) is anybody already doing such a sync?
>> 2) if not, from which date should I start synchronizing changes?
>> 
>> I'm not fully aware of which extra changes are required for the synchronization
>> (except for the long name -> subdirectory fix), so directions will be much
>> appreciated.

> I planned to do a sync after the Emacs 23.2 release branch is made, but
> you are welcome to do it if you like.

I really don't like that smell.  We need to make sure the two code-bases
evolve in-sync, which won't work as long as we keep "gratuitous"
differences between the two (file names and things like that).

I thought Eric was to incorporate most/all of the changes we made into
his version.  If this doesn't take place real soon, it'll become much
too painful to maintain.


        Stefan

Re: Fwd: CEDET sync

[Fabian Ezequiel Gallina]

2010/3/1 Stefan Monnier <monnier@iro.umontreal.ca>:
>
> I really don't like that smell.  We need to make sure the two code-bases
> evolve in-sync, which won't work as long as we keep "gratuitous"
> differences between the two (file names and things like that).
>
> I thought Eric was to incorporate most/all of the changes we made into
> his version.  If this doesn't take place real soon, it'll become much
> too painful to maintain.
>

Right now because of the incompatibilities between both versions of
CEDET I installed the main project's CVS one and I'm using just that.

From my user point of view, these incompatibilities are quite annoying
and keeping things that way will probably make the merge useless and
people will prefer to install CEDET by themselves anyways.


Best Regards,
-- 
Fabián E. Gallina
http://www.from-the-cloud.com

Re: Fwd: CEDET sync

[Eric M. Ludlam]

On 03/01/2010 04:27 PM, Stefan Monnier wrote:
>>> Questions are:
>>> 1) is anybody already doing such a sync?
>>> 2) if not, from which date should I start synchronizing changes?
>>>
>>> I'm not fully aware of which extra changes are required for the synchronization
>>> (except for the long name ->  subdirectory fix), so directions will be much
>>> appreciated.
>
>> I planned to do a sync after the Emacs 23.2 release branch is made, but
>> you are welcome to do it if you like.
>
> I really don't like that smell.  We need to make sure the two code-bases
> evolve in-sync, which won't work as long as we keep "gratuitous"
> differences between the two (file names and things like that).
>
> I thought Eric was to incorporate most/all of the changes we made into
> his version.  If this doesn't take place real soon, it'll become much
> too painful to maintain.

Indeed, that is my plan.  I fear the big merge will make it harder to 
support older Emacsen and XEmacs, so I wanted to get some sort of stable 
release out that can finalize that style of CEDET.  It's just been slow. 
  Since I don't have a feature freeze or anything, CEDET keeps getting a 
little better over time, almost without me, while I've been getting test 
suites up and running against various Emacs flavors.

My hope is that this last release I did shows few build/compatibility 
problems and I can easily just post the last release on CVS, then move 
on.  Last year issues and patches kept coming for a couple months.  It's 
been much slower this time around.

Eric

AW: Fwd: CEDET sync

[Berndl, Klaus]

From my point of view which is also ECBs point of view:

Supporting not only Emacs but also Xemacs should be a value upheld be tools like CEDET and ECB, even when merged into Emacs. But cause of some really heavy incompatibilities between these both flavors of Emacs it is a smart move to decide where to invest the main power (of development). And IMHO a) GNU Emacs has high potential future (just compare the different traffic on the both development mailing lists) whereas b) Xemacs is headed south (again IMHO) and will be of little importance for software development - but a) one only if it (Emacs) goes the way towards a really Integrated development environment (IDE) - for this a stable backbone like CEDET is essetial and also essential that this backbone is a stable part of Emacs.

Eric, please do not wait with CEDET 1.0 release until thew cows come home...IMHO CEDET 1.0 should have been released month (or even years) ago... Push it out and that's it. Then please merge the two code bases as soon as possible and factorize out all Xemacs-compatibility stuff into some separated libraries like cedet-xemacs-support.el. I have decided to this for my ECB to make a clear code-basis for the main development direction (which is Emacs). So on one hand CEDET will have a unique code-structure and can be evolved easily even with two repositories (Emacs and CEDET-project) and you can uphold the Xemacs-compatibility by just maintaining the "cedet-xemacs-support.el"...

For a tool like ECB it's a pain to support two different main interfaces for one external library. So i second Stefan and my vote for the priorities is: No further effort for CEDET 1.0 but all effort into the merge. Many many many ... many thanks in advance from me!

Best Regards
Klaus

-----Ursprüngliche Nachricht-----
Von: emacs-devel-bounces+klaus.berndl=sdm.de@gnu.org [mailto:emacs-devel-bounces+klaus.berndl=sdm.de@gnu.org] Im Auftrag von Eric M. Ludlam
Gesendet: Montag, 1. März 2010 23:43
An: Stefan Monnier
Cc: Chong Yidong; Lluís; emacs-devel@gnu.org
Betreff: Re: Fwd: CEDET sync

On 03/01/2010 04:27 PM, Stefan Monnier wrote:
>>> Questions are:
>>> 1) is anybody already doing such a sync?
>>> 2) if not, from which date should I start synchronizing changes?
>>>
>>> I'm not fully aware of which extra changes are required for the synchronization
>>> (except for the long name ->  subdirectory fix), so directions will be much
>>> appreciated.
>
>> I planned to do a sync after the Emacs 23.2 release branch is made, but
>> you are welcome to do it if you like.
>
> I really don't like that smell.  We need to make sure the two code-bases
> evolve in-sync, which won't work as long as we keep "gratuitous"
> differences between the two (file names and things like that).
>
> I thought Eric was to incorporate most/all of the changes we made into
> his version.  If this doesn't take place real soon, it'll become much
> too painful to maintain.

Indeed, that is my plan.  I fear the big merge will make it harder to 
support older Emacsen and XEmacs, so I wanted to get some sort of stable 
release out that can finalize that style of CEDET.  It's just been slow. 
  Since I don't have a feature freeze or anything, CEDET keeps getting a 
little better over time, almost without me, while I've been getting test 
suites up and running against various Emacs flavors.

My hope is that this last release I did shows few build/compatibility 
problems and I can easily just post the last release on CVS, then move 
on.  Last year issues and patches kept coming for a couple months.  It's 
been much slower this time around.

Eric

AW: Fwd: CEDET sync

[Stephen J. Turnbull]

Berndl, Klaus writes:

 > Supporting not only Emacs but also Xemacs should be a value upheld
 > be tools like CEDET and ECB, even when merged into Emacs. But cause
 > of some really heavy incompatibilities between these both flavors
 > of Emacs it is a smart move to decide where to invest the main
 > power (of development). And IMHO a) GNU Emacs has high potential
 > future (just compare the different traffic on the both development
 > mailing lists) whereas b) Xemacs is headed south (again IMHO)

The reports of the death of XEmacs are greatly exaggerated.  Look
here:

http://list-archive.xemacs.org/pipermail/xemacs-patches/2010-February/

(and divide by 2 as most patches get posted twice, once by the
submitter and again by the commit 'bot).

You should also remember that SXEmacs also has a fair following now;
measuring only by the traffic on the XEmacs lists is not necessarily
representative of the interest in XEmacs APIs.

Re: AW: Fwd: CEDET sync

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Berndl, Klaus writes:
>
>  > Supporting not only Emacs but also Xemacs should be a value upheld
>  > be tools like CEDET and ECB, even when merged into Emacs. But cause
>  > of some really heavy incompatibilities between these both flavors
>  > of Emacs it is a smart move to decide where to invest the main
>  > power (of development). And IMHO a) GNU Emacs has high potential
>  > future (just compare the different traffic on the both development
>  > mailing lists) whereas b) Xemacs is headed south (again IMHO)
>
> The reports of the death of XEmacs are greatly exaggerated.  Look
> here:

Worms may wriggle, too.  The question is whether there is a central
agency moving forward.  There has been recent rekindling of work in core
areas, but following years of quiescence.

As long as everybody caters for _his_ favorite editor and takes care not
to sabotage the work of others catering for _theirs_, the systems will
thrive according to the interest in them.  I would recommend against
dedicating resources to systems you don't actively use yourself.
Putting projects on foreign "life support" is not going to make them
survive on their own strengths.

-- 
David Kastrup

Re: AW: Fwd: CEDET sync

[Lennart Borgman]

On Tue, Mar 2, 2010 at 10:35 AM, David Kastrup <dak@gnu.org> wrote:
> "Stephen J. Turnbull" <stephen@xemacs.org> writes:
>
>> Berndl, Klaus writes:
>>
>>  > Supporting not only Emacs but also Xemacs should be a value upheld
>>  > be tools like CEDET and ECB, even when merged into Emacs. But cause
>>  > of some really heavy incompatibilities between these both flavors
>>  > of Emacs it is a smart move to decide where to invest the main
>>  > power (of development). And IMHO a) GNU Emacs has high potential
>>  > future (just compare the different traffic on the both development
>>  > mailing lists) whereas b) Xemacs is headed south (again IMHO)
>>
>> The reports of the death of XEmacs are greatly exaggerated.  Look
>> here:
>
> Worms may wriggle, too.  The question is whether there is a central
> agency moving forward.  There has been recent rekindling of work in core
> areas, but following years of quiescence.
>
> As long as everybody caters for _his_ favorite editor and takes care not
> to sabotage the work of others catering for _theirs_, the systems will
> thrive according to the interest in them.  I would recommend against
> dedicating resources to systems you don't actively use yourself.
> Putting projects on foreign "life support" is not going to make them
> survive on their own strengths.


I think the worst problem is the scattering of scarce resources. Eric
Ludlam is such a resource ;-)

And of course also Stephen Turnbull.

AW: AW: Fwd: CEDET sync

[Berndl, Klaus]

On Tue, Mar 2, 2010 at 10:35 AM, David Kastrup <dak@gnu.org> wrote:
>> "Stephen J. Turnbull" <stephen@xemacs.org> writes:
>>
>>> Berndl, Klaus writes:
>>>
>>>  > Supporting not only Emacs but also Xemacs should be a value upheld
>>>  > be tools like CEDET and ECB, even when merged into Emacs. But cause
>>>  > of some really heavy incompatibilities between these both flavors
>>>  > of Emacs it is a smart move to decide where to invest the main
>>>  > power (of development). And IMHO a) GNU Emacs has high potential
>>>  > future (just compare the different traffic on the both development
>>>  > mailing lists) whereas b) Xemacs is headed south (again IMHO)
>>>
>>> The reports of the death of XEmacs are greatly exaggerated.  Look
>>> here:
>>
>> Worms may wriggle, too.  The question is whether there is a central
>> agency moving forward.  There has been recent rekindling of work in core
>> areas, but following years of quiescence.
>>
>> As long as everybody caters for _his_ favorite editor and takes care not
>> to sabotage the work of others catering for _theirs_, the systems will
>> thrive according to the interest in them.  I would recommend against
>> dedicating resources to systems you don't actively use yourself.
>> Putting projects on foreign "life support" is not going to make them
>> survive on their own strengths.


>I think the worst problem is the scattering of scarce resources. Eric
>Ludlam is such a resource ;-)

exactly - therefore my vote for focussing the scarce resources to the most
important tasks - otherwise there will be a very high risk to get bogged
down...

Klaus

Re: AW: Fwd: CEDET sync

[Lennart Borgman]

On Tue, Mar 2, 2010 at 11:36 AM, Berndl, Klaus
<klaus.berndl@capgemini-sdm.com> wrote:
>
>>I think the worst problem is the scattering of scarce resources. Eric
>>Ludlam is such a resource ;-)
>
> exactly - therefore my vote for focussing the scarce resources to the most
> important tasks - otherwise there will be a very high risk to get bogged
> down...


And you are of course a scarce resource too and I have noticed you
have had difficulties to find time to support ECB as you want to.

It is a common and serious problem and one we must fight if we want
free software to succeed.

The diversity hits the users too. As I have said I recently had a
discussion with a long term GNU/Linux user who jump off to Windows 7
because the quality of the mid-level library was too low on GNU/Linux.
The key factor was the diversity (too many libraries doing the same
thing) which he thought creates this problem.

I think solving this is urgent - and very, very difficult.

AW: AW: Fwd: CEDET sync

[Berndl, Klaus]

On Tue, Mar 2, 2010 at 11:36 AM, Berndl, Klaus
<klaus.berndl@capgemini-sdm.com> wrote:
>>
>>>I think the worst problem is the scattering of scarce resources. Eric
>>>Ludlam is such a resource ;-)
>>
>> exactly - therefore my vote for focussing the scarce resources to the most
>> important tasks - otherwise there will be a very high risk to get bogged
>> down...

>And you are of course a scarce resource too and I have noticed you
>have had difficulties to find time to support ECB as you want to.

Yes, indeed - and therefore i have made hard priorities:
1. Making ECB compatible with current Emacs-development-stream (currently 23.2)
2. Fixing serious bugs
3. - 5. Nothing
6. Some small and not time-consuming enhancements
7. Some but only very few compatibility checks after 1 - 6 if Xemacs still works

This eats up all my time available for maintaining ECB. Unfortunatelly i have no time
(and probably will not find any time in the near-term and medium-term future) to
work on the heavy rewritting of the layout engine for the sake of eliminating (or at least 
reducing) the bunch of heavy-weighted advices and instead bringing forward the emacs-
display-engine to be ready for layouting something like ECB without the need of advices.
This would be also a good example for the conflict between the advantages of merging ECB into
Emacs and the value uphelding compatibility of Xemacs: Replacing the ECB-advices with
Emacs-internal mechanisms would in fact either throw away the XEmacs-compatibility of ECB
or would "cost" an even much more complex layout code of ECB as it is currently.
Well, merging ECB and my available time is off-topic to this thread... ;-)

>It is a common and serious problem and one we must fight if we want
>free software to succeed.

Re: AW: AW: Fwd: CEDET sync

[Juri Linkov]

> Unfortunatelly i have no time (and probably will not find any time
> in the near-term and medium-term future) to work on the heavy rewritting
> of the layout engine for the sake of eliminating (or at least
> reducing) the bunch of heavy-weighted advices and instead bringing
> forward the emacs- display-engine to be ready for layouting something
> like ECB without the need of advices.  This would be also a good
> example for the conflict between the advantages of merging ECB into
> Emacs and the value uphelding compatibility of Xemacs: Replacing the
> ECB-advices with Emacs-internal mechanisms would in fact either throw
> away the XEmacs-compatibility of ECB or would "cost" an even much more
> complex layout code of ECB as it is currently.

IIUC, the main obstacle is that window configurations currently don't have
a read syntax.  Once this is implemented it would be possible to define
different layouts (with window properties), save/restore them, etc.

From a recent discussion, I remember that now Emacs has the hash table
read syntax compatible with XEmacs.  Since XEmacs have lots of other
object types, maybe XEmacs already has a read syntax for window
configurations too?  In this case, it would be easier to keep
compatibility with XEmacs in ECB.

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

Re: AW: AW: Fwd: CEDET sync

[Stephen J. Turnbull]

Juri Linkov writes:

 > Since XEmacs have lots of other object types, maybe XEmacs already
 > has a read syntax for window configurations too?  In this case, it
 > would be easier to keep compatibility with XEmacs in ECB.

The person to ask is probably Mike Sperber (cc'd).

He's been busy recently, give him a few days to respond.

Re: AW: AW: Fwd: CEDET sync

[Michael Sperber]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Juri Linkov writes:
>
>  > Since XEmacs have lots of other object types, maybe XEmacs already
>  > has a read syntax for window configurations too?  In this case, it
>  > would be easier to keep compatibility with XEmacs in ECB.
>
> The person to ask is probably Mike Sperber (cc'd).
>
> He's been busy recently, give him a few days to respond.

Window configurations in XEmacs don't have read syntax, but they're
pretty close, and thus it wouldn't be hard to do.  I lack context from
this discussion: Is there a read syntax in GNU Emacs and/or an API that
I should try to emulate?  (When I do `(current-window-configuration)'
there, I just get "#<window-configuration>".)  Or, lacking that,
specific requirements for them.<

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla

read syntax for window configs (was: CEDET sync)

[Drew Adams]

> >  > Since XEmacs have lots of other object types, maybe 
> >  > XEmacs already has a read syntax for window configurations
> 
> Window configurations in XEmacs don't have read syntax, but they're
> pretty close, and thus it wouldn't be hard to do.

Read syntax for window (and frame) configs would be very welcome.

Currently, we have things like desktop.el that save some session state, but they
don't save window/frame configs. Lennart was working on something that did that
(winsav.el), but AFAIK he's sort of abandoned it.

FWIW, one of my libraries bookmarks desktops, so you can more easily switch
among different contexts (desktop files). It would be nice to do the same for
window/frame configs.

And it would be nice for desktop.el (and the like) to optionally save
window/frame state also. (Yes, it should be optional.)

And it's obviously good if all such efforts can use the same serialization
format - i.e., if Emacs itself has a read syntax for window/frame configs.

Re: read syntax for window configs (was: CEDET sync)

[Lennart Borgman]

On Fri, Mar 5, 2010 at 6:07 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> >  > Since XEmacs have lots of other object types, maybe
>> >  > XEmacs already has a read syntax for window configurations
>>
>> Window configurations in XEmacs don't have read syntax, but they're
>> pretty close, and thus it wouldn't be hard to do.
>
> Read syntax for window (and frame) configs would be very welcome.
>
> Currently, we have things like desktop.el that save some session state, but they
> don't save window/frame configs. Lennart was working on something that did that
> (winsav.el), but AFAIK he's sort of abandoned it.


Eh, no, I have not abondoned it. I am using it and it is part of nXhtml.

To make it work properly in all cases more than simple read syntax is
required though.

Re: read syntax for window configs

[Juri Linkov]

>> Lennart was working on something that did that (winsav.el),
>> but AFAIK he's sort of abandoned it.
>
> Eh, no, I have not abondoned it. I am using it and it is part of nXhtml.
>
> To make it work properly in all cases more than simple read syntax is
> required though.

Yes, it requires different representations for different tasks:

1. To manipulate window configurations in one session, a cons tree should keep
pointers to window structures in memory.

2. To save/restore a window configuration to/from .emacs.desktop
requires to serialize/deserialize the window tree.  There is already
buffer serialization using `desktop-create-buffer', but no for windows.

3. To customize window layouts like `ecb-layout-define' that uses
percentage instead of absolute window coordinates.

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

Re: read syntax for window configs

[Juri Linkov]

> Read syntax for window (and frame) configs would be very welcome.
>
> Currently, we have things like desktop.el that save some session state, but they
> don't save window/frame configs.

There is a task in etc/TODO:

  ** Make desktop.el save the "frame configuration" of Emacs (in some
    useful sense).

> FWIW, one of my libraries bookmarks desktops, so you can more easily switch
> among different contexts (desktop files).

This looks like another task in etc/TODO:

  ** Give desktop.el a feature to switch between different named
    desktops.

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

RE: read syntax for window configs

[Drew Adams]

> > Read syntax for window (and frame) configs would be very welcome.
> >
> > Currently, we have things like desktop.el that save some 
> > session state, but they don't save window/frame configs.
> 
> There is a task in etc/TODO:
> 
>   ** Make desktop.el save the "frame configuration" of Emacs (in some
>     useful sense).

Better to separate that feature out. Have a separate feature (library) to save
window/frame configs. And then let desktop.el optionally make use of that
separate feature.

IOW, saving/restoring buffers, variables, etc. (what desktop does today) is
different from saving/restoring window/frame configs. There is no reason to
couple them by putting them in the same library - no reason to require code that
needs only one of the features to load a big library that does both.

> > FWIW, one of my libraries bookmarks desktops, so you can 
> > more easily switch among different contexts (desktop files).
> 
> This looks like another task in etc/TODO:
> 
>   ** Give desktop.el a feature to switch between different named
>     desktops.

Desktop has an unfortunate limitation (IMO) that is also, it seems, somewhat
gratuitous: It expects (and therefore pretty much requires) only one desktop
file per directory. All of the desktop.el functions are written that way - they
drive off of a directory name. 

That means that trying to use the desktop.el code to do something more flexible,
switching among arbitrary desktop files located anywhere, is ugly. My code has
to jump through some otherwise unnecessary hoops to do this. I had to duplicate
and modify some of the desktop.el code, just to get around this function
interface.

Anyway, the TODO item you cite is fine, but a welcome preliminary TODO item
would be to change the desktop.el functions to accept (at least optionally) a
desktop file location (file name), and not just rely on a directory.

See also thread "desktop.el - only one desktop file per directory?",
http://lists.gnu.org/archive/html/emacs-devel/2010-01/msg01112.html

---

FWIW, my bookmark code is a trivial extension to bookmark.el, which defines a
`desktop' bookmark type. I just define:

1. A command to set a desktop bookmark (reads a file name and writes a desktop
file).

2. A function to make a desktop bookmark record ( records the desktop file and a
desktop bookmark handler).

3. A desktop bookmark handler (gets the desktop file name from the bookmark and
changes to that saved desktop).

The code is here:
http://www.emacswiki.org/emacs/bookmark%2b.el

Because I allow multiple desktop files per dir, the code for #1 and #3 is more
involved that it should need to be. With more reasonable desktop.el functions,
which accepted a desktop file name, it would be short and simple.

Note: My code doesn't worry about multiple users and sessions wrt locks - it is
rudimentary (hence fragile) wrt locking. While I allow multiple desktop files
per dir, I haven't bothered to try to handle multiple lock files per dir etc.

Really, it is an individual desktop file (not a directory) that should have an
associated lock. Truly breaking with the current directory-level granularity
would require handling locks on a per-file basis, I imagine (but I'm no expert
on how the locking works).

If the TODO item I proposed were implemented, then the necessary file-level
locking would hopefully be taken care of also.

Re: read syntax for window configs

[Michael Sperber]

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


"Drew Adams" <drew.adams@oracle.com> writes:

>> >  > Since XEmacs have lots of other object types, maybe 
>> >  > XEmacs already has a read syntax for window configurations
>> 
>> Window configurations in XEmacs don't have read syntax, but they're
>> pretty close, and thus it wouldn't be hard to do.
>
> Read syntax for window (and frame) configs would be very welcome.

I've attached code that works for XEmacs.  Is this along the line of
what you'd like?

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla

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

(defun window-configuration->sexp (config)
  "Convert a window configuration to a readable S-expression."
  `(window-configuration
    (frame . ,(position (window-configuration-frame config) (frame-list))) ; lame, but the best we can do
    (frame-top . ,(window-configuration-frame-top config))
    (frame-left . ,(window-configuration-frame-left config))
    (frame-pixel-width . ,(window-configuration-frame-pixel-width config))
    (frame-pixel-height . ,(window-configuration-frame-pixel-height config))
    (current-buffer . ,(buffer-name (window-configuration-current-buffer config)))
    (minibuffer-pixel-height . ,(window-configuration-minibuffer-pixel-height config))
    (min-width . ,(window-configuration-min-width config))
    (min-height . ,(window-configuration-min-height config))
    (saved-root-window . ,(saved-window->sexp (window-configuration-saved-root-window config)))))

(defun saved-window->sexp (saved)
  "Convert a saved-window structure to a readable S-expression."
  `(saved-window
    (currentp . ,(saved-window-currentp saved))
    (minibufferp . ,(saved-window-minibuffer-scrollp saved))
    (minibuffer-scrollp . ,(saved-window-minibuffer-scrollp saved))
    (buffer . ,(buffer-name (saved-window-buffer saved)))
    (mark-marker . ,(maybe-marker-position (saved-window-mark-marker saved)))
    (start-marker . ,(maybe-marker-position (saved-window-start-marker saved)))
    (point-marker . ,(maybe-marker-position (saved-window-point-marker saved)))
    (pixel-left . ,(saved-window-pixel-left saved))
    (pixel-top . ,(saved-window-pixel-top saved))
    (pixel-right . ,(saved-window-pixel-right saved))
    (pixel-bottom . ,(saved-window-pixel-bottom saved))
    (hscroll . ,(saved-window-hscroll saved))
    (modeline-hscroll . ,(saved-window-modeline-hscroll saved))
    (dedicatedp . ,(saved-window-dedicatedp saved))
    (first-hchild . ,(maybe-saved-window->sexp (saved-window-first-hchild saved)))
    (first-vchild . ,(maybe-saved-window->sexp (saved-window-first-vchild saved)))
    (next-child . ,(maybe-saved-window->sexp (saved-window-next-child saved)))))

(defun maybe-saved-window->sexp (saved)
  "Like `saved-window->sexp', but also accepts nil."
  (and saved (saved-window->sexp saved)))

(defun maybe-marker-position (marker)
  "Extract position from marker, or return nil for nil marker."
  (and marker (marker-position marker)))

(defun sexp->window-configuration (sexp)
  "Convert return value of `window-configuration->sexp' back into window config."
  (make-window-configuration
   :frame (let ((pos (sexp-tag->value sexp 'frame))
		(frames (frame-list)))
	    (if (< pos (length frames))
		(nth pos frames)
	      (car frames)))
   :frame-top (sexp-tag->value sexp 'frame-top)
   :frame-left (sexp-tag->value sexp 'frame-left)
   :frame-pixel-width (sexp-tag->value sexp 'frame-pixel-width)
   :frame-pixel-height (sexp-tag->value sexp 'frame-pixel-height)
   :current-buffer (get-buffer-create (sexp-tag->value sexp 'current-buffer))
   :min-width (sexp-tag->value sexp 'min-width)
   :min-height (sexp-tag->value sexp 'min-height)
   :minibuffer-pixel-height (sexp-tag->value sexp 'minibuffer-pixel-height)
   :saved-root-window (sexp->saved-window (sexp-tag->value sexp 'saved-root-window))))

(defun sexp->saved-window (sexp)
  "Convert return value of `saved-window->sexp' back into saved window."
  (let ((buf (get-buffer-create (sexp-tag->value sexp 'buffer))))
    (make-saved-window
     :window nil			; sorry
     :currentp (sexp-tag->value sexp 'currentp)
     :minibufferp (sexp-tag->value sexp 'minibufferp)
     :minibuffer-scrollp (sexp-tag->value sexp 'minibuffer-scrollp)
     :buffer buf
     :mark-marker (maybe-marker-position->marker buf (sexp-tag->value sexp 'mark-marker))
     :start-marker (maybe-marker-position->marker buf (sexp-tag->value sexp 'start-marker))
     :point-marker (maybe-marker-position->marker buf (sexp-tag->value sexp 'point-marker))
     :pixel-left (sexp-tag->value sexp 'pixel-left)
     :pixel-top (sexp-tag->value sexp 'pixel-top)
     :pixel-right (sexp-tag->value sexp 'pixel-right)
     :pixel-bottom (sexp-tag->value sexp 'pixel-bottom)
     :hscroll (sexp-tag->value sexp 'hscroll)
     :modeline-hscroll (sexp-tag->value sexp 'modeline-hscroll)
     :dedicatedp (sexp-tag->value sexp 'dedicatedp)
     :first-hchild (maybe-sexp->saved-window (sexp-tag->value sexp 'first-hchild))
     :first-vchild (maybe-sexp->saved-window (sexp-tag->value sexp 'first-vchild))
     :next-child (maybe-sexp->saved-window (sexp-tag->value sexp 'next-child)))))

(defun maybe-sexp->saved-window (sexp)
  "Like `sexp->saved-window', but accepts nil."
  (and sexp (sexp->saved-window sexp)))

(defun sexp-tag->value (sexp tag)
  "Extract value for tag in S-expression sexp.
This works for the values returned by `window-configuration->sexp' and
`saved-window->sexp'.  Returns nil if the tag is not there."
  (cdr (assq tag (cdr sexp))))

(defun maybe-marker-position->marker (buffer pos)
  "Turn nil or a marker position into a marker."
  (let ((marker (make-marker)))
    (set-marker marker pos buffer)
    marker))

RE: read syntax for window configs

[Drew Adams]

> >> >  > Since XEmacs have lots of other object types, maybe 
> >> >  > XEmacs already has a read syntax for window configurations
> >> 
> >> Window configurations in XEmacs don't have read syntax, but they're
> >> pretty close, and thus it wouldn't be hard to do.
> >
> > Read syntax for window (and frame) configs would be very welcome.
> 
> I've attached code that works for XEmacs.  Is this along the line of
> what you'd like?

Thanks. I'll try to take a look at it soon.

Re: read syntax for window configs

[martin rudalics]

 > I've attached code that works for XEmacs.

Thank you for posting this.  It won't work out of the box for Emacs
because Emacs lacks `make-window-configuration' and `make-saved-window'.
Can you post their definitions here or tell us a page on the net where
we can look at them?  Do they check a configuration for integrity (e.g.,
whether the combined window sizes match those of their parents, that of
the root window the size of the frame, ...) before mapping the frame?
Can you restore on machine A a configuration saved on machine B when A
and B have different toolkits?

Also, am I right that the `next-child' field denotes the right sibling
of the window?  And, how do you translate back from pixel values (like
`pixel-left' ... ) to normal line/column values?  Do you?

Finally, do you have any ideas how this would integrate with a thing
like ECB?  For example, how would ECB find its editor window in a
restored configuration unless we make such a property part of the save
configuration?

Thanks, martin

Re: read syntax for window configs

[Michael Sperber]

martin rudalics <rudalics@gmx.at> writes:

>> I've attached code that works for XEmacs.
>
> Thank you for posting this.  It won't work out of the box for Emacs
> because Emacs lacks `make-window-configuration' and `make-saved-window'.
> Can you post their definitions here or tell us a page on the net where
> we can look at them?

http://hg.debian.org/hg/xemacs/xemacs/file/45753d9a0dc4/lisp/window-xemacs.el

> Do they check a configuration for integrity (e.g., whether the
> combined window sizes match those of their parents, that of the root
> window the size of the frame, ...) before mapping the frame?  

Yes: Since all restoration happens from Lisp, there's no way to get
anything inconsistent.

> Can you restore on machine A a configuration saved on machine B when A
> and B have different toolkits?

I don't see why not.  You're not always going to get an
identical-looking configurations because the original frame will be
gone, but as close an approximation as the code knows how to recreate.

> Also, am I right that the `next-child' field denotes the right sibling
> of the window?

If I recall correctly, it depends on whether windows are going right or
down.  It's just whatever `window-next-child' returns on XEmacs.

> And, how do you translate back from pixel values (like `pixel-left'
> ... ) to normal line/column values?  Do you?

No, we don't.

> Finally, do you have any ideas how this would integrate with a thing
> like ECB?  For example, how would ECB find its editor window in a
> restored configuration unless we make such a property part of the save
> configuration?

I don't know anything about ECB, so I don't really know.  However, I
would think that it needs to remember the name of the buffer to find the
window, or remember the window's place in the layout.  (That's a general
issue with window configurations, but it becomes very clear here -
there's no way to preserve window identity across sessions.)

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla

Re: read syntax for window configs

[martin rudalics]

 >> Thank you for posting this.  It won't work out of the box for Emacs
 >> because Emacs lacks `make-window-configuration' and `make-saved-window'.
 >> Can you post their definitions here or tell us a page on the net where
 >> we can look at them?
 >
 > http://hg.debian.org/hg/xemacs/xemacs/file/45753d9a0dc4/lisp/window-xemacs.el

Sorry but this has only a call to `make-window-configuration' in
`current-window-configuration'.  I've been looking into window.c but
didn't find it there either :-( I suppose it simply builds a vector from
its arguments.

 >> Do they check a configuration for integrity (e.g., whether the
 >> combined window sizes match those of their parents, that of the root
 >> window the size of the frame, ...) before mapping the frame?
 >
 > Yes: Since all restoration happens from Lisp, there's no way to get
 > anything inconsistent.

Well, if something happens in Elisp there's always a chance that things
get messed up on the fly.  I'd very much prefer to do the elementary
checks (those that prevent Emacs from crashing or showing distorted
frames) only in C.

 >> Can you restore on machine A a configuration saved on machine B when A
 >> and B have different toolkits?
 >
 > I don't see why not.  You're not always going to get an
 > identical-looking configurations because the original frame will be
 > gone, but as close an approximation as the code knows how to recreate.

OK.  So I presume your code handles the case where window sizes don't
fit because, for example, toolbars or scrollbars have different widths.

 >> Also, am I right that the `next-child' field denotes the right sibling
 >> of the window?
 >
 > If I recall correctly, it depends on whether windows are going right or
 > down.  It's just whatever `window-next-child' returns on XEmacs.

I've checked that.  It _is_ the right sibling and it doesn't depend on
whether windows go right or down (obviously, when windows go down the
right sibling denotes the window below).

 >> And, how do you translate back from pixel values (like `pixel-left'
 >> ... ) to normal line/column values?  Do you?
 >
 > No, we don't.

That's good (but momentarily not suitable for Emacs).  You apparently do
all these calculations via window_pixel_height_to_char_height /
window_char_height_to_pixel_height and friends.  And it will allow to
fix any of the scroll- or toolbar problems I mentioned above by giving
the remaining pixels to one of the involved windows.

Emacs should eventually do something similar ;-)

 > I don't know anything about ECB, so I don't really know.  However, I
 > would think that it needs to remember the name of the buffer to find the
 > window, or remember the window's place in the layout.  (That's a general
 > issue with window configurations, but it becomes very clear here -
 > there's no way to preserve window identity across sessions.)

Funnily, nothing would prevent us from keeping window identities across
sessions.  If and only if a saved configuration is restored _before_ the
first user interaction.  Well we could check whether a window with such
an identity exists already but I wouldn't like that ...

Thanks again, martin

Re: read syntax for window configs

[Michael Sperber]

martin rudalics <rudalics@gmx.at> writes:

>>> Thank you for posting this.  It won't work out of the box for Emacs
>>> because Emacs lacks `make-window-configuration' and `make-saved-window'.
>>> Can you post their definitions here or tell us a page on the net where
>>> we can look at them?
>>
>> http://hg.debian.org/hg/xemacs/xemacs/file/45753d9a0dc4/lisp/window-xemacs.el
>
> Sorry but this has only a call to `make-window-configuration' in
> `current-window-configuration'.  I've been looking into window.c but
> didn't find it there either :-( I suppose it simply builds a vector from
> its arguments.

`make-window-configuration' is defined by the `(defstruct
window-configuration ...)'.

> Funnily, nothing would prevent us from keeping window identities across
> sessions.  

Yes, it would, unless you're thinking of some other meaning of the word
"identity".  The original window simply isn't there anymore.

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla

Re: AW: Fwd: CEDET sync

[Richard Riley]

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

> On Tue, Mar 2, 2010 at 11:36 AM, Berndl, Klaus
> <klaus.berndl@capgemini-sdm.com> wrote:
>>
>>>I think the worst problem is the scattering of scarce resources. Eric
>>>Ludlam is such a resource ;-)
>>
>> exactly - therefore my vote for focussing the scarce resources to the most
>> important tasks - otherwise there will be a very high risk to get bogged
>> down...
>
> And you are of course a scarce resource too and I have noticed you
> have had difficulties to find time to support ECB as you want to.
>
> It is a common and serious problem and one we must fight if we want
> free software to succeed.
>
> The diversity hits the users too. As I have said I recently had a
> discussion with a long term GNU/Linux user who jump off to Windows 7
> because the quality of the mid-level library was too low on GNU/Linux.
> The key factor was the diversity (too many libraries doing the same
> thing) which he thought creates this problem.
>
> I think solving this is urgent - and very, very difficult.
>

Common sense.

The main issue is that as soon as you suggest concentrating resources in
any shape or form then the usual suspects jump out and accuse you of
being anti Freedom and choice.

Its madness.

Support the main Emacs distribution and let the tiny minority who want
their own little niche port it over if necessary.

Re: AW: Fwd: CEDET sync

[David Kastrup]

Richard Riley <rileyrgdev@gmail.com> writes:

> Lennart Borgman <lennart.borgman@gmail.com> writes:
>>
>> The diversity hits the users too. As I have said I recently had a
>> discussion with a long term GNU/Linux user who jump off to Windows 7
>> because the quality of the mid-level library was too low on
>> GNU/Linux.  The key factor was the diversity (too many libraries
>> doing the same thing) which he thought creates this problem.
>>
>> I think solving this is urgent - and very, very difficult.
>
> Common sense.

Too common.

> The main issue is that as soon as you suggest concentrating resources
> in any shape or form then the usual suspects jump out and accuse you
> of being anti Freedom and choice.

That's a rant not supported by any facts regarding the Emacs/XEmacs
situation as far as I am concerned.  I've never seen such behavior from
XEmacs developers.  Complaints from their side focus about reinvention
of the wheel and (in their view) unnecessary incompatibilities.  With
regard to XEmacs ports, my impression is that they take what they can
get and do the rest themselves given sufficient resources.  That's one
point of their package system source tree.

The results are not always convincing, but that is not harming Emacs
development.

Most current XEmacs developers would not be interested in working on
Emacs anyway.  The main cost of diversity comes not by "usual suspects
jumping out" but rather by developers focused on Emacs, but investing
research and development time in order to provide XEmacs compatibility.
Out of a personal feeling of responsibility.

At times that may not be the most prudent course for the interest of
their own usage patterns, but then even on Emacs we often have the
situation that the active developer of some package is not actually
among its "power users": a certain degree of unselfishness seems hard to
suppress reliably.

> Its madness.
>
> Support the main Emacs distribution and let the tiny minority who want
> their own little niche port it over if necessary.

It is not exactly a "little niche port", and they do an impressive job
doing exactly that given their numbers.

-- 
David Kastrup

Re: AW: Fwd: CEDET sync

[Stephen J. Turnbull]

David Kastrup writes:

 > Worms may wriggle, too.  The question is whether there is a central
 > agency moving forward.

Of course *we* have a central agency moving forward.  It's called
"Emacs", and it has bright red taillights we can follow through the
fog.

It's *you* guys who have to *worry* about being a pack of wriggling
worms, not us.[1]  Worse, your development is constrained by political
considerations that have saddled you with a 1990s bug tracker and a
VCS that gives 1980s performance while satisfying the requirement to
support 1970s workflows.  Not to mention massive internal obstacles to
benefitting from work done by anybody who doesn't actively pledge
allegiance to Emacs. :-(

I really don't think you should kid yourselves about how thriving
Emacs is.  On the other hand, I don't think there's anything
inherently fatal in being an uncoordinated pack of hackers.

Footnotes: 
[1]  Of course we are a pack of wriggling worms just as you are, and
just as every FLOSS project that has grown beyond the single hacker
scale is.  The difference is that being #2 means we have an obvious
direction for progress.

Re: AW: Fwd: CEDET sync

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> David Kastrup writes:
>
>  > Worms may wriggle, too.  The question is whether there is a central
>  > agency moving forward.
>
> Of course *we* have a central agency moving forward.  It's called
> "Emacs", and it has bright red taillights we can follow through the
> fog.
>
> It's *you* guys who have to *worry* about being a pack of wriggling
> worms, not us.[1]  Worse, your development is constrained by political
> considerations that have saddled you with a 1990s bug tracker and a
> VCS that gives 1980s performance while satisfying the requirement to
> support 1970s workflows.  Not to mention massive internal obstacles to
> benefitting from work done by anybody who doesn't actively pledge
> allegiance to Emacs. :-(

A copyright assignment is not written out to Emacs, and it is not a
pledge of allegiance, most certainly not to Emacs.

A main consideration for GNU software is not to leave GNU software
behind for short-term benefits.

It may at times be a nuisance for GNU subprojects, but it certainly has
helped in completing the GNU software landscape from isolated programs
to completely free systems.

If the FSF's sole goal were to make Emacs the best editor to be found,
some decisions in its development might have been made differently.  You
might call them "political considerations", but it is not like they are
anything new.  The GNU project has been shaped and motivated by
political decisions for the sake of creating a workground compatible
with a certain set of morals and views.

People with quite different focus and goals still profit: that is a
consequence of the goals.  But their profit is a side-effect that may
simplify work and things, but which is not ultimately what keeps the
system as such going any better than less free alternatives.

I am quite annoyed by some decisions and their effects at times.  Sure.
But I am not so stupid not to see what long-term effects they have made
possible in the past ultimately.

-- 
David Kastrup

Re: AW: Fwd: CEDET sync

[Stephen J. Turnbull]

David Kastrup writes:

 > > Not to mention massive internal obstacles to benefitting from
 > > work done by anybody who doesn't actively pledge allegiance to
 > > Emacs. :-(
 > 
 > A copyright assignment is not written out to Emacs, and it is not a
 > pledge of allegiance, most certainly not to Emacs.

The point is that unless people make a point of making code available
to Emacs by signing a copyright assignment, it won't get in.  This
applies not just to XEmacs code, but to AUCTeX (as you know better
than anyone), and to many GNU projects as well.  I wonder how many
thousands of .emacs are out there containing valuable code that will
never be part of Emacs?

 > It may at times be a nuisance for GNU subprojects, but it certainly has
 > helped in completing the GNU software landscape from isolated programs
 > to completely free systems.

That project was basically finished 15 years ago.  The real threats to
the GNU system today are (a) patents and (b) lags vs. commercial
systems built on free software, even if they are not completely free
software.  Neither of those can be helped by frictions like resisting
a package system for 15 years or DLLs for 15 years plus the
foreseeable future, because somebody careless *might* be misled into
thinking that a feature loaded into Emacs was therefore free, when it
might not be.

 > The GNU project has been shaped and motivated by political
 > decisions for the sake of creating a workground compatible with a
 > certain set of morals and views.

That's only part of it.  It has also been heavily motivated by the
desire to ostracize those with different beliefs, even if they are
compatible with freedom.  Specifically, the BSDs have shown that it is
possible to maintain freedom of the whole for those who want it with
important parts of the system (eg, the OS kernel) licensed under less
restrictive conditions.

It is an open question whether this could be done without a copyleft
core; it has never been tried, really (the BSDs started out without,
but later made the intelligent decision to adopt a mixed copyleft/
permissive system with GCC and GNU binutils as the core development
tools, and today the main desktop suites are also copyleft; of course
Emacs is available if not the weapon of choice for true-blue BSDers).

Similarly, I have to wonder if Emacs could not benefit from a similar
(but more conservative in important ways) strategy by allowing DLLs
and relying on legal prosecution to exclude proprietary DLLs.

 > I am quite annoyed by some decisions and their effects at times.  Sure.
 > But I am not so stupid not to see what long-term effects they have made
 > possible in the past ultimately.

The question is not "did it work well in the past?"  The question is,
"in the future, do we want to attract the unbelievers to freedom, or
do we want to just sit around and congratulate ourselves on our own
purity?"

Re: AW: Fwd: CEDET sync

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> The question is not "did it work well in the past?"  The question is,
> "in the future, do we want to attract the unbelievers to freedom, or
> do we want to just sit around and congratulate ourselves on our own
> purity?"

Taking a look at the GNU/Linux user demographic, there is little enough
doubt that "attracting unbelievers to freedom" is happening in copious
amounts.  The vast majority enjoys its fruits but can't be bothered all
too much about its origins.  Creating cheapened versions for the sake of
temporarily catching their attention span does not seem like a
sustainable long-term bargain.

Watering down always needs some substance to start with.

-- 
David Kastrup

Re: AW: Fwd: CEDET sync

[Stephen J. Turnbull]

David Kastrup writes:
 > "Stephen J. Turnbull" <stephen@xemacs.org> writes:
 > 
 > > The question is not "did it work well in the past?"  The question is,
 > > "in the future, do we want to attract the unbelievers to freedom, or
 > > do we want to just sit around and congratulate ourselves on our own
 > > purity?"
 > 
 > Taking a look at the GNU/Linux user demographic,

You mean like the million or so Japanese businessmen who have a Sharp
Zaurus or Netwalker?  It's true that Sharp has screwed the pooch by
making it relatively hard to develop for their hardware (in particular
for the Zaurus, at least, it's not possible to have both a non-Sharp
version of Linux plus GUI, and use the really excellent Japanese input
facilities), but (low-level) folks inside Sharp have told me they find
the GNU project to be hostile to them, to insist on extremes before
giving them any credit, and so they don't see the point in opening up,
since (they believe) they can't satisfy the demands of "freedom
lovers" without destroying their profit margin.

 > there is little enough doubt that "attracting unbelievers to
 > freedom" is happening in copious amounts.

I see it happening all the time in the "open source" arena.  I know
many Ubuntu and Centos users who value freedom for itself and ask for
it in the products they use, looking at proprietary products only
after exhausting the free offerings as too sucky to be worked around.
Of course, they remain unwilling to give up the features they want if
no free program offers them, and they are unable to contribute
directly to developing them, so they adopt a pragmatic stance.

I believe that enjoying a taste *of* freedom leads to developing a
taste *for* freedom.  Of course such users are unlikely to become
extremists[1] like Richard, but how many of those do we need?  I
believe it would useful if "ordinary" users come to recognize that
software freedom is a necessity, not a luxury, and learn to demand it,
bargain hard for it, and not to give it up without a really good
reason, as many of my non-hacker friends in the Tokyo Linux Users
Group have learned.  It is certainly true that several vendors of
Linux-based systems[2] in Tokyo vocally appreciate that "bedrock"
support in our meetings!

There is no need for GNU or Emacs to conceal its moral stance, just to
make the "We hold that" part of moral statements explicit, and be more
accepting of those who "do the right things for the wrong reasons".


Footnotes: 
[1]  "Extremism in the defense of freedom is no vice."

[2]  In this case, several of them do not use GNU userspace, thus the
lack of "GNU/".

OT: threats to Free Software (was: AW: Fwd: CEDET sync)

[Stefan Monnier]

> That project was basically finished 15 years ago.  The real threats to
> the GNU system today are (a) patents and (b) lags vs. commercial
> systems built on free software, even if they are not completely free
> software.

I think the real threat the FSF's ideals is that computers are being
split into two camps:
- cell-phones
- web-services
there are still some things in the middle (laptops/desktops) where users
can run Free Software, but the tendency is pretty clear.

Both sides (cell-phones and web-services) may internally run Free
Software, but users enjoy (currently at least) none of the freedoms
provided by Free Software.


        Stefan

Re: OT: threats to Free Software (was: AW: Fwd: CEDET sync)

[Lennart Borgman]

On Tue, Mar 2, 2010 at 7:40 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
> I think the real threat the FSF's ideals is that computers are being
> split into two camps:
> - cell-phones
> - web-services
> there are still some things in the middle (laptops/desktops) where users
> can run Free Software, but the tendency is pretty clear.
>
> Both sides (cell-phones and web-services) may internally run Free
> Software, but users enjoy (currently at least) none of the freedoms
> provided by Free Software.


I think there is some true in this. Considering that maybe these two
points are could be useful:

- Free software for editing and creating web services might be
valuable. Emacs might help there.

- Tight integration between the middle (laptops) and web-services (and
also cell-phones) is important. To make this happen I suspect that the
library level must be straightened up. This means perhaps actively
killing alternatives so that things comes out tested, used and
reliable.

Re: OT: threats to Free Software (was: AW: Fwd: CEDET sync)

[David Reitter]

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

On Mar 2, 2010, at 1:40 PM, Stefan Monnier wrote:
> I think the real threat the FSF's ideals is that computers are being
> split into two camps:
> - cell-phones
> - web-services
> there are still some things in the middle (laptops/desktops) where users
> can run Free Software, but the tendency is pretty clear.

One may dislike the lack of freedom on a platform like the iPhone, but it is worthwhile to consider why the platform is successful (as in: popular).  Potential reasons: 

1. The applications are highly usable, reliable, polished and cheap.  The marketplace allows customers to read and publish reviews, and a ranking system to endorse interesting useful apps.  The review system put in place by Apple ensures that apps are relatively free of bugs, standards-compliant (UI and API standards) and usable.  When developers have their apps reviewed, theory even get free feedback.  Also, the middleware (Apple's CocoaTouch/iPhoneOS frameworks) are tested, reliable, well-documented, easy-to-use and there are easy-to-learn development/debug tools.

The middleware provided by the iPhone OS (and also by OS X) is so extensive and reliable that it competes well with the "bazaar" of free libraries and and other code.  Think NSSpellChecker vs. ispell/aspell, or CoreImage vs. ImageMagick/libpng/etc.

2. There is a working revenue model in place that gives application developers their deserved financial rewards.  Per-hour wages are around US$150 as far as I know.  Even developers who appreciate the ethical considerations of writing free and non-free software have to pay the mortgage, feed their kids, get a health plan (or they even want to enjoy life in their own Tesla sports car or their own aircraft).

There are further hardware-related and business-strategy related reasons, which may be less relevant for our agenda.  Perhaps there is something to be learned for free software from the above two points.  See also Lennart's point w.r.t libraries.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: OT: threats to Free Software (was: AW: Fwd: CEDET sync)

[Richard Stallman]

      Even developers who appreciate the ethical =
    considerations of writing free and non-free software have to pay the =
    mortgage, feed their kids,

Why do you assume they have a mortgage?
Why do you assume they have children?
Not everyone has these things.

People are not compelled to have these things; it is a choice.
Choosing not to have a mortgage can make life a lot less worrysome.
Choosing not to have children is itself a substantial contribution to
civilization's survival, and it greatly facilitates contributing to
society in many other ways (developing free software being one).

Anyway, the fact that it is easier to make money from proprietary
software is nothing new, and we won't learn anything useful about
how to live ethically by rehearsing it.

OT: threats to Free Software (was: AW: Fwd: CEDET sync)

[Stephen J. Turnbull]

Stefan Monnier writes:

 > I think the real threat the FSF's ideals is that computers are being
 > split into two camps:
 > - cell-phones
 > - web-services
 > there are still some things in the middle (laptops/desktops) where users
 > can run Free Software, but the tendency is pretty clear.

Good point.  But Emacs doesn't really run on either extreme.  How is
this relevant to Emacs?

 > Both sides (cell-phones and web-services) may internally run Free
 > Software, but users enjoy (currently at least) none of the freedoms
 > provided by Free Software.

The question I ask is "how much of that is due to user taste?"

There's also the problem that the GNU/FSF line has long been that
hardware and software can be separated, and insisting on freedom in
software is sine qua non, while insisting on freedom in hardware (ie,
embedded systems) is a non-starter (this is the original reason for
the GNU/Aladdin split in Ghostscript, you may recall).  But these new
platforms very much blur the line, just as printers and faxes did for
Ghostscript.

The answer that Richard gave Peter at the time may very well have been
correct at that time.  Clearly however the situation has changed, such
that new licenses such as the Affero license have been developed to
address *some* of these issues.  I have to wonder if this should not
affect Emacs's strategy as well.

Re: OT: threats to Free Software (was: AW: Fwd: CEDET sync)

[Richard Stallman]

For cell phones, we need a cell phone whose software is free.
OpenMoko tried to do this, but did not get it done well.  I hope
someone else will try.  However, this involves manufacturing hardware,
so the FSF is not in a position to do it.

There are people who want to use reverse engineering to make free
drivers for some Android phones.  I don't see much connection between
this and Emacs.

Even if all the software in a phone is free, it can still
be used to track you, so people who are against Big Brother
will still decide not to use them.

Re: OT: threats to Free Software (was: AW: Fwd: CEDET sync)

[Richard Stallman]

    I think the real threat the FSF's ideals is that computers are being
    split into two camps:
    - cell-phones
    - web-services
    there are still some things in the middle (laptops/desktops) where users
    can run Free Software, but the tendency is pretty clear.

Yes, this is a real problem.  We are going to campaign against
Software as a Service.

Re: AW: Fwd: CEDET sync

[Richard Stallman]

    That's only part of it.  It has also been heavily motivated by the
    desire to ostracize those with different beliefs, even if they are
    compatible with freedom.  Specifically, the BSDs have shown that it is
    possible to maintain freedom of the whole for those who want it with
    important parts of the system (eg, the OS kernel) licensed under less
    restrictive conditions.

Stop these false accusations!  We do not reject developers for
disagreeing with us on philosophical questions, as long as they are
willing to participate in the project under the rules and policies it
has.

BSD supporters have attacked the GPL for around 20 years now, but we
have never attacked the BSD licenses.

There is plenty of experience showing the danger that free programs
under lax licenses will have proprietary improvements.  Apache is a
very large example today.  The nonfree dynamically loadable device
drivers for Linux are another example showing that nonfree extensions
are a real danger.

Whatever has happened with the BSD systems cannot disprove these
facts.

You are welcome to participate in this discussion to help improve
Emacs.  You are not welcome to use the list to post accusations or
spread falsehoods about us.

Re: AW: Fwd: CEDET sync

[Stephen J. Turnbull]

Richard Stallman writes:
 >     That's only part of it.  It has also been heavily motivated by the
 >     desire to ostracize those with different beliefs, even if they are
 >     compatible with freedom.  Specifically, the BSDs have shown that it is
 >     possible to maintain freedom of the whole for those who want it with
 >     important parts of the system (eg, the OS kernel) licensed under less
 >     restrictive conditions.
 > 
 > Stop these false accusations!

Read what others write!

 > We do not reject developers for disagreeing with us on
 > philosophical questions, as long as they are willing to participate
 > in the project under the rules and policies it has.

But you do reject them if they are not so willing.  What good is their
moral position if they do not act on it, merely so they can have the
benefit of using a piece of software?  I believe the word you normally
apply to such behavior is "backsliding", is it not?  And you write
your licenses to apply to developers working outside of the project,
and to ensure that those who act on different beliefs cannot use your
software.  That may be necessary, but it surely is ostracism,
exclusion from the community.

 > There is plenty of experience showing the danger that free programs
 > under lax licenses will have proprietary improvements.

Sure.  Nevertheless, the whole of the unextended program or system,
that was written by the person(s) who gave it a free license, remains
free (which is almost definitional), not obsolete, and available to
those who want it (which is the practically important observation).
As I stated and you quoted.  You don't have to think that outcome is
sufficient for the cause of freedom, but it is not false.

 > Whatever has happened with the BSD systems cannot disprove these
 > facts.

There was no attempt to disprove the fact that permissive licenses are
used as intended, which includes both free and proprietary extensions.
I'm amazed that you think the implication that I would try to prove
otherwise could pass for truth.

 > You are welcome to participate in this discussion to help improve
 > Emacs.  You are not welcome to use the list to post accusations or
 > spread falsehoods about us.

But you are welcome to spread falsehoods and misinterpretations of my
posts, is that it?  You don't like what I post, so you label it
"accusation" and "falsehood", and attribute statements to me which I
did not intend and are hardly supportable in the light of a careful
reading.

And at the same time you post that the Emacs 19 debacle was due to
having your maintainer hired away.  Of course that's a big problem,
but surely anybody who's worked professionally will realize that that
can be at most half the story.

I don't think my posts suffer by comparison with yours, which is very
unfortunate.

Re: AW: Fwd: CEDET sync

[Chong Yidong]

Please move the drama off-list.  Thanks.

Re: AW: Fwd: CEDET sync

[Richard Stallman]

     >     That's only part of it.  It has also been heavily motivated by the
     >     desire to ostracize those with different beliefs, even if they are
     >     compatible with freedom.

     > We do not reject developers for disagreeing with us on
     > philosophical questions, as long as they are willing to participate
     > in the project under the rules and policies it has.

    But you do reject them if they are not so willing.

We don't reject them, but we may reject their contributions.  We have
certain rules for contributing.  If people do not follow these rules,
we cannot accept their contributions.

Is that the only fact that your insulting words refer to?

Most free software projects have rules about contributing.  But it is
only in our case that you twist these facts and present them as if
they were nasty.

We do not "ostracize" or reject people for their beliefs if they
wish to contribute and will follow our rules for doing so.
But we may ostracize people for persistent hostility and trying
to put us unjustly in the wrong.

Re: AW: Fwd: CEDET sync

[Stephen J. Turnbull]

Richard Stallman writes:

 > We do not "ostracize" or reject people for their beliefs if they
 > wish to contribute and will follow our rules for doing so.
 > But we may ostracize people for persistent hostility and trying
 > to put us unjustly in the wrong.

I've already been told to stop posting to this thread, and therefore
cannot reply.

Re: AW: Fwd: CEDET sync

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Richard Stallman writes:
>
>  > We do not "ostracize" or reject people for their beliefs if they
>  > wish to contribute and will follow our rules for doing so.
>  > But we may ostracize people for persistent hostility and trying
>  > to put us unjustly in the wrong.
>
> I've already been told to stop posting to this thread, and therefore
> cannot reply.

A mailing list is not a good place to discuss matters for which the
primary correspondent would be Richard.  In particular regarding issues
you feel agitated about.  Richard has intermittent access and time, and
so it is likely that there results a more or less heated back and forth
before he even has time to address an issue.  By that time, the
atmosphere might already have moved way beyond the state where
addressing the initial posting makes much sense.  And even if his mail
queue is worked off strictly sequentially, it is likely that initial
calm-headed answers are wasted since they can't keep up with an
escalation that has already happened.  And wasting time and effort on a
route already blocked is not likely to improve anyone's mood.

And purely electronic interaction has a much higher chance of escalation
anyway since face-to-face interaction makes you realize interactively at
what point of time a point has registered, and when not.  Which makes it
much easier to figure when it is appropriate give the other time and
room to ponder and respond.

So even in private mail, it might at times be a good rule to stop and
think: would I feel this issue would also warrant picking up the phone
and calling the person about it?

If so, maybe it is not the worst idea to actually do so.  Or at least
try to think it through (which by far is not the same).  It might
readjust one's sensors about what one feels comfortable about writing or
saying.

-- 
David Kastrup

Re: AW: Fwd: CEDET sync

[joakim]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> David Kastrup writes:
>
>  > Worms may wriggle, too.  The question is whether there is a central
>  > agency moving forward.
>
> Of course *we* have a central agency moving forward.  It's called
> "Emacs", and it has bright red taillights we can follow through the
> fog.
>
> It's *you* guys who have to *worry* about being a pack of wriggling
> worms, not us.[1]  Worse, your development is constrained by political
> considerations that have saddled you with a 1990s bug tracker and a
> VCS that gives 1980s performance while satisfying the requirement to
> support 1970s workflows.  Not to mention massive internal obstacles to
> benefitting from work done by anybody who doesn't actively pledge
> allegiance to Emacs. :-(

People enjoying Lisp systems and Emacs in particular often seem to agree
that some computer science concepts only get better with age, right?

The comparision with 1980:s style VCS:es seems unfair though, I dont
recall using any VCS in the 80:s with the bazaar feature set.

> I really don't think you should kid yourselves about how thriving
> Emacs is.  On the other hand, I don't think there's anything
> inherently fatal in being an uncoordinated pack of hackers.
>
> Footnotes: 
> [1]  Of course we are a pack of wriggling worms just as you are, and
> just as every FLOSS project that has grown beyond the single hacker
> scale is.  The difference is that being #2 means we have an obvious
> direction for progress.
>
-- 
Joakim Verona

Re: Fwd: CEDET sync

[Stefan Monnier]

> Supporting not only Emacs but also XEmacs should be a value upheld be
> tools like CEDET and ECB, even when merged into Emacs. But cause of

I think the issue of support for XEmacs is mostly orthogonal: we can and
do include support for XEmacs in many of the bundled Emacs packages, and
AFAICT none of the changes made when incorporating CEDET into Emacs
should interect in any significant way with support for XEmacs.


        Stefan


PS: As for XEmacs's demise: don't forget that Emacs was also considered
as "heading south" around the Emacs-19 time frame.  I wouldn't rule out
the possibility of XEmacs (or some derivative) becoming the Emacs of
choice 10 years from now.

AW: Fwd: CEDET sync

[Berndl, Klaus]

>> Supporting not only Emacs but also XEmacs should be a value upheld be
>> tools like CEDET and ECB, even when merged into Emacs. But cause of

> I think the issue of support for XEmacs is mostly orthogonal: we can and
>do include support for XEmacs in many of the bundled Emacs packages, and
>AFAICT none of the changes made when incorporating CEDET into Emacs
>should interect in any significant way with support for XEmacs.

well, If i remember right, i have i mind that RMS told me some years ago that "we do not want
have XEmacs code in our code-base"... therefore i thought that packages have to 
be stripped concerning their XEmacs-code before merging into Emacs... but maybe
i have misunderstood this......

>PS: As for XEmacs's demise: don't forget that Emacs was also considered
>as "heading south" around the Emacs-19 time frame.  I wouldn't rule out
>the possibility of XEmacs (or some derivative) becoming the Emacs of
>choice 10 years from now.

interesting point of view - haven't thought in this direction...thanks for this hint!
Klaus

Re: AW: Fwd: CEDET sync

[Chong Yidong]

"Berndl, Klaus" <klaus.berndl@capgemini-sdm.com> writes:

> well, If i remember right, i have i mind that RMS told me some years
> ago that "we do not want have XEmacs code in our
> code-base"... therefore i thought that packages have to be stripped
> concerning their XEmacs-code before merging into Emacs... but maybe i
> have misunderstood this......

You probably misunderstood.  XEmacs does not require a copyright
assignment from its contributors, so we typically will not incorporate
XEmacs code into Emacs.  But if you write a package that supports both
Emacs and XEmacs, and have a copyright assignment, there is no problem
including the package into Emacs.

Re: AW: Fwd: CEDET sync

[Stephen J. Turnbull]

Chong Yidong writes:

 > You probably misunderstood.  XEmacs does not require a copyright
 > assignment from its contributors, so we typically will not incorporate
 > XEmacs code into Emacs.

Has that ever been done?  Of course Richard used to reply to every
assignment of XEmacs code with "encouragement" to work on Emacs
instead, but I don't recall ever hearing of someone being asked to
sign an assignment so that someone's private integration of XEmacs
code into Emacs could be published.

Re: AW: Fwd: CEDET sync

[Chong Yidong]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Has that ever been done?  Of course Richard used to reply to every
> assignment of XEmacs code with "encouragement" to work on Emacs
> instead, but I don't recall ever hearing of someone being asked to
> sign an assignment so that someone's private integration of XEmacs
> code into Emacs could be published.

If a contributor has papers, and wants to contribute code to Emacs, and
the code is helpful to the Emacs project (i.e. it has to make sense in
the Emacs code context), then whether or not the code has also been
contributed to XEmacs is irrelevant.  There is no reason to treat it any
more or less favorably than any other contribution.

Re: AW: Fwd: CEDET sync

[Stephen J. Turnbull]

Chong Yidong writes:
 > "Stephen J. Turnbull" <stephen@xemacs.org> writes:

 > > I don't recall ever hearing of someone being asked to sign an
 > > assignment so that someone's private integration of XEmacs code
 > > into Emacs could be published.
 > 
 > If a contributor has papers, and wants to contribute code to Emacs, and
 > the code is helpful to the Emacs project (i.e. it has to make sense in
 > the Emacs code context), then whether or not the code has also been
 > contributed to XEmacs is irrelevant.  There is no reason to treat it any
 > more or less favorably than any other contribution.

You're sidestepping the question.  The conditions you present are
those that I refer to as "(first) allegiance to Emacs".  What I am
asking for is examples where somebody said (as Juri Linkov just
suggested to Klaus Berndl) "hey, XEmacs has implemented a good
solution already; let's see if we can get papers for it!"  Or "hey,
libfoo has some code that does this, let's see if we can get papers
for that."

I know that David Kastrup has cried many tears over acquiring papers
for AUCTeX, so that's one example of effort (but it's not yet
integrated).

Re: AW: Fwd: CEDET sync

[Miles Bader]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
> What I am asking for is examples where somebody said (as Juri Linkov
> just suggested to Klaus Berndl) "hey, XEmacs has implemented a good
> solution already; let's see if we can get papers for it!"  Or "hey,
> libfoo has some code that does this, let's see if we can get papers
> for that."

Why is it useful to know this?

Even if nobody ever has, there are many reasons why that may be the case
(laziness/"i-wanna-write-it"/hard-to-port/sucky-code/etc).

Chong addressed what seems to be the relevant question, which is whether
there's a irrational bias against using xemacs code merely because it's
from xemacs.

-Miles

-- 
Corporation, n. An ingenious device for obtaining individual profit without
individual responsibility.

Re: AW: Fwd: CEDET sync

[Stephen J. Turnbull]

Miles Bader writes:

 > Chong addressed what seems to be the relevant question, which is
 > whether there's a irrational bias against using xemacs code merely
 > because it's from xemacs.

Why would anyone care about that?  The existence of a bias has been
denied often enough, and even if it does exist, it's not really a big
problem for Emacs, and it's an advantage for XEmacs (as Richard and
other Emacs advocates have remarked often enough in the past).

My questions are (1) is enough effort being made to acquire written
and tested code from outside of Emacs purely from a value-for-work
standpoint? and (2) does a lack of effort/lack of successful effort in
that direction tend to distance Emacs from the rest of the free
software community?  Some recent posters clearly feel the answers are
no and yes, respectively.  Those are not good things.

Re: AW: Fwd: CEDET sync

[Chong Yidong]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> My questions are (1) is enough effort being made to acquire written
> and tested code from outside of Emacs purely from a value-for-work
> standpoint? and (2) does a lack of effort/lack of successful effort in
> that direction tend to distance Emacs from the rest of the free
> software community?  Some recent posters clearly feel the answers are
> no and yes, respectively.  Those are not good things.

Thank you for your concern.

Re: AW: Fwd: CEDET sync

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Chong Yidong writes:
>  > "Stephen J. Turnbull" <stephen@xemacs.org> writes:
>
>  > > I don't recall ever hearing of someone being asked to sign an
>  > > assignment so that someone's private integration of XEmacs code
>  > > into Emacs could be published.
>  > 
>  > If a contributor has papers, and wants to contribute code to Emacs,
>  > and the code is helpful to the Emacs project (i.e. it has to make
>  > sense in the Emacs code context), then whether or not the code has
>  > also been contributed to XEmacs is irrelevant.  There is no reason
>  > to treat it any more or less favorably than any other contribution.
>
> You're sidestepping the question.  The conditions you present are
> those that I refer to as "(first) allegiance to Emacs".

Your use of inflammatory language is likely doing more for your mood
than for your argument.

> I know that David Kastrup has cried many tears over acquiring papers
> for AUCTeX, so that's one example of effort (but it's not yet
> integrated).

Because there have been too few tears.  We enforce assignment papers for
any new contributions, and we have assignments from the principal
authors (and previous maintainers) and those whose names actually
appeared in copyright notices, but I certainly have been dragging my
feet with regard to rounding up all previous contributors.  I've been
asking on the list for help with this task, but it is extensive and not
particularly gratifying work.  As you should be well aware of.  It is
not to my credit that I have not yet completed it.

I don't see how my failure to meet the necessary conditions for AUCTeX
inclusion should imply that the necessary conditions are not necessary.
There are valid and legal reasons discussed with the legal counsel of
the FSF for requiring copyright assignments for core GNU components such
as Emacs.  There is nothing arbitrary involved as you try to insinuate
with your verbiage of "pledging allegiance".  Yes, a line is drawn, and
it is drawn further on the side of legal defensibility than you can be
bothered to care for.  But the position of the line, contrary to what
you want to suggest, is determined by legal considerations, not moral
ones.  The morals are why we bother to be here in the first place.

-- 
David Kastrup

Re: AW: Fwd: CEDET sync

[Stephen J. Turnbull]

David Kastrup writes:

 > > You're sidestepping the question.  The conditions you present are
 > > those that I refer to as "(first) allegiance to Emacs".
 > 
 > Your use of inflammatory language is likely doing more for your mood
 > than for your argument.

What's inflammatory about the well-known fact that Emacs developers
are very proud of their program and of free software, and are willing
to jump through hoops that very few projects require to contribute to
it?

 > > I know that David Kastrup has cried many tears over acquiring
 > > papers for AUCTeX, so that's one example of effort (but it's not
 > > yet integrated).
 > 
 > I've been asking on the list for help with this task, but it is
 > extensive and not particularly gratifying work.  As you should be
 > well aware of.

Been there, done that, use the T-shirt to mop up kitchen spills, yes.

Success is very gratifying, though.

 > It is not to my credit that I have not yet completed it.

Nor is it to your *dis*credit that you haven't, necessarily; that's
for you to judge, not anyone else.

 > There are valid and legal reasons discussed with the legal counsel of
 > the FSF for requiring copyright assignments for core GNU components such
 > as Emacs.

I'm not talking about removing that requirement; I'm talking about
putting more effort into getting assignments, and other strategies
(incorporating an FFI, or a full package system) that might bring
Emacs closer to the rest of the community.  Refusing to add FFI or a
full package system are not legally required to protect Emacs as
distributed by GNU; they are strategies intended to raise annoying
technical obstacles to doing what is already either clearly legal (for
individual users) or illegal (for distributors).

 > There is nothing arbitrary involved as you try to insinuate
 > with your verbiage of "pledging allegiance".

Indeed, loyalty is an arbitrary criterion.  But what bothers you so
much about loyalty?  Is it somehow opposed to software freedom?

Re: AW: Fwd: CEDET sync

[tomas]

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

On Wed, Mar 03, 2010 at 08:41:27AM +0100, David Kastrup wrote:

[...]

> Your use of inflammatory language is likely doing more for your mood
> than for your argument.

Note that I'm just a bystander with very little say in this. But I think
you are being unfair with Stephen here. He makes his points very
politely and insightfully.

One might disagree with the points he makes (I actually agree on most!),
but his posts are far from inflammatory. Straight and clear, yes.

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

iD8DBQFLjiePBcgs9XrR2kYRAqI3AJ9dxYMkI/RaL/ULVUS9AS9xxXzOlQCfStxI
25lBseK7zbKSxxOqvv/WGTs=
=/ztV
-----END PGP SIGNATURE-----

Re: AW: Fwd: CEDET sync

[David Kastrup]

tomas@tuxteam.de writes:

> On Wed, Mar 03, 2010 at 08:41:27AM +0100, David Kastrup wrote:
>
> [...]
>
>> Your use of inflammatory language is likely doing more for your mood
>> than for your argument.
>
> Note that I'm just a bystander with very little say in this. But I think
> you are being unfair with Stephen here. He makes his points very
> politely and insightfully.
>
> One might disagree with the points he makes (I actually agree on most!),
> but his posts are far from inflammatory. Straight and clear, yes.

I don't see his claim of Emacs developers having to do a "pledge of
allegiance to Emacs" as polite, insightful, straight or clear.

If he considers inappropriate and factually wrong rhetorics necessary to
bolster his case, he might be playing with some success to the masses.

But they are not the ones who can take up the issues he has.

-- 
David Kastrup

Re: AW: Fwd: CEDET sync

[Stephen J. Turnbull]

David Kastrup writes:

 > I don't see his claim of Emacs developers having to do a "pledge of
 > allegiance to Emacs" as polite, insightful, straight or clear.

I didn't claim that you *have* to do a pledge of allegiance to
contribute to Emacs.  I claim that in practice it is those who have a
strong loyalty to Emacs who do contribute, because the costs of
contribution are too high for casual contributors.  I do not claim
that anything can be done about this for sure, merely that it would be
worth looking for ways to reduce those costs in order to encourage a
wider variety of users to contribute.

 > If he considers inappropriate and factually wrong rhetorics necessary to
 > bolster his case,

Of course the rhetoric is not necessary to my case.  If it were, I'd
post to alt.religion.emacs instead.

Re: Fwd: CEDET sync

[Stefan Monnier]

> well, If i remember right, i have i mind that RMS told me some years
> ago that "we do not want have XEmacs code in our
> code-base"... therefore i thought that packages have to  be stripped
> concerning their XEmacs-code before merging into Emacs... but maybe
> i have misunderstood this......

Well, we like our code as clean as possible, without compatibility hacks
(neither for XEmacs nor for older Emacsen).  But we also want to avoid
forking between a package's "external" version and Emacs's own, so we
accept compatibility code.  The only case where we've been known to be
more reticent is when the compatibility code is in a separate file, in
which case it seems easy enough to keep the file outside of Emacs.


        Stefan

Re: Fwd: CEDET sync

[Richard Stallman]

    PS: As for XEmacs's demise: don't forget that Emacs was also considered
    as "heading south" around the Emacs-19 time frame.

That was because Lucid had hired away the GNU Project's Emacs
maintainer.  I made sure Emacs got reinvigorated then, and I will do
so again in the future.