Upgrading suggestions

Upgrading suggestions

[Perry Smith]

I thought I would toss out this question to this group.

Over time, hacks and tweaks that I've added to my emacs init files get incorporated into the official release (usually with a much better implementation).  I assume I'm not unique in this area.

How do others, when moving up to a new level of emacs, deal with this?  How do you (or perhaps you don't bother) find the things that have moved into the production version and start using those versions rather than the old version that you have.  e.g. ruby mode is now part of the distribution.  There are countless examples of this.

The biggest example I have is all of the "customize" features.  I still have old lisp code that is setting things up using old setq's instead of the new customized stuff.  That seems to work ok but sorta bothers me.

Thanks,
pedz

Re: Upgrading suggestions

[Jambunathan K]

The following are your friends.

C-h n
M-x customize-changed-options RET

> I thought I would toss out this question to this group.
>
> Over time, hacks and tweaks that I've added to my emacs init files get
> incorporated into the official release (usually with a much better
> implementation).  I assume I'm not unique in this area.
>
> How do others, when moving up to a new level of emacs, deal with this?
> How do you (or perhaps you don't bother) find the things that have
> moved into the production version and start using those versions
> rather than the old version that you have.  e.g. ruby mode is now part
> of the distribution.  There are countless examples of this.
>
> The biggest example I have is all of the "customize" features.  I
> still have old lisp code that is setting things up using old setq's
> instead of the new customized stuff.  That seems to work ok but sorta
> bothers me.


> Thanks,
> pedz
>
>
>

-- 

Re: Upgrading suggestions

[S Boucher]

----- Original Message -----

> How do others, when moving up to a new level of emacs, deal with this?

I add tests based on emacs-major-version and emacs-minor-version.  For example, if I overwrite/clobber a particular defun (like I've done for vc-git), I add a check on the version that will throw me an error if I run in a version of emacs I've yet to use.  This way, I know I have to go back and review whether I still need the hack or not.

(if (not (and (= emacs-major-version 23) (= emacs-minor-version 2)))
  (error "....")
  (defun ....))

Re: Upgrading suggestions

[Ken Goldman]

I confess that I use the 'if it isn't broken, don't fix it' approach.

Like you, I have a collection of ancient customizations.  I only remove 
them when something breaks, which is rare.

On 10/4/2011 1:28 PM, Perry Smith wrote:
> I thought I would toss out this question to this group.
>
> Over time, hacks and tweaks that I've added to my emacs init files
> get incorporated into the official release (usually with a much
> better implementation).  I assume I'm not unique in this area.
>
> How do others, when moving up to a new level of emacs, deal with
> this?  How do you (or perhaps you don't bother) find the things that
> have moved into the production version and start using those versions
> rather than the old version that you have.  e.g. ruby mode is now
> part of the distribution.  There are countless examples of this.
>
> The biggest example I have is all of the "customize" features.  I
> still have old lisp code that is setting things up using old setq's
> instead of the new customized stuff.  That seems to work ok but sorta
> bothers me.
>
> Thanks, pedz
>
>
>

Re: Upgrading suggestions

[Jason Earl]

On Sun, Oct 23 2011, David Combs wrote:

> In article <87fwj8tadw.fsf@notengoamigos.org>,
> Jason Earl  <jearl@notengoamigos.org> wrote:
>> <snip>
>>I think that the best way to deal with this is to run a version of Emacs
>>straight out of bzr.  Not only does this get you the newest toys before
>>everyone else, but it also allows you access to the new configuration
>>changes and such piecemeal instead of having to make a big jump from one
>>version to the next.
>>
>>If something does break your configuration, you can even complain on
>>emacs-devel while the issue is still fresh on the developers mind.
>>
>>Jason
>
> What is "bzr"?   (A misspelled ".bz"?)
>
> And where is this early version located?
>
> Thanks!
>
> David

bzr is the version control system that the Emacs project uses.

http://bazaar.canonical.com/en/

To get a copy of the Emacs trunk in a folder named "emacs-devel" you
would do (after installing bzr):

bzr branch bzr://bzr.savannah.gnu.org/emacs/trunk emacs-devel

For more information there is a wiki page here:

http://www.emacswiki.org/emacs/BzrForEmacsDevs

Basically I am encouraging you to use the development version of Emacs.
It is much snazzier than the released version, and if the Emacs
developers break your configuration you are in a good position to tell
them about it.

Jason