emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: supporting older versions of emacs (was: Re: bootstrap fails AND how


From: Dan Nicolaescu
Subject: Re: supporting older versions of emacs (was: Re: bootstrap fails AND how about fixing the byte-compiler?)
Date: Wed, 16 Jan 2008 15:40:01 -0800

Hi Alan,

Alan Mackenzie <address@hidden> writes:


  > > 21.1 was released in October 2001. 
  > > Is the number of people that do not upgrade to emacs-21, but still want
  > > to use the latest cc-mode significant enough to be worth the trouble?
  > 
  > Upgrading an unfamiliar piece of software is a nightmare of fear,
  > uncertainty and doubt.  (And Emacs is "unfamiliar" to nearly all its
  > users in this context.)  Will the new version of the software work?  More
  > to the point how much work will it take to get it to work, iron out the
  > niggly little differences, and so on?

The same argument applies to installing a new version of cc-mode too,
doesn't it?

  > I think there will be a lot of Emacs users still on old versions, though
  > they make very little noise.  I don't think giving them compatibility
  > headaches is the best way of persuading them to upgrade.
  > 
  > However, this is just my personal opinion.  ;-)

Well, you are the maintainer, so your opinion matters.

  > > It's obviously your choice, but is it worth it to still support
  > > emacs-20? 
  > 
  > Yes, I think so, given how little effort that actually takes.

If nothing changes, not much effort is required. 
If only more recent versions of emacs/XEmacs are supported, then a lot
of cruft can go away. A cursory look over the code say that
cc-bytecomp-defvar, cc-bytecomp-fboundp and maybe cc-bytecomp-defun can
probably go.

Compare the bytecode for this: 

(defmacro c-put-overlay (from to property value)
  ;; Put an overlay/extent covering the given range in the current
  ;; buffer.  It's currently undefined whether it's front/end sticky
  ;; or not.  The overlay/extent object is returned.
  (if (cc-bytecomp-fboundp 'make-overlay)
      ;; Emacs.
      `(let ((ol (make-overlay ,from ,to)))
       (overlay-put ol ,property ,value)
        ol)
    ;; XEmacs.
    `(let ((ext (make-extent ,from ,to)))
       (set-extent-property ext ,property ,value)
       ext)))

With this:

(defmacro c-put-overlay (from to property value)
  ;; Put an overlay/extent covering the given range in the current
  ;; buffer.  It's currently undefined whether it's front/end sticky
  ;; or not.  The overlay/extent object is returned.
  (if (featurep 'emacs)
      ;; Emacs.
      `(let ((ol (make-overlay ,from ,to)))
       (overlay-put ol ,property ,value)
        ol)
    ;; XEmacs.
    `(let ((ext (make-extent ,from ,to)))
       (set-extent-property ext ,property ,value)
       ext)))

Not sure if this would make a difference from the performance point of
view (it might for c-point for example), but reducing the amount of
cc-elisp in favor of elisp seems like a good idea.

Just my 2 cents.

        --dan





reply via email to

[Prev in Thread] Current Thread [Next in Thread]