unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Jan Djärv" <jan.h.d@swipnet.se>
To: Joe Brenner <doom@kzsu.stanford.edu>
Cc: emacs-devel@gnu.org
Subject: Re: long-standing set-up errors on upgrade (elimination of x cut buffers)
Date: Wed, 15 Sep 2010 06:39:08 +0200	[thread overview]
Message-ID: <4C904DEC.9070902@swipnet.se> (raw)
In-Reply-To: <201009150110.o8F1AQGX093877@kzsu.stanford.edu>



Joe Brenner skrev 2010-09-15 03.10:
> I see in NEWS
>
>    "*** Support for X cut buffers has been removed."
>
> For some time, I've had this in my emacs init files:
>
>    (setq x-select-enable-clipboard t)

This is now the default in Emacs 24.

>    (setq interprogram-paste-function 'x-cut-buffer-or-selection-value)

AFAIK, this has been the default since forever, why are you setting it?

>
> Now, with a recent build of bzr emacs, I see that leading to this error
> message:
>
>    current-kill:
>      Symbol's function definition is void: x-cut-buffer-or-selection-value

Replace with x-selection-value, but there is no point in setting it to the 
same value it already has.

>
> I personally am not actually fussy about the details of how X the
> clipboard talks to the kill-ring and vice versa.  I need there to be a
> way to do it, but it almost doesn't matter which way it is (e.g. I prefer
> a yank to snag the current X selection, but if I need to do a Control C
> first before that will work, I can live with that).
>
> But what I do find really disturbing is when stuff I've had in my set-up
> for years suddenly causes problems because I did an upgrade.
>
> (Of late, the gnus emacs team seems to be having trouble with the idea
> of stable interfaces.)

It is fairly common to have in .emacs stuff like:

(if (>= emacs-major-version 20)
    ...

for version specific settings.

We are moving from 23 to 24, i.e. a major upgrade.  Thus interfaces are not 
guaranteed to be the same.  Furthermore, in the development branches, things 
are likely to break from time to time.  Don't use Emacs trunk unless you can 
live with that.

	Jan D.





  parent reply	other threads:[~2010-09-15  4:39 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-15  1:10 long-standing set-up errors on upgrade (elimination of x cut buffers) Joe Brenner
2010-09-15  4:03 ` Eli Zaretskii
2010-09-16 22:47   ` Chong Yidong
2010-09-15  4:39 ` Jan Djärv [this message]
2010-09-15  6:49 ` Lars Magne Ingebrigtsen
2010-09-19 22:39   ` Joe Brenner
2010-09-20 16:24     ` Chad Brown
2010-09-20 22:04       ` Stefan Monnier
2010-09-16 11:02 ` durducengiz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C904DEC.9070902@swipnet.se \
    --to=jan.h.d@swipnet.se \
    --cc=doom@kzsu.stanford.edu \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

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