* Strange change in bytecmop.el @ 2005-07-21 21:49 Stefan Monnier 2005-07-21 23:12 ` Juanma Barranquero 2005-07-22 22:52 ` Richard M. Stallman 0 siblings, 2 replies; 20+ messages in thread From: Stefan Monnier @ 2005-07-21 21:49 UTC (permalink / raw) Regarding the change below: * emacs-lisp/bytecomp.el (byte-compile-and-recursion): New function. (byte-compile-and): Use byte-compile-and-recursion. (byte-compile-or-recursion): New function. (byte-compile-or): Use that. (byte-compile-if): Guard the else-clause too. (byte-compile-maybe-guarded): Handle (not (featurep 'emacs)). the last part not only is strange because (featurep 'emacs) is never used (since Emacs does not provide the `emacs' feature) but also because it tries to handle (featurep 'xemacs) even though that's already handled in byteopt.el where we do: (put 'featurep 'byte-optimizer 'byte-optimize-featurep) (defun byte-optimize-featurep (form) ;; Emacs-21's byte-code doesn't run under XEmacs anyway, so we can ;; safely optimize away this test. (if (equal '((quote xemacs)) (cdr-safe form)) nil form)) -- Stefan ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Strange change in bytecmop.el 2005-07-21 21:49 Strange change in bytecmop.el Stefan Monnier @ 2005-07-21 23:12 ` Juanma Barranquero 2005-07-22 19:43 ` Stefan Monnier 2005-07-22 22:52 ` Richard M. Stallman 1 sibling, 1 reply; 20+ messages in thread From: Juanma Barranquero @ 2005-07-21 23:12 UTC (permalink / raw) Cc: emacs-devel On 7/21/05, Stefan Monnier <monnier@iro.umontreal.ca> wrote: > the last part not only is strange because (featurep 'emacs) is never used > (since Emacs does not provide the `emacs' feature) Yeah, I pointed this out in a message a few days ago. Perhaps it'd be useful to define the feature 'emacs, but even so it won't be a reliable way to detect GNU Emacs for years and years... > but also because it tries > to handle (featurep 'xemacs) even though that's already handled in > byteopt.el where we do: I think the handling in byteopt.el is about generating bytecode (or not doing it, for XEmacs-specific code) while the one in bytecomp.el is about not issuing warnings for XEmacs features. For example, it silences a warning in flymake.el about the use of `multiple-value-bind'. -- /L/e/k/t/u ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Strange change in bytecmop.el 2005-07-21 23:12 ` Juanma Barranquero @ 2005-07-22 19:43 ` Stefan Monnier 0 siblings, 0 replies; 20+ messages in thread From: Stefan Monnier @ 2005-07-22 19:43 UTC (permalink / raw) Cc: emacs-devel > I think the handling in byteopt.el is about generating bytecode (or > not doing it, for XEmacs-specific code) while the one in bytecomp.el > is about not issuing warnings for XEmacs features. For example, it > silences a warning in flymake.el about the use of > `multiple-value-bind'. The one in byteopt.el was introduced mostly to remove spurious warnings. The fact that it optimizes the bytecode was just a nicve side-effect. So I'm wondering in which circumstance the new code is useful/necessary. Stefan ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Strange change in bytecmop.el 2005-07-21 21:49 Strange change in bytecmop.el Stefan Monnier 2005-07-21 23:12 ` Juanma Barranquero @ 2005-07-22 22:52 ` Richard M. Stallman 2005-07-23 18:45 ` Stefan Monnier 1 sibling, 1 reply; 20+ messages in thread From: Richard M. Stallman @ 2005-07-22 22:52 UTC (permalink / raw) Cc: emacs-devel the last part not only is strange because (featurep 'emacs) is never used (since Emacs does not provide the `emacs' feature) I didn't realize that at the time, but maybe we should add it. but also because it tries to handle (featurep 'xemacs) even though that's already handled in byteopt.el where we do: Well, it didn't always do the job. This code is needed. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Strange change in bytecmop.el 2005-07-22 22:52 ` Richard M. Stallman @ 2005-07-23 18:45 ` Stefan Monnier 2005-07-24 14:41 ` Richard M. Stallman 2005-07-24 14:41 ` Richard M. Stallman 0 siblings, 2 replies; 20+ messages in thread From: Stefan Monnier @ 2005-07-23 18:45 UTC (permalink / raw) Cc: emacs-devel > the last part not only is strange because (featurep 'emacs) is never used > (since Emacs does not provide the `emacs' feature) > I didn't realize that at the time, but maybe we should add it. Why bother. People already use (featurep 'xemacs) in order to check whether they're running on Emacs or XEmacs. So (featurep 'emacs) would be redundant. > but also because it tries > to handle (featurep 'xemacs) even though that's already handled in > byteopt.el where we do: > Well, it didn't always do the job. > This code is needed. Could you give at least some example so we can add relevant comments explaining the apparent redundancy? Stefan ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Strange change in bytecmop.el 2005-07-23 18:45 ` Stefan Monnier @ 2005-07-24 14:41 ` Richard M. Stallman 2005-07-24 16:44 ` David Kastrup 2005-07-24 14:41 ` Richard M. Stallman 1 sibling, 1 reply; 20+ messages in thread From: Richard M. Stallman @ 2005-07-24 14:41 UTC (permalink / raw) Cc: emacs-devel Why bother. People already use (featurep 'xemacs) in order to check whether they're running on Emacs or XEmacs. So (featurep 'emacs) would be redundant. But that way the code always says (featurep 'xemacs). ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Strange change in bytecmop.el 2005-07-24 14:41 ` Richard M. Stallman @ 2005-07-24 16:44 ` David Kastrup 2005-07-25 1:43 ` Richard M. Stallman 0 siblings, 1 reply; 20+ messages in thread From: David Kastrup @ 2005-07-24 16:44 UTC (permalink / raw) Cc: Stefan Monnier, emacs-devel "Richard M. Stallman" <rms@gnu.org> writes: > Why bother. People already use (featurep 'xemacs) in order to > check whether they're running on Emacs or XEmacs. So (featurep > 'emacs) would be redundant. > > But that way the code always says (featurep 'xemacs). Naturally. (featurep 'xemacs) means "here is an exception for the sake of XEmacs". We don't have to make exceptions for the sake of Emacs. We are the main line. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Strange change in bytecmop.el 2005-07-24 16:44 ` David Kastrup @ 2005-07-25 1:43 ` Richard M. Stallman 2005-07-25 1:59 ` David Kastrup 0 siblings, 1 reply; 20+ messages in thread From: Richard M. Stallman @ 2005-07-25 1:43 UTC (permalink / raw) Cc: monnier, emacs-devel Naturally. (featurep 'xemacs) means "here is an exception for the sake of XEmacs". We don't have to make exceptions for the sake of Emacs. We are the main line. That's a valid point. At the same time, it means that our code is full of mentions of XEmacs. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Strange change in bytecmop.el 2005-07-25 1:43 ` Richard M. Stallman @ 2005-07-25 1:59 ` David Kastrup 2005-07-25 11:39 ` Robert J. Chassell ` (2 more replies) 0 siblings, 3 replies; 20+ messages in thread From: David Kastrup @ 2005-07-25 1:59 UTC (permalink / raw) Cc: monnier, emacs-devel "Richard M. Stallman" <rms@gnu.org> writes: > Naturally. (featurep 'xemacs) means "here is an exception for the > sake of XEmacs". > > We don't have to make exceptions for the sake of Emacs. We are the > main line. > > That's a valid point. At the same time, it means that our code is > full of mentions of XEmacs. Sure. As long as we have code intended to run with XEmacs, calling it anything but code intended to run with XEmacs would be obfuscate. The only way around that would be to completely remove all such code. This does not make sense except where code has fallen out of active maintenance and nobody knows whether it is working, anyway. XEmacs, after all, does meet the criteria of free software. Forcing the maintainers of subsystems that are willing to support XEmacs to have different distribution paths for versions that also work with XEmacs would be quite out of proportion in my opinion. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Strange change in bytecmop.el 2005-07-25 1:59 ` David Kastrup @ 2005-07-25 11:39 ` Robert J. Chassell 2005-07-25 12:51 ` David Kastrup 2005-07-25 16:03 ` Richard M. Stallman 2005-07-26 8:12 ` Juanma Barranquero 2 siblings, 1 reply; 20+ messages in thread From: Robert J. Chassell @ 2005-07-25 11:39 UTC (permalink / raw) David Kastrup <dak@gnu.org> wrote, XEmacs, after all, does meet the criteria of free software. Actually and unfortunately, we do not know whether it does. Certainly, the main authors intend that. But they have not collected the legal paperwork necessary to prove it to a hostile court. I agree that Forcing the maintainers ... to have different distribution paths ... is wrong. But the sad truth is that legally (although not morally) the effort is a waste for themselves and others until the very bothersome legal requirements are met. -- Robert J. Chassell bob@rattlesnake.com GnuPG Key ID: 004B4AC8 http://www.rattlesnake.com http://www.teak.cc ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Strange change in bytecmop.el 2005-07-25 11:39 ` Robert J. Chassell @ 2005-07-25 12:51 ` David Kastrup 0 siblings, 0 replies; 20+ messages in thread From: David Kastrup @ 2005-07-25 12:51 UTC (permalink / raw) Cc: emacs-devel "Robert J. Chassell" <bob@rattlesnake.com> writes: > David Kastrup <dak@gnu.org> wrote, > > XEmacs, after all, does meet the criteria of free software. > > Actually and unfortunately, we do not know whether it does. > > Certainly, the main authors intend that. But they have not > collected the legal paperwork necessary to prove it to a hostile > court. It shares this property with a large body of free software. Not everybody is as careful as the FSF with regard to copyright assignments. Following your way of reasoning, Linux is a non-free operating system kernel, and we should remove all references to GNU/Linux from Emacs. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Strange change in bytecmop.el 2005-07-25 1:59 ` David Kastrup 2005-07-25 11:39 ` Robert J. Chassell @ 2005-07-25 16:03 ` Richard M. Stallman 2005-07-25 17:21 ` David Kastrup 2005-07-26 8:12 ` Juanma Barranquero 2 siblings, 1 reply; 20+ messages in thread From: Richard M. Stallman @ 2005-07-25 16:03 UTC (permalink / raw) Cc: monnier, emacs-devel Sure. As long as we have code intended to run with XEmacs, calling it anything but code intended to run with XEmacs would be obfuscate. The option we're actually talking about is not obfuscated. (if (featurep 'emacs) ... ...) ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Strange change in bytecmop.el 2005-07-25 16:03 ` Richard M. Stallman @ 2005-07-25 17:21 ` David Kastrup 0 siblings, 0 replies; 20+ messages in thread From: David Kastrup @ 2005-07-25 17:21 UTC (permalink / raw) Cc: monnier, emacs-devel "Richard M. Stallman" <rms@gnu.org> writes: > Sure. As long as we have code intended to run with XEmacs, calling it > anything but code intended to run with XEmacs would be obfuscate. > > The option we're actually talking about is not obfuscated. > > (if (featurep 'emacs) > ... > ...) Frankly, I can't make head nor tails out of it. If this is supposed to differentiate just XEmacs (and it will rule out any older version of Emacs, too, as collateral), then I find it offensive that the _default_ code path is for XEmacs, and we have to make an _exception_ for Emacs. This is so backwards that I consider it repulsive. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Strange change in bytecmop.el 2005-07-25 1:59 ` David Kastrup 2005-07-25 11:39 ` Robert J. Chassell 2005-07-25 16:03 ` Richard M. Stallman @ 2005-07-26 8:12 ` Juanma Barranquero 2005-07-26 8:44 ` David Kastrup 2 siblings, 1 reply; 20+ messages in thread From: Juanma Barranquero @ 2005-07-26 8:12 UTC (permalink / raw) Cc: emacs-devel, rms, monnier On 7/25/05, David Kastrup <dak@gnu.org> wrote: > Sure. As long as we have code intended to run with XEmacs, calling it > anything but code intended to run with XEmacs would be obfuscate. > > The only way around that would be to completely remove all such code. > This does not make sense except where code has fallen out of active > maintenance and nobody knows whether it is working, anyway. IMHO, maintaining "(if (boundp 'xemacs)..)" in Emacs code makes sense when the package affected has a life *outside* Emacs and XEmacs distributions. For those packages that only live in Emacs and XEmacs source trees, there are already lots of site-specific changes, and frankly, for us Emacs maintainers the "(boundp 'xemacs)" bit brings no benefit: we're not going to sync with XEmacs code because of legal issues, and it's more code to maintain or at least to consciously ignore when fixing an issue or otherwise modifying the package. However, supporting "(boundp 'emacs)" would make sense. I don't think we're in the business of telling outside elisp developers whether they should consider Emacs or XEmacs the "main line". If a guy uses XEmacs and develops a package for it, and he's nice enough to make allowances for it to work on Emacs, it's a bit absurd to ask him to consider Emacs the main line and put XEmacs code inside guards. Supporting the 'emacs feature is not a big deal, but it is certainly nicer to non-Emacs developers (at least long term). -- /L/e/k/t/u ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Strange change in bytecmop.el 2005-07-26 8:12 ` Juanma Barranquero @ 2005-07-26 8:44 ` David Kastrup 2005-07-26 10:09 ` Juanma Barranquero 2005-07-28 22:04 ` Kim F. Storm 0 siblings, 2 replies; 20+ messages in thread From: David Kastrup @ 2005-07-26 8:44 UTC (permalink / raw) Cc: emacs-devel, rms, monnier Juanma Barranquero <lekktu@gmail.com> writes: > However, supporting "(boundp 'emacs)" would make sense. So, just _when_ would you use it? > I don't think we're in the business of telling outside elisp > developers whether they should consider Emacs or XEmacs the "main > line". You just said above that making the distinction only makes sense for packages maintained externally. > If a guy uses XEmacs and develops a package for it, and he's nice > enough to make allowances for it to work on Emacs, it's a bit absurd > to ask him to consider Emacs the main line and put XEmacs code > inside guards. Supporting the 'emacs feature is not a big deal, but > it is certainly nicer to non-Emacs developers (at least long term). I don't see that. I am afraid of people putting (boundp 'emacs) into code also for things that Emacs happens to have _now_, even though XEmacs might gain them in a later synch, or just putting (boundp 'emacs) habitually in without thinking anything about it. I really think that this is one change that we are better off without. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Strange change in bytecmop.el 2005-07-26 8:44 ` David Kastrup @ 2005-07-26 10:09 ` Juanma Barranquero 2005-07-26 12:38 ` David Kastrup 2005-07-28 22:04 ` Kim F. Storm 1 sibling, 1 reply; 20+ messages in thread From: Juanma Barranquero @ 2005-07-26 10:09 UTC (permalink / raw) Cc: emacs-devel, rms, monnier On 7/26/05, David Kastrup <dak@gnu.org> wrote: > So, just _when_ would you use it? Me? I wouldn't use it. I don't develop packages with XEmacs as the primary target. I don't ever intend to. > You just said above that making the distinction only makes sense for > packages maintained externally. And so, what? Obviously, if we added the feature 'emacs it *would not* be for us to use, just to help outside developers. That's the exact same reason why some functions we've added are XEmacs-compatible (I just happen to hate the names `define-obsolete-function-alias' and `define-obsolete-variable-alias', which I would make shorter in a blink, but they were added as such because XEmacs already define them, IIRC). > I don't see that. I am afraid of people putting (boundp 'emacs) into > code also for things that Emacs happens to have _now_, even though > XEmacs might gain them in a later synch, or just putting (boundp > 'emacs) habitually in without thinking anything about it. That's no different of using "(fboundp 'feature-such-and-such)" for features Emacs already have. And, worrying about people using things without thinking smells a bit of patronizing, to me. (No insult intended, I can assure you.) > I really think that this is one change that we are better off without. I didn't propose it, so I'm hardly going to enter a fight for it. I just happen to think is not only not as outrageous as you made it sound (when you said "This is so backwards that I consider it repulsive."), but I even think that could be useful. -- /L/e/k/t/u ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Strange change in bytecmop.el 2005-07-26 10:09 ` Juanma Barranquero @ 2005-07-26 12:38 ` David Kastrup 2005-07-26 12:58 ` Juanma Barranquero 0 siblings, 1 reply; 20+ messages in thread From: David Kastrup @ 2005-07-26 12:38 UTC (permalink / raw) Cc: emacs-devel, rms, monnier Juanma Barranquero <lekktu@gmail.com> writes: > On 7/26/05, David Kastrup <dak@gnu.org> wrote: > >> I really think that this is one change that we are better off without. > > I didn't propose it, so I'm hardly going to enter a fight for it. I > just happen to think is not only not as outrageous as you made it > sound (when you said "This is so backwards that I consider it > repulsive."), but I even think that could be useful. Well, we have to agree to disagree, then. I can see no even slightly relevant political advantages for this (I am apparently in disagreement with Richard here, even given rather similar goals), and it adds no new functionality whatsoever, at the cost of backward incompatibilities. If there are no new points to make, I suggest we all just wait with baited breath what Richard will decide, and then either of us will have the opportunity to be exasperated. Though it does not sound like you in particular would mind much either which way. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Strange change in bytecmop.el 2005-07-26 12:38 ` David Kastrup @ 2005-07-26 12:58 ` Juanma Barranquero 0 siblings, 0 replies; 20+ messages in thread From: Juanma Barranquero @ 2005-07-26 12:58 UTC (permalink / raw) Cc: emacs-devel, rms, monnier On 7/26/05, David Kastrup <dak@gnu.org> wrote: > Though it does not sound like > you in particular would mind much either which way. That's it. To me, the exasperation rate of the issue is almost zero. :) -- /L/e/k/t/u ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Strange change in bytecmop.el 2005-07-26 8:44 ` David Kastrup 2005-07-26 10:09 ` Juanma Barranquero @ 2005-07-28 22:04 ` Kim F. Storm 1 sibling, 0 replies; 20+ messages in thread From: Kim F. Storm @ 2005-07-28 22:04 UTC (permalink / raw) Cc: Juanma Barranquero, rms, monnier, emacs-devel David Kastrup <dak@gnu.org> writes: > I really think that this is one change that we are better off without. I agree. -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Strange change in bytecmop.el 2005-07-23 18:45 ` Stefan Monnier 2005-07-24 14:41 ` Richard M. Stallman @ 2005-07-24 14:41 ` Richard M. Stallman 1 sibling, 0 replies; 20+ messages in thread From: Richard M. Stallman @ 2005-07-24 14:41 UTC (permalink / raw) Cc: emacs-devel > Well, it didn't always do the job. > This code is needed. Could you give at least some example so we can add relevant comments explaining the apparent redundancy? I don't remember what it was, but the bug report was within the past three weeks. ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2005-07-28 22:04 UTC | newest] Thread overview: 20+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-07-21 21:49 Strange change in bytecmop.el Stefan Monnier 2005-07-21 23:12 ` Juanma Barranquero 2005-07-22 19:43 ` Stefan Monnier 2005-07-22 22:52 ` Richard M. Stallman 2005-07-23 18:45 ` Stefan Monnier 2005-07-24 14:41 ` Richard M. Stallman 2005-07-24 16:44 ` David Kastrup 2005-07-25 1:43 ` Richard M. Stallman 2005-07-25 1:59 ` David Kastrup 2005-07-25 11:39 ` Robert J. Chassell 2005-07-25 12:51 ` David Kastrup 2005-07-25 16:03 ` Richard M. Stallman 2005-07-25 17:21 ` David Kastrup 2005-07-26 8:12 ` Juanma Barranquero 2005-07-26 8:44 ` David Kastrup 2005-07-26 10:09 ` Juanma Barranquero 2005-07-26 12:38 ` David Kastrup 2005-07-26 12:58 ` Juanma Barranquero 2005-07-28 22:04 ` Kim F. Storm 2005-07-24 14:41 ` Richard M. Stallman
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.