unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
* Upgrading suggestions
@ 2011-10-04 17:28 Perry Smith
  2011-10-04 18:09 ` Jambunathan K
                   ` (2 more replies)
  0 siblings, 3 replies; 5+ messages in thread
From: Perry Smith @ 2011-10-04 17:28 UTC (permalink / raw)
  To: help-gnu-emacs List

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




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Upgrading suggestions
  2011-10-04 17:28 Upgrading suggestions Perry Smith
@ 2011-10-04 18:09 ` Jambunathan K
  2011-10-04 20:32 ` S Boucher
  2011-10-06 19:19 ` Ken Goldman
  2 siblings, 0 replies; 5+ messages in thread
From: Jambunathan K @ 2011-10-04 18:09 UTC (permalink / raw)
  To: Perry Smith; +Cc: help-gnu-emacs List


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
>
>
>

-- 



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Upgrading suggestions
  2011-10-04 17:28 Upgrading suggestions Perry Smith
  2011-10-04 18:09 ` Jambunathan K
@ 2011-10-04 20:32 ` S Boucher
  2011-10-06 19:19 ` Ken Goldman
  2 siblings, 0 replies; 5+ messages in thread
From: S Boucher @ 2011-10-04 20:32 UTC (permalink / raw)
  To: Perry Smith, help-gnu-emacs List





----- 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 ....))




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Upgrading suggestions
  2011-10-04 17:28 Upgrading suggestions Perry Smith
  2011-10-04 18:09 ` Jambunathan K
  2011-10-04 20:32 ` S Boucher
@ 2011-10-06 19:19 ` Ken Goldman
  2 siblings, 0 replies; 5+ messages in thread
From: Ken Goldman @ 2011-10-06 19:19 UTC (permalink / raw)
  To: help-gnu-emacs

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
>
>
>





^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Upgrading suggestions
       [not found]   ` <j82j09$fun$3@reader1.panix.com>
@ 2011-10-24  3:38     ` Jason Earl
  0 siblings, 0 replies; 5+ messages in thread
From: Jason Earl @ 2011-10-24  3:38 UTC (permalink / raw)
  To: help-gnu-emacs

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2011-10-24  3:38 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-10-04 17:28 Upgrading suggestions Perry Smith
2011-10-04 18:09 ` Jambunathan K
2011-10-04 20:32 ` S Boucher
2011-10-06 19:19 ` Ken Goldman
     [not found] <mailman.5127.1317749352.939.help-gnu-emacs@gnu.org>
     [not found] ` <87fwj8tadw.fsf@notengoamigos.org>
     [not found]   ` <j82j09$fun$3@reader1.panix.com>
2011-10-24  3:38     ` Jason Earl

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).