* Fwd: CEDET sync @ 2010-03-01 18:53 Lluís 2010-03-01 18:59 ` Chong Yidong 0 siblings, 1 reply; 64+ messages in thread From: Lluís @ 2010-03-01 18:53 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Fwd: CEDET sync 2010-03-01 18:53 Fwd: CEDET sync Lluís @ 2010-03-01 18:59 ` Chong Yidong 2010-03-01 19:36 ` Lennart Borgman 2010-03-01 21:27 ` Stefan Monnier 0 siblings, 2 replies; 64+ messages in thread From: Chong Yidong @ 2010-03-01 18:59 UTC (permalink / raw) To: Lluís; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Fwd: CEDET sync 2010-03-01 18:59 ` Chong Yidong @ 2010-03-01 19:36 ` Lennart Borgman 2010-03-01 21:27 ` Stefan Monnier 1 sibling, 0 replies; 64+ messages in thread From: Lennart Borgman @ 2010-03-01 19:36 UTC (permalink / raw) To: Chong Yidong; +Cc: Lluís, emacs-devel 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? ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Fwd: CEDET sync 2010-03-01 18:59 ` Chong Yidong 2010-03-01 19:36 ` Lennart Borgman @ 2010-03-01 21:27 ` Stefan Monnier 2010-03-01 22:07 ` Fabian Ezequiel Gallina 2010-03-01 22:42 ` Eric M. Ludlam 1 sibling, 2 replies; 64+ messages in thread From: Stefan Monnier @ 2010-03-01 21:27 UTC (permalink / raw) To: Chong Yidong, Eric M. Ludlam; +Cc: Lluís, emacs-devel >> 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 ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Fwd: CEDET sync 2010-03-01 21:27 ` Stefan Monnier @ 2010-03-01 22:07 ` Fabian Ezequiel Gallina 2010-03-01 22:42 ` Eric M. Ludlam 1 sibling, 0 replies; 64+ messages in thread From: Fabian Ezequiel Gallina @ 2010-03-01 22:07 UTC (permalink / raw) To: Stefan Monnier; +Cc: Chong Yidong, emacs-devel, Lluís, Eric M. Ludlam 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 ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Fwd: CEDET sync 2010-03-01 21:27 ` Stefan Monnier 2010-03-01 22:07 ` Fabian Ezequiel Gallina @ 2010-03-01 22:42 ` Eric M. Ludlam 2010-03-02 7:58 ` AW: " Berndl, Klaus 1 sibling, 1 reply; 64+ messages in thread From: Eric M. Ludlam @ 2010-03-01 22:42 UTC (permalink / raw) To: Stefan Monnier; +Cc: Chong Yidong, Lluís, emacs-devel 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 ^ permalink raw reply [flat|nested] 64+ messages in thread
* AW: Fwd: CEDET sync 2010-03-01 22:42 ` Eric M. Ludlam @ 2010-03-02 7:58 ` Berndl, Klaus 2010-03-02 8:51 ` Stephen J. Turnbull 2010-03-02 15:25 ` Stefan Monnier 0 siblings, 2 replies; 64+ messages in thread From: Berndl, Klaus @ 2010-03-02 7:58 UTC (permalink / raw) To: Eric M. Ludlam, Stefan Monnier Cc: Chong Yidong, Lluís, emacs-devel@gnu.org 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 ^ permalink raw reply [flat|nested] 64+ messages in thread
* AW: Fwd: CEDET sync 2010-03-02 7:58 ` AW: " Berndl, Klaus @ 2010-03-02 8:51 ` Stephen J. Turnbull 2010-03-02 9:35 ` David Kastrup 2010-03-02 15:25 ` Stefan Monnier 1 sibling, 1 reply; 64+ messages in thread From: Stephen J. Turnbull @ 2010-03-02 8:51 UTC (permalink / raw) To: Berndl, Klaus Cc: Chong Yidong, Lluís, emacs-devel@gnu.org, Stefan Monnier, Eric M. Ludlam 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. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: AW: Fwd: CEDET sync 2010-03-02 8:51 ` Stephen J. Turnbull @ 2010-03-02 9:35 ` David Kastrup 2010-03-02 9:43 ` Lennart Borgman 2010-03-02 15:23 ` Stephen J. Turnbull 0 siblings, 2 replies; 64+ messages in thread From: David Kastrup @ 2010-03-02 9:35 UTC (permalink / raw) To: emacs-devel "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 ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: AW: Fwd: CEDET sync 2010-03-02 9:35 ` David Kastrup @ 2010-03-02 9:43 ` Lennart Borgman 2010-03-02 10:36 ` AW: " Berndl, Klaus 2010-03-02 15:23 ` Stephen J. Turnbull 1 sibling, 1 reply; 64+ messages in thread From: Lennart Borgman @ 2010-03-02 9:43 UTC (permalink / raw) To: David Kastrup; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 64+ messages in thread
* AW: AW: Fwd: CEDET sync 2010-03-02 9:43 ` Lennart Borgman @ 2010-03-02 10:36 ` Berndl, Klaus 2010-03-02 10:43 ` Lennart Borgman 0 siblings, 1 reply; 64+ messages in thread From: Berndl, Klaus @ 2010-03-02 10:36 UTC (permalink / raw) To: Lennart Borgman, David Kastrup; +Cc: emacs-devel@gnu.org 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 ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: AW: Fwd: CEDET sync 2010-03-02 10:36 ` AW: " Berndl, Klaus @ 2010-03-02 10:43 ` Lennart Borgman 2010-03-02 11:08 ` AW: " Berndl, Klaus 2010-03-02 11:13 ` AW: Fwd: CEDET sync Richard Riley 0 siblings, 2 replies; 64+ messages in thread From: Lennart Borgman @ 2010-03-02 10:43 UTC (permalink / raw) To: Berndl, Klaus; +Cc: David Kastrup, emacs-devel@gnu.org 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. ^ permalink raw reply [flat|nested] 64+ messages in thread
* AW: AW: Fwd: CEDET sync 2010-03-02 10:43 ` Lennart Borgman @ 2010-03-02 11:08 ` Berndl, Klaus 2010-03-02 21:03 ` Juri Linkov 2010-03-02 11:13 ` AW: Fwd: CEDET sync Richard Riley 1 sibling, 1 reply; 64+ messages in thread From: Berndl, Klaus @ 2010-03-02 11:08 UTC (permalink / raw) To: Lennart Borgman; +Cc: David Kastrup, emacs-devel@gnu.org 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. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: AW: AW: Fwd: CEDET sync 2010-03-02 11:08 ` AW: " Berndl, Klaus @ 2010-03-02 21:03 ` Juri Linkov 2010-03-03 3:20 ` Stephen J. Turnbull 0 siblings, 1 reply; 64+ messages in thread From: Juri Linkov @ 2010-03-02 21:03 UTC (permalink / raw) To: Berndl, Klaus; +Cc: emacs-devel > 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/ ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: AW: AW: Fwd: CEDET sync 2010-03-02 21:03 ` Juri Linkov @ 2010-03-03 3:20 ` Stephen J. Turnbull 2010-03-05 13:45 ` Michael Sperber 0 siblings, 1 reply; 64+ messages in thread From: Stephen J. Turnbull @ 2010-03-03 3:20 UTC (permalink / raw) To: Juri Linkov; +Cc: Berndl, Klaus, mike, emacs-devel 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. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: AW: AW: Fwd: CEDET sync 2010-03-03 3:20 ` Stephen J. Turnbull @ 2010-03-05 13:45 ` Michael Sperber 2010-03-05 17:07 ` read syntax for window configs (was: CEDET sync) Drew Adams 0 siblings, 1 reply; 64+ messages in thread From: Michael Sperber @ 2010-03-05 13:45 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Juri Linkov, Berndl, Klaus, mike, emacs-devel "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 ^ permalink raw reply [flat|nested] 64+ messages in thread
* read syntax for window configs (was: CEDET sync) 2010-03-05 13:45 ` Michael Sperber @ 2010-03-05 17:07 ` Drew Adams 2010-03-05 17:48 ` Lennart Borgman ` (2 more replies) 0 siblings, 3 replies; 64+ messages in thread From: Drew Adams @ 2010-03-05 17:07 UTC (permalink / raw) To: 'Michael Sperber', 'Stephen J. Turnbull' Cc: 'Juri Linkov', 'Berndl, Klaus', mike, 'Lennart Borgman', emacs-devel > > > 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. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: read syntax for window configs (was: CEDET sync) 2010-03-05 17:07 ` read syntax for window configs (was: CEDET sync) Drew Adams @ 2010-03-05 17:48 ` Lennart Borgman 2010-03-06 17:44 ` read syntax for window configs Juri Linkov 2010-03-06 17:48 ` Juri Linkov 2010-03-18 16:07 ` Michael Sperber 2 siblings, 1 reply; 64+ messages in thread From: Lennart Borgman @ 2010-03-05 17:48 UTC (permalink / raw) To: Drew Adams Cc: Berndl, Klaus, mike, emacs-devel, Juri Linkov, Michael Sperber, Stephen J. Turnbull 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. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: read syntax for window configs 2010-03-05 17:48 ` Lennart Borgman @ 2010-03-06 17:44 ` Juri Linkov 0 siblings, 0 replies; 64+ messages in thread From: Juri Linkov @ 2010-03-06 17:44 UTC (permalink / raw) To: Lennart Borgman; +Cc: klaus.berndl, sperber, drew.adams, emacs-devel >> 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/ ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: read syntax for window configs 2010-03-05 17:07 ` read syntax for window configs (was: CEDET sync) Drew Adams 2010-03-05 17:48 ` Lennart Borgman @ 2010-03-06 17:48 ` Juri Linkov 2010-03-06 19:32 ` Drew Adams 2010-03-18 16:07 ` Michael Sperber 2 siblings, 1 reply; 64+ messages in thread From: Juri Linkov @ 2010-03-06 17:48 UTC (permalink / raw) To: Drew Adams; +Cc: klaus.berndl, sperber, lennart.borgman, emacs-devel > 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/ ^ permalink raw reply [flat|nested] 64+ messages in thread
* RE: read syntax for window configs 2010-03-06 17:48 ` Juri Linkov @ 2010-03-06 19:32 ` Drew Adams 0 siblings, 0 replies; 64+ messages in thread From: Drew Adams @ 2010-03-06 19:32 UTC (permalink / raw) To: 'Juri Linkov'; +Cc: klaus.berndl, sperber, lennart.borgman, emacs-devel > > 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. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: read syntax for window configs 2010-03-05 17:07 ` read syntax for window configs (was: CEDET sync) Drew Adams 2010-03-05 17:48 ` Lennart Borgman 2010-03-06 17:48 ` Juri Linkov @ 2010-03-18 16:07 ` Michael Sperber 2010-03-18 16:41 ` Drew Adams 2010-03-19 10:48 ` martin rudalics 2 siblings, 2 replies; 64+ messages in thread From: Michael Sperber @ 2010-03-18 16:07 UTC (permalink / raw) To: Drew Adams Cc: 'Berndl, Klaus', 'Lennart Borgman', mike, emacs-devel, 'Juri Linkov', 'Stephen J. Turnbull' [-- 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)) ^ permalink raw reply [flat|nested] 64+ messages in thread
* RE: read syntax for window configs 2010-03-18 16:07 ` Michael Sperber @ 2010-03-18 16:41 ` Drew Adams 2010-03-19 10:48 ` martin rudalics 1 sibling, 0 replies; 64+ messages in thread From: Drew Adams @ 2010-03-18 16:41 UTC (permalink / raw) To: 'Michael Sperber' Cc: 'Berndl, Klaus', 'Lennart Borgman', mike, emacs-devel, 'Juri Linkov', 'Stephen J. Turnbull' > >> > > 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. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: read syntax for window configs 2010-03-18 16:07 ` Michael Sperber 2010-03-18 16:41 ` Drew Adams @ 2010-03-19 10:48 ` martin rudalics 2010-03-19 11:09 ` Michael Sperber 1 sibling, 1 reply; 64+ messages in thread From: martin rudalics @ 2010-03-19 10:48 UTC (permalink / raw) To: Michael Sperber; +Cc: mike, emacs-devel > 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 ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: read syntax for window configs 2010-03-19 10:48 ` martin rudalics @ 2010-03-19 11:09 ` Michael Sperber 2010-03-19 13:07 ` martin rudalics 0 siblings, 1 reply; 64+ messages in thread From: Michael Sperber @ 2010-03-19 11:09 UTC (permalink / raw) To: martin rudalics; +Cc: mike, emacs-devel 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 ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: read syntax for window configs 2010-03-19 11:09 ` Michael Sperber @ 2010-03-19 13:07 ` martin rudalics 2010-03-19 15:31 ` Michael Sperber 0 siblings, 1 reply; 64+ messages in thread From: martin rudalics @ 2010-03-19 13:07 UTC (permalink / raw) To: Michael Sperber; +Cc: mike, emacs-devel >> 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 ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: read syntax for window configs 2010-03-19 13:07 ` martin rudalics @ 2010-03-19 15:31 ` Michael Sperber 0 siblings, 0 replies; 64+ messages in thread From: Michael Sperber @ 2010-03-19 15:31 UTC (permalink / raw) To: martin rudalics; +Cc: mike, emacs-devel 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 ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: AW: Fwd: CEDET sync 2010-03-02 10:43 ` Lennart Borgman 2010-03-02 11:08 ` AW: " Berndl, Klaus @ 2010-03-02 11:13 ` Richard Riley 2010-03-02 11:42 ` David Kastrup 1 sibling, 1 reply; 64+ messages in thread From: Richard Riley @ 2010-03-02 11:13 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: AW: Fwd: CEDET sync 2010-03-02 11:13 ` AW: Fwd: CEDET sync Richard Riley @ 2010-03-02 11:42 ` David Kastrup 0 siblings, 0 replies; 64+ messages in thread From: David Kastrup @ 2010-03-02 11:42 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: AW: Fwd: CEDET sync 2010-03-02 9:35 ` David Kastrup 2010-03-02 9:43 ` Lennart Borgman @ 2010-03-02 15:23 ` Stephen J. Turnbull 2010-03-02 16:06 ` David Kastrup 2010-03-03 7:07 ` joakim 1 sibling, 2 replies; 64+ messages in thread From: Stephen J. Turnbull @ 2010-03-02 15:23 UTC (permalink / raw) To: David Kastrup; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: AW: Fwd: CEDET sync 2010-03-02 15:23 ` Stephen J. Turnbull @ 2010-03-02 16:06 ` David Kastrup 2010-03-02 17:20 ` Stephen J. Turnbull 2010-03-03 7:07 ` joakim 1 sibling, 1 reply; 64+ messages in thread From: David Kastrup @ 2010-03-02 16:06 UTC (permalink / raw) To: emacs-devel "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 ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: AW: Fwd: CEDET sync 2010-03-02 16:06 ` David Kastrup @ 2010-03-02 17:20 ` Stephen J. Turnbull 2010-03-02 17:58 ` David Kastrup ` (2 more replies) 0 siblings, 3 replies; 64+ messages in thread From: Stephen J. Turnbull @ 2010-03-02 17:20 UTC (permalink / raw) To: David Kastrup; +Cc: emacs-devel 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?" ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: AW: Fwd: CEDET sync 2010-03-02 17:20 ` Stephen J. Turnbull @ 2010-03-02 17:58 ` David Kastrup 2010-03-03 3:51 ` Stephen J. Turnbull 2010-03-02 18:40 ` OT: threats to Free Software (was: AW: Fwd: CEDET sync) Stefan Monnier 2010-03-03 10:37 ` AW: Fwd: CEDET sync Richard Stallman 2 siblings, 1 reply; 64+ messages in thread From: David Kastrup @ 2010-03-02 17:58 UTC (permalink / raw) To: emacs-devel "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 ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: AW: Fwd: CEDET sync 2010-03-02 17:58 ` David Kastrup @ 2010-03-03 3:51 ` Stephen J. Turnbull 0 siblings, 0 replies; 64+ messages in thread From: Stephen J. Turnbull @ 2010-03-03 3:51 UTC (permalink / raw) To: David Kastrup; +Cc: emacs-devel 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/". ^ permalink raw reply [flat|nested] 64+ messages in thread
* OT: threats to Free Software (was: AW: Fwd: CEDET sync) 2010-03-02 17:20 ` Stephen J. Turnbull 2010-03-02 17:58 ` David Kastrup @ 2010-03-02 18:40 ` Stefan Monnier 2010-03-02 19:33 ` Lennart Borgman ` (3 more replies) 2010-03-03 10:37 ` AW: Fwd: CEDET sync Richard Stallman 2 siblings, 4 replies; 64+ messages in thread From: Stefan Monnier @ 2010-03-02 18:40 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: David Kastrup, emacs-devel > 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 ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: OT: threats to Free Software (was: AW: Fwd: CEDET sync) 2010-03-02 18:40 ` OT: threats to Free Software (was: AW: Fwd: CEDET sync) Stefan Monnier @ 2010-03-02 19:33 ` Lennart Borgman 2010-03-02 22:07 ` David Reitter ` (2 subsequent siblings) 3 siblings, 0 replies; 64+ messages in thread From: Lennart Borgman @ 2010-03-02 19:33 UTC (permalink / raw) To: Stefan Monnier; +Cc: Stephen J. Turnbull, David Kastrup, emacs-devel 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. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: OT: threats to Free Software (was: AW: Fwd: CEDET sync) 2010-03-02 18:40 ` OT: threats to Free Software (was: AW: Fwd: CEDET sync) Stefan Monnier 2010-03-02 19:33 ` Lennart Borgman @ 2010-03-02 22:07 ` David Reitter 2010-03-03 22:48 ` Richard Stallman 2010-03-03 4:00 ` Stephen J. Turnbull 2010-03-03 10:37 ` Richard Stallman 3 siblings, 1 reply; 64+ messages in thread From: David Reitter @ 2010-03-02 22:07 UTC (permalink / raw) To: emacs-devel@gnu.org discussions [-- 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 --] ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: OT: threats to Free Software (was: AW: Fwd: CEDET sync) 2010-03-02 22:07 ` David Reitter @ 2010-03-03 22:48 ` Richard Stallman 0 siblings, 0 replies; 64+ messages in thread From: Richard Stallman @ 2010-03-03 22:48 UTC (permalink / raw) To: David Reitter; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 64+ messages in thread
* OT: threats to Free Software (was: AW: Fwd: CEDET sync) 2010-03-02 18:40 ` OT: threats to Free Software (was: AW: Fwd: CEDET sync) Stefan Monnier 2010-03-02 19:33 ` Lennart Borgman 2010-03-02 22:07 ` David Reitter @ 2010-03-03 4:00 ` Stephen J. Turnbull 2010-03-03 22:48 ` Richard Stallman 2010-03-03 10:37 ` Richard Stallman 3 siblings, 1 reply; 64+ messages in thread From: Stephen J. Turnbull @ 2010-03-03 4:00 UTC (permalink / raw) To: Stefan Monnier; +Cc: David Kastrup, emacs-devel 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. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: OT: threats to Free Software (was: AW: Fwd: CEDET sync) 2010-03-03 4:00 ` Stephen J. Turnbull @ 2010-03-03 22:48 ` Richard Stallman 0 siblings, 0 replies; 64+ messages in thread From: Richard Stallman @ 2010-03-03 22:48 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: dak, monnier, emacs-devel 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. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: OT: threats to Free Software (was: AW: Fwd: CEDET sync) 2010-03-02 18:40 ` OT: threats to Free Software (was: AW: Fwd: CEDET sync) Stefan Monnier ` (2 preceding siblings ...) 2010-03-03 4:00 ` Stephen J. Turnbull @ 2010-03-03 10:37 ` Richard Stallman 3 siblings, 0 replies; 64+ messages in thread From: Richard Stallman @ 2010-03-03 10:37 UTC (permalink / raw) To: Stefan Monnier; +Cc: stephen, dak, emacs-devel 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. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: AW: Fwd: CEDET sync 2010-03-02 17:20 ` Stephen J. Turnbull 2010-03-02 17:58 ` David Kastrup 2010-03-02 18:40 ` OT: threats to Free Software (was: AW: Fwd: CEDET sync) Stefan Monnier @ 2010-03-03 10:37 ` Richard Stallman 2010-03-03 18:37 ` Stephen J. Turnbull 2 siblings, 1 reply; 64+ messages in thread From: Richard Stallman @ 2010-03-03 10:37 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: dak, emacs-devel 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. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: AW: Fwd: CEDET sync 2010-03-03 10:37 ` AW: Fwd: CEDET sync Richard Stallman @ 2010-03-03 18:37 ` Stephen J. Turnbull 2010-03-03 19:00 ` Chong Yidong 2010-03-05 20:05 ` Richard Stallman 0 siblings, 2 replies; 64+ messages in thread From: Stephen J. Turnbull @ 2010-03-03 18:37 UTC (permalink / raw) To: rms; +Cc: dak, emacs-devel 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. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: AW: Fwd: CEDET sync 2010-03-03 18:37 ` Stephen J. Turnbull @ 2010-03-03 19:00 ` Chong Yidong 2010-03-05 20:05 ` Richard Stallman 1 sibling, 0 replies; 64+ messages in thread From: Chong Yidong @ 2010-03-03 19:00 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: dak, rms, emacs-devel Please move the drama off-list. Thanks. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: AW: Fwd: CEDET sync 2010-03-03 18:37 ` Stephen J. Turnbull 2010-03-03 19:00 ` Chong Yidong @ 2010-03-05 20:05 ` Richard Stallman 2010-03-06 4:29 ` Stephen J. Turnbull 1 sibling, 1 reply; 64+ messages in thread From: Richard Stallman @ 2010-03-05 20:05 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: dak, emacs-devel > 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. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: AW: Fwd: CEDET sync 2010-03-05 20:05 ` Richard Stallman @ 2010-03-06 4:29 ` Stephen J. Turnbull 2010-03-06 7:45 ` David Kastrup 0 siblings, 1 reply; 64+ messages in thread From: Stephen J. Turnbull @ 2010-03-06 4:29 UTC (permalink / raw) To: rms; +Cc: dak, emacs-devel 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. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: AW: Fwd: CEDET sync 2010-03-06 4:29 ` Stephen J. Turnbull @ 2010-03-06 7:45 ` David Kastrup 0 siblings, 0 replies; 64+ messages in thread From: David Kastrup @ 2010-03-06 7:45 UTC (permalink / raw) To: emacs-devel "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 ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: AW: Fwd: CEDET sync 2010-03-02 15:23 ` Stephen J. Turnbull 2010-03-02 16:06 ` David Kastrup @ 2010-03-03 7:07 ` joakim 1 sibling, 0 replies; 64+ messages in thread From: joakim @ 2010-03-03 7:07 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: David Kastrup, emacs-devel "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 ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Fwd: CEDET sync 2010-03-02 7:58 ` AW: " Berndl, Klaus 2010-03-02 8:51 ` Stephen J. Turnbull @ 2010-03-02 15:25 ` Stefan Monnier 2010-03-02 15:59 ` AW: " Berndl, Klaus 2010-03-03 10:38 ` Richard Stallman 1 sibling, 2 replies; 64+ messages in thread From: Stefan Monnier @ 2010-03-02 15:25 UTC (permalink / raw) To: Berndl, Klaus Cc: Chong Yidong, emacs-devel@gnu.org, Lluís, Eric M. Ludlam > 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. ^ permalink raw reply [flat|nested] 64+ messages in thread
* AW: Fwd: CEDET sync 2010-03-02 15:25 ` Stefan Monnier @ 2010-03-02 15:59 ` Berndl, Klaus 2010-03-02 16:08 ` Chong Yidong 2010-03-02 18:45 ` Stefan Monnier 2010-03-03 10:38 ` Richard Stallman 1 sibling, 2 replies; 64+ messages in thread From: Berndl, Klaus @ 2010-03-02 15:59 UTC (permalink / raw) To: Stefan Monnier Cc: Chong Yidong, emacs-devel@gnu.org, Lluís, Eric M. Ludlam >> 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 ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: AW: Fwd: CEDET sync 2010-03-02 15:59 ` AW: " Berndl, Klaus @ 2010-03-02 16:08 ` Chong Yidong 2010-03-02 16:44 ` Stephen J. Turnbull 2010-03-02 18:45 ` Stefan Monnier 1 sibling, 1 reply; 64+ messages in thread From: Chong Yidong @ 2010-03-02 16:08 UTC (permalink / raw) To: Berndl, Klaus Cc: Lluís, emacs-devel@gnu.org, Stefan Monnier, Eric M. Ludlam "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. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: AW: Fwd: CEDET sync 2010-03-02 16:08 ` Chong Yidong @ 2010-03-02 16:44 ` Stephen J. Turnbull 2010-03-02 20:28 ` Chong Yidong 0 siblings, 1 reply; 64+ messages in thread From: Stephen J. Turnbull @ 2010-03-02 16:44 UTC (permalink / raw) To: Chong Yidong Cc: Berndl, Klaus, Eric M. Ludlam, Lluís, Stefan Monnier, emacs-devel@gnu.org 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. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: AW: Fwd: CEDET sync 2010-03-02 16:44 ` Stephen J. Turnbull @ 2010-03-02 20:28 ` Chong Yidong 2010-03-03 4:06 ` Stephen J. Turnbull 0 siblings, 1 reply; 64+ messages in thread From: Chong Yidong @ 2010-03-02 20:28 UTC (permalink / raw) To: Stephen J. Turnbull Cc: Berndl, Klaus, ís, emacs-devel@gnu.org, Stefan Monnier, Eric M. Ludlam "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. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: AW: Fwd: CEDET sync 2010-03-02 20:28 ` Chong Yidong @ 2010-03-03 4:06 ` Stephen J. Turnbull 2010-03-03 4:47 ` Miles Bader 2010-03-03 7:41 ` David Kastrup 0 siblings, 2 replies; 64+ messages in thread From: Stephen J. Turnbull @ 2010-03-03 4:06 UTC (permalink / raw) To: Chong Yidong Cc: Berndl, Klaus, Llu, ís, emacs-devel@gnu.org, Stefan Monnier, Eric M. Ludlam 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). ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: AW: Fwd: CEDET sync 2010-03-03 4:06 ` Stephen J. Turnbull @ 2010-03-03 4:47 ` Miles Bader 2010-03-03 7:21 ` Stephen J. Turnbull 2010-03-03 7:41 ` David Kastrup 1 sibling, 1 reply; 64+ messages in thread From: Miles Bader @ 2010-03-03 4:47 UTC (permalink / raw) To: Stephen J. Turnbull Cc: Berndl, Klaus, Llu, Chong Yidong, ís, emacs-devel@gnu.org, Stefan Monnier, Eric M. Ludlam "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. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: AW: Fwd: CEDET sync 2010-03-03 4:47 ` Miles Bader @ 2010-03-03 7:21 ` Stephen J. Turnbull 2010-03-03 15:45 ` Chong Yidong 0 siblings, 1 reply; 64+ messages in thread From: Stephen J. Turnbull @ 2010-03-03 7:21 UTC (permalink / raw) To: Miles Bader Cc: Berndl, Klaus, Llu, Chong Yidong, ís, emacs-devel@gnu.org, Stefan Monnier, Eric M. Ludlam 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. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: AW: Fwd: CEDET sync 2010-03-03 7:21 ` Stephen J. Turnbull @ 2010-03-03 15:45 ` Chong Yidong 0 siblings, 0 replies; 64+ messages in thread From: Chong Yidong @ 2010-03-03 15:45 UTC (permalink / raw) To: Stephen J. Turnbull Cc: Berndl, Klaus, Llu, ís, emacs-devel@gnu.org, Monnier, Eric M. Ludlam, Miles Bader "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. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: AW: Fwd: CEDET sync 2010-03-03 4:06 ` Stephen J. Turnbull 2010-03-03 4:47 ` Miles Bader @ 2010-03-03 7:41 ` David Kastrup 2010-03-03 8:51 ` Stephen J. Turnbull 2010-03-03 9:10 ` tomas 1 sibling, 2 replies; 64+ messages in thread From: David Kastrup @ 2010-03-03 7:41 UTC (permalink / raw) To: emacs-devel "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 ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: AW: Fwd: CEDET sync 2010-03-03 7:41 ` David Kastrup @ 2010-03-03 8:51 ` Stephen J. Turnbull 2010-03-03 9:10 ` tomas 1 sibling, 0 replies; 64+ messages in thread From: Stephen J. Turnbull @ 2010-03-03 8:51 UTC (permalink / raw) To: David Kastrup; +Cc: emacs-devel 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? ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: AW: Fwd: CEDET sync 2010-03-03 7:41 ` David Kastrup 2010-03-03 8:51 ` Stephen J. Turnbull @ 2010-03-03 9:10 ` tomas 2010-03-03 10:02 ` David Kastrup 1 sibling, 1 reply; 64+ messages in thread From: tomas @ 2010-03-03 9:10 UTC (permalink / raw) To: emacs-devel -----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----- ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: AW: Fwd: CEDET sync 2010-03-03 9:10 ` tomas @ 2010-03-03 10:02 ` David Kastrup 2010-03-03 16:51 ` Stephen J. Turnbull 0 siblings, 1 reply; 64+ messages in thread From: David Kastrup @ 2010-03-03 10:02 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: AW: Fwd: CEDET sync 2010-03-03 10:02 ` David Kastrup @ 2010-03-03 16:51 ` Stephen J. Turnbull 0 siblings, 0 replies; 64+ messages in thread From: Stephen J. Turnbull @ 2010-03-03 16:51 UTC (permalink / raw) To: David Kastrup; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Fwd: CEDET sync 2010-03-02 15:59 ` AW: " Berndl, Klaus 2010-03-02 16:08 ` Chong Yidong @ 2010-03-02 18:45 ` Stefan Monnier 1 sibling, 0 replies; 64+ messages in thread From: Stefan Monnier @ 2010-03-02 18:45 UTC (permalink / raw) To: Berndl, Klaus Cc: Chong Yidong, emacs-devel@gnu.org, Lluís, Eric M. Ludlam > 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 ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Fwd: CEDET sync 2010-03-02 15:25 ` Stefan Monnier 2010-03-02 15:59 ` AW: " Berndl, Klaus @ 2010-03-03 10:38 ` Richard Stallman 1 sibling, 0 replies; 64+ messages in thread From: Richard Stallman @ 2010-03-03 10:38 UTC (permalink / raw) To: Stefan Monnier; +Cc: klaus.berndl, cyd, eric, xscript, emacs-devel 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. ^ permalink raw reply [flat|nested] 64+ messages in thread
end of thread, other threads:[~2010-03-19 15:31 UTC | newest] Thread overview: 64+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-03-01 18:53 Fwd: CEDET sync Lluís 2010-03-01 18:59 ` Chong Yidong 2010-03-01 19:36 ` Lennart Borgman 2010-03-01 21:27 ` Stefan Monnier 2010-03-01 22:07 ` Fabian Ezequiel Gallina 2010-03-01 22:42 ` Eric M. Ludlam 2010-03-02 7:58 ` AW: " Berndl, Klaus 2010-03-02 8:51 ` Stephen J. Turnbull 2010-03-02 9:35 ` David Kastrup 2010-03-02 9:43 ` Lennart Borgman 2010-03-02 10:36 ` AW: " Berndl, Klaus 2010-03-02 10:43 ` Lennart Borgman 2010-03-02 11:08 ` AW: " Berndl, Klaus 2010-03-02 21:03 ` Juri Linkov 2010-03-03 3:20 ` Stephen J. Turnbull 2010-03-05 13:45 ` Michael Sperber 2010-03-05 17:07 ` read syntax for window configs (was: CEDET sync) Drew Adams 2010-03-05 17:48 ` Lennart Borgman 2010-03-06 17:44 ` read syntax for window configs Juri Linkov 2010-03-06 17:48 ` Juri Linkov 2010-03-06 19:32 ` Drew Adams 2010-03-18 16:07 ` Michael Sperber 2010-03-18 16:41 ` Drew Adams 2010-03-19 10:48 ` martin rudalics 2010-03-19 11:09 ` Michael Sperber 2010-03-19 13:07 ` martin rudalics 2010-03-19 15:31 ` Michael Sperber 2010-03-02 11:13 ` AW: Fwd: CEDET sync Richard Riley 2010-03-02 11:42 ` David Kastrup 2010-03-02 15:23 ` Stephen J. Turnbull 2010-03-02 16:06 ` David Kastrup 2010-03-02 17:20 ` Stephen J. Turnbull 2010-03-02 17:58 ` David Kastrup 2010-03-03 3:51 ` Stephen J. Turnbull 2010-03-02 18:40 ` OT: threats to Free Software (was: AW: Fwd: CEDET sync) Stefan Monnier 2010-03-02 19:33 ` Lennart Borgman 2010-03-02 22:07 ` David Reitter 2010-03-03 22:48 ` Richard Stallman 2010-03-03 4:00 ` Stephen J. Turnbull 2010-03-03 22:48 ` Richard Stallman 2010-03-03 10:37 ` Richard Stallman 2010-03-03 10:37 ` AW: Fwd: CEDET sync Richard Stallman 2010-03-03 18:37 ` Stephen J. Turnbull 2010-03-03 19:00 ` Chong Yidong 2010-03-05 20:05 ` Richard Stallman 2010-03-06 4:29 ` Stephen J. Turnbull 2010-03-06 7:45 ` David Kastrup 2010-03-03 7:07 ` joakim 2010-03-02 15:25 ` Stefan Monnier 2010-03-02 15:59 ` AW: " Berndl, Klaus 2010-03-02 16:08 ` Chong Yidong 2010-03-02 16:44 ` Stephen J. Turnbull 2010-03-02 20:28 ` Chong Yidong 2010-03-03 4:06 ` Stephen J. Turnbull 2010-03-03 4:47 ` Miles Bader 2010-03-03 7:21 ` Stephen J. Turnbull 2010-03-03 15:45 ` Chong Yidong 2010-03-03 7:41 ` David Kastrup 2010-03-03 8:51 ` Stephen J. Turnbull 2010-03-03 9:10 ` tomas 2010-03-03 10:02 ` David Kastrup 2010-03-03 16:51 ` Stephen J. Turnbull 2010-03-02 18:45 ` Stefan Monnier 2010-03-03 10:38 ` Richard Stallman
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.