Re: [comp.emacs.xemacs] Package incompatibility

>>>>> "mb" == Martin Buchholz <martin(a)xemacs.org&gt; writes: SJT> been lobotomized. Again, IUTPC. mb> ^^^^ ^^^^^ what? ????? SJT> "If I Understand The Process Correctly." (I seem to have dropped an I SJT> there.) mb> You mean mb> (defmacro fast-marker-position (x) (+ x 0)) mb> as a speed hack? SJT> I had more in mind something like SJT> (defmacro total-line-width (this-start column-width) SJT> `(progn SJT> (do-side-effects ,this-start ,column-width) SJT> (+ ,this-start ,column-width))) SJT> which might get called as (total-line-width (current-column) 0) at the SJT> right margin, since there's no space to add another text column. SJT> AFAICT what the byte compiler sees after macro expansion is SJT> (progn SJT> (do-side-effects (current-column) 0) SJT> (+ this-start 0)) SJT> which gets optimized to SJT> (progn SJT> (do-side-effects (current-column) 0) SJT> this-start) This particular example is not a problem since (current-column) is an integer. And the default for most operations is to use integers (e.g. (point)), rather than markers (e.g. (point-marker)), which means that markers tend to only be used where they their markerness is needed. And markers can be used almost everywhere that the equivalent integers can, so leaving the markers unconverted is usually OK. SJT> I thought it was clear that that's what worried me all along. mb> I still think optimizing (+ x 0) to x was the Right Thing to mb> do. SJT> *shrug* SJT> Maybe this will not occasion a bug report for decades. But SJT> mathematical certainty is such a rare and wonderful thing, I thought SJT> I'd advocate it. Anyways, let's spend some time fixing Real Bugs. No shortage of those.