* Re: Next pretest, and branching plans [not found] ` <87ljemdzxo.fsf@stupidchicken.com> @ 2010-02-23 5:31 ` Jason Rumney 2010-02-23 18:29 ` Eli Zaretskii ` (2 more replies) 0 siblings, 3 replies; 149+ messages in thread From: Jason Rumney @ 2010-02-23 5:31 UTC (permalink / raw To: Chong Yidong; +Cc: Christoph, eliz, emacs-devel On 22/02/2010 05:46, Chong Yidong wrote: > Jason, do you think you could down write some instructions? You could > put it at the end of admin/make-tarball.txt, or as its own file in the > admin/ directory. > I don't have access to bzr at the moment, but here are the steps required: 1. Download the source tarball, check signature and unpack. 2. Make sure you have an up to date bzr source tree to use for the admin directory. 3. "make install" to create the bin subdirectory with the appropriate files. 4. Copy libxpm.dll from a previous tarball into the bin directory. 5. Check the file admin/nt/README.W32 (from bzr tree) for necessary changes. 6. Make sure 7z.exe is in your PATH, or modify admin/nt/makedist.bat to use your preferred zip utility (I found that InfoZip zip.exe does not work well, which is why I changed to use 7z.exe) 7. Run admin/nt/makedist.bat. With no args it will give you help on usage. 8. Test the resulting zip files. Then the process of signing and uploading begins. This is documented in the GNU maintainers manual, and is probably the more difficult part of the process, particularly if your internet connection is not fast and stable and uploads get interrupted. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Next pretest, and branching plans 2010-02-23 5:31 ` Next pretest, and branching plans Jason Rumney @ 2010-02-23 18:29 ` Eli Zaretskii 2010-02-23 21:12 ` Jason Rumney 2010-02-24 6:04 ` Richard Stallman 2010-03-13 3:10 ` Next pretest, and branching plans Christoph 2 siblings, 1 reply; 149+ messages in thread From: Eli Zaretskii @ 2010-02-23 18:29 UTC (permalink / raw To: Jason Rumney; +Cc: emacs-devel > Date: Tue, 23 Feb 2010 13:31:25 +0800 > From: Jason Rumney <jasonr@gnu.org> > CC: Christoph <cschol2112@googlemail.com>, eliz@gnu.org, > emacs-devel@gnu.org > > 6. Make sure 7z.exe is in your PATH, or modify admin/nt/makedist.bat to > use your preferred zip utility (I found that InfoZip zip.exe does not > work well, which is why I changed to use 7z.exe) What didn't work well with zip.exe? > 8. Test the resulting zip files. What tests did you usually run? > Then the process of signing and uploading begins. This is documented in > the GNU maintainers manual, and is probably the more difficult part of > the process, particularly if your internet connection is not fast and > stable and uploads get interrupted. It also requires to register a GPG signature, doesn't it? ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Next pretest, and branching plans 2010-02-23 18:29 ` Eli Zaretskii @ 2010-02-23 21:12 ` Jason Rumney 0 siblings, 0 replies; 149+ messages in thread From: Jason Rumney @ 2010-02-23 21:12 UTC (permalink / raw To: Eli Zaretskii; +Cc: emacs-devel On 24/02/2010 02:29, Eli Zaretskii wrote: >> 6. Make sure 7z.exe is in your PATH, or modify admin/nt/makedist.bat to >> use your preferred zip utility (I found that InfoZip zip.exe does not >> work well, which is why I changed to use 7z.exe) >> > What didn't work well with zip.exe > rem Info-ZIP zip seems to be broken on Windows. rem It always writes to zip.zip and treats the zipfile argument as one rem of the files to go in it. rem zip -9 -r %2-bin-i386 emacs-%1/BUGS emacs-%1/COPYING emacs-%1/README emacs-%1/README.W32 emacs-%1/INSTALL emacs-%1/bin emacs-%1/etc emacs-%1/info emacs-%1/lisp emacs-%1/leim -x emacs.mdp *.pdb *.opt *~ CVS >> 8. Test the resulting zip files. >> > What tests did you usually run? > Test that the unpacked Emacs runs, along with the other exes in the bin directory, and check that the number of files in the zip file is in the same ballpark as the previous version. > It also requires to register a GPG signature, doesn't it? > Yes, your public key needs to be in the GNU keyring to upload to the FTP server. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Next pretest, and branching plans 2010-02-23 5:31 ` Next pretest, and branching plans Jason Rumney 2010-02-23 18:29 ` Eli Zaretskii @ 2010-02-24 6:04 ` Richard Stallman 2010-02-24 13:34 ` Sean Sieger 2010-02-24 14:05 ` Chong Yidong 2010-03-13 3:10 ` Next pretest, and branching plans Christoph 2 siblings, 2 replies; 149+ messages in thread From: Richard Stallman @ 2010-02-24 6:04 UTC (permalink / raw To: Jason Rumney; +Cc: cschol2112, cyd, eliz, emacs-devel Have the manuals been updated? In a release, the manuals should always be up to date. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Next pretest, and branching plans 2010-02-24 6:04 ` Richard Stallman @ 2010-02-24 13:34 ` Sean Sieger 2010-02-24 15:05 ` Davis Herring 2010-02-24 14:05 ` Chong Yidong 1 sibling, 1 reply; 149+ messages in thread From: Sean Sieger @ 2010-02-24 13:34 UTC (permalink / raw To: emacs-devel [-- Attachment #1: Type: text/plain, Size: 231 bytes --] Richard Stallman <rms@gnu.org> writes: Have the manuals been updated? In a release, the manuals should always be up to date. I did emacs -Q --eval "(setq Info-default-directory-list '(\".\"))" \ -f info-xref-check-all [-- Attachment #2: manual xrefs --] [-- Type: application/octet-stream, Size: 2217 bytes --] In file /usr/local/texlive/2009/texmf/doc/info/dvips.info: No such node: (kpathsea)Bugs No such node: (kpathsea)unixtex No such node: (kpathsea)Bugs No such node: (kpathsea)Bugs No such node: (kpathsea)Path specifications No such node: (kpathsea)MakeTeX script arguments No such node: (kpathsea)unixtex No such node: (kpathsea)unixtex No such node: (kpathsea)unixtex No such node: (kpathsea)unixtex In file /usr/local/texlive/2009/texmf/doc/info/fontname.info: No such node: (dvips)psfonts In file /usr/local/texlive/2009/texmf/doc/info/kpathsea.info: Not available to check: (fontu) Not available to check: (bash) Not available to check: (autoconf) Not available to check: (coreutils) No such node: (web2c)inimf invocation Not available to check: (gcc) No such node: (web2c)dmp invocation No such node: (web2c)DMP invocation In file /usr/local/texlive/2009/texmf/doc/info/web2c.info: No such node: (kpathsea)unixtex No such node: (kpathsea)Copying No such node: (kpathsea)unixtex No such node: (kpathsea)Bugs Not available to check: (autoconf) Not available to check: (libc) No such node: (kpathsea)unixtex No such node: (dvips)psfonts No such node: (kpathsea)unixtex No such node: (kpathsea)unixtex No such node: (kpathsea)unixtex In file /home/sean/trunk/info/ccmode: Not available to check: (indent) In file /home/sean/trunk/info/eintr: Not available to check: (texinfo) In file /home/sean/trunk/info/elisp: Not available to check: (coreutils) Not available to check: (libc) In file /home/sean/trunk/info/emacs: Not available to check: (aspell) Not available to check: (diff) Not available to check: (make) Not available to check: (gdb) Not available to check: (mailutils) In file /home/sean/trunk/info/epa: Not available to check: (gnupg) In file /home/sean/trunk/info/eudc: Not available to check: (bbdb) In file /home/sean/trunk/info/info: Not available to check: (info-stnd) Not available to check: (texinfo) In file /home/sean/trunk/info/message: Not available to check: (gnupg) In file /home/sean/trunk/info/pgg: Not available to check: (gnupg) In file /home/sean/trunk/info/reftex: Not available to check: (auctex) In file /home/sean/trunk/info/tramp: Not available to check: (bbdb) done, 563 good, 23 bad [-- Attachment #3: Type: text/plain, Size: 50 bytes --] And I'm trying to figure out what to do next ... ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Next pretest, and branching plans 2010-02-24 13:34 ` Sean Sieger @ 2010-02-24 15:05 ` Davis Herring 2010-02-24 15:18 ` Sean Sieger 0 siblings, 1 reply; 149+ messages in thread From: Davis Herring @ 2010-02-24 15:05 UTC (permalink / raw To: Sean Sieger; +Cc: emacs-devel > And I'm trying to figure out what to do next ... The first 34 lines are unrelated to Emacs. All the error messages that are for Emacs are saying you're missing other Info files (like, say, those for `make') and so it can't check that the cross-references in the Emacs manual point to extant pages in those other manuals. In short, you've not found anything wrong, but there were lots of things you couldn't verify. Davis -- This product is sold by volume, not by mass. If it appears too dense or too sparse, it is because mass-energy conversion has occurred during shipping. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Next pretest, and branching plans 2010-02-24 15:05 ` Davis Herring @ 2010-02-24 15:18 ` Sean Sieger 0 siblings, 0 replies; 149+ messages in thread From: Sean Sieger @ 2010-02-24 15:18 UTC (permalink / raw To: emacs-devel The first 34 lines are unrelated to Emacs. All the error messages that are for Emacs are saying you're missing other Info files (like, say, those for `make') and so it can't check that the cross-references in the Emacs manual point to extant pages in those other manuals. In short, you've not found anything wrong, but there were lots of things you couldn't verify. Davis Thank you for your time and thought, Davis. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Next pretest, and branching plans 2010-02-24 6:04 ` Richard Stallman 2010-02-24 13:34 ` Sean Sieger @ 2010-02-24 14:05 ` Chong Yidong 2010-02-25 14:26 ` Richard Stallman 2010-02-27 16:52 ` Next pretest, and branching plans Johan Bockgård 1 sibling, 2 replies; 149+ messages in thread From: Chong Yidong @ 2010-02-24 14:05 UTC (permalink / raw To: rms; +Cc: cschol2112, eliz, emacs-devel, Jason Rumney Richard Stallman <rms@gnu.org> writes: > Have the manuals been updated? In a release, the manuals should always > be up to date. There are still a few items in NEWS that have not yet been documented, but we are mostly there. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Next pretest, and branching plans 2010-02-24 14:05 ` Chong Yidong @ 2010-02-25 14:26 ` Richard Stallman 2010-02-26 18:03 ` manuals [was Re: Next pretest, and branching plans] Glenn Morris 2010-02-27 16:52 ` Next pretest, and branching plans Johan Bockgård 1 sibling, 1 reply; 149+ messages in thread From: Richard Stallman @ 2010-02-25 14:26 UTC (permalink / raw To: Chong Yidong; +Cc: cschol2112, eliz, emacs-devel, jasonr There are still a few items in NEWS that have not yet been documented, but we are mostly there. To properly update the manuals calls for more than just to document the new features. That is the first step. The next step is to reread the whole text looking for statements that have become outdated or incorrect, and fix them. The next step is to ask other people to do likewise, looking for double coverage. ^ permalink raw reply [flat|nested] 149+ messages in thread
* manuals [was Re: Next pretest, and branching plans] 2010-02-25 14:26 ` Richard Stallman @ 2010-02-26 18:03 ` Glenn Morris 2010-02-27 2:32 ` Richard Stallman 0 siblings, 1 reply; 149+ messages in thread From: Glenn Morris @ 2010-02-26 18:03 UTC (permalink / raw To: rms; +Cc: cschol2112, Chong Yidong, jasonr, eliz, emacs-devel Richard Stallman wrote: > The next step is to reread the whole text looking for statements that > have become outdated or incorrect, and fix them. > > The next step is to ask other people to do likewise, looking for > double coverage. Emacs 23.2 is to 23.1 as 22.2 was to 22.1: largely a bug-fix release, with a few stand-alone new features. I seem to recall that for Emacs 22.x, the manuals were thoroughly checked in the way you describe only before 22.1. After that, they were only updated were needed. The manuals were checked quite well before 23.1, so following the same policy as for Emacs 22, and only updating them where needed, seems fine to me. The big changes in 23.2 are CEDET, which has its own manuals; and the change from mail-mode to message-mode. I do think the latter will affect quite a bit of documentation. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: manuals [was Re: Next pretest, and branching plans] 2010-02-26 18:03 ` manuals [was Re: Next pretest, and branching plans] Glenn Morris @ 2010-02-27 2:32 ` Richard Stallman 0 siblings, 0 replies; 149+ messages in thread From: Richard Stallman @ 2010-02-27 2:32 UTC (permalink / raw To: Glenn Morris; +Cc: cschol2112, cyd, jasonr, eliz, emacs-devel The manuals were checked quite well before 23.1, so following the same policy as for Emacs 22, and only updating them where needed, seems fine to me. If this was done thoroughly for 23.1, I agree there is no need to repeat it now. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Next pretest, and branching plans 2010-02-24 14:05 ` Chong Yidong 2010-02-25 14:26 ` Richard Stallman @ 2010-02-27 16:52 ` Johan Bockgård 2010-03-03 3:52 ` Glenn Morris 1 sibling, 1 reply; 149+ messages in thread From: Johan Bockgård @ 2010-02-27 16:52 UTC (permalink / raw To: emacs-devel Chong Yidong <cyd@stupidchicken.com> writes: > Richard Stallman <rms@gnu.org> writes: > >> Have the manuals been updated? In a release, the manuals should always >> be up to date. > > There are still a few items in NEWS that have not yet been documented, > but we are mostly there. The Emacs Lisp manual hasn't been updated with 30-bit integers (only the Emacs manual has (max buffer size)). 2.3.1 Integer Type 3.1 Integer Basics 3.8 Bitwise Operations on Integers ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Next pretest, and branching plans 2010-02-27 16:52 ` Next pretest, and branching plans Johan Bockgård @ 2010-03-03 3:52 ` Glenn Morris 2010-03-05 0:31 ` Johan Bockgård 0 siblings, 1 reply; 149+ messages in thread From: Glenn Morris @ 2010-03-03 3:52 UTC (permalink / raw To: Johan Bockgård; +Cc: emacs-devel Johan Bockgård wrote: > The Emacs Lisp manual hasn't been updated with 30-bit integers (only the > Emacs manual has (max buffer size)). > > 2.3.1 Integer Type > 3.1 Integer Basics > 3.8 Bitwise Operations on Integers Thanks, I tried to update this. It would be great if you could check it. (Please make a bug report for anything else that is incorrectly marked as having being updated.) ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Next pretest, and branching plans 2010-03-03 3:52 ` Glenn Morris @ 2010-03-05 0:31 ` Johan Bockgård 2010-03-05 19:50 ` integer overflow [was Re: Next pretest, and branching plans] Glenn Morris 0 siblings, 1 reply; 149+ messages in thread From: Johan Bockgård @ 2010-03-05 0:31 UTC (permalink / raw To: emacs-devel Glenn Morris <rgm@gnu.org> writes: > Johan Bockgård wrote: > >> The Emacs Lisp manual hasn't been updated with 30-bit integers (only the >> Emacs manual has (max buffer size)). >> >> 2.3.1 Integer Type >> 3.1 Integer Basics >> 3.8 Bitwise Operations on Integers > > Thanks, I tried to update this. It would be great if you could check it. Looks fine. However, there is another small complication. In 2.3.1 Integer Type: > 1073741825 ; Also the integer 1 on a 30-bit implementation. In 3.1 Integer Basics: > 1073741825 ; Also the integer 1, due to overflow. When in fact (type-of 1073741825) => float! Is this even documented? ^ permalink raw reply [flat|nested] 149+ messages in thread
* integer overflow [was Re: Next pretest, and branching plans] 2010-03-05 0:31 ` Johan Bockgård @ 2010-03-05 19:50 ` Glenn Morris 2010-03-05 22:35 ` integer overflow Stefan Monnier 0 siblings, 1 reply; 149+ messages in thread From: Glenn Morris @ 2010-03-05 19:50 UTC (permalink / raw To: emacs-devel Johan Bockgård wrote: > In 2.3.1 Integer Type: > >> 1073741825 ; Also the integer 1 on a 30-bit implementation. > > In 3.1 Integer Basics: > >> 1073741825 ; Also the integer 1, due to overflow. > > When in fact (type-of 1073741825) => float! > > Is this even documented? A good question. I can't see anything about this in NEWS. Might it be the following change? 2009-08-27 Stefan Monnier <monnier at iro.umontreal.ca> * lread.c (read_integer): Use doubles (and potentially return a float number) as we do in string-to-number. (read1): Use strtol to read integers, signal errors on strtol's overflow and use floats if strtol's output is too large for Elisp integers. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: integer overflow 2010-03-05 19:50 ` integer overflow [was Re: Next pretest, and branching plans] Glenn Morris @ 2010-03-05 22:35 ` Stefan Monnier 2010-03-06 2:55 ` Glenn Morris 2010-03-06 20:35 ` Chong Yidong 0 siblings, 2 replies; 149+ messages in thread From: Stefan Monnier @ 2010-03-05 22:35 UTC (permalink / raw To: Glenn Morris; +Cc: emacs-devel >> In 2.3.1 Integer Type: >>> 1073741825 ; Also the integer 1 on a 30-bit implementation. >> In 3.1 Integer Basics: >>> 1073741825 ; Also the integer 1, due to overflow. >> When in fact (type-of 1073741825) => float! >> Is this even documented? > A good question. I can't see anything about this in NEWS. > Might it be the following change? > 2009-08-27 Stefan Monnier <monnier at iro.umontreal.ca> > * lread.c (read_integer): Use doubles (and potentially > return a float number) as we do in string-to-number. > (read1): Use strtol to read integers, signal errors on > strtol's overflow and use floats if strtol's output is too large for > Elisp integers. Indeed, I thought about it as a pure bug-fix, but it needs to be added to the NEWS. Can you do that and update the doc accordingly? Stefan ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: integer overflow 2010-03-05 22:35 ` integer overflow Stefan Monnier @ 2010-03-06 2:55 ` Glenn Morris 2010-03-06 3:11 ` Chong Yidong 2010-03-06 20:35 ` Chong Yidong 1 sibling, 1 reply; 149+ messages in thread From: Glenn Morris @ 2010-03-06 2:55 UTC (permalink / raw To: Stefan Monnier; +Cc: emacs-devel Stefan Monnier wrote: > Indeed, I thought about it as a pure bug-fix, but it needs to be added > to the NEWS. Can you do that and update the doc accordingly? I don't really understand it. In a 32-bit Emacs: (1+ 536870911) -536870912 (+ 2 536870911) -536870911 (1+ 536870912) 536870913.0 (1+ 4294967295) overflow (1+ 4294967295.0) 4294967296.0 Can you summarize how it's supposed to work? ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: integer overflow 2010-03-06 2:55 ` Glenn Morris @ 2010-03-06 3:11 ` Chong Yidong 2010-03-06 7:03 ` Helmut Eller 2010-03-07 19:05 ` Johan Bockgård 0 siblings, 2 replies; 149+ messages in thread From: Chong Yidong @ 2010-03-06 3:11 UTC (permalink / raw To: Glenn Morris; +Cc: Stefan Monnier, emacs-devel Glenn Morris <rgm@gnu.org> writes: > I don't really understand it. In a 32-bit Emacs: > > (1+ 536870911) -536870912 > (+ 2 536870911) -536870911 > (1+ 536870912) 536870913.0 > (1+ 4294967295) overflow > (1+ 4294967295.0) 4294967296.0 > > Can you summarize how it's supposed to work? The change affects the Lisp reader: reading "536870912" or any larger number now gives you a float Lisp object, instead of an integer Lisp object (since there is no way to represent 536870912 or larger as integers). 536870911 and below are still read as integers. The change does not prevent the possibility of overflowing integers, as your example shows. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: integer overflow 2010-03-06 3:11 ` Chong Yidong @ 2010-03-06 7:03 ` Helmut Eller 2010-03-06 15:45 ` Stefan Monnier 2010-03-07 19:05 ` Johan Bockgård 1 sibling, 1 reply; 149+ messages in thread From: Helmut Eller @ 2010-03-06 7:03 UTC (permalink / raw To: emacs-devel * Chong Yidong [2010-03-06 04:11+0100] writes: >> Can you summarize how it's supposed to work? > > The change affects the Lisp reader: reading "536870912" or any larger > number now gives you a float Lisp object, instead of an integer Lisp > object (since there is no way to represent 536870912 or larger as > integers). 536870911 and below are still read as integers. What's the point of doing that? I would much prefer if read would just raise and error. Helmut ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: integer overflow 2010-03-06 7:03 ` Helmut Eller @ 2010-03-06 15:45 ` Stefan Monnier 2010-03-06 16:23 ` Davis Herring ` (3 more replies) 0 siblings, 4 replies; 149+ messages in thread From: Stefan Monnier @ 2010-03-06 15:45 UTC (permalink / raw To: Helmut Eller; +Cc: emacs-devel >>> Can you summarize how it's supposed to work? >> The change affects the Lisp reader: reading "536870912" or any larger >> number now gives you a float Lisp object, instead of an integer Lisp >> object (since there is no way to represent 536870912 or larger as >> integers). 536870911 and below are still read as integers. > What's the point of doing that? I would much prefer if read would just > raise an error. There are many cases where it's important to read an integer from some other program, so it's important to be able to read integers larger the Elisp's largest fixnum (tho less so for integers larger than the host system's natural "int"). Examples are file sizes, process ids, user ids, ... Stefan ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: integer overflow 2010-03-06 15:45 ` Stefan Monnier @ 2010-03-06 16:23 ` Davis Herring 2010-03-06 16:33 ` Drew Adams ` (2 subsequent siblings) 3 siblings, 0 replies; 149+ messages in thread From: Davis Herring @ 2010-03-06 16:23 UTC (permalink / raw To: Stefan Monnier; +Cc: Helmut Eller, emacs-devel >> What's the point of doing that? I would much prefer if read would just >> raise an error. > > There are many cases where it's important to read an integer from some > other program, so it's important to be able to read integers larger the > Elisp's largest fixnum (tho less so for integers larger than the > host system's natural "int"). > Examples are file sizes, process ids, user ids, ... It seems to me that such cases are relevant to `string-to-*' more than to `read'. There is value in having them be consistent in their shared domain, but there is also value in having the syntax of elisp not involve magic thresholds where the type of a literal changes. Davis -- This product is sold by volume, not by mass. If it appears too dense or too sparse, it is because mass-energy conversion has occurred during shipping. ^ permalink raw reply [flat|nested] 149+ messages in thread
* RE: integer overflow 2010-03-06 15:45 ` Stefan Monnier 2010-03-06 16:23 ` Davis Herring @ 2010-03-06 16:33 ` Drew Adams 2010-03-07 7:52 ` Richard Stallman 2010-03-06 19:04 ` integer overflow Helmut Eller 2010-03-07 7:51 ` Richard Stallman 3 siblings, 1 reply; 149+ messages in thread From: Drew Adams @ 2010-03-06 16:33 UTC (permalink / raw To: 'Stefan Monnier', 'Helmut Eller'; +Cc: emacs-devel > There are many cases where it's important to read an integer > from some other program, so it's important to be able to read > integers larger the Elisp's largest fixnum (tho less so for > integers larger than the host system's natural "int"). > Examples are file sizes, process ids, user ids, ... Lisp (MacLisp) invented bignums 40+ years ago. Maybe it's time... http://en.wikipedia.org/wiki/Bignum ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: integer overflow 2010-03-06 16:33 ` Drew Adams @ 2010-03-07 7:52 ` Richard Stallman 2010-03-07 16:06 ` David Kastrup 0 siblings, 1 reply; 149+ messages in thread From: Richard Stallman @ 2010-03-07 7:52 UTC (permalink / raw To: Drew Adams; +Cc: eller.helmut, monnier, emacs-devel I have heard that Guile now supports Emacs Lisp. And it has bignums. So if we make Emacs use Guile, that will automatically provide bignums. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: integer overflow 2010-03-07 7:52 ` Richard Stallman @ 2010-03-07 16:06 ` David Kastrup 2010-03-07 17:18 ` Stephen J. Turnbull 2010-03-08 8:04 ` Richard Stallman 0 siblings, 2 replies; 149+ messages in thread From: David Kastrup @ 2010-03-07 16:06 UTC (permalink / raw To: emacs-devel Richard Stallman <rms@gnu.org> writes: > I have heard that Guile now supports Emacs Lisp. And it has bignums. > So if we make Emacs use Guile, that will automatically provide > bignums. My first reaction to that would be "Whoa, whoa, whoa!". The second that "librep" might be an easier starting point for migrating the Lisp engine. After all, it was designed to be like Emacs Lisp. From glancing over the wording of the manual, it appears to be a one-man project. Given his motivation of imitating Emacs Lisp, it is conceivable that he would not be averse to copyright assignment. Anyway: supplanting Elisp is not exactly a small-hearted task. Even making the lexbind branch the default would be quite some change (being able to write lexical closured would be nice, though). -- David Kastrup ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: integer overflow 2010-03-07 16:06 ` David Kastrup @ 2010-03-07 17:18 ` Stephen J. Turnbull 2010-03-07 17:42 ` David Kastrup 2010-03-08 8:04 ` Richard Stallman 1 sibling, 1 reply; 149+ messages in thread From: Stephen J. Turnbull @ 2010-03-07 17:18 UTC (permalink / raw To: David Kastrup; +Cc: emacs-devel David Kastrup writes: > Richard Stallman <rms@gnu.org> writes: > > > I have heard that Guile now supports Emacs Lisp. And it has bignums. > > So if we make Emacs use Guile, that will automatically provide > > bignums. > > My first reaction to that would be "Whoa, whoa, whoa!". > > The second that "librep" might be an easier starting point for migrating > the Lisp engine. For bignums, XEmacs or SXEmacs might be easier yet. The work of integrating bignums (GNU MP and BSD MP are both supported as compile-time options) was done by Jerry James. He is probably *not* available any time soon (his day job just turned into a day-and-night job) but the pedigree of the code is easily established and he and other contributors probably would be willing to sign papers. I believe SXEmacs supports quaternions and Gaussian integers, and perhaps even more exotic number systems. :-) However, I have no idea whether the SXEmacs folks would be willing to assign their contributions. However, this is all kind of irrelevant. Using bignums as pure numbers is relatively easy. The hard part is introducing them as numerical components of internal Emacs structures (buffer size and positions, markers, overlays, text properties), and integrating them with niceties like (system-dependent) large file support, etc. This is in no way an automatic consequence of language support for bignums. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: integer overflow 2010-03-07 17:18 ` Stephen J. Turnbull @ 2010-03-07 17:42 ` David Kastrup 2010-03-08 4:49 ` Jay Belanger 0 siblings, 1 reply; 149+ messages in thread From: David Kastrup @ 2010-03-07 17:42 UTC (permalink / raw To: emacs-devel "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp> writes: > David Kastrup writes: > > Richard Stallman <rms@gnu.org> writes: > > > > > I have heard that Guile now supports Emacs Lisp. And it has bignums. > > > So if we make Emacs use Guile, that will automatically provide > > > bignums. > > > > My first reaction to that would be "Whoa, whoa, whoa!". > > > > The second that "librep" might be an easier starting point for migrating > > the Lisp engine. > > For bignums, XEmacs or SXEmacs might be easier yet. But the "Whoa" factor is lost. > The work of integrating bignums (GNU MP and BSD MP are both supported > as compile-time options) was done by Jerry James. He is probably > *not* available any time soon (his day job just turned into a > day-and-night job) but the pedigree of the code is easily established > and he and other contributors probably would be willing to sign > papers. [...] > However, this is all kind of irrelevant. Using bignums as pure > numbers is relatively easy. The hard part is introducing them as > numerical components of internal Emacs structures (buffer size and > positions, markers, overlays, text properties), and integrating them > with niceties like (system-dependent) large file support, etc. This > is in no way an automatic consequence of language support for bignums. IIRC, this has not been done in the bignum integration of XEmacs and its ilk. So there is not much code worth the taking. Transparent bignums should indeed be easy to do: just check the overflow of integer arithmetic operations and behave accordingly. Arithmetic now catering for float and integer would have to cater for bignums as well. Anyway, I guess that Richard's point more or less was that Emacs' Lisp engine was worth substituting, and that such a radical move might solve unrelated problems as well. bignum support alone indeed should be reasonably straightforward. It should certainly speed up Emacs calc once Emacs calc is cleaned up to use it. -- David Kastrup ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: integer overflow 2010-03-07 17:42 ` David Kastrup @ 2010-03-08 4:49 ` Jay Belanger 0 siblings, 0 replies; 149+ messages in thread From: Jay Belanger @ 2010-03-08 4:49 UTC (permalink / raw To: emacs-devel; +Cc: jay.p.belanger David Kastrup <dak@gnu.org> writes: ... > bignum support alone indeed should be reasonably straightforward. It > should certainly speed up Emacs calc once Emacs calc is cleaned up to > use it. Yes, and if Emacs gets bignum support it shouldn't take long for Calc to use it. (Oddly enough, while he might have written Calc anyhow, being able to work with big integers was one of Dave Gillespie's motivations to write Calc.) Jay ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: integer overflow 2010-03-07 16:06 ` David Kastrup 2010-03-07 17:18 ` Stephen J. Turnbull @ 2010-03-08 8:04 ` Richard Stallman 2010-03-08 14:41 ` Guile in Emacs (was: integer overflow) Ted Zlatanov 1 sibling, 1 reply; 149+ messages in thread From: Richard Stallman @ 2010-03-08 8:04 UTC (permalink / raw To: David Kastrup; +Cc: emacs-devel The second that "librep" might be an easier starting point for migrating the Lisp engine. After all, it was designed to be like Emacs Lisp. If it only supports something like Emacs Lisp then it is not much of an advance. Guile supports Scheme and Javascript as well as Emacs Lisp. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Guile in Emacs (was: integer overflow) 2010-03-08 8:04 ` Richard Stallman @ 2010-03-08 14:41 ` Ted Zlatanov 2010-03-08 17:32 ` Guile in Emacs Ted Zlatanov ` (2 more replies) 0 siblings, 3 replies; 149+ messages in thread From: Ted Zlatanov @ 2010-03-08 14:41 UTC (permalink / raw To: emacs-devel On Mon, 08 Mar 2010 03:04:40 -0500 Richard Stallman <rms@gnu.org> wrote: RS> The second that "librep" might be an easier starting point for migrating RS> the Lisp engine. After all, it was designed to be like Emacs Lisp. RS> If it only supports something like Emacs Lisp then it is not much of RS> an advance. Guile supports Scheme and Javascript as well as Emacs Lisp. It also supports multithreading, which IMHO is a big deal as well, perhaps more important than bignums. Thread subject changed in the hopes that the topic change won't be lost. Ted ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-03-08 14:41 ` Guile in Emacs (was: integer overflow) Ted Zlatanov @ 2010-03-08 17:32 ` Ted Zlatanov 2010-03-08 18:42 ` Guile in Emacs (was: integer overflow) Chad Brown 2010-03-09 3:19 ` Guile in Emacs (was: integer overflow) Richard Stallman 2 siblings, 0 replies; 149+ messages in thread From: Ted Zlatanov @ 2010-03-08 17:32 UTC (permalink / raw To: emacs-devel On Mon, 08 Mar 2010 08:41:53 -0600 Ted Zlatanov <tzz@lifelogs.com> wrote: TZ> On Mon, 08 Mar 2010 03:04:40 -0500 Richard Stallman <rms@gnu.org> wrote: RS> The second that "librep" might be an easier starting point for migrating RS> the Lisp engine. After all, it was designed to be like Emacs Lisp. RS> If it only supports something like Emacs Lisp then it is not much of RS> an advance. Guile supports Scheme and Javascript as well as Emacs Lisp. TZ> It also supports multithreading, which IMHO is a big deal as well, TZ> perhaps more important than bignums. By "it" I meant Guile, not librep. librep does not (based on the manual) support multithreading. Ted ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs (was: integer overflow) 2010-03-08 14:41 ` Guile in Emacs (was: integer overflow) Ted Zlatanov 2010-03-08 17:32 ` Guile in Emacs Ted Zlatanov @ 2010-03-08 18:42 ` Chad Brown 2010-03-09 7:07 ` Ken Raeburn 2010-03-09 3:19 ` Guile in Emacs (was: integer overflow) Richard Stallman 2 siblings, 1 reply; 149+ messages in thread From: Chad Brown @ 2010-03-08 18:42 UTC (permalink / raw To: Ted Zlatanov, emacs-devel Ken Raeburn has done some work on Guile in Emacs, which might be helpful. There's a (not super-current) status page here: http://www.mit.edu/~raeburn/guilemacs/ Summary: there is something runable, but it's certainly not finished. There are some design questions that I think it's safe to say are still in an `exploratory' phase. Ken has given some thought to threading (not a surprise if you know Ken), but as of the middle of last year (the date on the status update), I would characterize his progress as `thoughts and questions'. Hope this helps, *Chad ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs (was: integer overflow) 2010-03-08 18:42 ` Guile in Emacs (was: integer overflow) Chad Brown @ 2010-03-09 7:07 ` Ken Raeburn 2010-03-09 16:22 ` Guile in Emacs Ted Zlatanov 0 siblings, 1 reply; 149+ messages in thread From: Ken Raeburn @ 2010-03-09 7:07 UTC (permalink / raw To: emacs-devel@gnu.org discussions On Mar 8, 2010, at 13:42, Chad Brown wrote: > Ken Raeburn has done some work on Guile in Emacs, which might be helpful. There's a (not super-current) status page here: > > http://www.mit.edu/~raeburn/guilemacs/ Yeah, I haven't updated that in a while... > Summary: there is something runable, but it's certainly not finished. There are some design questions that I think it's safe to say are still in an `exploratory' phase. Yes, though I think many of the open questions can be put off until what I might call "phase 2" ... where "phase 1" just deals with basic object representations, allocation and GC, and keeps the current single-threaded Lisp engine. I want that to be on solid footing before pushing other stuff forward too much, if only so there's something to show off. :-) So after "phase 1", I think it would be time to assess how well things work. Is work in certain areas of Guile needed? (If so, go hack on Guile a while and come back later.) Does it do some things better than stock Emacs? Is it time to discuss whether it would be suitable for integration into Emacs 24/25/26/whatever? What else needs to happen first? > Ken has given some thought to threading (not a surprise if you know Ken), but as of the middle of last year (the date on the status update), I would characterize his progress as `thoughts and questions'. Yeah, threads bring up lots of interesting issues, and there's enough stuff going on in this Guile project even without having to settle those issues right away. (Even though my original impetus was wanting to do work in Emacs while Gnus was crunching away on newsgroup data in the same process!) Other people are already working on related projects (Tom Tromey's work on the Emacs side, and Daniel Kraft and others working on a Lisp reader for Guile) where some of the issues may get hashed out. Though, I ought to be paying more attention to them.... I haven't made a lot of direct progress on the project since then. Some amount of my effort has gone into indirectly-helpful sub-projects, like making upstream Emacs work better without doing the unexec step, so that I don't have to make Guile and everything it might link against unexec-friendly, deal with shared libraries in unexec, make static versions of Guile and N other libraries, etc. (Obviously we don't want Emacs to take forever to start up for end users, but if we don't get another solution for that from the Guile side, we can work on the unexec bits later, and sidestepping that problem for now lets me focus on other things.) Another one that's appeared on the radar is digging up Dave Love's old work on making Emacs work with Boehm's GC library, which Guile uses, and Emacs-with-Guile would wind up using as a result, but I haven't even started with that one; currently I think I've just had Emacs leak memory since Guile switched to libgc. (And then there's the new job, which is sucking up a lot of my time now. Most of the work seems to get done in bursts every several years, when I'm between jobs; then I get a job, or there's some VCS breakage, and the work stops for a while.... I'm hoping to put more time in on it soon, especially since Andy Wingo surprised me with a proposed timeline for finishing this work in his Guile presentation at GHM '09, and I'd like to meet it, but not by going jobless again. :-) Ken ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-03-09 7:07 ` Ken Raeburn @ 2010-03-09 16:22 ` Ted Zlatanov 2010-03-10 8:07 ` Ken Raeburn 0 siblings, 1 reply; 149+ messages in thread From: Ted Zlatanov @ 2010-03-09 16:22 UTC (permalink / raw To: emacs-devel On Tue, 9 Mar 2010 02:07:11 -0500 Ken Raeburn <raeburn@raeburn.org> wrote: KR> On Mar 8, 2010, at 13:42, Chad Brown wrote: >> Ken has given some thought to threading (not a surprise if you know >> Ken), but as of the middle of last year (the date on the status >> update), I would characterize his progress as `thoughts and >> questions'. KR> Yeah, threads bring up lots of interesting issues, and there's KR> enough stuff going on in this Guile project even without having to KR> settle those issues right away. (Even though my original impetus KR> was wanting to do work in Emacs while Gnus was crunching away on KR> newsgroup data in the same process!) Other people are already KR> working on related projects (Tom Tromey's work on the Emacs side, KR> and Daniel Kraft and others working on a Lisp reader for Guile) KR> where some of the issues may get hashed out. Though, I ought to be KR> paying more attention to them.... Make sure you check out the emacs-mt work too at http://gitorious.org/emacs-mt as that's (AFAIK) the closest to getting into Emacs. Giuseppe Scrivano has done great work. Have you considered continuations support? I didn't see mention of them in the docs. Ted ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-03-09 16:22 ` Guile in Emacs Ted Zlatanov @ 2010-03-10 8:07 ` Ken Raeburn 2010-03-10 13:58 ` David Kastrup 0 siblings, 1 reply; 149+ messages in thread From: Ken Raeburn @ 2010-03-10 8:07 UTC (permalink / raw To: emacs-devel@gnu.org discussions On Mar 9, 2010, at 11:22, Ted Zlatanov wrote: > Make sure you check out the emacs-mt work too at > http://gitorious.org/emacs-mt as that's (AFAIK) the closest to getting > into Emacs. Giuseppe Scrivano has done great work. Ah, yes, I thought I might be forgetting someone. (Sorry!) So many to keep track of... that's a *good* thing! :-) > Have you considered continuations support? I didn't see mention of them > in the docs. Not even remotely, no. :-) I'm not particularly familiar with continuations in Scheme, let alone how you'd map that into elisp, or if the Lisp world has a similar construct.... Ken ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-03-10 8:07 ` Ken Raeburn @ 2010-03-10 13:58 ` David Kastrup 0 siblings, 0 replies; 149+ messages in thread From: David Kastrup @ 2010-03-10 13:58 UTC (permalink / raw To: emacs-devel Ken Raeburn <raeburn@raeburn.org> writes: > On Mar 9, 2010, at 11:22, Ted Zlatanov wrote: >> Make sure you check out the emacs-mt work too at >> http://gitorious.org/emacs-mt as that's (AFAIK) the closest to getting >> into Emacs. Giuseppe Scrivano has done great work. > > Ah, yes, I thought I might be forgetting someone. (Sorry!) > So many to keep track of... that's a *good* thing! :-) > >> Have you considered continuations support? I didn't see mention of them >> in the docs. > > Not even remotely, no. :-) I'm not particularly familiar with > continuations in Scheme, let alone how you'd map that into elisp, or > if the Lisp world has a similar construct.... Basically the idea (Chicken even implements it like that) is that you never clean up your return stack, but treat it like a garbage-collected heap. Procedures are called implicitly with a pointer to the return stack. When a procedure returns, it basically "calls" this pointer. Now call/cc does the same, but passes this pointer also _explicitly_ to the procedure in question, which may store it someplace. If at some later point of time somebody calls this from wherever it may have been stored, Scheme in effect returns "again" (if it did previously return) or for the first time, abandoning the control flow it happened to be in at that time (unless you stored its continuation somewhere else, of course). -- David Kastrup ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs (was: integer overflow) 2010-03-08 14:41 ` Guile in Emacs (was: integer overflow) Ted Zlatanov 2010-03-08 17:32 ` Guile in Emacs Ted Zlatanov 2010-03-08 18:42 ` Guile in Emacs (was: integer overflow) Chad Brown @ 2010-03-09 3:19 ` Richard Stallman 2010-04-11 23:33 ` Thomas Lord 2 siblings, 1 reply; 149+ messages in thread From: Richard Stallman @ 2010-03-09 3:19 UTC (permalink / raw To: Ted Zlatanov; +Cc: emacs-devel RS> If it only supports something like Emacs Lisp then it is not much of RS> an advance. Guile supports Scheme and Javascript as well as Emacs Lisp. It also supports multithreading, which IMHO is a big deal as well, perhaps more important than bignums. I think the support for multiple languages is the biggest advance. I hope support for other popular extension languages will be implemented eventually -- that was the original goal of Guile. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs (was: integer overflow) 2010-03-09 3:19 ` Guile in Emacs (was: integer overflow) Richard Stallman @ 2010-04-11 23:33 ` Thomas Lord 2010-04-12 12:30 ` Richard Stallman 0 siblings, 1 reply; 149+ messages in thread From: Thomas Lord @ 2010-04-11 23:33 UTC (permalink / raw To: rms; +Cc: Ted Zlatanov, emacs-devel I'd like to correct some accounts of history. On Mon, 2010-03-08 at 22:19 -0500, Richard Stallman wrote: > RS> If it only supports something like Emacs Lisp then it is not much of > RS> an advance. Guile supports Scheme and Javascript as well as Emacs Lisp. > > It also supports multithreading, which IMHO is a big deal as well, > perhaps more important than bignums. > > I think the support for multiple languages is the biggest advance. > I hope support for other popular extension languages will be > implemented > eventually -- that was the original goal of Guile. Your recollection there seems to me to be mistaken. It was a long time ago but I distinctly remember things differently. As I recall: The original GNU Manifesto described a unix-like foundation with a heavy emphasis on a Lisp-centric user-space. In the early 1990s, when I worked at the FSF, several of the hackers there (including me) understood the GNU vision to imply that many interactive programs - not just Emacs - would be extensible in a dialect of Lisp. We mostly shared the opinion that Scheme was an appropriate dialect. Before I got to the FSF people had already started on a GNU Extension Language Library - an embeddable Scheme interpreter. As the (bad) "joke" goes: they code-named the project "revoc" but upon reflection that's just a "cover". (Get it? Spooky, ain't it?) Revoc was (at least back then) going nowhere fast. Later, while working on a spreadsheet program, I attempted to start a new attempt at a scheme-based extension language library. You were (rightly, I suppose) upset that there were higher priorities. You also pointed out that I was probably wasting time by starting from scratch and that I ought to have started from some existing Scheme implementation. I don't recall if you specifically suggested SCM but I think you might have. So there were two attempts at a Scheme-based GNU extension library down - and one to go. A year or two later I went to work for Cygnus and we, there, initially agreed to invest in making a scheme-based extension language library for GNU programs. This was originally named "GEL" (for GNU Extension Language) until the company lawyers warned that "GEL" was a trademark for another program. It was renamed Guile (a cognitive relative of "scheme" and a pun for "Guy L."). You were informed of this work and were encouraging. I forget at which stage of this process you declared Guile to be a "GNU project" but I'm sure the extant public record has it somewhere. Around that time, Sun was beginning to announce and promote Java. They also hired John Ousterhout and began declaring "Tcl is to be the scripting language for the Internet!" Back then, Sun was a particularly influential company. On a technical level, Tcl was a horribly regressive language - a giant step backwards in many subtle but important ways. Its license was a free software license but it was uncomforable at the time to have Sun pushing it so heavily because of the technical problems and because of doubts about Sun's motives and control over the software. A faction arose within Cygnus that argued that Cygnus should divest from the Guile project and adopt Tcl instead. I made you aware of that and of Sun's swagger, regarding Tcl. Around the same time, two of Prof. Ousterhout's graduate students, John Blow and Adam Sah, were proposing that the TCL language be *altered* in some small but significant ways that would facilitate its translation into reasonable efficient Scheme code. Their altered version of Tcl was largely but not completely upward compatible with standard Tcl. By applying a Scheme->C compiler to the generated Scheme code, they were able to benchmark far better than standard Tcl in many cases. And around that same time I was independently proposing similar things. Mssrs. Blow, Sah, and I compared notes and so forth. Around that time, also, Python was beginning to gain recognition in the US (it already had a foothold in Europe). Blow, Sah, and I had dinner with Von Rossum and tried to persuade him to add LAMBDA and proper tail calls and perhaps continuations to the language so that it could be usefully translated to Scheme. He did not agree. Back at Cygnus, the oppositional factions had fun lampooning lisp syntax and pointing to examples like Python of what was better. Some of my notes to you mysteriously transmogrified into a USENET post which the archives show as having you in the "From:" line and with my signature at the bottom of the message. This sparked what people, to this day, still call "The TCL war". So: The "original goal" of Guile was most definitely *not* to support multiple languages. Rather, that was a goal that was established as a tactic in response to early competition with Guile. Moreover, it was *never*, in the early days, a goal that Guile support other popular extension languages. That was something that you added and that I (regrettably) agreed to in response to the perceived threat of Tcl and to a lesser extent Python. And: it was *never* in those years a goal to support any of those other languages exactly. It was *always* a goal to have a Tcl-like syntax, a Python-like syntax, and a C-like syntax for Guile Scheme. But tight compatibility with those languages was *not* the goal. The notion wasn't so much to "support Tcl" (or any other language) as to have a hyper-flexible syntax and to support, via libraries, environments with all of the convenience features of a shell-like language like Tcl. Early on after we adopted that tactic you and I and a few others had some lengthy discussions about adding Emacs Lisp to the list of languages that Guile could run. We ran into some severe issues such as the difference between 'NIL in Emacs lisp and '() and Scheme. Perhaps not to you but to several other of us it became fairly clear, back then, that a strictly compatible Emacs lisp would never sit comfortably alongside a proper Scheme environment. Just as we would need to make a "Tcl-like" language that would break some Tcl code, we would need to break some Emacs lisp code, if indeed we ultimately wanted to bother trying to support any. (That is part of why, at Cygnus, I built a from-scratch multi-buffer, self-documenting, extensible text editor in Scheme with multi-font and proportionally-spaced font capabilities that, at the time, GNU Emacs wasn't close to achieving. The notion was to see how far I could get just leapfrogging over GNU Emacs instead of trying to retrofit it.) Now, years have passed. In recent years, I gather, the implementation of Guile has been fairly radically altered so that it is now more of a bytecode VM with primitive LISP-ish types. In some sense, it has begun to drift away from being primarily a Scheme to being more in the category of JVM or the Mono VM. It is easier to target multiple languages to such a VM but no less easy to make them interoperate cleanly in a way one would want to live with for the long run. So Guile's goals have shifted. It was once (originally) to be a tight, clean, fun Scheme environment with some alternative syntaxes and specialized environments -- and only later did it become the kind of heterogenous language environment we see it moving towards today. So, again: > I hope support for other popular extension languages will be > implemented eventually -- that was the original goal of Guile. Nah. The heck it was. That's just not true. Now, there is a separate question: is that goal to support other popular extension languages a better idea or a worse idea (or not importantly different) than the original goal of a nice, tight, fun Scheme-based system? I have my opinion ("far worse!") but it's not my intent to argue for that opinion here. Just to set history straight. That multi-lingual stuff was *not* the original goal of Guile. On the contrary, the multi-lingual goals only came up at all because of a perceived crisis sparked by Sun's announcement that Tcl was to become the ubiquitous scripting language of the Internet. -t ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs (was: integer overflow) 2010-04-11 23:33 ` Thomas Lord @ 2010-04-12 12:30 ` Richard Stallman 2010-04-12 20:05 ` Thomas Lord 0 siblings, 1 reply; 149+ messages in thread From: Richard Stallman @ 2010-04-12 12:30 UTC (permalink / raw To: Thomas Lord; +Cc: tzz, emacs-devel When I read about Sun's plan to make TCL the universal scripting language, I decided to oppose that. The plan I chose was to implement Scheme and support other scripting languages by translation into Scheme. Guile is the program I chose to adopt to do this with. That plan is what I am talking about. Whatever history that code had before its adoption for this plan is not what I am talking about. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs (was: integer overflow) 2010-04-12 12:30 ` Richard Stallman @ 2010-04-12 20:05 ` Thomas Lord 2010-04-13 12:44 ` Guile in Emacs Bruce Stephens 0 siblings, 1 reply; 149+ messages in thread From: Thomas Lord @ 2010-04-12 20:05 UTC (permalink / raw To: rms; +Cc: tzz, emacs-devel On Mon, 2010-04-12 at 08:30 -0400, Richard Stallman wrote: > When I read about Sun's plan to make TCL the universal scripting > language, I decided to oppose that. The plan I chose was to implement > Scheme and support other scripting languages by translation into Scheme. > Guile is the program I chose to adopt to do this with. That plan > is what I am talking about. > > Whatever history that code had before its adoption for this plan > is not what I am talking about. Sure. In one sense it was just your use of the word "original" as in "original goal" that I was objecting too. Yet, there is another aspect of this which I think is relevant to "Guile in Emacs" and to your notion of supporting other scripting languages -- otherwise I wouldn't harp on it: In those early days of Guile, after your decision, those of us closer to the project discussed at considerable length how exactly to support Tcl, Emacs lisp, and other languages. Not just how to be able to run programs in those languages but how to integrate them into a cohesive environment. In each and every case we discovered devils in the details and realized "Well, we can't." We could make a TCL-like language that could run many simple TCL programs but that would not be upward compatible - and have that TCL-like language nicely integrated with the larger environment. We could make an Emacs Lisp style of environment that could run some Emacs Lisp code directly but that would not be upwards compatible - and have that alternative Emacs Lisp nicely integrated with the larger environment. But we absolutely could not, for fundamental reasons, directly support Tcl and Emacs Lisp with fidelity and wind up with a sane programming environment. We realized that pretty quickly and tried (but failed) to convey to you this notion that we could not promise to seamlessly integrate those other languages - but that we could offer a reasonable compromise. It was always an oversimplifying exaggeration to say that Guile would support all of those other languages in any strong sense of the word "support". We could offer alternative syntaxes. We could offer environments with simplified evaluation models and more flexible types. We could give people the *feel* of Tcl or Python or Emacs Lisp but there was no point in trying to faithfully reimplement those languages in detail. We failed miserably at communicating that distinction, apparently. There was some momentary political convenience, back then, around the burning question of which scripting language would "win" and take over the world. Would Tcl become the ubiquitous scripting language? Python? It was an easy story to tell that Guile somehow transcended the question for it could be both Tcl *and* Python (*and* Scheme) depending solely on user preference. But it was clear at the technical level that really Guile could only be Scheme, pure and simple, although perhaps offering a Tcl-*like* environment and a Python-*like* environment. We - meaning you, me, and several others - were sloppy back then about making that distinction clear. If anything remains of the shared *technical* vision of a complete GNU system that is lisp-centric with many extensible, self-documenting programs -- and if sentiment remains that Scheme is a fine choice for extension language -- then I mainly hope that people pursuing that vision today won't go down the same rat-hole that caught us up back then. "I, alone, survive to tell the tale...". If you want a half-decent Scheme as your core extension language then *make that work first* and don't worry so much about compatibility with legacy code in those other languages. There are no good answers about how to cleanly integrate Emacs Lisp and other languages with Scheme at that level. People have thought about for, what, something over 15 years now and the ones thinking about it today are getting stuck going over the very same questions people got stuck on 15 years ago. Meanwhile, with all the (often interesting and skilled - admirable) work that has gone down that rat-hole in those years, a thoroughly Scheme-based but not upwards compatible Emacs could have been casually produced by, say, 10 or 12 years ago. Coulda' Shoulda' Woulda' but Didn't, as the saying goes. I just hope that the next 10 years of GNU generally and Emacs specifically isn't going to be tied down to the historic baggage of the "Tcl Wars" and the misunderstandings it provoked. Someone -- that is to say "someone" -- should just rip Emacs Lisp out of the C part of GNU Emacs, bind the best parts of that stuff to Guile, and start *there*. It's not a small job but it's also not a "more than a decade" job. It could have been started much more than a decade ago. It'd be, in my view, a giant leap back towards the vision of a GNU system that was shared among several key GNU hackers back in the early 1990s and earlier. And it'd be, in my view, technically sane in comparison to some more popular alternatives like trying to support Emacs Lisp in detail. I'm done. I've said my piece. -t ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-12 20:05 ` Thomas Lord @ 2010-04-13 12:44 ` Bruce Stephens 2010-04-13 15:51 ` Thomas Lord 0 siblings, 1 reply; 149+ messages in thread From: Bruce Stephens @ 2010-04-13 12:44 UTC (permalink / raw To: emacs-devel Thomas Lord <lord@emf.net> writes: [...] > Someone -- that is to say "someone" -- should just rip Emacs Lisp out > of the C part of GNU Emacs, bind the best parts of that stuff to > Guile, and start *there*. It's not a small job but it's also not a > "more than a decade" job. It could have been started much more than a > decade ago. It'd be, in my view, a giant leap back towards the vision > of a GNU system that was shared among several key GNU hackers back in > the early 1990s and earlier. I wonder. Looking at the list of Guile applications doesn't give me the impression of a guile-using GNU ecosystem just waiting for Emacs to join. Wouldn't it be about as good (and probably less work), to give up on the guile idea and evolve emacs lisp (with Miles's lexical-bind changes, and (one hopes) multithreading, and maybe other things)? [...] ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-13 12:44 ` Guile in Emacs Bruce Stephens @ 2010-04-13 15:51 ` Thomas Lord 2010-04-13 16:07 ` Stefan Monnier 2010-04-13 19:13 ` Christian Lynbech 0 siblings, 2 replies; 149+ messages in thread From: Thomas Lord @ 2010-04-13 15:51 UTC (permalink / raw To: Bruce Stephens; +Cc: emacs-devel We risk drifting into the topic of "general strategies for GNU" and away from "what could / should(?) Emacs do" so let's not make a long discussion of it but: On Tue, 2010-04-13 at 13:44 +0100, Bruce Stephens wrote: > I wonder. Looking at the list of Guile applications doesn't give me the > impression of a guile-using GNU ecosystem just waiting for Emacs to > join. Sure. The optimist's version of that observation is that, hey, it's a blank slate: pure opportunity, no legacy "baggage". The sky's the limit. > Wouldn't it be about as good (and probably less work), to give up on the > guile idea and evolve emacs lisp (with Miles's lexical-bind changes, and > (one hopes) multithreading, and maybe other things)? I dunno. Maybe. I'd guess that, no, that's not a good strategy. Four reasons come quickly to mind: 1) There are many more materials out there that teach Scheme than teach a novel spin-off of Emacs Lisp. 2) There are many and will continue to be many implementations of Scheme. Some of these implementations are the product of pretty intense R&D. No, they aren't all 100% compatible with one another - far from it - but it is easier to start with any one of those and make it more like the others than to, say, build better and alternative implementations of Emacs Lisp. 3) Scheme has features that we know make it a pretty good "multi-paradigm" language. Features like Scheme's macro systems, proper safe-for-space tail recursion, etc. are pretty good to have. It would be easier to just use those existing features than to try to retrofit them into Emacs Lisp. 4) Using Scheme, you can can leverage third party Scheme code. There isn't a huge amount worth using but there is a decent amount. There are the SRFIs. There is SCSH (the Scheme shell). For a long-term investment, I'd put my money on Scheme rather than an ad hoc offspring of Emacs Lisp. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-13 15:51 ` Thomas Lord @ 2010-04-13 16:07 ` Stefan Monnier 2010-04-13 18:56 ` Thomas Lord ` (2 more replies) 2010-04-13 19:13 ` Christian Lynbech 1 sibling, 3 replies; 149+ messages in thread From: Stefan Monnier @ 2010-04-13 16:07 UTC (permalink / raw To: Thomas Lord; +Cc: Bruce Stephens, emacs-devel > I dunno. Maybe. I'd guess that, no, that's not a > good strategy. Four reasons come quickly to mind: I agree with your conclusion but for a very different reason. In my opinion the actual language used is not very important because most of the code that will be used with Emacs will be written specifically for Emacs. The availability of alternative implementations is also of no use because changing the underlying implementation is the part that's difficult (at least with Emacs's current structure). What matters is that we reuse some existing implementation and benefit from all the work done on it, so we don't have to spend time working on the Elisp byte-compiler. I like the idea of Guile not because it's using a "standard preexisting language with libraries and experienced coders", but because it'll give us a bunch of hackers working on efficient implementation, multithreading, ... Stefan PS: The same holds for the redisplay engine; I really hope/wish we will be able to switch to some other project's redisplay engine at some point. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-13 16:07 ` Stefan Monnier @ 2010-04-13 18:56 ` Thomas Lord 2010-04-13 19:22 ` Christian Lynbech 2010-04-14 10:14 ` Bruce Stephens 2010-04-14 14:10 ` joakim 2 siblings, 1 reply; 149+ messages in thread From: Thomas Lord @ 2010-04-13 18:56 UTC (permalink / raw To: Stefan Monnier; +Cc: Bruce Stephens, emacs-devel On Tue, 2010-04-13 at 12:07 -0400, Stefan Monnier wrote: > I agree with your conclusion but for a very different reason. > In my opinion the actual language used is not very important because > most of the code that will be used with Emacs will be written > specifically for Emacs. Well, I'm not so sure that that's entirely true and I'm also not so sure that that's the only consideration. What you say is less than obviously true in this way, at least: Consider how modern browsers are often written. On the one hand there is some lower-level library for rendering HTML and doing various HTTP magic. On the other hand, there are higher levels that make the complete application. That lower level part gets re-used in other applications. A text editor isn't obviously much (or perhaps at all) a different case. It might be desirable to start thinking of Emacs in two layers: an embeddable library and, sure, a default application as its basic front-end. Emacs lisp library code would then be "emacs specific" in some sense (relative to the library) but not really application specific. Beyond that: While it might be the case that "most" Emacs lisp library code is Emacs-specific in some sense, some important code need not be. One example is SCSH (the Scheme "shell" for managing sub-processes). A possible future example is Unicode-oriented string libraries. "Most" of the code might be Emacs-specific but some important parts of the code need not be. And, anyway, it's not the only consideration. If Scheme were used by many GNU programs as an extension language, then inter-process communication by writing and reading Scheme s-exps would be more common. Two standard Scheme environments can exchange s-exps with relatively little problem. But toss in a very different lisp - like Emacs lisp - and you start to have problems. E.g., what does "nil" read as? What's the syntax for strings? Are symbols case sensitive? > The availability of alternative implementations is also of no use > because changing the underlying implementation is the part that's > difficult (at least with Emacs's current structure). Sure. But if we're thinking of a long term strategy rather than quick hacks, we should also keep in mind that much of what is today in C in Emacs could well be usefully replaced by Scheme code. That's part of why I suggest (you know, given the infinite amount of spare time we all have) the radical option of stripping Emacs lisp out and re-binding to Scheme: because that exercise would lead to some careful re-evaluation of what needs to be in the C part and how best to make a clean interface to it. > What matters is that we reuse some existing implementation and benefit > from all the work done on it, so we don't have to spend time working on > the Elisp byte-compiler. I fully agree that that matters. > I like the idea of Guile not because it's using a "standard preexisting > language with libraries and experienced coders", but because it'll give > us a bunch of hackers working on efficient implementation, > multithreading, ... Yup. A big "gotcha" trap to watch out for on that path is Guile's C API. The less intertwingled Guile's (or any other implementations) assumptions about the C client can be, the better and more flexible the result. I.e., it would be pretty much the same mistake as being too Emacs lisp centric to be too Guile centric. It would ideally be plausible to swap out Guile for some other implementation, even if the initial investment and commitment is to use Guile. -t > > Stefan > > > PS: The same holds for the redisplay engine; I really hope/wish we will > be able to switch to some other project's redisplay engine at some point. > > ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-13 18:56 ` Thomas Lord @ 2010-04-13 19:22 ` Christian Lynbech 0 siblings, 0 replies; 149+ messages in thread From: Christian Lynbech @ 2010-04-13 19:22 UTC (permalink / raw To: emacs-devel >>>>> "Thomas" == Thomas Lord <lord@emf.net> writes: >> Wouldn't it be about as good (and probably less work), to give up on the >> guile idea and evolve emacs lisp (with Miles's lexical-bind changes, and >> (one hopes) multithreading, and maybe other things)? Thomas> I dunno. Maybe. I'd guess that, no, that's not a Thomas> good strategy. Four reasons come quickly to mind: ... Wouldn't a reasonable alternative to using a scheme implementation be to use a Common Lisp ditto? And wouldn't that be a much closer fit semantically to the current Emacs Lisp dialect? I kind of hear you suggesting ditching all of the existing Emacs Lisp in favour of starting over from scratch with scheme. While it will be easy to list examples of existing libraries few will miss, emacs killer features such as gnus or org-mode still represent significant investments that are not easily reproduced from scratch. ------------------------+----------------------------------------------------- Christian Lynbech | christian #\@ defun #\. dk ------------------------+----------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic) ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-13 16:07 ` Stefan Monnier 2010-04-13 18:56 ` Thomas Lord @ 2010-04-14 10:14 ` Bruce Stephens 2010-04-14 14:10 ` joakim 2 siblings, 0 replies; 149+ messages in thread From: Bruce Stephens @ 2010-04-14 10:14 UTC (permalink / raw To: emacs-devel Stefan Monnier <monnier@IRO.UMontreal.CA> writes: [...] > What matters is that we reuse some existing implementation and benefit > from all the work done on it, so we don't have to spend time working on > the Elisp byte-compiler. > > I like the idea of Guile not because it's using a "standard preexisting > language with libraries and experienced coders", but because it'll give > us a bunch of hackers working on efficient implementation, > multithreading, ... That seems like a stronger argument to me. Back in 1995 (or thereabouts) using scheme for better interoperability with other GNU applications seemed a plausible argument, but I don't think that's how things have worked out. I doubt that replacing emacs lisp with scheme would have much impact for interoperability, though removing one extension language won't hurt. [...] ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-13 16:07 ` Stefan Monnier 2010-04-13 18:56 ` Thomas Lord 2010-04-14 10:14 ` Bruce Stephens @ 2010-04-14 14:10 ` joakim 2 siblings, 0 replies; 149+ messages in thread From: joakim @ 2010-04-14 14:10 UTC (permalink / raw To: Stefan Monnier; +Cc: Bruce Stephens, Thomas Lord, emacs-devel Stefan Monnier <monnier@IRO.UMontreal.CA> writes: >> I dunno. Maybe. I'd guess that, no, that's not a >> good strategy. Four reasons come quickly to mind: > > I agree with your conclusion but for a very different reason. > In my opinion the actual language used is not very important because > most of the code that will be used with Emacs will be written > specifically for Emacs. > The availability of alternative implementations is also of no use > because changing the underlying implementation is the part that's > difficult (at least with Emacs's current structure). > > What matters is that we reuse some existing implementation and benefit > from all the work done on it, so we don't have to spend time working on > the Elisp byte-compiler. > > I like the idea of Guile not because it's using a "standard preexisting > language with libraries and experienced coders", but because it'll give > us a bunch of hackers working on efficient implementation, > multithreading, ... > > > Stefan > > > PS: The same holds for the redisplay engine; I really hope/wish we will > be able to switch to some other project's redisplay engine at some point. > IMHO it would be interesting to have Emacs as a set of components which could be plugged together, which also happened to include an elisp interpreter. This could work sort of like JNI in Java, or some other component model(Like one of the lightweight corba implementations) A start would be a plug-in model that allowed C plugins to be jacked into Emacs. That could allow other runtimes, like Guile, to run in Emacs and affect the Emacs internal state. -- Joakim Verona ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-13 15:51 ` Thomas Lord 2010-04-13 16:07 ` Stefan Monnier @ 2010-04-13 19:13 ` Christian Lynbech 2010-04-14 1:47 ` Thomas Lord ` (2 more replies) 1 sibling, 3 replies; 149+ messages in thread From: Christian Lynbech @ 2010-04-13 19:13 UTC (permalink / raw To: Thomas Lord; +Cc: Bruce Stephens, emacs-devel >>>>> "Thomas" == Thomas Lord <lord@emf.net> writes: >> Wouldn't it be about as good (and probably less work), to give up on the >> guile idea and evolve emacs lisp (with Miles's lexical-bind changes, and >> (one hopes) multithreading, and maybe other things)? Thomas> I dunno. Maybe. I'd guess that, no, that's not a Thomas> good strategy. Four reasons come quickly to mind: ... Wouldn't a reasonable alternative to using a scheme implementation be to use a Common Lisp ditto? And wouldn't that be a much closer fit semantically to the current Emacs Lisp dialect? I kind of hear you suggesting ditching all of the existing Emacs Lisp in favour of starting over from scratch with scheme. While it will be easy to list examples of existing libraries few will miss, emacs killer features such as gnus or org-mode still represent significant investments that are not easily reproduced from scratch. ------------------------+----------------------------------------------------- Christian Lynbech | christian #\@ defun #\. dk ------------------------+----------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic) ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-13 19:13 ` Christian Lynbech @ 2010-04-14 1:47 ` Thomas Lord 2010-04-14 3:33 ` Christian Lynbech 2010-04-14 5:02 ` Richard Stallman 2010-04-14 7:51 ` David Kastrup 2 siblings, 1 reply; 149+ messages in thread From: Thomas Lord @ 2010-04-14 1:47 UTC (permalink / raw To: Christian Lynbech; +Cc: Bruce Stephens, emacs-devel On Tue, 2010-04-13 at 21:13 +0200, Christian Lynbech wrote: > >>>>> "Thomas" == Thomas Lord <lord@emf.net> writes: > > >> Wouldn't it be about as good (and probably less work), to give up on the > >> guile idea and evolve emacs lisp (with Miles's lexical-bind changes, and > >> (one hopes) multithreading, and maybe other things)? > > Thomas> I dunno. Maybe. I'd guess that, no, that's not a > Thomas> good strategy. Four reasons come quickly to mind: ... > > Wouldn't a reasonable alternative to using a scheme implementation be to > use a Common Lisp ditto? I would have a hard time arguing conclusively that that would be unreasonable. Scheme is tidier and more compact and yields more interesting subsets. I think that Scheme currently enjoys way more R&D than CL. So I'd be on Scheme over CL for the general GNU extension language (not just for Emacs). And I don't suppose that legacy Emacs lisp code should in any way be allowed to hold back or mess up the design of a GNU extension language. But there are are good arguments both ways and I think you are right that a CL "ditto" might be a good alternative. > And wouldn't that be a much closer fit > semantically to the current Emacs Lisp dialect? Yes, I think it would. I'm free enough in my current position in life that I can afford to be cavalier and say "Eh, who cares about all that tonnage of extant Emacs lisp code. What's the Right Thing if we discount that code?" I can't sell you or anyone on that attitude and it might just be flat out wrong. It's just, at least, a position worth considering in the "big picture". > I kind of hear you suggesting ditching all of the existing Emacs Lisp in > favour of starting over from scratch with scheme. Yeah, I am, but I don't see anyone who is an obvious candidate to take on such a huge job with no guaranteed success at the end. As I said (and the scare-quotes are significant): it's something that "someone" should do. > While it will be easy to list examples of existing libraries few will > miss, emacs killer features such as gnus or org-mode still represent > significant investments that are not easily reproduced from scratch. Sure. But don't misunderestimate the rapidity with which a programmer fluent in both Emacs lisp and Scheme can sit down and port those programs from one language to the other. (The one that really scares *me* is calc.el!) -t > > > ------------------------+----------------------------------------------------- > Christian Lynbech | christian #\@ defun #\. dk > ------------------------+----------------------------------------------------- > Hit the philistines three times over the head with the Elisp reference manual. > - petonic@hal.com (Michael A. Petonic) ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-14 1:47 ` Thomas Lord @ 2010-04-14 3:33 ` Christian Lynbech 2010-04-14 23:33 ` Richard Stallman 0 siblings, 1 reply; 149+ messages in thread From: Christian Lynbech @ 2010-04-14 3:33 UTC (permalink / raw To: Thomas Lord; +Cc: Bruce Stephens, emacs-devel >>>>> "Thomas" == Thomas Lord <lord@emf.net> writes: >> While it will be easy to list examples of existing libraries few will >> miss, emacs killer features such as gnus or org-mode still represent >> significant investments that are not easily reproduced from scratch. Thomas> Sure. But don't misunderestimate the rapidity with Thomas> which a programmer fluent in both Emacs lisp and Scheme Thomas> can sit down and port those programs from one language to Thomas> the other. Possibly, but what scares me in that is the amount of dedication from *both* library authors and users needed at the same point in time to make such a switch happen. Users will not switch unless the packages they use are not ready in the new form and authors will not switch until the user base is ready to follow. It can very easily end up in a catch 22 situation. It is not that there haven't been several attempts already to implement a new direction for emacs. -- Chrisitian ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-14 3:33 ` Christian Lynbech @ 2010-04-14 23:33 ` Richard Stallman 0 siblings, 0 replies; 149+ messages in thread From: Richard Stallman @ 2010-04-14 23:33 UTC (permalink / raw To: Christian Lynbech; +Cc: bruce.stephens, lord, emacs-devel I think it would be a tremendous waste of effort to rewrite Emacs libraries in any language other than Emacs Lisp. Thus, what interests me is the idea of supporting other languages in addition to Emacs Lisp. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-13 19:13 ` Christian Lynbech 2010-04-14 1:47 ` Thomas Lord @ 2010-04-14 5:02 ` Richard Stallman 2010-04-14 6:45 ` christian.lynbech 2010-04-14 13:30 ` John Wiegley 2010-04-14 7:51 ` David Kastrup 2 siblings, 2 replies; 149+ messages in thread From: Richard Stallman @ 2010-04-14 5:02 UTC (permalink / raw To: Christian Lynbech; +Cc: bruce.stephens, lord, emacs-devel Common Lisp is extremely complicated and ugly. When I wrote GNU Emacs I had just finished implementing Common Lisp, and I did not like it much. It would bloat Emacs terribly, and documenting it would be hard too. Scheme is elegant, and it is a better direction to move in. Since we have our own Scheme implementation, we should use that one. If it has a serious disadvantage, we should do something about that. There are various things that might be right to do, but simply disregarding it in the case of Emacs cannot be right. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-14 5:02 ` Richard Stallman @ 2010-04-14 6:45 ` christian.lynbech 2010-04-14 19:07 ` Thomas Lord 2010-04-14 23:33 ` Richard Stallman 2010-04-14 13:30 ` John Wiegley 1 sibling, 2 replies; 149+ messages in thread From: christian.lynbech @ 2010-04-14 6:45 UTC (permalink / raw To: rms@gnu.org Cc: bruce.stephens@isode.com, lord@emf.net, Christian Lynbech, emacs-devel@gnu.org >>>>> "RMS" == Richard Stallman <rms@gnu.org> writes: RMS> Common Lisp is extremely complicated and ugly. When I wrote GNU Emacs RMS> I had just finished implementing Common Lisp, and I did not like it RMS> much. It would bloat Emacs terribly, and documenting it would be hard RMS> too. Fair enough, I happen to disagree but I respect that you have real-life experiennce in the matter. I do not understand the point about documentation though. Why would it be harder to document a common lisp based emacs than a scheme based emacs? I do not expect that we would like to make a brand new common lisp from scratch but rather to start out from an exisiting implementation, just as we would with scheme. RMS> Scheme is elegant, and it is a better direction to move in. I will challenge the claim that emacs-on-scheme would be any less bloated than an emacs-on-cl. Sure, core scheme is smaller than core common lisp, but once you have finished adding all of the stuff you need to get a working application, I believe you will have reached pretty much the same level of bloat. RMS> Since we have our own Scheme implementation, we should use that one. RMS> If it has a serious disadvantage, we should do something about that. RMS> There are various things that might be right to do, but simply RMS> disregarding it in the case of Emacs cannot be right. I am personally mostly worried about Thomas' points about getting scheme and emacs lisp to coexist. I just cannot see any evolution of emacs fly in the real world if it involves a clean cut away from the existing base of emacs lisp libraries. How we would ever get all developers and all users to back up such a move is beyond me ("all" used here in the sense of "enough to form a critical mass"). (Incidently, there is still something called GNU Common Lisp, even if not updated since 2005) ------------------------+----------------------------------------------------- Christian Lynbech | christian #\@ defun #\. dk ------------------------+----------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic) ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-14 6:45 ` christian.lynbech @ 2010-04-14 19:07 ` Thomas Lord 2010-04-14 19:34 ` Bruce Stephens ` (2 more replies) 2010-04-14 23:33 ` Richard Stallman 1 sibling, 3 replies; 149+ messages in thread From: Thomas Lord @ 2010-04-14 19:07 UTC (permalink / raw To: christian.lynbech Cc: bruce.stephens@isode.com, Christian Lynbech, rms@gnu.org, emacs-devel@gnu.org I really didn't mean to provoke a 20 message thread about what was, to me, just an idle thought and an interesting idea I wanted to share. So, below I'll reply to Christian and I'll also indirectly reply to some of the other messages - but unless there is someone or are some people who, right away, want to start working on a Scheme-based Emacs - there is probably not a lot to discuss. If there *is* a non-empty set of people who want to work on it, they should speak up and we can try to organize such an effort - the first step of which would be to convene elsewhere besides this mailing list. Otherwise, the whole thing is just a (to me) pretty thought that I wanted to share with others who might like to put in the back of their minds and contemplate it a bit, until perhaps someday when there is an obvious course of action to take. On Wed, 2010-04-14 at 08:45 +0200, christian.lynbech@tieto.com wrote: > I am personally mostly worried about Thomas' points about > getting scheme and emacs lisp to coexist. I just cannot > see any evolution of emacs fly in the real world if it > involves a clean cut away from the existing base > of emacs lisp libraries. How we would ever get > all developers and all users to back up such a move > is beyond me ("all" used here in the sense > of "enough to form a critical mass"). That's a legitimate concern but there are viable solutions to the problem: a) I'm *not* suggesting the idea of abandoning work on the main development line of GNU Emacs. I would expect that work to continue and to continue to use Emacs lisp. There are so many GNU Emacs users and the program generates such a large amount of good will for GNU that it seems to me very desirable to not "fix" what isn't broken. b) I don't imagine that a Scheme-centric Emacs would find itself with especially huge numbers of users in its first few years of life. I would *guess* that what would happen is that many people would try out the first release just to see what the fuss was about, that a much smaller number would stick with it, and that a slightly smaller number of those initial users would become contributing developers. My guess is based on the assumption that the first release is any good. If things went well in the first few years, then the Scheme-based Emacs might start becoming seriously popular. c) Someone - I think it was Tom Tromey - observed that Emacs Lisp is hardly something that is holding Emacs back (so why change at all?, he asks). I pretty much agree with that, at least in this sense: If the only serious difference between GNU Emacs and a new Scheme-based GNU Emacs were a change in extension language - then there would be little point in bothering. To succeed, a Scheme-based Emacs project would have to produce an Emacs with features that users really enjoy but that would be hard if not impossible to do in GNU Emacs with Emacs lisp. (In contrast, just replacing the Emacs lisp interpreter with a version of Guile that faithfully implements Emacs Lisp can succeed without needing to produce radically new features.) What kind of features might a Scheme-based Emacs offer that would be that important? Some speculation: Because Emacs Lisp support would be an explicit non-goal, everyone's favorite lisp package would have to be re-written (though, yes, often cribbing off of the Emacs Lisp version). Thus there would be opportunity (and a forcing function) to reconsider countless "little annoying details" of those packages and produce new versions with many improved details. Because a Scheme engine *should* wind up being significantly faster, and because such radical changes to the C code would be needed anyway, there is an opportunity to write more of the editor in the extension language, and less in C. In and of itself that doesn't help users. In practice it can help users by making more of Emacs much easier to modify and improve. For example (and, yes, this is a bit hand-wavy): if more of the display code were in Scheme, there is a good chance that there would be more and fancier features and "nice touches" in the display. I think that most people would agree that Scheme is a significantly more powerful language than Emacs lisp in the sense that it is easier to write more sophisticated programs in Scheme (with its closures, its fancy macro systems, and so forth). This, again, does not directly benefit users. In practice it could benefit users because in the same number of lines of code (Scheme vs. Emacs Lisp) an extension package could often provide more ambitious, fancier features. I've a few times mentioned the example SCSH (the Scheme shell) and it's a fine example to use here: a SCSH is not especially large or complicated. SCSH presents a subprocess management interface that is light years ahead of Emacs' and that would be rather painful to write in Emacs Lisp. The interface to sub-processes is again of no direct importance to users but what would benefit users are creative new applications enabled by the new interface. That is, Scheme's more powerful environment leads to subsystems like SCSH which leads to extension package developers using sub-processes more often and in fancier ways which - one would hope - leads to fancier, user-facing extension language packages. You get the idea, I hope. Scheme isn't some magic bullet that, by its mere presence, would advance Emacs into a bright new future. It is a nicer, more comfortable extension language, more standard than Emacs lisp, and affording more efficient implementations than Emacs lisp could ever hope to afford - all details that don't help users directly. The stubborn decision to start fresh and cannibalize GNU Emacs to make a Scheme-based Emacs *could* be, in addition to possibly being fun, a catalyst. By forcing the rewrite or significant modification of large subsystems, it would force a careful design review and updating - without the pressure of being upwards compatible with Emacs lisp. In that adapt / rewrite process, there is opportunity not just to go after one or two new "killer features" - but rather to go after many, many small but noticeable improvements all across the board. And if more of the editor is written in the extension language and the extension language is a more powerful language with a faster implementation - then it *should* (no guarantees) work out that within a few years the Scheme based version will have user-facing features that make people say "Wow. The old Emacs couldn't do that!" -t ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-14 19:07 ` Thomas Lord @ 2010-04-14 19:34 ` Bruce Stephens 2010-04-14 20:09 ` Jose A. Ortega Ruiz 2010-04-15 7:34 ` christian.lynbech 2 siblings, 0 replies; 149+ messages in thread From: Bruce Stephens @ 2010-04-14 19:34 UTC (permalink / raw To: emacs-devel Thomas Lord <lord@emf.net> writes: [...] > If there *is* a non-empty set of people who want > to work on it, they should speak up and we can try > to organize such an effort - the first step of which > would be to convene elsewhere besides this mailing > list. Judging by <http://wingolog.org/archives/2010/04/02/recent-developments-in-guile>, it is being worked on. The claim is that there's an emacs lisp compiler to guile that gives (or will give RSN) a faster implementation than that in Emacs. I presume the language will be equivalent to current emacs lisp (so that wouldn't force the rewrite and perhaps spur the improvements you'd like to see), on the other hand not having to rewrite the lisp libraries would make it an easier sell. Presumably it could easily support lexical binding (and closures) and other features. Nothing wrong (IMHO) in proceeding to improve emacs lisp by integrating the lexical-binding branch, perhaps adding hygienic (or other) macros, etc. [...] ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-14 19:07 ` Thomas Lord 2010-04-14 19:34 ` Bruce Stephens @ 2010-04-14 20:09 ` Jose A. Ortega Ruiz 2010-04-15 7:34 ` christian.lynbech 2 siblings, 0 replies; 149+ messages in thread From: Jose A. Ortega Ruiz @ 2010-04-14 20:09 UTC (permalink / raw To: emacs-devel; +Cc: lord Thomas Lord <lord@emf.net> writes: > If there *is* a non-empty set of people who want > to work on it, they should speak up and we can try > to organize such an effort - the first step of which > would be to convene elsewhere besides this mailing > list. i am interested. cheers, jao ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-14 19:07 ` Thomas Lord 2010-04-14 19:34 ` Bruce Stephens 2010-04-14 20:09 ` Jose A. Ortega Ruiz @ 2010-04-15 7:34 ` christian.lynbech 2 siblings, 0 replies; 149+ messages in thread From: christian.lynbech @ 2010-04-15 7:34 UTC (permalink / raw To: Thomas Lord Cc: bruce.stephens@isode.com, Christian Lynbech, rms@gnu.org, emacs-devel@gnu.org >>>>> "Thomas" == Thomas Lord <lord@emf.net> writes: Thomas> If the only serious difference between GNU Emacs and Thomas> a new Scheme-based GNU Emacs were a change in extension Thomas> language - then there would be little point in bothering. Theses points have been made more or less in several places already but just to reiterate, changing the extension language to a more widely used language variant, even if everything else stays the same, would have several benefits: - faster execution of also emacs lisp code - shared burden of maintenance for the language platform - ability to load up (external) libaries written in the new language - a platform to evolve also the emacs lisp parts into safer/better/faster - a platform to evolve C parts back into the extension language realm What kind of future this would lead Emacs into is hard to say but it would certainly facilitate many great things. I agree with you that, as on example, being able to move functionality from back into scheme or elisp or whatever will be a very exiticing thing. ------------------------+----------------------------------------------------- Christian Lynbech | christian #\@ defun #\. dk ------------------------+----------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic) ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-14 6:45 ` christian.lynbech 2010-04-14 19:07 ` Thomas Lord @ 2010-04-14 23:33 ` Richard Stallman 2010-04-15 3:52 ` Drew Adams 1 sibling, 1 reply; 149+ messages in thread From: Richard Stallman @ 2010-04-14 23:33 UTC (permalink / raw To: christian.lynbech; +Cc: bruce.stephens, lord, christian, emacs-devel I do not understand the point about documentation though. Why would it be harder to document a common lisp based emacs than a scheme based emacs? Common Lisp has sooo much to document. The Emacs Lisp Manual would get a lot bigger if it had to include the specs of so many functions. ^ permalink raw reply [flat|nested] 149+ messages in thread
* RE: Guile in Emacs 2010-04-14 23:33 ` Richard Stallman @ 2010-04-15 3:52 ` Drew Adams 2010-04-15 6:01 ` David Kastrup 2010-04-15 18:47 ` Richard Stallman 0 siblings, 2 replies; 149+ messages in thread From: Drew Adams @ 2010-04-15 3:52 UTC (permalink / raw To: rms, christian.lynbech; +Cc: bruce.stephens, lord, christian, emacs-devel > Common Lisp has sooo much to document. The Emacs Lisp Manual would > get a lot bigger if it had to include the specs of so many functions. The Elisp manual would not need to document things that are vanilla Common Lisp (i.e. respect the CL standard). It could simply cross-reference the relevant CL doc. The Elisp manual would need to document only extensions or departures from the standard. It does not need to reproduce all of the existing CL documentation. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-15 3:52 ` Drew Adams @ 2010-04-15 6:01 ` David Kastrup 2010-04-15 6:54 ` Drew Adams 2010-04-15 7:21 ` christian.lynbech 2010-04-15 18:47 ` Richard Stallman 1 sibling, 2 replies; 149+ messages in thread From: David Kastrup @ 2010-04-15 6:01 UTC (permalink / raw To: emacs-devel "Drew Adams" <drew.adams@oracle.com> writes: >> Common Lisp has sooo much to document. The Emacs Lisp Manual would >> get a lot bigger if it had to include the specs of so many functions. > > The Elisp manual would not need to document things that are vanilla > Common Lisp (i.e. respect the CL standard). It could simply > cross-reference the relevant CL doc. The Elisp manual would need to > document only extensions or departures from the standard. It does not > need to reproduce all of the existing CL documentation. The manuals of an editor with a user-accessible extension language (with Emacs, this is the case for Elisp but not for C) need to document this extension language. Otherwise, only programmers can be expected to be able to use it. One reason for that is that non-Emacs specific Lisp manuals will not focus about how to get things done with Emacs. Applying a manual utterly without editing focus to editing tasks is quite a large intellectual feat. -- David Kastrup ^ permalink raw reply [flat|nested] 149+ messages in thread
* RE: Guile in Emacs 2010-04-15 6:01 ` David Kastrup @ 2010-04-15 6:54 ` Drew Adams 2010-04-15 11:59 ` Jeff Clough 2010-04-15 7:21 ` christian.lynbech 1 sibling, 1 reply; 149+ messages in thread From: Drew Adams @ 2010-04-15 6:54 UTC (permalink / raw To: 'David Kastrup', emacs-devel > >> Common Lisp has sooo much to document. The Emacs Lisp Manual would > >> get a lot bigger if it had to include the specs of so many > >> functions. > > > > The Elisp manual would not need to document things that are vanilla > > Common Lisp (i.e. respect the CL standard). It could simply > > cross-reference the relevant CL doc. The Elisp manual would need to > > document only extensions or departures from the standard. > > It does not need to reproduce all of the existing CL documentation. > > The manuals of an editor with a user-accessible extension > language (with Emacs, this is the case for Elisp but not > for C) need to document this extension language. Emacs needs to document its extension language, yes of course. That means that it needs to enable users to obtain complete documentation about the language. That does not mean that the Emacs manuals (e.g. Elisp manual) themselves need to specify everything about CL functions Emacs might support. It simply means that Emacs needs to provide users access to that information. A cross reference can be focused directly to an appropriate section of existing Common-Lisp documentation. We need not just dump a user into the TOC of a large manual. It is a choice whether we want clicking a cross-reference in an Emacs manual to take you (a) to a section of the same manual or another manual available locally or (b) to a section of a manual that might be on the Web. A cross reference might well be to a non-local or a non-GNU manual or specification. What is important is that we give users access to the specific info they need. > Otherwise, only programmers can be expected to be able to use it. One > reason for that is that non-Emacs specific Lisp manuals will not focus > about how to get things done with Emacs. Applying a manual utterly > without editing focus to editing tasks is quite a large intellectual > feat. The Emacs manual(s) will of course focus on how to get things done with Emacs. If there is something Emacs-specific to be said about a function such as `some', then yes, the Emacs manuals are an appropriate place to say that. That does not imply that everything possible to be said about every Common-Lisp construct needs to be covered in the Emacs manual. That would be an absurd approach. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-15 6:54 ` Drew Adams @ 2010-04-15 11:59 ` Jeff Clough 2010-04-15 12:49 ` christian.lynbech 2010-04-15 16:11 ` Guile in Emacs Drew Adams 0 siblings, 2 replies; 149+ messages in thread From: Jeff Clough @ 2010-04-15 11:59 UTC (permalink / raw To: Drew Adams; +Cc: 'David Kastrup', emacs-devel "Drew Adams" <drew.adams@oracle.com> writes: > It is a choice whether we want clicking a cross-reference in an Emacs manual to > take you (a) to a section of the same manual or another manual available locally > or (b) to a section of a manual that might be on the Web. A cross reference > might well be to a non-local or a non-GNU manual or specification. What is > important is that we give users access to the specific info they need. It is also important for that information to be available in one place. When the information you need is split between two (or more) manuals, a wiki, a HOW-TO and Wonder Tommy's blog, it sucks, no matter how well cross-referenced or searchable it is. There's a better way and Emacs has it (for the most part). I've never subscribed to the theory that just because a feature is described on some web page out there, and not in the official manual, that it's "documented". Why people want to see this as the success of the internet rather than as a failure of the documentation is beyond me. Keep the information itself in one place that I can put on a tablet as a PDF, or print out and take with me on an overnight. Not everyone reads their docs from within Emacs all of the time. For what it's worth. Jeff ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-15 11:59 ` Jeff Clough @ 2010-04-15 12:49 ` christian.lynbech 2010-04-15 13:54 ` Jeff Clough 2010-04-15 16:11 ` Guile in Emacs Drew Adams 1 sibling, 1 reply; 149+ messages in thread From: christian.lynbech @ 2010-04-15 12:49 UTC (permalink / raw To: Jeff Clough; +Cc: 'David Kastrup', Drew Adams, emacs-devel@gnu.org >>>>> "Jeff" == Jeff Clough <jeff@chaosphere.com> writes: Jeff> It is also important for that information to be available in one place. I agree that Emacs should come with all relevant documentation bundled up as part of the package, but I can not see that this is the same as everything necessarily has to sit inside (the moral equivalent of) one single gigantic texinfo file. There will need to be easy acces to the reference just as we get today easily can get from the documentation of a function to its source definition and there should probably be some top-level entry points with proper reading guidance just as the editing library manual should of course link to the language manual where relevant. ------------------------+----------------------------------------------------- Christian Lynbech | christian #\@ defun #\. dk ------------------------+----------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic) ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-15 12:49 ` christian.lynbech @ 2010-04-15 13:54 ` Jeff Clough 2010-04-15 14:03 ` Lennart Borgman ` (3 more replies) 0 siblings, 4 replies; 149+ messages in thread From: Jeff Clough @ 2010-04-15 13:54 UTC (permalink / raw To: christian.lynbech Cc: 'David Kastrup', Drew Adams, emacs-devel@gnu.org <christian.lynbech@tieto.com> writes: > Jeff> It is also important for that information to be available in one place. > > I agree that Emacs should come with all relevant documentation bundled > up as part of the package, but I can not see that this is the same as > everything necessarily has to sit inside (the moral equivalent of) one > single gigantic texinfo file. Neither do I, but what we have today works. That's what I'm for. Don't fix what isn't broken. Or, more appropriately, don't fix what Emacs seems to be the only application to do *right*. For Emacs itself, there are exactly four places, organized by context, someone has to look to find the information they need. 1. The Emacs Manual - How to use Emacs as an editor. The only Lisp found here is for basic, simple configuration. This is for people that don't want to learn Lisp, they just want to use Emacs as an editor, run macros, dired, etc. 2. The Emacs Lisp Intro - Teaches the basics of Emacs Lisp. How to use defadvice, creating a simple major mode, etc. This is for people just getting started, or who want to know only how to write a simple function to accomplish some task this afternoon. 3. The Emacs Lisp Reference - Describes every function, macro and language construct with a few explainations. There may be more information to be had about a particular thing, but it at least lists all things with *some* amount of description. This is for people seriously interested in the language who want to browse for ideas/knowledge, read something away from their computer or copy a quick "toy" example (if available) and make it work for them right now. 4. The online documentation/what you get from describe-function and it's kin - The definitive reference to every symbol you can throw at Emacs. Assumed to be up-to-date and accurate. This is for people knee-deep in code right now that can't remember what the third argument of the function at point needs to be, or can't remember if what they want is insert-file-contents or insert-file-contents-literally. All four of these sources have their proper use, and none of them could be used to duplicate exactly the purpose of any other. And it covers all of the contexts you'd want documentation (IMHO) well, in a minimum number of places. > There will need to be easy acces to the reference just as we get today > easily can get from the documentation of a function to its source > definition and there should probably be some top-level entry points with > proper reading guidance just as the editing library manual should of > course link to the language manual where relevant. I think having cross references between the four sources described above is a great thing. There should be more of that today. Jeff ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-15 13:54 ` Jeff Clough @ 2010-04-15 14:03 ` Lennart Borgman 2010-04-15 16:13 ` Drew Adams ` (2 subsequent siblings) 3 siblings, 0 replies; 149+ messages in thread From: Lennart Borgman @ 2010-04-15 14:03 UTC (permalink / raw To: Jeff Clough Cc: David Kastrup, emacs-devel@gnu.org, Drew Adams, christian.lynbech On Thu, Apr 15, 2010 at 3:54 PM, Jeff Clough <jeff@chaosphere.com> wrote: > > 4. The online documentation/what you get from describe-function and > it's kin - The definitive reference to every symbol you can throw at > Emacs. Assumed to be up-to-date and accurate. This is for people > knee-deep in code right now that can't remember what the third argument > of the function at point needs to be, or can't remember if what they > want is insert-file-contents or insert-file-contents-literally. Maybe it should be mentioned here that the online documentation can't handle defstruct etc in the cl packages. To me this means that the package is not up to Emacs normal standards. ^ permalink raw reply [flat|nested] 149+ messages in thread
* RE: Guile in Emacs 2010-04-15 13:54 ` Jeff Clough 2010-04-15 14:03 ` Lennart Borgman @ 2010-04-15 16:13 ` Drew Adams 2010-04-16 13:48 ` Jeff Clough 2010-04-16 8:27 ` christian.lynbech 2010-04-16 22:29 ` Emacs Info manuals (was: Guile in Emacs) Juri Linkov 3 siblings, 1 reply; 149+ messages in thread From: Drew Adams @ 2010-04-15 16:13 UTC (permalink / raw To: 'Jeff Clough', christian.lynbech Cc: 'David Kastrup', emacs-devel > I think having cross references between the four sources > described above is a great thing. There should be more > of that today. According to *your* argument: For any topic, you should be able to find an explanation of *everything* about that topic (including all possible relations and ramifications) in *one* place. According to your argument, cross references are anathema - not even a necessary evil, but something that can and should be dispensed with. Do you get it now? Your argument is in fact an argument against *any* doc organization. It is an argument against cross references and the need for or the utility of cross references. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-15 16:13 ` Drew Adams @ 2010-04-16 13:48 ` Jeff Clough 2010-04-16 14:03 ` christian.lynbech 2010-04-16 14:25 ` Drew Adams 0 siblings, 2 replies; 149+ messages in thread From: Jeff Clough @ 2010-04-16 13:48 UTC (permalink / raw To: Drew Adams; +Cc: 'David Kastrup', emacs-devel, christian.lynbech "Drew Adams" <drew.adams@oracle.com> writes: >> I think having cross references between the four sources >> described above is a great thing. There should be more >> of that today. > > According to *your* argument: For any topic, you should be able to find an > explanation of *everything* about that topic (including all possible relations > and ramifications) in *one* place. > > According to your argument, cross references are anathema - not even a necessary > evil, but something that can and should be dispensed with. Did you read the rest of that referenced post? I clarified that what I want from a future Emacs, in terms of documentation, is what is provided by today's Emacs. > Do you get it now? Your argument is in fact an argument against *any* doc > organization. It is an argument against cross references and the need for or the > utility of cross references. *I* got what I wrote, but I'm pretty sure that *you* didn't. It is perfectly fine for an "Intro Manual" included with Emacs to link to a "Reference Manual" included with Emacs. It is not okay for critical documentation to be hosted anywhere but a user's hard drive, and the number of files this documentation is contained in should be kept to a minimum. I am not asking for a monolithic document that would be the end all, be all Emacs Bible. I am stating that the four manuals + describe-function, et al, are a great arrangment and the example I would point to when someone asked me for an example of good documentation. If a change was made to this system, I have a hard time believing it would be anything other than a mistake, if only because I cannot imagine any change improving it and if no improvement is made, effort is wasted. Jeff ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-16 13:48 ` Jeff Clough @ 2010-04-16 14:03 ` christian.lynbech 2010-04-16 14:25 ` Jeff Clough 2010-04-16 14:25 ` Drew Adams 1 sibling, 1 reply; 149+ messages in thread From: christian.lynbech @ 2010-04-16 14:03 UTC (permalink / raw To: Jeff Clough; +Cc: 'David Kastrup', Drew Adams, emacs-devel@gnu.org >>>>> "Jeff" == Jeff Clough <jeff@chaosphere.com> writes: Jeff> I am stating that the four manuals + describe-function, et al, are Jeff> a great arrangment I fail to see why 5 manuals are significantly worse than 4 manuals as long as there is a clear separation between them. ------------------------+----------------------------------------------------- Christian Lynbech | christian #\@ defun #\. dk ------------------------+----------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic) ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-16 14:03 ` christian.lynbech @ 2010-04-16 14:25 ` Jeff Clough 0 siblings, 0 replies; 149+ messages in thread From: Jeff Clough @ 2010-04-16 14:25 UTC (permalink / raw To: christian.lynbech Cc: 'David Kastrup', Drew Adams, emacs-devel@gnu.org <christian.lynbech@tieto.com> writes: >>>>>> "Jeff" == Jeff Clough <jeff@chaosphere.com> writes: > > Jeff> I am stating that the four manuals + describe-function, et al, are > Jeff> a great arrangment > > I fail to see why 5 manuals are significantly worse than 4 manuals as > long as there is a clear separation between them. At this point I'm just going to assume that I'm either being unreasonable and not knowing it or that I'm not able to properly explain my reasoning concerning this. I believe that Emacs works perfectly with the four manuals it has today. I fail to see how a fifth manual would improve it. That a fifth manual would not make things "significantly worse" isn't a glowing endorsement. Regardless, I think I've explained myself here as best as I am able to. When/if the change is made, I'm sure I'll be able to see for myself how much of an effect it has and I may even be pleasantly surprised. Jeff ^ permalink raw reply [flat|nested] 149+ messages in thread
* RE: Guile in Emacs 2010-04-16 13:48 ` Jeff Clough 2010-04-16 14:03 ` christian.lynbech @ 2010-04-16 14:25 ` Drew Adams 2010-04-16 14:39 ` David Kastrup 2010-04-16 14:40 ` Jeff Clough 1 sibling, 2 replies; 149+ messages in thread From: Drew Adams @ 2010-04-16 14:25 UTC (permalink / raw To: 'Jeff Clough' Cc: 'David Kastrup', emacs-devel, christian.lynbech > It is not okay for critical documentation to be hosted > anywhere but a user's hard drive, 1. Not every bit of description of every single Common-Lisp construct is "critical" documentation. Far from it. You've added "critical" now, but your previous argument was against all, not just "critical", non-local reference. 2. Depending on what is meant by such a watered-down meaning of "critical", it would be absurd in 2010 and beyond to limit, by design, the doc set to what is or can be hosted on a user's hard drive. Which user? What size hard drive? Will you tailor the available doc set by design to Emacs running on a 1 gig flash drive or other lowest common denominator? Nowadays, the number of people who actually download PDF docs for a large software product, in order to have them locally, is miniscule, compared to the number who consult the same doc set on demand, on line (Web) as HTML. It is good for users to be _able_ to have a certain number of core docs locally. And they should be able to control just how much they want to keep locally and how much they are willing to access remotely. But that doesn't mean that the entire doc set for Emacs (or anything else) needs to be or should be kept to a minimal size that every user could store on a typical hard disk. Yes, there are good reasons to avoid documentation bloat - always. Just as there are good reasons to avoid software bloat (a more important argument concerning CL, perhaps). The question in both cases is whether users _need_ all that doc or all that software. _If_ we decide the answer is yes, then, well, it's needed, regardless of how big typical hard disks might be this year. A hard-and-simple hard-disk criterion such as you express is not appropriate. Doc that is not needed by users is wasted and should be pruned. But if some particular doc is needed to explain something, then it's needed, period. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-16 14:25 ` Drew Adams @ 2010-04-16 14:39 ` David Kastrup 2010-04-16 14:40 ` Jeff Clough 1 sibling, 0 replies; 149+ messages in thread From: David Kastrup @ 2010-04-16 14:39 UTC (permalink / raw To: emacs-devel "Drew Adams" <drew.adams@oracle.com> writes: >> It is not okay for critical documentation to be hosted >> anywhere but a user's hard drive, > > 1. Not every bit of description of every single Common-Lisp construct is > "critical" documentation. Far from it. It is critical if it is being used in a package you are trying to understand. -- David Kastrup ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-16 14:25 ` Drew Adams 2010-04-16 14:39 ` David Kastrup @ 2010-04-16 14:40 ` Jeff Clough 1 sibling, 0 replies; 149+ messages in thread From: Jeff Clough @ 2010-04-16 14:40 UTC (permalink / raw To: Drew Adams; +Cc: 'David Kastrup', emacs-devel, christian.lynbech "Drew Adams" <drew.adams@oracle.com> writes: >> It is not okay for critical documentation to be hosted >> anywhere but a user's hard drive, > > You've added "critical" now, but your previous argument was against all, not > just "critical", non-local reference. Sigh. I'm not adding requirements, *you* are being pedantic. > Which user? What size hard drive? Will you tailor the available doc set by > design to Emacs running on a 1 gig flash drive or other lowest common > denominator? I'll just point at what Emacs is doing today and say "Pretty much that". > Nowadays, the number of people who actually download PDF docs for a large > software product, in order to have them locally, is miniscule, compared to the > number who consult the same doc set on demand, on line (Web) as HTML. And a growing number of people are using netbooks with dodgy wi-fi connections. There is a general philosophical debate showing up in various places as to whether it is okay to assume the presence of the network when the user is not doing non network-specific things. Apparently you feel the answer is yes. > But that doesn't mean that the entire doc set for Emacs (or anything else) needs > to be or should be kept to a minimal size that every user could store on a > typical hard disk. My info directory is 14 megabytes. Even if the new version required this to increase by a full order of magnitude in order to be "complete", I fail to see how this is in any way a limitation. > A hard-and-simple hard-disk criterion such as you express is not appropriate. > Doc that is not needed by users is wasted and should be pruned. But if some > particular doc is needed to explain something, then it's needed, period. Again, I'm going to point to what Emacs has today and say "See, that? We should do that." You disagree, fair enough. Jeff ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-15 13:54 ` Jeff Clough 2010-04-15 14:03 ` Lennart Borgman 2010-04-15 16:13 ` Drew Adams @ 2010-04-16 8:27 ` christian.lynbech 2010-04-17 4:41 ` Richard Stallman 2010-04-16 22:29 ` Emacs Info manuals (was: Guile in Emacs) Juri Linkov 3 siblings, 1 reply; 149+ messages in thread From: christian.lynbech @ 2010-04-16 8:27 UTC (permalink / raw To: Jeff Clough; +Cc: 'David Kastrup', Drew Adams, emacs-devel@gnu.org >>>>> "Jeff" == Jeff Clough <jeff@chaosphere.com> writes: Jeff> Neither do I, but what we have today works. That's what I'm for. Don't Jeff> fix what isn't broken. Or, more appropriately, don't fix what Emacs Jeff> seems to be the only application to do *right*. Well, something needs to be done if emacs changes extension language. Either we accept keeping the language documentation in a separate document such we can use what the language platform already provides *or* we duplicate the work done by the language platform in order to integrate the language documentation into the emacs specific reference manual. The latter option both incurs an initial significant cost plus a continued burden of maintenance to keep the emacs manual in synch with the language platform. It does not strike me as a good way of spending volunteer resources. ------------------------+----------------------------------------------------- Christian Lynbech | christian #\@ defun #\. dk ------------------------+----------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic) ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-16 8:27 ` christian.lynbech @ 2010-04-17 4:41 ` Richard Stallman 2010-04-19 7:52 ` christian.lynbech 0 siblings, 1 reply; 149+ messages in thread From: Richard Stallman @ 2010-04-17 4:41 UTC (permalink / raw To: christian.lynbech; +Cc: jeff, dak, drew.adams, emacs-devel Well, something needs to be done if emacs changes extension language. There is no plan to change the extension language of Emacs, only to support others in addition. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-17 4:41 ` Richard Stallman @ 2010-04-19 7:52 ` christian.lynbech 0 siblings, 0 replies; 149+ messages in thread From: christian.lynbech @ 2010-04-19 7:52 UTC (permalink / raw To: rms@gnu.org Cc: jeff@chaosphere.com, dak@gnu.org, drew.adams@oracle.com, emacs-devel@gnu.org >>>>> "Richard" == Richard Stallman <rms@gnu.org> writes: > Well, something needs to be done if emacs changes extension language. Richard> There is no plan to change the extension language of Emacs, Richard> only to support others in addition. Ok, I see. If emacs becomes multi-lingual (or perhaps even if it just changes the base implementation), I still think it would make sense to split out the language specific documentation from the editing library reference manual to increase the maintainability of both. This is of course not a terribly important thing to discuss at the moment. ------------------------+----------------------------------------------------- Christian Lynbech | christian #\@ defun #\. dk ------------------------+----------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic) ^ permalink raw reply [flat|nested] 149+ messages in thread
* Emacs Info manuals (was: Guile in Emacs) 2010-04-15 13:54 ` Jeff Clough ` (2 preceding siblings ...) 2010-04-16 8:27 ` christian.lynbech @ 2010-04-16 22:29 ` Juri Linkov 3 siblings, 0 replies; 149+ messages in thread From: Juri Linkov @ 2010-04-16 22:29 UTC (permalink / raw To: Jeff Clough; +Cc: emacs-devel > 1. The Emacs Manual [...] > 2. The Emacs Lisp Intro [...] > 3. The Emacs Lisp Reference [...] > 4. The online documentation/what you get from describe-function and > it's kin - The definitive reference to every symbol you can throw at > Emacs. Assumed to be up-to-date and accurate. This is for people > knee-deep in code right now that can't remember what the third argument > of the function at point needs to be, or can't remember if what they > want is insert-file-contents or insert-file-contents-literally. I'd like to also clarify that the purpose of the fourth is not only to provide actual information about available functions and their arguments but also to add dynamical information like whether a function is advised, what keybindings it has, etc. IOW, this information can't be in a static Info file. So unlike 3 static Info manuals, the online help manual should be dynamically created at run time. This is possible to do using virtual Info manuals. > I think having cross references between the four sources described above > is a great thing. There should be more of that today. Yes, this would be a great thing, but unfortunately currently cross references between the online documentation and Info manuals are largely dysfunctional. However, with the online documentation in a virtual Info manual, cross references between these four sources will use the existing Info cross references, thus providing more consistent UI. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 149+ messages in thread
* RE: Guile in Emacs 2010-04-15 11:59 ` Jeff Clough 2010-04-15 12:49 ` christian.lynbech @ 2010-04-15 16:11 ` Drew Adams 1 sibling, 0 replies; 149+ messages in thread From: Drew Adams @ 2010-04-15 16:11 UTC (permalink / raw To: 'Jeff Clough'; +Cc: 'David Kastrup', emacs-devel > > It is a choice whether we want clicking a cross-reference > > in an Emacs manual to take you (a) to a section of the > > same manual or another manual available locally > > or (b) to a section of a manual that might be on the Web. A > > cross reference might well be to a non-local or a non-GNU > > manual or specification. What is important is that we give > > users access to the specific info they need. > > It is also important for that information to be available in > one place. When the information you need is split between two > (or more) manuals, a wiki, a HOW-TO and Wonder Tommy's blog, > it sucks, no matter how well cross-referenced or searchable it is. > There's a better way and Emacs has it (for the most part). It is a classic documentation dilemma that you cannot have everything you want to know about something in a single place. What you want to know about something is different from what person X wants/needs to know. And what you need to know today is different from what you need tomorrow. This is still a problem even if you are dealing with only a single, local manual that is self-contained as a whole (contains all of the info on its subject). You might want to see one organization into manual sections and person X might want to see a different organization. And for you alone, the optimal organization might be different today (looking for info on some topic) from tomorrow (looking with a different eye). IOW, there are *trade-offs*. People dealing with documentation professsionally deal with such trade-offs everyday - it's a significant part of what they do. Of course, there are trade-offs that many users might agree are reasonably good ones, and there are trade-offs that many would agree are poor ones. Picking an extremely poor documention organization as your example does not invalidate the fact that trade-offs are always required. > I've never subscribed to the theory that just because a feature is > described on some web page out there, and not in the official manual, > that it's "documented". Why people want to see this as the success of > the internet rather than as a failure of the documentation is > beyond me. No one mentioned "some web page out there". You are simply arguing about a straw man. The point is that Common Lisp has a standard definition (at least one!), and the language is documented. To the extent that Emacs supports some or all of that standard to various degrees, the Emacs documentation needs to: 1. Be clear about that support, specifying which CL standard is supported and specifying exactly any divergences from that standard. 2. Give clear guidance about any Emacs-specific uses of particular features from that standard. That does not imply that the *Emacs* doc needs to reproduce, in addition, a complete documentation of the standard language that it (more or less) supports. That's the point of having a standard that can be referenced. Nothing prevents the Emacs doc from giving examples and explanation of how to use particular Common Lisp constructs in an Emacs environment. Quite the contrary. > Keep the information itself in one place It's a wonderfully naive idea. Get involved with documenting something (non-trivial) and you will soon discover the trade-offs. Keeping X "in one place" begs the question of what X is, how much X encompasses, and what point of view X is regarded from (audience background, audience quest/need). > that I can put on a tablet as a PDF, or print out and take with > me on an overnight. Not everyone reads their docs from within > Emacs all of the time. > > For what it's worth. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-15 6:01 ` David Kastrup 2010-04-15 6:54 ` Drew Adams @ 2010-04-15 7:21 ` christian.lynbech 2010-04-15 7:36 ` David Kastrup 1 sibling, 1 reply; 149+ messages in thread From: christian.lynbech @ 2010-04-15 7:21 UTC (permalink / raw To: David Kastrup; +Cc: emacs-devel@gnu.org >>>>> "David" == David Kastrup <dak@gnu.org> writes: David> The manuals of an editor with a user-accessible extension language (with David> Emacs, this is the case for Elisp but not for C) need to document this David> extension language. Of course, but there is no reason why this information cannot be split across several manuals and having the CL parts be documented by respectively the CL standard (eg. the hyperspec) and whatever other documentation exists for the CL implementation chosen to host emacs. The documentation must be accessible but this is not the same as the emacs maintainers need to (re)write all of it nor that it necessarily must be put into one particular (already somewhat unwieldy) document. ------------------------+----------------------------------------------------- Christian Lynbech | christian #\@ defun #\. dk ------------------------+----------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic) ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-15 7:21 ` christian.lynbech @ 2010-04-15 7:36 ` David Kastrup 2010-04-15 8:34 ` christian.lynbech 0 siblings, 1 reply; 149+ messages in thread From: David Kastrup @ 2010-04-15 7:36 UTC (permalink / raw To: emacs-devel <christian.lynbech@tieto.com> writes: >>>>>> "David" == David Kastrup <dak@gnu.org> writes: > > David> The manuals of an editor with a user-accessible extension > David> language (with Emacs, this is the case for Elisp but not for C) > David> need to document this extension language. > > Of course, but there is no reason why this information cannot be split > across several manuals and having the CL parts be documented by > respectively the CL standard (eg. the hyperspec) and whatever other > documentation exists for the CL implementation chosen to host emacs. Did you bother to read my posting to its end before replying to the first sentence? I should think that I already addressed this. -- David Kastrup ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-15 7:36 ` David Kastrup @ 2010-04-15 8:34 ` christian.lynbech 2010-04-15 9:06 ` David Kastrup 0 siblings, 1 reply; 149+ messages in thread From: christian.lynbech @ 2010-04-15 8:34 UTC (permalink / raw To: David Kastrup; +Cc: emacs-devel@gnu.org >>>>> "David" == David Kastrup <dak@gnu.org> writes: David> Did you bother to read my posting to its end before replying to the David> first sentence? I should think that I already addressed this. My apologies if I have misunderstood something; I did read all of the mail. You wrote in the second paragraph: > Otherwise, only programmers can be expected to be able to use it. One > reason for that is that non-Emacs specific Lisp manuals will not focus > about how to get things done with Emacs. Applying a manual utterly > without editing focus to editing tasks is quite a large intellectual > feat. I would imagine that the system came with several manuals, a generic one for common lisp (for instance the hyperspec) and a more emacs specific one for the editing libraries (such as the buffer related functions). Why would it make a big difference whether (say) `loop' and `current-buffer' appear in different manuals as long as both are available in the system and there are some appropriate top-level index/search/contents/reading-guide support for the user? It is even possible in some distant future that one would like to unbundle some of the core emacs functionality (again take the buffer functions as somewhat poor example) into standalone libraries that could be made available to other applications supporting the same extension language. In that case one would actually want to split up the current emacs lisp manual into separate manuals that could accompany the respective libraries. ------------------------+----------------------------------------------------- Christian Lynbech | christian #\@ defun #\. dk ------------------------+----------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic) ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-15 8:34 ` christian.lynbech @ 2010-04-15 9:06 ` David Kastrup 2010-04-15 9:45 ` Helmut Eller 2010-04-15 10:39 ` christian.lynbech 0 siblings, 2 replies; 149+ messages in thread From: David Kastrup @ 2010-04-15 9:06 UTC (permalink / raw To: emacs-devel <christian.lynbech@tieto.com> writes: >>>>>> "David" == David Kastrup <dak@gnu.org> writes: > > David> Did you bother to read my posting to its end before replying to the > David> first sentence? I should think that I already addressed this. > > My apologies if I have misunderstood something; I did read all of the > mail. > > You wrote in the second paragraph: > >> Otherwise, only programmers can be expected to be able to use it. One >> reason for that is that non-Emacs specific Lisp manuals will not focus >> about how to get things done with Emacs. Applying a manual utterly >> without editing focus to editing tasks is quite a large intellectual >> feat. > > I would imagine that the system came with several manuals, a generic > one for common lisp (for instance the hyperspec) and a more emacs > specific one for the editing libraries (such as the buffer related > functions). > > Why would it make a big difference whether (say) `loop' and > `current-buffer' appear in different manuals as long as both are > available in the system and there are some appropriate top-level > index/search/contents/reading-guide support for the user? Because the language specific manual would have no constructs and no examples using any editor-specific data structures or any editor-specific tasks. But that's actually more or less a paraphrase of the "Otherwise, [...]" paragraph above again. I don't see anything in your reply that would address that. -- David Kastrup ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-15 9:06 ` David Kastrup @ 2010-04-15 9:45 ` Helmut Eller 2010-04-15 10:39 ` christian.lynbech 1 sibling, 0 replies; 149+ messages in thread From: Helmut Eller @ 2010-04-15 9:45 UTC (permalink / raw To: emacs-devel * David Kastrup [2010-04-15 11:06+0200] writes: > <christian.lynbech@tieto.com> writes: > >>>>>>> "David" == David Kastrup <dak@gnu.org> writes: >> >> David> Did you bother to read my posting to its end before replying to the >> David> first sentence? I should think that I already addressed this. >> >> My apologies if I have misunderstood something; I did read all of the >> mail. >> >> You wrote in the second paragraph: >> >>> Otherwise, only programmers can be expected to be able to use it. One >>> reason for that is that non-Emacs specific Lisp manuals will not focus >>> about how to get things done with Emacs. Applying a manual utterly >>> without editing focus to editing tasks is quite a large intellectual >>> feat. >> >> I would imagine that the system came with several manuals, a generic >> one for common lisp (for instance the hyperspec) and a more emacs >> specific one for the editing libraries (such as the buffer related >> functions). >> >> Why would it make a big difference whether (say) `loop' and >> `current-buffer' appear in different manuals as long as both are >> available in the system and there are some appropriate top-level >> index/search/contents/reading-guide support for the user? > > Because the language specific manual would have no constructs and no > examples using any editor-specific data structures or any > editor-specific tasks. > > But that's actually more or less a paraphrase of the "Otherwise, [...]" > paragraph above again. I don't see anything in your reply that would > address that. Guile supposedly supports multiple languages, like Scheme, Python and Javascript. So who writes the manual for Python and Javascript? Helmut ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-15 9:06 ` David Kastrup 2010-04-15 9:45 ` Helmut Eller @ 2010-04-15 10:39 ` christian.lynbech 1 sibling, 0 replies; 149+ messages in thread From: christian.lynbech @ 2010-04-15 10:39 UTC (permalink / raw To: David Kastrup; +Cc: emacs-devel@gnu.org >>>>> "David" == David Kastrup <dak@gnu.org> writes: David> Because the language specific manual would have no constructs and David> no examples using any editor-specific data structures or any David> editor-specific tasks. Ah, now I begin to see more clearly what you are talking about (I think). However, I am not really sure I understand why this is a problem. In the editing library part of the manual, one could include the necessary examples of how to express one self in the language related to that feature. I do not see why, say, the description of `defun' or `loop' necessarily need to use editing related examples. The description of the core language will, IMHO, only really make sense to programmers anyway. Non-programmers will (even today) find some relevant code snippet, search for the relevant editing function and apply some patterne matching between the examples there and the code snippet. I doubt they will be anymore compelled to learn the language just because examples have an editing focus. I am also not entirely sure just how closely coupled the current manuals are to the editing context. If one flips through the first dozen pages of the emacs lisp introduction, there is nothing related to editing. Flipping through the control structures chapter in the emacs lisp reference manual shows a similar pattern. Most of those examples uses `print'/`princ' rather than `insert'. This is obviously not a thorough review of all of the manuals, but I am unconvinced that the current manual could not be separated into a language part and an editing library part with good effects if need be. We will anyway have the same problem with Guile, I think. One of the advantages of Guile is precisely that it is an independent piece of software on which a future emacs will be based, among other applications which also uses Guile. I would expect Guile to have, and to continue to have, its own manual. Whether this will include (in an integrated way) contents equivalent to the relevant RxRS standards or just point to them and focus on documenting the differences/extensions (as some CL implementation do with the hyperspec) I do not know, but surely it will be prudent for the Guile manual to be selfcontained and not littered with examples that only makes sense in an emacs context. Even though scheme is smaller than CL, and it could very well be that even Guile is significantly smaller than some CL implementations, I hope that the emacs maintainers would not opt to *duplicate* the Guile documentation simply for the sake of being able to provide a version with a more editing focus. ------------------------+----------------------------------------------------- Christian Lynbech | christian #\@ defun #\. dk ------------------------+----------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic) ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-15 3:52 ` Drew Adams 2010-04-15 6:01 ` David Kastrup @ 2010-04-15 18:47 ` Richard Stallman 2010-04-15 22:42 ` Harald Hanche-Olsen 2010-04-15 23:02 ` Helmut Eller 1 sibling, 2 replies; 149+ messages in thread From: Richard Stallman @ 2010-04-15 18:47 UTC (permalink / raw To: Drew Adams Cc: bruce.stephens, lord, emacs-devel, christian, christian.lynbech The Elisp manual would not need to document things that are vanilla Common Lisp (i.e. respect the CL standard). It could simply cross-reference the relevant CL doc. Do we have a good quality free Common Lisp manual? ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-15 18:47 ` Richard Stallman @ 2010-04-15 22:42 ` Harald Hanche-Olsen 2010-04-15 22:50 ` Harald Hanche-Olsen 2010-04-15 23:02 ` Helmut Eller 1 sibling, 1 reply; 149+ messages in thread From: Harald Hanche-Olsen @ 2010-04-15 22:42 UTC (permalink / raw To: rms; +Cc: emacs-devel + Richard Stallman <rms@gnu.org>: > Do we have a good quality free Common Lisp manual? Unfortunately, assuming the GNU definition of "free", I am afraid the answer is no. You can read the copyright notice here: http://www.lispworks.com/documentation/HyperSpec/Front/Help.htm#Legal - Harald ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-15 22:42 ` Harald Hanche-Olsen @ 2010-04-15 22:50 ` Harald Hanche-Olsen 2010-04-17 4:40 ` Richard Stallman 0 siblings, 1 reply; 149+ messages in thread From: Harald Hanche-Olsen @ 2010-04-15 22:50 UTC (permalink / raw To: rms; +Cc: emacs-devel + Harald Hanche-Olsen <hanche@math.ntnu.no>: > You can read the copyright notice here: > > http://www.lispworks.com/documentation/HyperSpec/Front/Help.htm#Legal Of course, I meant to say the copyright notice of the HyperSpec. But as far as I know, it is the only high quality reference that is available for free (as in free beer), apart from Common Lisp the Language 2nd ed (http://www.cs.cmu.edu/Groups/AI/html/cltl/cltl2.html), whose license is not explicitly stated anywhere I can see. Besides, it predates the CL standard, so it may be partially outdated. - Harald ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-15 22:50 ` Harald Hanche-Olsen @ 2010-04-17 4:40 ` Richard Stallman 0 siblings, 0 replies; 149+ messages in thread From: Richard Stallman @ 2010-04-17 4:40 UTC (permalink / raw To: Harald Hanche-Olsen; +Cc: emacs-devel apart from Common Lisp the Language 2nd ed (http://www.cs.cmu.edu/Groups/AI/html/cltl/cltl2.html), whose license is not explicitly stated anywhere I can see. If it has no language, that means copying and modification are prohibited by copyright law. If you can find the authors, maybe we can convince them to free it. it predates the CL standard, so it may be partially outdated. Updating it is surely much easier than starting from scratch. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-15 18:47 ` Richard Stallman 2010-04-15 22:42 ` Harald Hanche-Olsen @ 2010-04-15 23:02 ` Helmut Eller 2010-04-17 4:40 ` Richard Stallman 1 sibling, 1 reply; 149+ messages in thread From: Helmut Eller @ 2010-04-15 23:02 UTC (permalink / raw To: emacs-devel * Richard Stallman [2010-04-15 20:47+0200] writes: > The Elisp manual would not need to document things that are > vanilla Common Lisp (i.e. respect the CL standard). It could > simply cross-reference the relevant CL doc. > > Do we have a good quality free Common Lisp manual? The Tex sources of the "draft" of the ANSI standard are available on the net[1]. I'm pretty sure that's the same text as the actual standard. Bill Schelter used that to create an info version for GCL[2] and that is also in the Debian package gclcvs-doc. Independently, Jesper Harder wrote some ELisp code[3] to convert the Tex code to texinfo which tries to preserve more of the font information and cross references. The legal status of the Tex sources seems a bit messy, though. Apparently the intention of the involved parties was to put them into Public Domain but somehow failed to make that formally correct[4]. Helmut [1] http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/doc/standard/ansi/0.html [2] ftp://ftp.ma.utexas.edu/pub/gcl/gcl-info+texi.tgz [3] http://www.phys.au.dk/~harder/dpans.html [4] http://lists.debian.org/debian-legal/2004/06/msg00492.html ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-15 23:02 ` Helmut Eller @ 2010-04-17 4:40 ` Richard Stallman 2010-04-17 6:46 ` Helmut Eller 0 siblings, 1 reply; 149+ messages in thread From: Richard Stallman @ 2010-04-17 4:40 UTC (permalink / raw To: Helmut Eller; +Cc: emacs-devel The Tex sources of the "draft" of the ANSI standard are available on the net[1]. What license do they carry? The legal status of the Tex sources seems a bit messy, though. Apparently the intention of the involved parties was to put them into Public Domain but somehow failed to make that formally correct[4]. Can you boil down the facts they found and state them concisely? ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-17 4:40 ` Richard Stallman @ 2010-04-17 6:46 ` Helmut Eller 2010-04-17 19:55 ` Richard Stallman 0 siblings, 1 reply; 149+ messages in thread From: Helmut Eller @ 2010-04-17 6:46 UTC (permalink / raw To: emacs-devel * Richard Stallman [2010-04-17 06:40+0200] writes: > The Tex sources of the "draft" of the ANSI standard are available on the > net[1]. > > What license do they carry? Apparently none. The only paragraph containing the word "copyright" is this: Special thanks to Guy L. Steele Jr. and Digital Press for producing {\CLtL}, and for relaxing copyright restrictions enough to make it possible for that document's text to provide an early basis of this work. > > The legal status of the Tex sources seems a bit messy, though. > Apparently the intention of the involved parties was to put them into > Public Domain but somehow failed to make that formally correct[4]. > > Can you boil down the facts they found and state them concisely? At least in this thread, the Debian people didn't find any facts and only stated that some lawyer would be needed to clarify the issues. On another message board[1] Peter Seibel summarized the situation: So here's some info that I got from Steve Haflich of Franz and onetime chair of XJ13, the committee that brought us the ANSI Standard. (This is from a conversation we had standing in the lobby of the Franz office building; I wasn't taking notes. Caveat Lector.) - At some point in the standardization process it became apparent that there was a bunch of editorial work to be done and no one to do it and no funding to pay someone to do it. - Various organizations involved in the standardization such as Franz, Symbolics, Harlequin, Apple, and others decided that they would each contract with Symbolics to pay for a Symbolic's employee, Kent Pitman, to produce a draft standard which he would then "give" to ANSI to do with whatever they wished. - All these organizations agreed that they would place the work (to which they held copyright since they were paying Symbolics to do it as a work for hire) into the public domain. Except some lawyer pointed out that you can't really affirmatively put something in the public domain. So they did something--not clear what--to assert their copyright but to allow anyone to use the draft they were paying to have produced for any purpose whatsoever. - That draft is the so-called dpANS2. - ANSI took the dpANS2 and made a few minor copy edits, slapped on their logo and some front matter, and published it as the ANSI standard. - Kent Pitman, then at Harlequin then used the dpANS2 as the basis for the HyperSpec. Franz similarly used it to make their HTML version. Pitman also fought with ANSI to get permission to do something (not clear exactly what) beyond what he would have been allowed to do with dpANS2. - I'm pretty sure Harlequin (or Xanalys or Lispworks) owns the copyright to the HyperSpec. - The issue of copyright on dpANS2 is muddied by the fact that it includes big chunks of text that were written by Guy Steele for CLTL. He, according to Haflich, donated that text to ANSI to use in the standard but it's not clear that the folks (i.e. those companies) that produced the dpANS actually had the right to use it. Obviously, from a practical point of view, he and Digital Press, publishers of CLTL2, haven't been bothered by the fact that their text is in the HyperSpec and the dpANS, etc. but technically they could probably make a stink. (Though maybe Pitman actually cleared that with them-- he seems to make a point of being pretty scrupulous about intellectual property issues.) - The issue of copyright on dpANS2 is also muddied by the many small contributions of text by other people who participated in the standardization process. So, to answer Don's question, probably not. If one wanted to take the text of dpANS2 and use it for the basis of a derived work (say an annotated version), and you wanted to be incredibly scrupulous about making sure you weren't stepping on anyone's copyrights, you'd probably need to track down the contracts wherein the companies that funded the dpANS2 "licensed" it for use by anyone for any purpose. Then you'd probably want to talk to Guy Steele and/or Digital Press. And for good measure the known authors of any of the sections of the dpANS2 that were written by someone else (e.g. Dick Waters, I believe, wrote large chunks of the section on the pretty printer since he invented it.) Then, if you really wanted to nail things down, you'd probably need to contact the 100 or so folks who participated in the standardization and who may have contributed text. But probably the right and most efficient thing to do is to find a good IP lawyer and tell them what, specifically you want to do, and ask them to help you figure out what you need to do to make sure you're not exposing yourself to excessive liability by doing it. -Peter I don't know how Pitman "asked" ANSI for permission he only writes this in the HyperSpec: Parts of this work incorporate material taken from American National Standard X3.226, copyright 1994, and is used with permission of the X3 Secretariat, ITI, 1250 Eye St., NW., Suite 200, Washington, DC 20005 and of the copyright holder, American National Standards Institute. ANSI/X3.226 was developed by Technical Committee X3J13, Common Lisp. Helmut [1] http://www.mail-archive.com/gardeners@lispniks.com/msg00189.html ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-17 6:46 ` Helmut Eller @ 2010-04-17 19:55 ` Richard Stallman 0 siblings, 0 replies; 149+ messages in thread From: Richard Stallman @ 2010-04-17 19:55 UTC (permalink / raw To: Helmut Eller; +Cc: emacs-devel > The Tex sources of the "draft" of the ANSI standard are available on the > net[1]. > > What license do they carry? Apparently none. The only paragraph containing the word "copyright" is this: Special thanks to Guy L. Steele Jr. and Digital Press for producing {\CLtL}, and for relaxing copyright restrictions enough to make it possible for that document's text to provide an early basis of this work. Unless they state a license elsewhere, they are not free. - All these organizations agreed that they would place the work (to which they held copyright since they were paying Symbolics to do it as a work for hire) into the public domain. Except some lawyer pointed out that you can't really affirmatively put something in the public domain. You can in the US, according to my lawyers. So they did something--not clear what--to assert their copyright but to allow anyone to use the draft they were paying to have produced for any purpose whatsoever. That would be tantamout to granting a license. If we can find the statement they made, it might be adequate. I will ask GLS if he can do anything about this. However, unless you hear about something that changes the situation, you may as well give up on that text. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-14 5:02 ` Richard Stallman 2010-04-14 6:45 ` christian.lynbech @ 2010-04-14 13:30 ` John Wiegley 2010-04-14 14:18 ` Helmut Eller 2010-04-14 15:40 ` Tom Tromey 1 sibling, 2 replies; 149+ messages in thread From: John Wiegley @ 2010-04-14 13:30 UTC (permalink / raw To: rms; +Cc: bruce.stephens, lord, Christian Lynbech, emacs-devel On Apr 14, 2010, at 1:02 AM, Richard Stallman wrote: > Common Lisp is extremely complicated and ugly. When I wrote GNU Emacs > I had just finished implementing Common Lisp, and I did not like it > much. It would bloat Emacs terribly, and documenting it would be hard > too. Do you mean the libraries are? Because the core syntax of CL is pretty simple. Also, with Scheme there are several core semantic differences from Emacs Lisp: a) It's a Lisp-1, and b) the difference between nil, () and #f. Those two right there can make porting any significant Emacs application extremely difficult. As for Common Lisp -- or let's say, a functional subset for the purpose of making it an Emacs extension language -- if, as some suggest, it's worthwhile to ignore existing code and start afresh, why isn't a project like CLmacs more interesting? It's very Emacs like, but lacks all the useful libraries which make Emacs what it is. Personally I think adopting a new internal language for Emacs, just so GNU can have a common scripting language, is somewhat ludicrous. Emacs Lisp has proven itself to be incredibly useful, as shown by the enormous number of contributors and extensive library of code -- some of which has seen extensive usage for a decade or more now. It may have its warts, but so will any system by the time its use\x01rs are done with it. Lastly, I'm not at all convinced Emacs Lisp needs multithreading. I would prefer a coarser model of process separation to allow things like Gnus to run in tandem with other tasks. It would be nice if a wholly separate process could connect to the frames/windows/buffers (but not symbol space) of a master Emacs process. I was just considering yesterday the truly scary-to-debug scenarios that come up when you realize dynamic variables can change mid-form, or that hooks might run while other hooks are executing. There is so much code that depends on sequence of execution that I think multithreading could cause us stability headaches for years and years. John ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-14 13:30 ` John Wiegley @ 2010-04-14 14:18 ` Helmut Eller 2010-04-14 15:40 ` Tom Tromey 1 sibling, 0 replies; 149+ messages in thread From: Helmut Eller @ 2010-04-14 14:18 UTC (permalink / raw To: emacs-devel * John Wiegley [2010-04-14 15:30+0200] writes: > Lastly, I'm not at all convinced Emacs Lisp needs multithreading. I > would prefer a coarser model of process separation to allow things > like Gnus to run in tandem with other tasks. It would be nice if a > wholly separate process could connect to the frames/windows/buffers > (but not symbol space) of a master Emacs process. I was just > considering yesterday the truly scary-to-debug scenarios that come up > when you realize dynamic variables can change mid-form, or that hooks > might run while other hooks are executing. There is so much code that > depends on sequence of execution that I think multithreading could > cause us stability headaches for years and years. Amen. Also consider that all the web browsers move away from multithreading and use processes these days. Good that Emacs is so slow at adapting new techologies; maybe we can take a shortcut this time and skip the multithreading dead-end :-) Helmut ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-14 13:30 ` John Wiegley 2010-04-14 14:18 ` Helmut Eller @ 2010-04-14 15:40 ` Tom Tromey 1 sibling, 0 replies; 149+ messages in thread From: Tom Tromey @ 2010-04-14 15:40 UTC (permalink / raw To: John Wiegley; +Cc: bruce.stephens, lord, Christian Lynbech, rms, emacs-devel John> Lastly, I'm not at all convinced Emacs Lisp needs multithreading. John> I would prefer a coarser model of process separation to allow John> things like Gnus to run in tandem with other tasks. I did consider this model. I even floated the idea on this list, though as I recall nobody replied. One thing worth noting is that you can experiment with this approach right now. I haven't tried but I think you can do it purely in elisp with no emacs changes required. Give it a try. If it is a better model, well, great, let's use it. John> I was just considering yesterday the truly scary-to-debug John> scenarios that come up when you realize dynamic variables can John> change mid-form That is true, but due to the nature of actually existing Emacs code I don't think it will be a problem in practice. Also: (1) this cannot happen with let-bound variables, only globals; and (2) this can already happen today via process filters (in limited scenarios, to be sure -- but the threading is cooperative, so the same applies). Tom ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-13 19:13 ` Christian Lynbech 2010-04-14 1:47 ` Thomas Lord 2010-04-14 5:02 ` Richard Stallman @ 2010-04-14 7:51 ` David Kastrup 2010-04-14 8:42 ` christian.lynbech ` (2 more replies) 2 siblings, 3 replies; 149+ messages in thread From: David Kastrup @ 2010-04-14 7:51 UTC (permalink / raw To: emacs-devel Christian Lynbech <christian@defun.dk> writes: >>>>>> "Thomas" == Thomas Lord <lord@emf.net> writes: > >>> Wouldn't it be about as good (and probably less work), to give up on the >>> guile idea and evolve emacs lisp (with Miles's lexical-bind changes, and >>> (one hopes) multithreading, and maybe other things)? > > Thomas> I dunno. Maybe. I'd guess that, no, that's not a > Thomas> good strategy. Four reasons come quickly to mind: ... > > Wouldn't a reasonable alternative to using a scheme implementation be to > use a Common Lisp ditto? And wouldn't that be a much closer fit > semantically to the current Emacs Lisp dialect? Emacs Lisp is streamlined for editing. Common Lisp has its own focus. For an extension language, it is preferable to have a system where you can read through the manual in one day and basically understand it. Scheme is a smaller starting point than Common Lisp. -- David Kastrup ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-14 7:51 ` David Kastrup @ 2010-04-14 8:42 ` christian.lynbech 2010-04-14 9:55 ` immanuel litzroth 2010-04-14 15:47 ` Tom Tromey 2 siblings, 0 replies; 149+ messages in thread From: christian.lynbech @ 2010-04-14 8:42 UTC (permalink / raw To: David Kastrup; +Cc: emacs-devel@gnu.org >>>>> "David" == David Kastrup <dak@gnu.org> writes: David> Emacs Lisp is streamlined for editing. Common Lisp has its own focus. You could say the same of Scheme. I am also not quite sure I understand how Emacs Lisp as such is streamlined for editing. Sure there are a bunch of libraries, for instance for handling buffers, but I think of that as a library and not really an integral part of the language. Whatever the solution, we will always have an `current-buffer' function. David> For an extension language, it is preferable to have a system where you David> can read through the manual in one day and basically understand it. Well, that is not exactly wrong, but I would maintain that you can write a Common Lisp tutorial that you could read through and understand in a day as easily as you can for Scheme or the current Emacs Lisp. Much of what is in the Common Lisp standard has the character of libraries; you need not understand pathnames or CLOS to get started writing functions. Wrt. libraries you will anyway be in for a lifelong journey, adding a handfull on top of what is already in Emacs will not drastically change that. ------------------------+----------------------------------------------------- Christian Lynbech | christian #\@ defun #\. dk ------------------------+----------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic) ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-14 7:51 ` David Kastrup 2010-04-14 8:42 ` christian.lynbech @ 2010-04-14 9:55 ` immanuel litzroth 2010-04-14 10:28 ` christian.lynbech ` (2 more replies) 2010-04-14 15:47 ` Tom Tromey 2 siblings, 3 replies; 149+ messages in thread From: immanuel litzroth @ 2010-04-14 9:55 UTC (permalink / raw To: David Kastrup; +Cc: emacs-devel > Emacs Lisp is streamlined for editing. Common Lisp has its own focus. Common Lisp doesn't have a focus that I am aware of. It is the language that is most close to Emacs Lisp syntactically, and most emacs code that doesn't have editor specific stuff will run in Common Lisp & vice versa. > For an extension language, it is preferable to have a system where you > can read through the manual in one day and basically understand it The effort to "basically" understand CL is the same as the for scheme. Moreover scheme has some exotic stuff like hygienic macros and continuations which are not stuff you "basically understand in a day". > Scheme is a smaller starting point than Common Lisp. So with a common lisp system you get: 1) compilation to machine code 2) standardized implementation of classes 3) structures, hashes 4) Exceptions With a scheme system you get 1) call-with-current-continuation Moreover if you really like emacs based on scheme why not go for edwin? Immanuel ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-14 9:55 ` immanuel litzroth @ 2010-04-14 10:28 ` christian.lynbech 2010-04-14 11:25 ` Stephen J. Turnbull 2010-04-14 11:23 ` Jeff Clough 2010-04-14 13:11 ` Stephen Eilert 2 siblings, 1 reply; 149+ messages in thread From: christian.lynbech @ 2010-04-14 10:28 UTC (permalink / raw To: immanuel litzroth; +Cc: David Kastrup, emacs-devel@gnu.org >>>>> immanuel litzroth <ilitzroth@gmail.com> writes: >> Scheme is a smaller starting point than Common Lisp. > So with a common lisp system you get: > 1) compilation to machine code > 2) standardized implementation of classes > 3) structures, hashes > 4) Exceptions > With a scheme system you get > 1) call-with-current-continuation This is probably a little unfair to Scheme. I do not know where the latest scheme standard is wrt. OO and exceptions but many concrete implementations will have solutions for most of this. Again, in practice, there just is a bunch of stuff you need and whether you put it into the standard or bolt it onto your concrete implementation is not all that important. There are also scheme implementation that compile to native code and although Guile isn't among them, it has a reasonable enough performance on modern hardware that you for instance can successfully run a window manager implemented in Guile (which I did for a couple of years). ------------------------+----------------------------------------------------- Christian Lynbech | christian #\@ defun #\. dk ------------------------+----------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic) ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-14 10:28 ` christian.lynbech @ 2010-04-14 11:25 ` Stephen J. Turnbull 2010-04-14 12:26 ` christian.lynbech 0 siblings, 1 reply; 149+ messages in thread From: Stephen J. Turnbull @ 2010-04-14 11:25 UTC (permalink / raw To: christian.lynbech; +Cc: immanuel litzroth, David Kastrup, emacs-devel@gnu.org christian.lynbech@tieto.com writes: > There are also scheme implementation that compile to native code and > although Guile isn't among them, it has a reasonable enough performance > on modern hardware that you for instance can successfully run a window > manager implemented in Guile (which I did for a couple of years). That's hardly a recommendation -- window managers are not very demanding of performance. Heck, you can run a window manager (xwem) implemented in Emacs Lisp (which in turn is based on X protocol implemented in Emacs Lisp -- xlib). Several SXEmacs guys do. (Not to mention anybody running sawfish -- librepl was basically Emacs Lisp on Ritalin.) ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-14 11:25 ` Stephen J. Turnbull @ 2010-04-14 12:26 ` christian.lynbech 2010-04-14 16:49 ` Ken Raeburn 0 siblings, 1 reply; 149+ messages in thread From: christian.lynbech @ 2010-04-14 12:26 UTC (permalink / raw To: Stephen J. Turnbull; +Cc: immanuel litzroth, David Kastrup, emacs-devel@gnu.org >>>>> "Stephen" == Stephen J Turnbull <stephen@xemacs.org> writes: Stephen> That's hardly a recommendation -- window managers are not very Stephen> demanding of performance. True, though one could argue that anything that sits between you and your windows will be very visible if there is even the slightest lag. Anyway, I just wanted to say that the performance issues of Guile is not the most overwhelming problem we face (and I haven't touched Guile in years so I do not actually know how it competes these days). I am certainly prepared to believe that Guile is faster than the current Emacs Lisp engine but I am also absolutely convinced that unless it has improved radically it will fall noticeably behind systems that compiles to native code, whether directly or via C. ------------------------+----------------------------------------------------- Christian Lynbech | christian #\@ defun #\. dk ------------------------+----------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic) ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-14 12:26 ` christian.lynbech @ 2010-04-14 16:49 ` Ken Raeburn 2010-04-14 18:29 ` Tom Tromey 0 siblings, 1 reply; 149+ messages in thread From: Ken Raeburn @ 2010-04-14 16:49 UTC (permalink / raw To: <christian.lynbech@tieto.com>; +Cc: emacs-devel@gnu.org discussions On Apr 14, 2010, at 08:26, <christian.lynbech@tieto.com> <christian.lynbech@tieto.com> wrote: > I am certainly prepared to believe that Guile is faster than the current > Emacs Lisp engine I have no idea if that's true, at the moment. > but I am also absolutely convinced that unless it has > improved radically If you haven't used it in a while, it may have -- the current development version uses a byte code engine for execution, which I believe has sped most stuff up quite a bit. > it will fall noticeably behind systems that compiles > to native code, whether directly or via C. Both approaches are getting serious consideration from the current Guile developers. Ken ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-14 16:49 ` Ken Raeburn @ 2010-04-14 18:29 ` Tom Tromey 2010-04-14 20:02 ` Ken Raeburn 0 siblings, 1 reply; 149+ messages in thread From: Tom Tromey @ 2010-04-14 18:29 UTC (permalink / raw To: Ken Raeburn Cc: emacs-devel@gnu.org discussions, <christian.lynbech@tieto.com> >>>>> "Ken" == Ken Raeburn <raeburn@raeburn.org> writes: >> it will fall noticeably behind systems that compiles >> to native code, whether directly or via C. Ken> Both approaches are getting serious consideration from the current Ken> Guile developers. FWIW, there was once an elisp JIT compiler. http://www.mundell.ukfsn.org/native/ It was rejected: http://lists.gnu.org/archive/html/emacs-devel/2004-06/msg00103.html Tom ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-14 18:29 ` Tom Tromey @ 2010-04-14 20:02 ` Ken Raeburn 0 siblings, 0 replies; 149+ messages in thread From: Ken Raeburn @ 2010-04-14 20:02 UTC (permalink / raw To: Tom Tromey Cc: emacs-devel@gnu.org discussions, <christian.lynbech@tieto.com> On Apr 14, 2010, at 14:29, Tom Tromey wrote: > FWIW, there was once an elisp JIT compiler. > It was rejected: Interesting! I'd wondered if there'd be anything to gain from doing that, but stopped short of actually trying it myself. I'm glad to see someone else has tried it, even if the conclusion from the experiment was that it wasn't worth folding in. Actually, I'd been thinking about converting byte-code to C, changing stack slots to register variables, that sort of thing, and turning GCC's optimizer loose on it, but I doubt it'd perform all that much better than the JIT version if the primitives were dominating. Thanks for the links! Ken ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-14 9:55 ` immanuel litzroth 2010-04-14 10:28 ` christian.lynbech @ 2010-04-14 11:23 ` Jeff Clough 2010-04-14 13:11 ` Stephen J. Turnbull 2010-04-14 13:11 ` Stephen Eilert 2 siblings, 1 reply; 149+ messages in thread From: Jeff Clough @ 2010-04-14 11:23 UTC (permalink / raw To: emacs-devel It seems I've lost track of this conversation. Is this a purely hypothetical discussion, or is it to be expected that some relatively near future version of Emacs will be Guile-based? For what it's worth, as someone who's used Emacs for years but only got into Lisp a couple of months ago... I can see this as a good thing for people who'd like a more "modern" Lisp with their Emacs (and a consistent, "core" extension language across GNU), but a bad thing for people relying on a large, complex application maintained by a single busy guy. Emacs Lisp supports such a grow-it-as-you-need-it development approach that a lot of stuff out there was built a few lines at a time over months or years. Expecting the author of an application like that to carve out a chunk of time for a complete re-write might be asking too much. Jeff ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-14 11:23 ` Jeff Clough @ 2010-04-14 13:11 ` Stephen J. Turnbull 0 siblings, 0 replies; 149+ messages in thread From: Stephen J. Turnbull @ 2010-04-14 13:11 UTC (permalink / raw To: Jeff Clough; +Cc: emacs-devel Jeff Clough writes: > Expecting the author of an application like that to carve out a > chunk of time for a complete re-write might be asking too much. Mike Sperber supervised a student at U. Tuebingen who wrote a proof-of-concept Emacs Lisp system in Scheme48, with quite reasonable performance characteristics for a student project. His estimate was that performance equivalent to existing bytecode of the time was achievable with reasonable effort. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-14 9:55 ` immanuel litzroth 2010-04-14 10:28 ` christian.lynbech 2010-04-14 11:23 ` Jeff Clough @ 2010-04-14 13:11 ` Stephen Eilert 2010-04-14 13:49 ` Helmut Eller 2 siblings, 1 reply; 149+ messages in thread From: Stephen Eilert @ 2010-04-14 13:11 UTC (permalink / raw To: immanuel litzroth; +Cc: David Kastrup, emacs-devel On Wed, Apr 14, 2010 at 6:55 AM, immanuel litzroth <ilitzroth@gmail.com> wrote: >> Emacs Lisp is streamlined for editing. Common Lisp has its own focus. > Common Lisp doesn't have a focus that I am aware of. It is the language > that is most close to Emacs Lisp syntactically, and most emacs code that > doesn't have editor specific stuff will run in Common Lisp & vice versa. > >> For an extension language, it is preferable to have a system where you >> can read through the manual in one day and basically understand it > The effort to "basically" understand CL is the same as the for scheme. Moreover > scheme has some exotic stuff like hygienic macros and continuations which are > not stuff you "basically understand in a day". > >> Scheme is a smaller starting point than Common Lisp. > So with a common lisp system you get: > 1) compilation to machine code > 2) standardized implementation of classes > 3) structures, hashes > 4) Exceptions > With a scheme system you get > 1) call-with-current-continuation > And who said you won't get native code, classes, structures, hashes and exceptions with scheme? They are just not documented in R5RS (let's forget R6RS ever existed). Most scheme implementations have these features, they are not portable however. Which is hardly a concern for Guile and Emacs Guile. --Stephen programmer, n: A red eyed, mumbling mammal capable of conversing with inanimate monsters. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-14 13:11 ` Stephen Eilert @ 2010-04-14 13:49 ` Helmut Eller 0 siblings, 0 replies; 149+ messages in thread From: Helmut Eller @ 2010-04-14 13:49 UTC (permalink / raw To: emacs-devel * Stephen Eilert [2010-04-14 15:11+0200] writes: > On Wed, Apr 14, 2010 at 6:55 AM, immanuel litzroth <ilitzroth@gmail.com> wrote: >>> Emacs Lisp is streamlined for editing. Â Common Lisp has its own focus. >> Common Lisp doesn't have a focus that I am aware of. It is the language >> that is most close to Emacs Lisp syntactically, and most emacs code that >> doesn't have editor specific stuff will run in Common Lisp & vice versa. >> >>> For an extension language, it is preferable to have a system where you >>> can read through the manual in one day and basically understand it >> The effort to "basically" understand CL is the same as the for scheme. Moreover >> scheme has some exotic stuff like hygienic macros and continuations which are >> not stuff you "basically understand in a day". >> >>> Scheme is a smaller starting point than Common Lisp. >> So with a common lisp system you get: >> 1) compilation to machine code >> 2) standardized implementation of classes >> 3) structures, hashes >> 4) Exceptions >> With a scheme system you get >> 1) call-with-current-continuation >> > > And who said you won't get native code, classes, structures, hashes > and exceptions with scheme? Those who say that Scheme is small and elegant. If Scheme has all the features of CL it's no longer smaller than CL. > They are just not documented in R5RS (let's forget R6RS ever > existed). Most scheme implementations have these features, they are > not portable however. Comparing implementations of one language with the specification of another language makes as much sense as comparing apples with oranges. Helmut ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-14 7:51 ` David Kastrup 2010-04-14 8:42 ` christian.lynbech 2010-04-14 9:55 ` immanuel litzroth @ 2010-04-14 15:47 ` Tom Tromey 2010-04-14 16:41 ` Drew Adams 2010-04-15 10:38 ` Leo 2 siblings, 2 replies; 149+ messages in thread From: Tom Tromey @ 2010-04-14 15:47 UTC (permalink / raw To: David Kastrup; +Cc: emacs-devel >>>>> "David" == David Kastrup <dak@gnu.org> writes: David> Scheme is a smaller starting point than Common Lisp. But we aren't talking about "Scheme", we're talking about Guile, which is significantly larger. It has modules and OO and all kinds of other stuff. While I rather like CL, and much prefer it to Scheme, I don't see why we need to consider either. I don't see much wrong with elisp as it is. In my view it simply is not among the major limiting factors of Emacs. Tom ^ permalink raw reply [flat|nested] 149+ messages in thread
* RE: Guile in Emacs 2010-04-14 15:47 ` Tom Tromey @ 2010-04-14 16:41 ` Drew Adams 2010-04-14 20:10 ` David De La Harpe Golden 2010-04-15 10:38 ` Leo 1 sibling, 1 reply; 149+ messages in thread From: Drew Adams @ 2010-04-14 16:41 UTC (permalink / raw To: emacs-devel > While I rather like CL, and much prefer it to Scheme, I don't > see why we need to consider either. I don't see much wrong > with elisp as it is. In my view it simply is not among the > major limiting factors of Emacs. FWIW, I agree. I don't see a need to change things fundamentally. If some particular aspects of either CL or Scheme are considered desirable individually, then we could move toward accommodating them (adopting/adapting). Incremental evolution that way, in the normal Emacs base code (as opposed to creating a parallel Scheme-based or CL-based Emacs), would help ensure that non-core libraries, including 3rd-party libraries, kept pace. Emacs is not just someone's term project. The main and most important difference from Elisp, for both CL and Scheme, lies in more robust support for lexical scoping. CL's approach to mixing lexical and dynamic scoping would be a reasonable one for Emacs Lisp. We currently have `lexical-let' and that's about all. Common Lisp goes much further toward taking advantage of lexical scoping than we currently do in Emacs. I might add that a better time to have considered this would have been 1985 or 1990, not 2010. ;-) When both CL and GNU Emacs were young would have been the perfect time. Richard is not crazy about CL, and my guess is that that's the reason we aren't as close to it now as we might be. I do, BTW, agree with Richard that there is a lot in CL that Emacs does not necessarily need. But the basic design of CL would not be a bad one for Emacs, IMO. I also suspect that if there were really much interest in moving in this direction, then we would already have moved Emacs Lisp a little closer to CL. It just hasn't happened. It is also the case that Emacs would already have much more CL-like and CL-somewhat-compatible code now if there were not so much push-back to using CL functions at runtime. Don't get me wrong - I support the push-back. My point is only that if you look at 3rd-party Emacs-Lisp libraries (not mine ;-)), especially by younger developers, you'll see widespread use of cl.el functions. That's an indication that people would use CL constructs if they were more solidly part of Emacs Lisp. The evolution toward more CL-ness would thus partly take care of itself. The problem is that the foundation is shaky. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-14 16:41 ` Drew Adams @ 2010-04-14 20:10 ` David De La Harpe Golden 0 siblings, 0 replies; 149+ messages in thread From: David De La Harpe Golden @ 2010-04-14 20:10 UTC (permalink / raw To: Drew Adams; +Cc: emacs-devel Drew Adams wrote: > The main and most important difference from Elisp, for both CL and Scheme, lies > in more robust support for lexical scoping. CL's approach to mixing lexical and > dynamic scoping would be a reasonable one for Emacs Lisp. islisp's [1] approach is a little bit better IIRC. Islisp impls are few and far between of course. Emacs Lisp and CL or Islisp are far, far closer than emacs lisp and scheme. [1] http://islisp.info/ ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Guile in Emacs 2010-04-14 15:47 ` Tom Tromey 2010-04-14 16:41 ` Drew Adams @ 2010-04-15 10:38 ` Leo 1 sibling, 0 replies; 149+ messages in thread From: Leo @ 2010-04-15 10:38 UTC (permalink / raw To: emacs-devel On 2010-04-14 16:47 +0100, Tom Tromey wrote: > While I rather like CL, and much prefer it to Scheme, I don't see why > we need to consider either. I don't see much wrong with elisp as it > is. In my view it simply is not among the major limiting factors of > Emacs. Keep elisp but extend it with some goodies from common lisp or scheme sounds good to me. Leo ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: integer overflow 2010-03-06 15:45 ` Stefan Monnier 2010-03-06 16:23 ` Davis Herring 2010-03-06 16:33 ` Drew Adams @ 2010-03-06 19:04 ` Helmut Eller 2010-03-06 21:26 ` Stefan Monnier 2010-03-07 7:51 ` Richard Stallman 3 siblings, 1 reply; 149+ messages in thread From: Helmut Eller @ 2010-03-06 19:04 UTC (permalink / raw To: Stefan Monnier; +Cc: emacs-devel * Stefan Monnier [2010-03-06 16:45+0100] writes: >>>> Can you summarize how it's supposed to work? >>> The change affects the Lisp reader: reading "536870912" or any larger >>> number now gives you a float Lisp object, instead of an integer Lisp >>> object (since there is no way to represent 536870912 or larger as >>> integers). 536870911 and below are still read as integers. >> What's the point of doing that? I would much prefer if read would just >> raise an error. > > There are many cases where it's important to read an integer from some > other program, so it's important to be able to read integers larger the > Elisp's largest fixnum (tho less so for integers larger than the > host system's natural "int"). > Examples are file sizes, process ids, user ids, ... read doesn't seem the right tool for this job; read is for parsing Lisp syntax. Those few programs which produce Lisp syntax should probably just write floats if there is a danger of overflow and precision doesn't matter. For those cases were precision does matter (eg. a 32bit Emacs reading a file produced by a 64bit Emacs) I'd prefer an error instead of automatic coercions. Helmut ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: integer overflow 2010-03-06 19:04 ` integer overflow Helmut Eller @ 2010-03-06 21:26 ` Stefan Monnier 0 siblings, 0 replies; 149+ messages in thread From: Stefan Monnier @ 2010-03-06 21:26 UTC (permalink / raw To: Helmut Eller; +Cc: emacs-devel > read doesn't seem the right tool for this job; read is for parsing Lisp > syntax. I can partly agree with the feeling, but since writing a lexer&parser in Elisp results in fairly poor performance, it's common to (ab)use the Lisp reader when possible. The use of bignums would probably be a generally better option than floats, but noone has tried to solve this yet (there have been some patches that add bignums, but they still require a fair bit of work). Stefan ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: integer overflow 2010-03-06 15:45 ` Stefan Monnier ` (2 preceding siblings ...) 2010-03-06 19:04 ` integer overflow Helmut Eller @ 2010-03-07 7:51 ` Richard Stallman 3 siblings, 0 replies; 149+ messages in thread From: Richard Stallman @ 2010-03-07 7:51 UTC (permalink / raw To: Stefan Monnier; +Cc: eller.helmut, emacs-devel There are many cases where it's important to read an integer from some other program, so it's important to be able to read integers larger the Elisp's largest fixnum (tho less so for integers larger than the host system's natural "int"). Examples are file sizes, process ids, user ids, ... Would it make sense to set up a variable to control this? You could bind it to t for those special cases. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: integer overflow 2010-03-06 3:11 ` Chong Yidong 2010-03-06 7:03 ` Helmut Eller @ 2010-03-07 19:05 ` Johan Bockgård 1 sibling, 0 replies; 149+ messages in thread From: Johan Bockgård @ 2010-03-07 19:05 UTC (permalink / raw To: emacs-devel Chong Yidong <cyd@stupidchicken.com> writes: > Glenn Morris <rgm@gnu.org> writes: > >> I don't really understand it. In a 32-bit Emacs: >> >> (1+ 536870911) -536870912 >> (+ 2 536870911) -536870911 >> (1+ 536870912) 536870913.0 >> (1+ 4294967295) overflow >> (1+ 4294967295.0) 4294967296.0 >> >> Can you summarize how it's supposed to work? > > The change affects the Lisp reader: reading "536870912" or any larger > number now gives you a float Lisp object or an error if the integer is larger than 32 bits, as the fourth example shows. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: integer overflow 2010-03-05 22:35 ` integer overflow Stefan Monnier 2010-03-06 2:55 ` Glenn Morris @ 2010-03-06 20:35 ` Chong Yidong 1 sibling, 0 replies; 149+ messages in thread From: Chong Yidong @ 2010-03-06 20:35 UTC (permalink / raw To: Stefan Monnier; +Cc: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: > Indeed, I thought about it as a pure bug-fix, but it needs to be added > to the NEWS. Can you do that and update the doc accordingly? I've just done so. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Next pretest, and branching plans 2010-02-23 5:31 ` Next pretest, and branching plans Jason Rumney 2010-02-23 18:29 ` Eli Zaretskii 2010-02-24 6:04 ` Richard Stallman @ 2010-03-13 3:10 ` Christoph 2010-03-13 7:42 ` Eli Zaretskii 2010-03-13 18:30 ` Stefan Monnier 2 siblings, 2 replies; 149+ messages in thread From: Christoph @ 2010-03-13 3:10 UTC (permalink / raw To: emacs-devel On 2/22/2010 10:31 PM, Jason Rumney wrote: > On 22/02/2010 05:46, Chong Yidong wrote: > >> Jason, do you think you could down write some instructions? You could >> put it at the end of admin/make-tarball.txt, or as its own file in the >> admin/ directory. > > I don't have access to bzr at the moment, but here are the steps > required: > > 3. "make install" to create the bin subdirectory with the appropriate > files. I am trying to package the Windows binaries per Jason's instructions and I was wondering about the make install command on Windows: without specifying a prefix it installs in the current directory but it also does other stuff, for example adding a shortcut to the start menu (by calling addpm.exe). Would it make sense to create a 'make package-install' target that omits these things (if there is other stuff besides the shortcut, that is more intended for a real installation rather than packaging)? When I am packaging I don't want the shortcut created. Or maybe I am just overlooking an obvious way to do this? Thanks, Christoph ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Next pretest, and branching plans 2010-03-13 3:10 ` Next pretest, and branching plans Christoph @ 2010-03-13 7:42 ` Eli Zaretskii 2010-03-13 14:54 ` Christoph 2010-03-13 18:30 ` Stefan Monnier 1 sibling, 1 reply; 149+ messages in thread From: Eli Zaretskii @ 2010-03-13 7:42 UTC (permalink / raw To: Christoph; +Cc: emacs-devel > Date: Fri, 12 Mar 2010 20:10:09 -0700 > From: Christoph <cschol2112@googlemail.com> > > I am trying to package the Windows binaries per Jason's instructions and > I was wondering about the make install command on Windows: without > specifying a prefix it installs in the current directory but it also > does other stuff, for example adding a shortcut to the start menu (by > calling addpm.exe). I think "make install" does that even if you do specify the directory to install in. > Would it make sense to create a 'make package-install' target that omits > these things (if there is other stuff besides the shortcut, that is more > intended for a real installation rather than packaging)? When I am > packaging I don't want the shortcut created. Patches are welcome. While at that, perhaps have that package-install target run the admin/nt/makedist.bat automatically. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Next pretest, and branching plans 2010-03-13 7:42 ` Eli Zaretskii @ 2010-03-13 14:54 ` Christoph 0 siblings, 0 replies; 149+ messages in thread From: Christoph @ 2010-03-13 14:54 UTC (permalink / raw To: Eli Zaretskii; +Cc: emacs-devel On 3/13/2010 12:42 AM, Eli Zaretskii wrote: >> Would it make sense to create a 'make package-install' target that omits >> these things (if there is other stuff besides the shortcut, that is more >> intended for a real installation rather than packaging)? When I am >> packaging I don't want the shortcut created. >> > Patches are welcome. While at that, perhaps have that package-install > target run the admin/nt/makedist.bat automatically. > Sounds good, I will take a stab at that. Thanks, Christoph ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Next pretest, and branching plans 2010-03-13 3:10 ` Next pretest, and branching plans Christoph 2010-03-13 7:42 ` Eli Zaretskii @ 2010-03-13 18:30 ` Stefan Monnier 2010-03-13 19:06 ` Eli Zaretskii 2010-03-14 2:38 ` Jason Rumney 1 sibling, 2 replies; 149+ messages in thread From: Stefan Monnier @ 2010-03-13 18:30 UTC (permalink / raw To: Christoph; +Cc: emacs-devel > Would it make sense to create a 'make package-install' target that omits > these things (if there is other stuff besides the shortcut, that is more > intended for a real installation rather than packaging)? When I am packaging > I don't want the shortcut created. To me at least, the name "package-install" would not be helpful. Something like "install_files_only" would sound more meaningful (or "install_for_packaging", or ...). Stefan ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Next pretest, and branching plans 2010-03-13 18:30 ` Stefan Monnier @ 2010-03-13 19:06 ` Eli Zaretskii 2010-03-14 2:38 ` Jason Rumney 1 sibling, 0 replies; 149+ messages in thread From: Eli Zaretskii @ 2010-03-13 19:06 UTC (permalink / raw To: Stefan Monnier; +Cc: cschol2112, emacs-devel > From: Stefan Monnier <monnier@iro.umontreal.ca> > Date: Sat, 13 Mar 2010 13:30:28 -0500 > Cc: emacs-devel@gnu.org > > > Would it make sense to create a 'make package-install' target that omits > > these things (if there is other stuff besides the shortcut, that is more > > intended for a real installation rather than packaging)? When I am packaging > > I don't want the shortcut created. > > To me at least, the name "package-install" would not be helpful. > Something like "install_files_only" would sound more meaningful (or > "install_for_packaging", or ...). I suggest "dist", like in the top-level Makefile.in. There's no need for this target without actually producing the binary zip file, so it should run the makedist.bat script as part of its job. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Next pretest, and branching plans 2010-03-13 18:30 ` Stefan Monnier 2010-03-13 19:06 ` Eli Zaretskii @ 2010-03-14 2:38 ` Jason Rumney 2010-03-14 2:50 ` Christoph 1 sibling, 1 reply; 149+ messages in thread From: Jason Rumney @ 2010-03-14 2:38 UTC (permalink / raw To: Stefan Monnier; +Cc: Christoph, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> Would it make sense to create a 'make package-install' target that omits >> these things (if there is other stuff besides the shortcut, that is more >> intended for a real installation rather than packaging)? When I am packaging >> I don't want the shortcut created. > > To me at least, the name "package-install" would not be helpful. > Something like "install_files_only" would sound more meaningful (or > "install_for_packaging", or ...). My preference would be for make install to install the files only, and a new rule for making shortcuts (install_icons). Most people who build from source on Windows are probably building in the same location all the time, so they don't always need to replace the shortcut. And if they have multiple versions installed, they will want to maintain the shortcut icons manually to avoid having all the versions overwrite each other. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Next pretest, and branching plans 2010-03-14 2:38 ` Jason Rumney @ 2010-03-14 2:50 ` Christoph 2010-03-14 3:07 ` Jason Rumney 2010-03-14 17:55 ` Eli Zaretskii 0 siblings, 2 replies; 149+ messages in thread From: Christoph @ 2010-03-14 2:50 UTC (permalink / raw To: Jason Rumney; +Cc: Stefan Monnier, emacs-devel On 3/13/2010 7:38 PM, Jason Rumney wrote: > Stefan Monnier<monnier@iro.umontreal.ca> writes: > >>> Would it make sense to create a 'make package-install' target that omits >>> these things (if there is other stuff besides the shortcut, that is more >>> intended for a real installation rather than packaging)? When I am packaging >>> I don't want the shortcut created. >>> >> To me at least, the name "package-install" would not be helpful. >> Something like "install_files_only" would sound more meaningful (or >> "install_for_packaging", or ...). >> > My preference would be for make install to install the files only, and a > new rule for making shortcuts (install_icons). > > Most people who build from source on Windows are probably building in > the same location all the time, so they don't always need to replace the > shortcut. And if they have multiple versions installed, they will want > to maintain the shortcut icons manually to avoid having all the versions > overwrite each other. > For packaging, a make dist rule would also need to copy the dist files (libXpm.dll for example) before invoking makedist.bat to really automate the entire process. I agree with you, Jason, that installing shortcuts should be a separate step and not the included in the normal make install (for pretty much the same reasons you pointed out). But that to me, is a separate issue from packaging. I went ahead and implemented the following so far in my local branch: - added an option "--distfiles [path to file, for example libXpm.dll]" to configure.bat. Adding those external binaries was the only manual step left in the process and can also be automated now. - added build target 'dist' to makefile.w32-in. It basically does a 'make install' without creating shortcuts, copies the distfiles, i.e. the libXpm.dll to the bin directory and then calls 'makedist.bat' to create the zip file for distribution. One problem is that calling makedist.bat means a dependency on the trunk, since it is not available in the source tarball. Can we add the /admin/nt directory and its contents to the source tarball? Or move the files to ../nt? Then, the 'make dist' target would be able to create a zip from just the tarball, without having to have the trunk available. But since the directory structure is the same, running 'make dist' would also work in the trunk itself to easily create binary snapshots of the trunk. The makedist.bat needs to be changed a little because it expects the files to be in a folder emacs-xx.x.xx as they are in the tarball, but that is a trivial change change to make it more generic and automated. Also, is there any way to get the version number from a file contained in the source tar ball? Then make dist would always output a zip file properly named according to the current version. Any thoughts? Christoph ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Next pretest, and branching plans 2010-03-14 2:50 ` Christoph @ 2010-03-14 3:07 ` Jason Rumney 2010-03-14 17:55 ` Eli Zaretskii 1 sibling, 0 replies; 149+ messages in thread From: Jason Rumney @ 2010-03-14 3:07 UTC (permalink / raw To: Christoph; +Cc: Stefan Monnier, emacs-devel Christoph <cschol2112@googlemail.com> writes: > One problem is that calling makedist.bat means a dependency on the > trunk, since it is not available in the source tarball. Can we add the > /admin/nt directory and its contents to the source tarball? Or move > the files to ../nt? Then, the 'make dist' target would be able to > create a zip from just the tarball, without having to have the trunk > available. But since the directory structure is the same, running > make dist' would also work in the trunk itself to easily create binary > snapshots of the trunk. Moving the files to the top level nt subdirectory would be OK. > Also, is there any way to get the version number from a file contained > in the source tar ball? Then make dist would always output a zip file > properly named according to the current version. The lib-src makefile contains the version number on Windows. You could update admin/admin.el if you want to move this to nt/makefile. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Next pretest, and branching plans 2010-03-14 2:50 ` Christoph 2010-03-14 3:07 ` Jason Rumney @ 2010-03-14 17:55 ` Eli Zaretskii 2010-03-17 0:29 ` Christoph 1 sibling, 1 reply; 149+ messages in thread From: Eli Zaretskii @ 2010-03-14 17:55 UTC (permalink / raw To: Christoph; +Cc: emacs-devel, monnier, jasonr > Date: Sat, 13 Mar 2010 19:50:30 -0700 > From: Christoph <cschol2112@googlemail.com> > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org > > - added an option "--distfiles [path to file, for example libXpm.dll]" > to configure.bat. That's gratuitous, I think: modern Windows shells are powerful enough to let you write a FOR loop looking for libXpm.dll along PATH. > Also, is there any way to get the version number from a file contained > in the source tar ball? Then make dist would always output a zip file > properly named according to the current version. Again, one of the variants of the FOR command should do the trick. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Next pretest, and branching plans 2010-03-14 17:55 ` Eli Zaretskii @ 2010-03-17 0:29 ` Christoph 2010-03-17 4:14 ` Eli Zaretskii 0 siblings, 1 reply; 149+ messages in thread From: Christoph @ 2010-03-17 0:29 UTC (permalink / raw To: Eli Zaretskii; +Cc: emacs-devel, monnier, jasonr On 3/14/2010 11:55 AM, Eli Zaretskii wrote: >> Date: Sat, 13 Mar 2010 19:50:30 -0700 >> From: Christoph<cschol2112@googlemail.com> >> Cc: Stefan Monnier<monnier@iro.umontreal.ca>, emacs-devel@gnu.org >> >> - added an option "--distfiles [path to file, for example libXpm.dll]" >> to configure.bat. >> > That's gratuitous, I think: modern Windows shells are powerful enough > to let you write a FOR loop looking for libXpm.dll along PATH. > This assumes that libXpm.dll is actually somwhere on the PATH, which it might or might not be (and I might not put it on the path). I think the command line option for configure.bat is way more flexible for one's individual build environment, plus who knows, maybe I want to also package libSvg.dll or libWhatever.dll. Now I can do this without having to change the code. >> Also, is there any way to get the version number from a file contained >> in the source tar ball? Then make dist would always output a zip file >> properly named according to the current version. >> > Again, one of the variants of the FOR command should do the trick. > Could you elaborate on this solution? Thanks! Christoph PS: As for the "powerful Windows shells"...not before Windows 7 (or Vista?) with Powershell did Windows ever have a powerful shell... ;) ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Next pretest, and branching plans 2010-03-17 0:29 ` Christoph @ 2010-03-17 4:14 ` Eli Zaretskii 2010-03-17 12:44 ` Jason Rumney 0 siblings, 1 reply; 149+ messages in thread From: Eli Zaretskii @ 2010-03-17 4:14 UTC (permalink / raw To: Christoph; +Cc: jasonr, monnier, emacs-devel > Date: Tue, 16 Mar 2010 18:29:17 -0600 > From: Christoph <cschol2112@googlemail.com> > Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, jasonr@gnu.org > > >> - added an option "--distfiles [path to file, for example libXpm.dll]" > >> to configure.bat. > >> > > That's gratuitous, I think: modern Windows shells are powerful enough > > to let you write a FOR loop looking for libXpm.dll along PATH. > > > This assumes that libXpm.dll is actually somwhere on the PATH, which it > might or might not be (and I might not put it on the path). If it's not on PATH, it's in the directory where you have the Emacs binary. > I think the > command line option for configure.bat is way more flexible for one's > individual build environment Yes, but flexibility comes at a price: one needs _always_ to type that argument. Why impose this inconvenience on the user? > >> Also, is there any way to get the version number from a file contained > >> in the source tar ball? Then make dist would always output a zip file > >> properly named according to the current version. > >> > > Again, one of the variants of the FOR command should do the trick. > > > Could you elaborate on this solution? Thanks! Type "for /?" from the cmd prompt, and read there, especially about "for /f". It's too long to post that info here. > PS: As for the "powerful Windows shells"...not before Windows 7 (or > Vista?) with Powershell did Windows ever have a powerful shell... ;) I was talking about cmd, not about Powershell. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Next pretest, and branching plans 2010-03-17 4:14 ` Eli Zaretskii @ 2010-03-17 12:44 ` Jason Rumney 0 siblings, 0 replies; 149+ messages in thread From: Jason Rumney @ 2010-03-17 12:44 UTC (permalink / raw To: Eli Zaretskii; +Cc: Christoph, monnier, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > If it's not on PATH, it's in the directory where you have the Emacs > binary. Well, no. The directory where he has the Emacs binary has just been created via make install, so it doesn't contain any files that are not part of Emacs. > Yes, but flexibility comes at a price: one needs _always_ to type that > argument. Why impose this inconvenience on the user? The make target Christoph is creating is for packaging Emacs. Most users will have no need to use it. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Next pretest, and branching plans @ 2010-02-18 11:02 Chong Yidong 2010-02-18 15:29 ` Drew Adams 0 siblings, 1 reply; 149+ messages in thread From: Chong Yidong @ 2010-02-18 11:02 UTC (permalink / raw To: emacs-devel I will roll the next pretest, 23.1.93, next week, Friday the 26th of February. Shortly afterwards, around Monday 1 March, we will make the release branch, which will be used for all subsequent 23.1.xx pretests, as well as the final 23.2 release. Once this branch is made, the feature freeze will be made "harder". Except for documentation improvements and special exceptions (which must first be discussed on emacs-devel, or with Stefan or myself), the only allowed bugfixes are for regressions with respect to Emacs 22. (At a still later date, we will only allow bugfixes for regressions with respect to Emacs 23.1.) Once the branch is made, Stefan or myself will announce on emacs-devel that the trunk is open for Emacs 24 development. At this point, we can merge the projects from the pending branch into the trunk, and so forth. We'll give more details about commit policy for the trunk, and our general goals for Emacs 24, later. (Opinions are welcome.) Once the branch is made, some bugfixes will need to be applied both to the trunk and to the branch. This is important, so anyone who has commit access should take note. ^ permalink raw reply [flat|nested] 149+ messages in thread
* RE: Next pretest, and branching plans 2010-02-18 11:02 Chong Yidong @ 2010-02-18 15:29 ` Drew Adams 2010-02-20 12:25 ` Leo 0 siblings, 1 reply; 149+ messages in thread From: Drew Adams @ 2010-02-18 15:29 UTC (permalink / raw To: 'Chong Yidong', emacs-devel > I will roll the next pretest, 23.1.93, next week, Friday the 26th of > February. Never got a Windows binary for the last one, 23.1.92. Spent a lot of time fiddling with stuff, trying to help test bugs and bug fixes (e.g. #5478) without the latest binary. Certainly couldn't file any new, pretest-related bugs. If pretest feedback from Windows users is at all useful or important to you, then you might consider this a loss. If not, just keep on rolling... ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Next pretest, and branching plans 2010-02-18 15:29 ` Drew Adams @ 2010-02-20 12:25 ` Leo 2010-02-20 13:05 ` Sean Sieger 2010-02-20 16:52 ` Drew Adams 0 siblings, 2 replies; 149+ messages in thread From: Leo @ 2010-02-20 12:25 UTC (permalink / raw To: emacs-devel On 2010-02-18 15:29 +0000, Drew Adams wrote: >> I will roll the next pretest, 23.1.93, next week, Friday the 26th of >> February. > > Never got a Windows binary for the last one, 23.1.92. > > Spent a lot of time fiddling with stuff, trying to help test bugs and bug fixes > (e.g. #5478) without the latest binary. Certainly couldn't file any new, > pretest-related bugs. > > If pretest feedback from Windows users is at all useful or important to you, > then you might consider this a loss. If not, just keep on rolling... Is a policy to provide a binary for windows? There's no binary for GNU/Linux, OSX and many others. But when I was using Windows, I have found the following two sources that provide excellent binary for windows. http://code.google.com/p/emacs-for-windows/ http://www.ourcomments.org/Emacs/DL/EmacsW32/EmacsCVS/unptch/emacs-from-cvs-091015.zip Cheers, Leo ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Next pretest, and branching plans 2010-02-20 12:25 ` Leo @ 2010-02-20 13:05 ` Sean Sieger 2010-02-20 17:02 ` Drew Adams 2010-02-28 12:36 ` Sean Sieger 2010-02-20 16:52 ` Drew Adams 1 sibling, 2 replies; 149+ messages in thread From: Sean Sieger @ 2010-02-20 13:05 UTC (permalink / raw To: emacs-devel http://code.google.com/p/emacs-for-windows/ I'll have try this one, thank you. http://www.ourcomments.org/Emacs/DL/EmacsW32/EmacsCVS/unptch/emacs-from-cvs-091015.zip Huh? Look at the date stamp. This used to be a good resource. ^ permalink raw reply [flat|nested] 149+ messages in thread
* RE: Next pretest, and branching plans 2010-02-20 13:05 ` Sean Sieger @ 2010-02-20 17:02 ` Drew Adams 2010-02-28 12:36 ` Sean Sieger 1 sibling, 0 replies; 149+ messages in thread From: Drew Adams @ 2010-02-20 17:02 UTC (permalink / raw To: 'Sean Sieger', emacs-devel > http://code.google.com/p/emacs-for-windows/ > > I'll have try this one, thank you. > > http://www.ourcomments.org/Emacs/DL/EmacsW32/EmacsCVS/unptch/e > macs-from-cvs-091015.zip > > Huh? Look at the date stamp. This used to be a good resource. Neither represents the 23.1.92 pretest, AFAIK. The former says: GNU Emacs 23.1.91.1 (i386-mingw-nt5.1.2600) of 2010-01-02 on PRETEST Yidong announced the 23.1.92 pretest on 2010/01/29. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Next pretest, and branching plans 2010-02-20 13:05 ` Sean Sieger 2010-02-20 17:02 ` Drew Adams @ 2010-02-28 12:36 ` Sean Sieger 2010-02-28 15:13 ` Lennart Borgman 1 sibling, 1 reply; 149+ messages in thread From: Sean Sieger @ 2010-02-28 12:36 UTC (permalink / raw To: emacs-devel Sean Sieger <sean.sieger@gmail.com> writes: http://www.ourcomments.org/Emacs/DL/EmacsW32/EmacsCVS/unptch/emacs-from-cvs-091015.zip Huh? Look at the date stamp. This used to be a good resource. I'm sorry for this comment, Lennart. It didn't come out right. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Next pretest, and branching plans 2010-02-28 12:36 ` Sean Sieger @ 2010-02-28 15:13 ` Lennart Borgman 0 siblings, 0 replies; 149+ messages in thread From: Lennart Borgman @ 2010-02-28 15:13 UTC (permalink / raw To: Sean Sieger; +Cc: emacs-devel On Sun, Feb 28, 2010 at 1:36 PM, Sean Sieger <sean.sieger@gmail.com> wrote: > Sean Sieger <sean.sieger@gmail.com> writes: > > http://www.ourcomments.org/Emacs/DL/EmacsW32/EmacsCVS/unptch/emacs-from-cvs-091015.zip > > Huh? Look at the date stamp. This used to be a good resource. > > I'm sorry for this comment, Lennart. It didn't come out right. No problem. I have just been caught in too much things to get the uploads working without problem again. It will work again in a while. ^ permalink raw reply [flat|nested] 149+ messages in thread
* RE: Next pretest, and branching plans 2010-02-20 12:25 ` Leo 2010-02-20 13:05 ` Sean Sieger @ 2010-02-20 16:52 ` Drew Adams 2010-02-20 17:35 ` Drew Adams 2010-02-20 17:51 ` Eli Zaretskii 1 sibling, 2 replies; 149+ messages in thread From: Drew Adams @ 2010-02-20 16:52 UTC (permalink / raw To: 'Leo', emacs-devel > > If pretest feedback from Windows users is at all useful or > > important to you, then you might consider this a loss. > > If not, just keep on rolling... > > Is a policy to provide a binary for windows? There's no binary for > GNU/Linux, OSX and many others. I cannot speak to what the "policy" is, or whether there even is a policy. I make no claim about policy. GNU Emacs does publish this, FWIW: http://alpha.gnu.org/gnu/emacs/pretest/windows/. The README there (from 2010/01/03) says, "This directory contains precompiled distributions for GNU Emacs on Windows". That is, GNU Emacs publishes a directory that has _only_ Windows binaries. No, the README does not claim that the directory includes a binary of the latest pretest. And it did not include a binary for the previous pretest (23.1.91) either, until we reminded about it a few times and Jason found time to create and post it (thank you). But prior to that, AFAIK, it generally _has_ included pretest binaries. I repeat: *IF* such feedback from Windows users is important to Emacs development, then you might consider that not posting a binary will reduce useful feedback. Speaking for myself only, that will be the case. As an example, I recently spent some time with Michael A. trying to debug and fix bug #5478, and we were forced to test using the previous Windows pretest because the latest was not available. With no pretest binaries at all, next time perhaps we will need to wait for a binary of the next release. Or the bug might find someone who wants to not only fix the bug but also build Emacs on Windows. Perhaps more importantly, there will be fewer (far fewer, IMO) new bug reports from Windows users for the latest code. Instead of a pretest, you will, in effect, just wait until after the release to get such bug reports. The purpose of the pretest will thus be defeated, except for those Windows pretesters who are willing to build Emacs. Speaking for myself again, I have submitted many bug reports for Emacs pretests, including for the last one (23.1.91). I submitted none for 23.1.92, since there was no binary. IF you think that bug reports during pretest can be helpful in general, then this is a loss. > But when I was using Windows, I have found the following two sources > that provide excellent binary for windows. > http://code.google.com/p/emacs-for-windows/ > http://www.ourcomments.org/Emacs/DL/EmacsW32/EmacsCVS/unptch/e > macs-from-cvs-091015.zip Yes, and there are other sites that also have, or have had, old Windows binaries. And people appreciate this. But that is all beside the point. Those you cite are from 2010/02/02 and 2009/10/15, respectively. Neither represents the latest pretest. That's the point: the pretest. If you, Lennart or anyone else builds a pretest binary and posts it, that will be helpful and appreciated. ^ permalink raw reply [flat|nested] 149+ messages in thread
* RE: Next pretest, and branching plans 2010-02-20 16:52 ` Drew Adams @ 2010-02-20 17:35 ` Drew Adams 2010-02-20 19:45 ` Eli Zaretskii 2010-02-20 17:51 ` Eli Zaretskii 1 sibling, 1 reply; 149+ messages in thread From: Drew Adams @ 2010-02-20 17:35 UTC (permalink / raw To: emacs-devel Related to this is the fact that bug #5299, a regression, is still outstanding. It prevents Windows users from using `M-x report-emacs-bug' to file bugs. Do you really want bug reports from Windows users? ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Next pretest, and branching plans 2010-02-20 17:35 ` Drew Adams @ 2010-02-20 19:45 ` Eli Zaretskii 2010-02-20 20:39 ` Drew Adams 2010-02-21 0:11 ` Lennart Borgman 0 siblings, 2 replies; 149+ messages in thread From: Eli Zaretskii @ 2010-02-20 19:45 UTC (permalink / raw To: Drew Adams; +Cc: emacs-devel > From: "Drew Adams" <drew.adams@oracle.com> > Date: Sat, 20 Feb 2010 09:35:24 -0800 > > Related to this is the fact that bug #5299, a regression, is still outstanding. > It prevents Windows users from using `M-x report-emacs-bug' to file bugs. I don't know what to fix there. Email never worked for me on Windows without some setup. I use smtpmail, but it will not work without setting it up for your ISP's mail server. So, for me, there's no regression: it never worked in previous versions of Emacs, and it does not work now. Lennart seems to know what kind of solution worked for you in the past, so perhaps Lennart could try fixing that, or at least describing what changed in Emacs that broke that solution, whatever it is. I don't have Outlook set up to even try what you describe. > Do you really want bug reports from Windows users? Yes, and you know that. ^ permalink raw reply [flat|nested] 149+ messages in thread
* RE: Next pretest, and branching plans 2010-02-20 19:45 ` Eli Zaretskii @ 2010-02-20 20:39 ` Drew Adams 2010-02-20 20:53 ` Lennart Borgman 2010-02-21 0:11 ` Lennart Borgman 1 sibling, 1 reply; 149+ messages in thread From: Drew Adams @ 2010-02-20 20:39 UTC (permalink / raw To: 'Eli Zaretskii'; +Cc: emacs-devel > > Related to this is the fact that bug #5299, a regression, > > is still outstanding. It prevents Windows users from > > using `M-x report-emacs-bug' to file bugs. > > I don't know what to fix there. Email never worked for me on Windows > without some setup. I use smtpmail, but it will not work without > setting it up for your ISP's mail server. > > So, for me, there's no regression: it never worked in previous > versions of Emacs, and it does not work now. > > Lennart seems to know what kind of solution worked for you in the > past, so perhaps Lennart could try fixing that, or at least describing > what changed in Emacs that broke that solution, whatever it is. I > don't have Outlook set up to even try what you describe. (Perhaps this really belongs in the bug #5299 thread?) I have no idea what problems you had previously, or what caused the recent problem. But I can (and do) use `M-x report-emacs-bug' fine with Emacs releases 22 and 23 (and with pretests, before I reported the bug). It works fine in those releases (still). My mail client is Outlook, but I don't know if your mail client has anything to do with your problems using `M-x report-emacs-bug'. Something was changed since the Emacs 23.1 release, so that this became broken. It _is_ a regression, at least for my use case with an external mail client (Outlook). If it never worked for you, that's unfortunate, but that does not mean that it never worked. I don't think (but I don't know) that whatever enabled `report-emacs-bug' to work previously was Outlook-specific. It might have been something Windows-specific (dunno). It might have been something specific for use with an external mail client (any external client) - dunno. But I doubt that it was something Outlook-specific. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Next pretest, and branching plans 2010-02-20 20:39 ` Drew Adams @ 2010-02-20 20:53 ` Lennart Borgman 0 siblings, 0 replies; 149+ messages in thread From: Lennart Borgman @ 2010-02-20 20:53 UTC (permalink / raw To: Drew Adams; +Cc: Eli Zaretskii, emacs-devel On Sat, Feb 20, 2010 at 9:39 PM, Drew Adams <drew.adams@oracle.com> wrote: >> >> Lennart seems to know what kind of solution worked for you in the >> past, so perhaps Lennart could try fixing that, or at least describing >> what changed in Emacs that broke that solution, whatever it is. I >> don't have Outlook set up to even try what you describe. > > (Perhaps this really belongs in the bug #5299 thread?) > > I have no idea what problems you had previously, or what caused the recent > problem. > > But I can (and do) use `M-x report-emacs-bug' fine with Emacs releases 22 and 23 > (and with pretests, before I reported the bug). It works fine in those releases > (still). > > My mail client is Outlook, but I don't know if your mail client has anything to > do with your problems using `M-x report-emacs-bug'. > > Something was changed since the Emacs 23.1 release, so that this became broken. > It _is_ a regression, at least for my use case with an external mail client > (Outlook). If it never worked for you, that's unfortunate, but that does not > mean that it never worked. Yes, it is a regression. I spent quite a lot of time finding a simple useful solution before (the one that is broken now). It was a w32 only solution so I guess it has been broken by someone who does not understand the general nature of the OS interface. > I don't think (but I don't know) that whatever enabled `report-emacs-bug' to > work previously was Outlook-specific. It might have been something > Windows-specific (dunno). It might have been something specific for use with an > external mail client (any external client) - dunno. But I doubt that it was > something Outlook-specific. No, the mail client has nothing to do with it. The solution was general enough to use any mail client on w32. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Next pretest, and branching plans 2010-02-20 19:45 ` Eli Zaretskii 2010-02-20 20:39 ` Drew Adams @ 2010-02-21 0:11 ` Lennart Borgman 2010-02-21 4:11 ` Eli Zaretskii 1 sibling, 1 reply; 149+ messages in thread From: Lennart Borgman @ 2010-02-21 0:11 UTC (permalink / raw To: Eli Zaretskii; +Cc: Drew Adams, emacs-devel On Sat, Feb 20, 2010 at 8:45 PM, Eli Zaretskii <eliz@gnu.org> wrote: > >> Do you really want bug reports from Windows users? > > Yes, and you know that. I just uploaded new unpatched binaries as I told. However I wonder if I was uploading the right thing from a pretest point of view. If I already have Emacs sources checked out (which I have of course) is there a way to build pretest binaries from what I have? I have no idea about how the branches and bazaar works for this. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Next pretest, and branching plans 2010-02-21 0:11 ` Lennart Borgman @ 2010-02-21 4:11 ` Eli Zaretskii 0 siblings, 0 replies; 149+ messages in thread From: Eli Zaretskii @ 2010-02-21 4:11 UTC (permalink / raw To: Lennart Borgman; +Cc: emacs-devel > From: Lennart Borgman <lennart.borgman@gmail.com> > Date: Sun, 21 Feb 2010 01:11:22 +0100 > Cc: Drew Adams <drew.adams@oracle.com>, emacs-devel@gnu.org > > I just uploaded new unpatched binaries as I told. However I wonder if > I was uploading the right thing from a pretest point of view. > > If I already have Emacs sources checked out (which I have of course) > is there a way to build pretest binaries from what I have? I have no > idea about how the branches and bazaar works for this. The easiest way is to build the pretest sources downloaded from alpha.gnu.org. It is also possible to find out the revision number of the tree from which the pretest tarball was tarred, then "bzr revert" to that revert, and build it. But I don't see how this is easier. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Next pretest, and branching plans 2010-02-20 16:52 ` Drew Adams 2010-02-20 17:35 ` Drew Adams @ 2010-02-20 17:51 ` Eli Zaretskii 2010-02-20 18:35 ` Drew Adams ` (2 more replies) 1 sibling, 3 replies; 149+ messages in thread From: Eli Zaretskii @ 2010-02-20 17:51 UTC (permalink / raw To: Drew Adams; +Cc: sdl.web, emacs-devel > From: "Drew Adams" <drew.adams@oracle.com> > Date: Sat, 20 Feb 2010 08:52:50 -0800 > Cc: > > Perhaps more importantly, there will be fewer (far fewer, IMO) new bug reports > from Windows users for the latest code. Instead of a pretest, you will, in > effect, just wait until after the release to get such bug reports. The purpose > of the pretest will thus be defeated, except for those Windows pretesters who > are willing to build Emacs. It's not clear what statistics you have to back this up. I know for a fact that several users of the Windows port build Emacs themselves; what percentage that is of the overall number of people who use the pretest on Windows should be a subject of survey, not guesswork. FWIW, tools for such a build are readily available, and help for setting them up is offered here. So I could never understand why people who want to contribute refuse to install the necessary development environment. It's not that setting up such a development environment is hard or needs many hours. ^ permalink raw reply [flat|nested] 149+ messages in thread
* RE: Next pretest, and branching plans 2010-02-20 17:51 ` Eli Zaretskii @ 2010-02-20 18:35 ` Drew Adams 2010-02-20 19:49 ` Eli Zaretskii 2010-02-20 18:36 ` Chong Yidong 2010-02-20 19:08 ` Lennart Borgman 2 siblings, 1 reply; 149+ messages in thread From: Drew Adams @ 2010-02-20 18:35 UTC (permalink / raw To: 'Eli Zaretskii'; +Cc: sdl.web, emacs-devel > > Perhaps more importantly, there will be fewer (far fewer, > > IMO) new bug reports from Windows users for the latest code. > > > > Instead of a pretest, you will, in effect, just wait until > > after the release to get such bug reports. The purpose > > of the pretest will thus be defeated, except for those > > Windows pretesters who are willing to build Emacs. > > It's not clear what statistics you have to back this up. To back what up? I cited _myself_ as an example. And I have reported a _lot_ of bugs, many of which have been fixed. There will therefore be absolutely fewer (IMO far fewer) bug reports, just counting my own. QED. > I know for a fact that several users of the Windows port > build Emacs themselves; I know that for a fact also. So what? > what percentage that is of the overall number of people who use the > pretest on Windows should be a subject of survey, not guesswork. So go ahead, make such a survey. But check the overall number of Windows pretest _bug reports_ (and the number of such bugs that get fixed, and the number of such bugs that you deem important), not just the number of people who _use_ the Windows pretest. If you limit your check to those who use the Windows pretest, and if no Windows binary is posted, then you've obviously limited your check to those who build Emacs themselves. You will not notice a diminution in _their_ bug reports, obviously. 'Round and 'round you go... [French govt official in the 90s: "Since we stopped listening to the New Caledonian independentists, we no longer hear anything from them."] But even if you do an accurate survey, and you fairly survey the bugs _reported_, not just the number of Windows _users_ of a pretest, and you consider both the number of bug reports and the importance of the bugs reported, a percentage will only give you part of the story. That will indicate a relative loss but not the absolute loss of user feedback. Taking only myself as an example: Even if my bug reports represent a negligible percentage of the total number of Windows bug reports (which I doubt, but which might be the case), they nevertheless represent info that could be useful to Emacs development (that has proven to be the case, in the past). The question is, do you want that info or not? The question still is, "Do you really want bug reports from Windows users?" > FWIW, tools for such a build are readily available, and help for > setting them up is offered here. So I could never understand why > people who want to contribute refuse to install the necessary > development environment. It's not that setting up such a development > environment is hard or needs many hours. There can be many reasons why someone cannot or does not wish to build Emacs. And if building it is so simple, and you have already built the pretest, then why not post your binary of it? Certainly it is at least as easy to post it as to build it, no? What holds you back? "Tools for such a posting are readily available". The purpose of the pretest is only partly to test whether Emacs builds with no problem. And typically you don't need a zillion build reports for the same platform to identify bugs affecting building. You don't need every Emacs pretest tester to build Emacs. The greater purpose of the pretest is to test _Emacs_ itself, after it is built, to see what problems might have been introduced by the latest development changes, 99% of which do not affect building. (No, I don't have statistical evidence for claiming 99%. Sue me.) For that, there is no reason to limit the pretest to those who build Emacs themselves. Especially if you already have a binary available that you can post (which you apparently do have). ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Next pretest, and branching plans 2010-02-20 18:35 ` Drew Adams @ 2010-02-20 19:49 ` Eli Zaretskii 0 siblings, 0 replies; 149+ messages in thread From: Eli Zaretskii @ 2010-02-20 19:49 UTC (permalink / raw To: Drew Adams; +Cc: sdl.web, emacs-devel > From: "Drew Adams" <drew.adams@oracle.com> > Cc: <sdl.web@gmail.com>, <emacs-devel@gnu.org> > Date: Sat, 20 Feb 2010 10:35:02 -0800 > > > > Perhaps more importantly, there will be fewer (far fewer, > > > IMO) new bug reports from Windows users for the latest code. > > > > > > Instead of a pretest, you will, in effect, just wait until > > > after the release to get such bug reports. The purpose > > > of the pretest will thus be defeated, except for those > > > Windows pretesters who are willing to build Emacs. > > > > It's not clear what statistics you have to back this up. > > To back what up? The claim that the purpose of the pretest will be defeated. > There can be many reasons why someone cannot or does not wish to build Emacs. We are here to help overcome whatever difficulties you have. > And if building it is so simple, and you have already built the pretest, then > why not post your binary of it? Building is simple, but packaging and uploading is not. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Next pretest, and branching plans 2010-02-20 17:51 ` Eli Zaretskii 2010-02-20 18:35 ` Drew Adams @ 2010-02-20 18:36 ` Chong Yidong 2010-02-20 18:40 ` Drew Adams 2010-02-20 18:54 ` Lennart Borgman 2010-02-20 19:08 ` Lennart Borgman 2 siblings, 2 replies; 149+ messages in thread From: Chong Yidong @ 2010-02-20 18:36 UTC (permalink / raw To: Eli Zaretskii; +Cc: sdl.web, Drew Adams, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > It's not clear what statistics you have to back this up. I know for a > fact that several users of the Windows port build Emacs themselves; > what percentage that is of the overall number of people who use the > pretest on Windows should be a subject of survey, not guesswork. > > FWIW, tools for such a build are readily available, and help for > setting them up is offered here. So I could never understand why > people who want to contribute refuse to install the necessary > development environment. It's not that setting up such a development > environment is hard or needs many hours. Anyhow, if anyone would like to volunteer to make binaries for the pretests, please step forward. ^ permalink raw reply [flat|nested] 149+ messages in thread
* RE: Next pretest, and branching plans 2010-02-20 18:36 ` Chong Yidong @ 2010-02-20 18:40 ` Drew Adams 2010-02-20 18:54 ` Lennart Borgman 1 sibling, 0 replies; 149+ messages in thread From: Drew Adams @ 2010-02-20 18:40 UTC (permalink / raw To: 'Chong Yidong', 'Eli Zaretskii'; +Cc: sdl.web, emacs-devel > > It's not clear what statistics you have to back this up. I > > know for a fact that several users of the Windows port build > > Emacs themselves; what percentage that is of the overall > > number of people who use the pretest on Windows should be a > > subject of survey, not guesswork. > > > > FWIW, tools for such a build are readily available, and help for > > setting them up is offered here. So I could never understand why > > people who want to contribute refuse to install the necessary > > development environment. It's not that setting up such a > > development environment is hard or needs many hours. > > Anyhow, if anyone would like to volunteer to make binaries for the > pretests, please step forward. It sounds like you already have lots of people making Windows pretest binaries - Eli knows it for a fact, and I don't doubt it. So what's needed is not a volunteer to make a binary, but a volunteer to post a binary that s?he has already made. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Next pretest, and branching plans 2010-02-20 18:36 ` Chong Yidong 2010-02-20 18:40 ` Drew Adams @ 2010-02-20 18:54 ` Lennart Borgman 2010-02-20 19:15 ` Drew Adams 1 sibling, 1 reply; 149+ messages in thread From: Lennart Borgman @ 2010-02-20 18:54 UTC (permalink / raw To: Chong Yidong; +Cc: Eli Zaretskii, sdl.web, Drew Adams, emacs-devel On Sat, Feb 20, 2010 at 7:36 PM, Chong Yidong <cyd@stupidchicken.com> wrote: > Eli Zaretskii <eliz@gnu.org> writes: > >> It's not clear what statistics you have to back this up. I know for a >> fact that several users of the Windows port build Emacs themselves; >> what percentage that is of the overall number of people who use the >> pretest on Windows should be a subject of survey, not guesswork. >> >> FWIW, tools for such a build are readily available, and help for >> setting them up is offered here. So I could never understand why >> people who want to contribute refuse to install the necessary >> development environment. It's not that setting up such a development >> environment is hard or needs many hours. > > Anyhow, if anyone would like to volunteer to make binaries for the > pretests, please step forward. I have not made binaries for the pretest, but since I noticed the request for newer (unpatched) binaries I have uploaded this today to http://ourcomments.org/cgi-bin/emacsw32-dl-latest.pl ^ permalink raw reply [flat|nested] 149+ messages in thread
* RE: Next pretest, and branching plans 2010-02-20 18:54 ` Lennart Borgman @ 2010-02-20 19:15 ` Drew Adams 0 siblings, 0 replies; 149+ messages in thread From: Drew Adams @ 2010-02-20 19:15 UTC (permalink / raw To: 'Lennart Borgman', 'Chong Yidong' Cc: 'Eli Zaretskii', sdl.web, emacs-devel > I have not made binaries for the pretest, but since I noticed the > request for newer (unpatched) binaries I have uploaded this today to > > http://ourcomments.org/cgi-bin/emacsw32-dl-latest.pl Thank you, Lennart. ^ permalink raw reply [flat|nested] 149+ messages in thread
* Re: Next pretest, and branching plans 2010-02-20 17:51 ` Eli Zaretskii 2010-02-20 18:35 ` Drew Adams 2010-02-20 18:36 ` Chong Yidong @ 2010-02-20 19:08 ` Lennart Borgman 2 siblings, 0 replies; 149+ messages in thread From: Lennart Borgman @ 2010-02-20 19:08 UTC (permalink / raw To: Eli Zaretskii; +Cc: sdl.web, Drew Adams, emacs-devel On Sat, Feb 20, 2010 at 6:51 PM, Eli Zaretskii <eliz@gnu.org> wrote: > > It's not clear what statistics you have to back this up. I know for a > fact that several users of the Windows port build Emacs themselves; > what percentage that is of the overall number of people who use the > pretest on Windows should be a subject of survey, not guesswork. There actually use to be many people downloading prebuilt binaries from my site (most people prefer my patched version then). But I have not checked how many downloads there are for a very long time. ^ permalink raw reply [flat|nested] 149+ messages in thread
end of thread, other threads:[~2010-04-19 7:52 UTC | newest] Thread overview: 149+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <4B8147A9.7030504@gmail.com> [not found] ` <87ljemdzxo.fsf@stupidchicken.com> 2010-02-23 5:31 ` Next pretest, and branching plans Jason Rumney 2010-02-23 18:29 ` Eli Zaretskii 2010-02-23 21:12 ` Jason Rumney 2010-02-24 6:04 ` Richard Stallman 2010-02-24 13:34 ` Sean Sieger 2010-02-24 15:05 ` Davis Herring 2010-02-24 15:18 ` Sean Sieger 2010-02-24 14:05 ` Chong Yidong 2010-02-25 14:26 ` Richard Stallman 2010-02-26 18:03 ` manuals [was Re: Next pretest, and branching plans] Glenn Morris 2010-02-27 2:32 ` Richard Stallman 2010-02-27 16:52 ` Next pretest, and branching plans Johan Bockgård 2010-03-03 3:52 ` Glenn Morris 2010-03-05 0:31 ` Johan Bockgård 2010-03-05 19:50 ` integer overflow [was Re: Next pretest, and branching plans] Glenn Morris 2010-03-05 22:35 ` integer overflow Stefan Monnier 2010-03-06 2:55 ` Glenn Morris 2010-03-06 3:11 ` Chong Yidong 2010-03-06 7:03 ` Helmut Eller 2010-03-06 15:45 ` Stefan Monnier 2010-03-06 16:23 ` Davis Herring 2010-03-06 16:33 ` Drew Adams 2010-03-07 7:52 ` Richard Stallman 2010-03-07 16:06 ` David Kastrup 2010-03-07 17:18 ` Stephen J. Turnbull 2010-03-07 17:42 ` David Kastrup 2010-03-08 4:49 ` Jay Belanger 2010-03-08 8:04 ` Richard Stallman 2010-03-08 14:41 ` Guile in Emacs (was: integer overflow) Ted Zlatanov 2010-03-08 17:32 ` Guile in Emacs Ted Zlatanov 2010-03-08 18:42 ` Guile in Emacs (was: integer overflow) Chad Brown 2010-03-09 7:07 ` Ken Raeburn 2010-03-09 16:22 ` Guile in Emacs Ted Zlatanov 2010-03-10 8:07 ` Ken Raeburn 2010-03-10 13:58 ` David Kastrup 2010-03-09 3:19 ` Guile in Emacs (was: integer overflow) Richard Stallman 2010-04-11 23:33 ` Thomas Lord 2010-04-12 12:30 ` Richard Stallman 2010-04-12 20:05 ` Thomas Lord 2010-04-13 12:44 ` Guile in Emacs Bruce Stephens 2010-04-13 15:51 ` Thomas Lord 2010-04-13 16:07 ` Stefan Monnier 2010-04-13 18:56 ` Thomas Lord 2010-04-13 19:22 ` Christian Lynbech 2010-04-14 10:14 ` Bruce Stephens 2010-04-14 14:10 ` joakim 2010-04-13 19:13 ` Christian Lynbech 2010-04-14 1:47 ` Thomas Lord 2010-04-14 3:33 ` Christian Lynbech 2010-04-14 23:33 ` Richard Stallman 2010-04-14 5:02 ` Richard Stallman 2010-04-14 6:45 ` christian.lynbech 2010-04-14 19:07 ` Thomas Lord 2010-04-14 19:34 ` Bruce Stephens 2010-04-14 20:09 ` Jose A. Ortega Ruiz 2010-04-15 7:34 ` christian.lynbech 2010-04-14 23:33 ` Richard Stallman 2010-04-15 3:52 ` Drew Adams 2010-04-15 6:01 ` David Kastrup 2010-04-15 6:54 ` Drew Adams 2010-04-15 11:59 ` Jeff Clough 2010-04-15 12:49 ` christian.lynbech 2010-04-15 13:54 ` Jeff Clough 2010-04-15 14:03 ` Lennart Borgman 2010-04-15 16:13 ` Drew Adams 2010-04-16 13:48 ` Jeff Clough 2010-04-16 14:03 ` christian.lynbech 2010-04-16 14:25 ` Jeff Clough 2010-04-16 14:25 ` Drew Adams 2010-04-16 14:39 ` David Kastrup 2010-04-16 14:40 ` Jeff Clough 2010-04-16 8:27 ` christian.lynbech 2010-04-17 4:41 ` Richard Stallman 2010-04-19 7:52 ` christian.lynbech 2010-04-16 22:29 ` Emacs Info manuals (was: Guile in Emacs) Juri Linkov 2010-04-15 16:11 ` Guile in Emacs Drew Adams 2010-04-15 7:21 ` christian.lynbech 2010-04-15 7:36 ` David Kastrup 2010-04-15 8:34 ` christian.lynbech 2010-04-15 9:06 ` David Kastrup 2010-04-15 9:45 ` Helmut Eller 2010-04-15 10:39 ` christian.lynbech 2010-04-15 18:47 ` Richard Stallman 2010-04-15 22:42 ` Harald Hanche-Olsen 2010-04-15 22:50 ` Harald Hanche-Olsen 2010-04-17 4:40 ` Richard Stallman 2010-04-15 23:02 ` Helmut Eller 2010-04-17 4:40 ` Richard Stallman 2010-04-17 6:46 ` Helmut Eller 2010-04-17 19:55 ` Richard Stallman 2010-04-14 13:30 ` John Wiegley 2010-04-14 14:18 ` Helmut Eller 2010-04-14 15:40 ` Tom Tromey 2010-04-14 7:51 ` David Kastrup 2010-04-14 8:42 ` christian.lynbech 2010-04-14 9:55 ` immanuel litzroth 2010-04-14 10:28 ` christian.lynbech 2010-04-14 11:25 ` Stephen J. Turnbull 2010-04-14 12:26 ` christian.lynbech 2010-04-14 16:49 ` Ken Raeburn 2010-04-14 18:29 ` Tom Tromey 2010-04-14 20:02 ` Ken Raeburn 2010-04-14 11:23 ` Jeff Clough 2010-04-14 13:11 ` Stephen J. Turnbull 2010-04-14 13:11 ` Stephen Eilert 2010-04-14 13:49 ` Helmut Eller 2010-04-14 15:47 ` Tom Tromey 2010-04-14 16:41 ` Drew Adams 2010-04-14 20:10 ` David De La Harpe Golden 2010-04-15 10:38 ` Leo 2010-03-06 19:04 ` integer overflow Helmut Eller 2010-03-06 21:26 ` Stefan Monnier 2010-03-07 7:51 ` Richard Stallman 2010-03-07 19:05 ` Johan Bockgård 2010-03-06 20:35 ` Chong Yidong 2010-03-13 3:10 ` Next pretest, and branching plans Christoph 2010-03-13 7:42 ` Eli Zaretskii 2010-03-13 14:54 ` Christoph 2010-03-13 18:30 ` Stefan Monnier 2010-03-13 19:06 ` Eli Zaretskii 2010-03-14 2:38 ` Jason Rumney 2010-03-14 2:50 ` Christoph 2010-03-14 3:07 ` Jason Rumney 2010-03-14 17:55 ` Eli Zaretskii 2010-03-17 0:29 ` Christoph 2010-03-17 4:14 ` Eli Zaretskii 2010-03-17 12:44 ` Jason Rumney 2010-02-18 11:02 Chong Yidong 2010-02-18 15:29 ` Drew Adams 2010-02-20 12:25 ` Leo 2010-02-20 13:05 ` Sean Sieger 2010-02-20 17:02 ` Drew Adams 2010-02-28 12:36 ` Sean Sieger 2010-02-28 15:13 ` Lennart Borgman 2010-02-20 16:52 ` Drew Adams 2010-02-20 17:35 ` Drew Adams 2010-02-20 19:45 ` Eli Zaretskii 2010-02-20 20:39 ` Drew Adams 2010-02-20 20:53 ` Lennart Borgman 2010-02-21 0:11 ` Lennart Borgman 2010-02-21 4:11 ` Eli Zaretskii 2010-02-20 17:51 ` Eli Zaretskii 2010-02-20 18:35 ` Drew Adams 2010-02-20 19:49 ` Eli Zaretskii 2010-02-20 18:36 ` Chong Yidong 2010-02-20 18:40 ` Drew Adams 2010-02-20 18:54 ` Lennart Borgman 2010-02-20 19:15 ` Drew Adams 2010-02-20 19:08 ` Lennart Borgman
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.