unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* long-standing set-up errors on upgrade (elimination of x cut buffers)
@ 2010-09-15  1:10 Joe Brenner
  2010-09-15  4:03 ` Eli Zaretskii
                   ` (3 more replies)
  0 siblings, 4 replies; 9+ messages in thread
From: Joe Brenner @ 2010-09-15  1:10 UTC (permalink / raw)
  To: emacs-devel


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




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

* Re: long-standing set-up errors on upgrade (elimination of x cut buffers)
  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
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2010-09-15  4:03 UTC (permalink / raw)
  To: Joe Brenner; +Cc: emacs-devel

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



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

* Re: long-standing set-up errors on upgrade (elimination of x cut buffers)
  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-15  4:39 ` Jan Djärv
  2010-09-15  6:49 ` Lars Magne Ingebrigtsen
  2010-09-16 11:02 ` durducengiz
  3 siblings, 0 replies; 9+ messages in thread
From: Jan Djärv @ 2010-09-15  4:39 UTC (permalink / raw)
  To: Joe Brenner; +Cc: emacs-devel



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.





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

* Re: long-standing set-up errors on upgrade (elimination of x cut buffers)
  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-15  4:39 ` Jan Djärv
@ 2010-09-15  6:49 ` Lars Magne Ingebrigtsen
  2010-09-19 22:39   ` Joe Brenner
  2010-09-16 11:02 ` durducengiz
  3 siblings, 1 reply; 9+ messages in thread
From: Lars Magne Ingebrigtsen @ 2010-09-15  6:49 UTC (permalink / raw)
  To: emacs-devel

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




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

* Re: long-standing set-up errors on upgrade (elimination of x cut buffers)
  2010-09-15  1:10 long-standing set-up errors on upgrade (elimination of x cut buffers) Joe Brenner
                   ` (2 preceding siblings ...)
  2010-09-15  6:49 ` Lars Magne Ingebrigtsen
@ 2010-09-16 11:02 ` durducengiz
  3 siblings, 0 replies; 9+ messages in thread
From: durducengiz @ 2010-09-16 11:02 UTC (permalink / raw)
  To: emacs-devel

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



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

* Re: long-standing set-up errors on upgrade (elimination of x cut buffers)
  2010-09-15  4:03 ` Eli Zaretskii
@ 2010-09-16 22:47   ` Chong Yidong
  0 siblings, 0 replies; 9+ messages in thread
From: Chong Yidong @ 2010-09-16 22:47 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel, Joe Brenner

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.



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

* Re: long-standing set-up errors on upgrade (elimination of x cut buffers)
  2010-09-15  6:49 ` Lars Magne Ingebrigtsen
@ 2010-09-19 22:39   ` Joe Brenner
  2010-09-20 16:24     ` Chad Brown
  0 siblings, 1 reply; 9+ messages in thread
From: Joe Brenner @ 2010-09-19 22:39 UTC (permalink / raw)
  To: emacs-devel


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.






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

* Re: long-standing set-up errors on upgrade (elimination of x cut buffers)
  2010-09-19 22:39   ` Joe Brenner
@ 2010-09-20 16:24     ` Chad Brown
  2010-09-20 22:04       ` Stefan Monnier
  0 siblings, 1 reply; 9+ messages in thread
From: Chad Brown @ 2010-09-20 16:24 UTC (permalink / raw)
  To: Joe Brenner; +Cc: emacs-devel

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

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

* Re: long-standing set-up errors on upgrade (elimination of x cut buffers)
  2010-09-20 16:24     ` Chad Brown
@ 2010-09-20 22:04       ` Stefan Monnier
  0 siblings, 0 replies; 9+ messages in thread
From: Stefan Monnier @ 2010-09-20 22:04 UTC (permalink / raw)
  To: Chad Brown; +Cc: emacs-devel, Joe Brenner

> 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



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

end of thread, other threads:[~2010-09-20 22:04 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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

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