long-standing set-up errors on upgrade (elimination of x cut buffers)

long-standing set-up errors on upgrade (elimination of x cut buffers)

[Joe Brenner]

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)
  (setq interprogram-paste-function 'x-cut-buffer-or-selection-value)

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

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

Re: long-standing set-up errors on upgrade (elimination of x cut buffers)

[Eli Zaretskii]

> Date: Tue, 14 Sep 2010 18:10:26 -0700
> From: Joe Brenner <doom@kzsu.stanford.edu>
> 
>   (setq x-select-enable-clipboard t)
>   (setq interprogram-paste-function 'x-cut-buffer-or-selection-value)
> 
> 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

Please submit a bug report about this.  We probably need to leave
behind an alias for that function, which just uses the clipboard.

Re: long-standing set-up errors on upgrade (elimination of x cut buffers)

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>>   (setq interprogram-paste-function 'x-cut-buffer-or-selection-value)
>>
>> 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
>
> Please submit a bug report about this.  We probably need to leave
> behind an alias for that function, which just uses the clipboard.

I've just checked in the obsolete alias definition.

Re: long-standing set-up errors on upgrade (elimination of x cut buffers)

[Jan Djärv]

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.

Re: long-standing set-up errors on upgrade (elimination of x cut buffers)

[Lars Magne Ingebrigtsen]

Joe Brenner <doom@kzsu.stanford.edu> writes:

> (Of late, the gnus emacs team seems to be having trouble with the idea
> of stable interfaces.)

Do you have anything in particular in mind?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: long-standing set-up errors on upgrade (elimination of x cut buffers)

[Joe Brenner]

Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:
> Joe Brenner <doom@kzsu.stanford.edu> writes:
>
> > (Of late, the gnus emacs team seems to be having trouble with the idea
> > of stable interfaces.)
>
> Do you have anything in particular in mind?

I could name a few things.

One example I'm not sure about any more: I could swear emacs had
suddenly switched to "typing-replaces-selection" behavior (standard on
post-Macintosh interfaces perhaps, but never in emacs).  Now I don't
think I'm seeing that behavior any more.

There was some discussion on usenet recently about subtle changes
to the behavior of next-line.

One that's been a minor annoyance to me is that repeated C-l's are no
longer a no-op, but flip the display around in a new way that took some
getting used to.

Re: long-standing set-up errors on upgrade (elimination of x cut buffers)

[Chad Brown]

[-- Attachment #1: Type: text/plain, Size: 1954 bytes --]

On Sep 19, 2010, at 3:39 PM, Joe Brenner wrote:

> (Of late, the gnus emacs team seems to be having trouble with the idea
> of stable interfaces.)


I don't think any of these have anything to do with gnus, but are definitely 
interface changes in emacs, potentially in the development trunk (i.e. the 
bleeding edge).

> One example I'm not sure about any more: I could swear emacs had
> suddenly switched to "typing-replaces-selection" behavior (standard on
> post-Macintosh interfaces perhaps, but never in emacs).  Now I don't
> think I'm seeing that behavior any more.

You would see this behavior if you were using the development trunk (i.e.
bzr HEAD) of emacs 24, unless you turned it off.  That interface is still
somewhat `under development' at the moment, so changes are expected.

Unless something changes, I would guess that ``typing replaces selection''
will be the default behavior in a future emacs release.  

> One that's been a minor annoyance to me is that repeated C-l's are no
> longer a no-op, but flip the display around in a new way that took some
> getting used to.

You might want to customize the variable recenter-positions to disable 
this new feature (which seems to have been introduced in Emacs 23.2).
I was quite pleasantly surprised to find it myself, as it more elegantly
solves a problem for which I'd long had a custom key binding.

There are very few changes to the emacs interface that aren't easily 
turned off.  If you're using the development head straight from the source
repository, you should expect to see these sort of changes now and then;
if such changes are unacceptable to you, then you probably shouldn't be
trying to use the active development code.  If you need some patch or bug
fix from the development HEAD but don't want to live on the bleeding edge,
I would suggest filling a bug report and asking if we can please put out a 
bug-fix release for your particular issue.

Hope that helps,
*Chad


[-- Attachment #2: Type: text/html, Size: 2819 bytes --]

Re: long-standing set-up errors on upgrade (elimination of x cut buffers)

[Stefan Monnier]

> Unless something changes, I would guess that ``typing replaces selection''
> will be the default behavior in a future Emacs release.  

While it's always a possibility, I don't expect it to happen any time
soon.  Deleting the active region in response to backspace or delete is
appreciated by many people and hurts relatively little (tho it does hurt
occasionally), so it's a tradeoff we're willing to make in Emacs-24.
But for "typing replaces the selection", the pain is a good bit higher,
so I'd only expect it to happen if/when we get transient-mark-mode to
a state where everyone can live with it, which seems like it's not going
to happen any time soon.


        Stefan

Re: long-standing set-up errors on upgrade (elimination of x cut buffers)

[durducengiz]

-- Joe Brenner wrote : 

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)
  (setq interprogram-paste-function 'x-cut-buffer-or-selection-value)

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

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




--
This message was sent on behalf of durducengiz@gmail.com at openSubscriber.com
http://opensubscriber.com/message/emacs-devel@gnu.org/14552599.html