Custom themes

Custom themes

[Chong Yidong]

Just a heads-up: I've mentioned before that I'd like to include some
easy way for newbies to choose a different color scheme, similar to what
color-theme.el does.  However, instead of including color-theme.el, I'm
writing an independent implementation.  (I haven't been able to get in
contact with the color-theme.el maintainer, and anyway there are just
too many contributors to color-theme.el to track down for assignment.)
This code will be based on the existing Custom theme code, so most of
the heavy lifting has been done.

Emacs looks for Custom themes in .emacs.d and the load path; a theme
named "foo" is looked for in foo-theme.el.  I'm currently not sure
whether the default selection of themes distributed with Emacs should be
in a subdirectory in etc/, or in lisp/.

Note, also, that because the package manager adds to the load-path, it
is possible to distribute Custom themes, or collections of themes, as
packages, which is nice.

Re: Custom themes

[Deniz Dogan]

2010/10/11 Chong Yidong <cyd@stupidchicken.com>:
> Just a heads-up: I've mentioned before that I'd like to include some
> easy way for newbies to choose a different color scheme, similar to what
> color-theme.el does.  However, instead of including color-theme.el, I'm
> writing an independent implementation.  (I haven't been able to get in
> contact with the color-theme.el maintainer, and anyway there are just
> too many contributors to color-theme.el to track down for assignment.)
> This code will be based on the existing Custom theme code, so most of
> the heavy lifting has been done.
>
> Emacs looks for Custom themes in .emacs.d and the load path; a theme
> named "foo" is looked for in foo-theme.el.  I'm currently not sure
> whether the default selection of themes distributed with Emacs should be
> in a subdirectory in etc/, or in lisp/.
>
> Note, also, that because the package manager adds to the load-path, it
> is possible to distribute Custom themes, or collections of themes, as
> packages, which is nice.
>
>

Will your implementation allow for "unplugging" themes? If I recall
correctly, it's not possible to select a theme in color-theme.el and
then "undo" that to get back to your old colors.

-- 
Deniz Dogan

Re: Custom themes

[Chong Yidong]

Deniz Dogan <deniz.a.m.dogan@gmail.com> writes:

> Will your implementation allow for "unplugging" themes? If I recall
> correctly, it's not possible to select a theme in color-theme.el and
> then "undo" that to get back to your old colors.

Yes, back the Custom themes code was written with this in mind (see
`disable-theme').

Re: Custom themes

[Lars Magne Ingebrigtsen]

Chong Yidong <cyd@stupidchicken.com> writes:

> Just a heads-up: I've mentioned before that I'd like to include some
> easy way for newbies to choose a different color scheme, similar to what
> color-theme.el does.  However, instead of including color-theme.el, I'm
> writing an independent implementation.

Will this just be for colour, or would it be usable for a general
"theme" functionality?  For instance, I'm currently contemplating
implementing different "privacy levels" in Gnus based on whether you're
in a private or public group, and it strikes me that this could probably
be implemented by something theme-like...  It involves changing several
variables at once, but should be roll-backable (that should be a word)
and allow the user to override certain elements in the theme...

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

Re: Custom themes

[Chong Yidong]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Will this just be for colour, or would it be usable for a general
> "theme" functionality?  For instance, I'm currently contemplating
> implementing different "privacy levels" in Gnus based on whether you're
> in a private or public group, and it strikes me that this could probably
> be implemented by something theme-like...  It involves changing several
> variables at once, but should be roll-backable (that should be a word)
> and allow the user to override certain elements in the theme...

The existing Custom Themes code already provides this functionality; it
is even documented in the manual.

Re: Custom themes

[Eric Lilja]

On 2010-10-11 07:15, Chong Yidong wrote:
> Just a heads-up: I've mentioned before that I'd like to include some
> easy way for newbies to choose a different color scheme, similar to what
> color-theme.el does.  However, instead of including color-theme.el, I'm
> writing an independent implementation.  (I haven't been able to get in
> contact with the color-theme.el maintainer, and anyway there are just
> too many contributors to color-theme.el to track down for assignment.)
> This code will be based on the existing Custom theme code, so most of
> the heavy lifting has been done.
>
> Emacs looks for Custom themes in .emacs.d and the load path; a theme
> named "foo" is looked for in foo-theme.el.  I'm currently not sure
> whether the default selection of themes distributed with Emacs should be
> in a subdirectory in etc/, or in lisp/.
>
> Note, also, that because the package manager adds to the load-path, it
> is possible to distribute Custom themes, or collections of themes, as
> packages, which is nice.
>
>

Mr Yidong, I just wanted to say how happy I reading this! I've been 
using color-theme but I was worried that it appeared to be abandonware, 
more or less, and I wanted something official already included. Thank you!

- Eric Lilja

Re: Custom themes

[Joel James Adamson]

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

Eric Lilja <mindcooler@gmail.com> writes:

> On 2010-10-11 07:15, Chong Yidong wrote:
>> Emacs looks for Custom themes in .emacs.d and the load path; a theme
>> named "foo" is looked for in foo-theme.el.  I'm currently not sure
>> whether the default selection of themes distributed with Emacs should be
>> in a subdirectory in etc/, or in lisp/.
>>
>> Note, also, that because the package manager adds to the load-path, it
>> is possible to distribute Custom themes, or collections of themes, as
>> packages, which is nice.
>>
>>
>
> Mr Yidong, I just wanted to say how happy I reading this! I've been
> using color-theme but I was worried that it appeared to be
> abandonware, more or less, and I wanted something official already
> included. Thank you!

Me too: color-theme surprises me far too much.  I like some of the
themes, but I would like to be able to readily switch between my own
light and dark themes depending on changing my desktop color scheme.  I
haven't gotten the existing theme machinery working on this.

Joel
-- 
Joel J. Adamson
Servedio Lab
University of North Carolina at Chapel Hill

FSF Member #8164
http://www.unc.edu/~adamsonj

[-- Attachment #2: Type: application/pgp-signature, Size: 229 bytes --]

Re: Custom themes

[Chong Yidong]

Chong Yidong <cyd@stupidchicken.com> writes:

> Just a heads-up: I've mentioned before that I'd like to include some
> easy way for newbies to choose a different color scheme, similar to what
> color-theme.el does.  However, instead of including color-theme.el, I'm
> writing an independent implementation.

I've checked in a simple implementation of the theme chooser, which can
be accessed via M-x customize-themes.  As mentioned, the underlying
mechanism is the Custom Themes feature which has existed since Emacs 22.

To start, I've slapped together a couple of default themes and put them
in the lisp/themes directory.  These won't necessarily be the ones we
end up including for Emacs 24; we might replace them later.

By default, we should include a small number of default color themes,
say 3-4 light-background themes and 3-4 dark-background themes.  (We can
also include variable themes, if there happens to be a need.)  If we end
up with a lot of extra themes, they can go into an `extra-themes'
package on elpa.gnu.org.  I don't know how we'll go about picking the
default themes to include, which could be the mother of all bikeshedding
discussions.  Procedural suggestions welcome.  One restriction is that
we have to treat themes distributed with Emacs like source code, so any
non-trivial theme will likely need a copyright assignment.

Re: Custom themes

[Eric Lilja]

On 2010-10-12 22:25, Chong Yidong wrote:

>
> By default, we should include a small number of default color themes,
> say 3-4 light-background themes and 3-4 dark-background themes.  (We can
> also include variable themes, if there happens to be a need.)

Would you consider having a little bit bigger default selection that 
that? It would be great for university work where I have limited 
possibilites to add extra stuff to installed programs.

- Eric Lilja

Re: Custom themes

[Christoph]

On 10/12/2010 02:25 PM, Chong Yidong wrote:

> I've checked in a simple implementation of the theme chooser, which can
> be accessed via M-x customize-themes.  As mentioned, the underlying
> mechanism is the Custom Themes feature which has existed since Emacs 22.

Cool. Thanks.

> To start, I've slapped together a couple of default themes and put them
> in the lisp/themes directory.  These won't necessarily be the ones we
> end up including for Emacs 24; we might replace them later.

Would it make sense to add lisp/themes to the default path? Right now, 
there are no themes listed when invoking customize-themes unless I add 
the path manually.

Christoph

Re: Custom themes

[Chong Yidong]

Christoph <cschol2112@googlemail.com> writes:

> Would it make sense to add lisp/themes to the default path? Right now,
> there are no themes listed when invoking customize-themes unless I add
> the path manually.

Try bootstrapping.

Re: Custom themes

[David De La Harpe Golden]

On 12/10/10 21:25, Chong Yidong wrote:

> (We can also include variable themes, if there happens to be a need.)

You mean themes of customisation variables? Or did you mean 
color-adjustment themes that adapted to light/dark backgrounds?

The color-adjustment themes are "look" themes rather than "feel" themes. 
  But "feel" themes are AFAIK equally feasible with the existing 
machinery - I hesitate to mention it* but I had been looking at the 
customisation theme mechanism as a way to encapsulate old vs. new 
selection settings, though was deterred by its previous interface that 
had little to no discoverability.

A "emacs22weirdoldselect" theme (probably need a separate one for w32) 
would probably be possible - though it would be necessary to use a 
customisation variable to control mouse-yank rather than the current 
rebind to mouse-yank-primary for the relevant mouse-2 adjustment to 
allow such a thing - obviously one can't control bindings via 
customisation themes right now because bindings aren't under the 
customisation umbrella yet (if they ever will be).

[If such "feel" themes were to be endorsed, then the ability to place 
themes into categories in the customize-theme interface it might be good]

* I'd be worried about it become a maintenance albatross long term, 
though I suppose things could just be eventually deprecated.

Re: Custom themes

[Chong Yidong]

David De La Harpe Golden <david@harpegolden.net> writes:

> You mean themes of customisation variables?

Yes.

> The color-adjustment themes are "look" themes rather than "feel"
> themes... I had been looking at the customisation theme mechanism as a
> way to encapsulate old vs. new selection settings

I'm not sure this is workable.  A big motivator for the selection
changes was to simplify the code in mouse.el by removing the
special-casing of mouse selections.  Providing complete backward
compatibility, even as an option, would necessitate putting all the
cruft back in, which mostly defeats the purpose.

Re: Custom themes

[Miles Bader]

Chong Yidong <cyd@stupidchicken.com> writes:
> I'm not sure this is workable.  A big motivator for the selection
> changes was to simplify the code in mouse.el by removing the
> special-casing of mouse selections.  Providing complete backward
> compatibility, even as an option, would necessitate putting all the
> cruft back in, which mostly defeats the purpose.

Tho see the emacs-help for my idea on one way to give the "new" code
some of the convenience of the old code without being strictly identical
in behavior.

-miles

-- 
Inhumanity, n. One of the signal and characteristic qualities of humanity.

users and selection changes [was: Custom themes]

[Drew Adams]

>> The color-adjustment themes are "look" themes rather than "feel"
>> themes... I had been looking at the customisation theme
>> mechanism as a way to encapsulate old vs. new selection settings
>
> I'm not sure this is workable.  A big motivator for the selection
> changes was to simplify the code in mouse.el by removing the
> special-casing of mouse selections.  Providing complete backward
> compatibility, even as an option, would necessitate putting all the
> cruft back in, which mostly defeats the purpose.

Hm.  We were told several times that users _would_ be able to get back exactly
the pre-Emacs 24 selection behavior (at least on Windows, and I thought
everywhere), and that we just had to wait patiently until the "wrinkles" were
"ironed" out and we would be told how.

Now you seem to be saying "Ha! we didn't really mean it; you can't get back the
old behavior after all. Users are lusers."

Removing bad code, with crufty special-casing, is one thing - a good thing.
That isn't necessarily user-visible anyway - it's essentially code cleanup or
optimization.

Changing user-visible behavior is something else.  And changing it in ways that
are irreversible, that don't give users the choice to get back the old behavior,
is something else again.  And it's not what was advertised.

If some of the code removed was _required_ for the previous (user-visible)
behavior, then that part of what was removed was not "cruft".

And there is still nothing in NEWS that describes these changes in a user-usable
way, including which variables and functions have changed interfaces and how,
and how to get back the previous behavior in each respect where that is
possible.  Listing incompatible changes is part of this: what you cannot do that
you used to be able to do, etc.  (See, for example, NEWS bugs #7196, #7195.)

Re: users and selection changes [was: Custom themes]

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Thu, 14 Oct 2010 06:18:33 -0700
> Cc: emacs-devel@gnu.org
> 
> We were told several times that users _would_ be able to get back exactly
> the pre-Emacs 24 selection behavior (at least on Windows, and I thought
> everywhere), and that we just had to wait patiently until the "wrinkles" were
> "ironed" out and we would be told how.

That time has come and gone.  I'm not aware of any problems with
getting the old behavior back by customizing mouse-drag-copy-region.
The only leftover I know about is your complain about the need to
customize mouse-drag-copy-region.  If there are other problems left,
please file specific bug reports.

RE: users and selection changes [was: Custom themes]

[Drew Adams]

> > We were told several times that users _would_ be able to 
> > get back exactly the pre-Emacs 24 selection behavior (at
> > least on Windows, and I thought everywhere), and that we
> > just had to wait patiently until the "wrinkles" were
> > "ironed" out and we would be told how.
> 
> That time has come and gone.  

Good to hear. So where's the explanation for users?

NEWS is incomplete and incorrect (see bugs #7196 & #7195).
I don't see it in the manuals either.

> I'm not aware of any problems with getting the old
> behavior back by customizing mouse-drag-copy-region.

Does that give exactly the same behavior as before?  On all platforms?

Yidong seems to have just said that that is impossible.

He also pointed out, in bug #6956, that there is now an inconsistency (same
inconsistency or another?) wrt mouse selection when `mouse-drag-copy-region' is
t:

YC> Any user who insists on changing mouse-drag-copy-region
YC> back to t can deal with the inconsistency.

If Yidong is wrong, and for all platforms it _is_ sufficient to customize
`mouse-drag-copy-region', then all that remains is to _document_:

(a) the changed default behavior
(b) how to restore the old behavior

Apparently the time has come.

> The only leftover I know about is your complain about the need to
> customize mouse-drag-copy-region.  

You are inventing.  I never complained about having to customize
`mouse-drag-copy-region'.  I have no problem using options to customize.  And I
explicitly said (in bug #6956) that setting `mouse-drag-copy-region' to t seems
sufficient for my personal use.

The point is that we need to document this change and let users know which
option(s) to use to get back the previous behavior (which Yidong seems to be
saying is not completely possible).

> If there are other problems left, please file specific bug reports.

From bug #6956: In previous Emacs releases on X Window, "Were users able to
mouse-select and mouse-paste between sessions without first copying to the kill
ring" (i.e. with nil `mouse-drag-copy-region')?  I don't know the answer.  If
yes, then that feature has apparently been lost (`mouse-drag-copy-region' was
previously a no-op MS Windows - it was effectively always t, so Windows never
had this feature).

Also from bug #6956: "If you can mouse-select+paste within an Emacs session
without affecting the kill ring, why shouldn't you be able to do that between
sessions? Seems natural, no?"  As you pointed out then, this is an enhancement
request if it was not already possible in X in previous releases.

Re: users and selection changes [was: Custom themes]

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <cyd@stupidchicken.com>, <david@harpegolden.net>, <emacs-devel@gnu.org>
> Date: Thu, 14 Oct 2010 13:51:39 -0700
> 
> > > We were told several times that users _would_ be able to 
> > > get back exactly the pre-Emacs 24 selection behavior (at
> > > least on Windows, and I thought everywhere), and that we
> > > just had to wait patiently until the "wrinkles" were
> > > "ironed" out and we would be told how.
> > 
> > That time has come and gone.  
> 
> Good to hear. So where's the explanation for users?
> 
> NEWS is incomplete and incorrect (see bugs #7196 & #7195).
> I don't see it in the manuals either.

You've filed these bugs, and they will be handled.  I thought this
thread was about something else.  Is it?

> > I'm not aware of any problems with getting the old
> > behavior back by customizing mouse-drag-copy-region.
> 
> Does that give exactly the same behavior as before?  On all platforms?

Yes, AFAIK, if by "behavior" you mean the effect of selecting text
with a mouse.

> Yidong seems to have just said that that is impossible.

My name is not Yidong.

> > The only leftover I know about is your complain about the need to
> > customize mouse-drag-copy-region.  
> 
> You are inventing.

Am I?  Then what's this about:

> From bug #6956: In previous Emacs releases on X Window, "Were users able to
> mouse-select and mouse-paste between sessions without first copying to the kill
> ring" (i.e. with nil `mouse-drag-copy-region')?  I don't know the answer.  If
> yes, then that feature has apparently been lost

?

> > If there are other problems left, please file specific bug reports.
> 
> From bug #6956:

I said "_other_ problems".  That means not this one.

RE: users and selection changes [was: Custom themes]

[Drew Adams]

> > Yidong seems to have just said that that is impossible.
> 
> My name is not Yidong.

Huh? No one said it is.  My mail was a reply to Yidong, who seemed to indicate
that this is impossible.  You then replied to my mail, indicating that we have
_already_ been told how to get back the previous behavior.

I mentioned that Yidong apparently thinks getting that behavior is not
(completely) possible.

And I stated that I do not see where we have already been told how to get back
the previous behavior.  Where "we" is Emacs users.  Where told means in the
NEWS/doc.

> > > The only leftover I know about is your complain about the need to
> > > customize mouse-drag-copy-region.  
> > 
> > You are inventing.
> 
> Am I?  Then what's this about:
> 
> > From bug #6956: In previous Emacs releases on X Window, 
> > "Were users able to mouse-select and mouse-paste between
> > sessions without first copying to the kill ring" (i.e.
> > with nil `mouse-drag-copy-region')?  I don't know the
> > answer.  If yes, then that feature has apparently been lost

It's a question.  And a statement that if the answer is yes, then a feature has
been lost.

How do you interpret that as my complaining about my having to customize option
`mouse-drag-copy-region'?  I've been very clear that customizing that option to
t seems to do what I need.

Re: users and selection changes [was: Custom themes]

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <cyd@stupidchicken.com>, <david@harpegolden.net>, <emacs-devel@gnu.org>
> Date: Thu, 14 Oct 2010 15:09:00 -0700
> 
> I mentioned that Yidong apparently thinks getting that behavior is not
> (completely) possible.

Then Yidong (or someone else who knows what the problems are) should
file a bug report with the details.  I don't see how it could be
useful to discuss hearsay problems.

> > > > The only leftover I know about is your complain about the need to
> > > > customize mouse-drag-copy-region.  
> > > 
> > > You are inventing.
> > 
> > Am I?  Then what's this about:
> > 
> > > From bug #6956: In previous Emacs releases on X Window, 
> > > "Were users able to mouse-select and mouse-paste between
> > > sessions without first copying to the kill ring" (i.e.
> > > with nil `mouse-drag-copy-region')?  I don't know the
> > > answer.  If yes, then that feature has apparently been lost
> 
> It's a question.  And a statement that if the answer is yes, then a feature has
> been lost.
> 
> How do you interpret that as my complaining about my having to customize option
> `mouse-drag-copy-region'?  I've been very clear that customizing that option to
> t seems to do what I need.

The issues with `mouse-drag-copy-region' has been beaten to death in
the past.  There are no reasons for me to go through all that misery
again.

Re: users and selection changes

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> The issues with `mouse-drag-copy-region' has been beaten to death in
> the past.  There are no reasons for me to go through all that misery
> again.

If the question is "why doesn't copying something in X make it end up in
the kill ring any more?", and the answer is "set variable foo to make
that happen again", then I'd like to know the answer.  Because I'd
really like to get that behaviour back.

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

Re: users and selection changes

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 15 Oct 2010 11:34:44 +0200
> 
> If the question is "why doesn't copying something in X make it end up in
> the kill ring any more?", and the answer is "set variable foo to make
> that happen again", then I'd like to know the answer.  Because I'd
> really like to get that behaviour back.

I only know the answer for the following question:

  Why does selecting text with the mouse inside Emacs doesn't make the
  selected text end up in the kill ring and in the X clipboard?

The answer to that is customize mouse-drag-copy-region to a non-nil
value.

If the above question is not what you meant, please explain what is
the meaning of "copying something in X".  Specifically, what gestures
are needed for "copying something", and does "in X" mean in the Emacs
session or in some other X application?

Re: users and selection changes

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I only know the answer for the following question:
>
>   Why does selecting text with the mouse inside Emacs doesn't make the
>   selected text end up in the kill ring and in the X clipboard?
>
> The answer to that is customize mouse-drag-copy-region to a non-nil
> value.

(setq x-select-enable-primary t)

helps a bit too, doesn't it?

> If the above question is not what you meant, please explain what is
> the meaning of "copying something in X".  Specifically, what gestures
> are needed for "copying something", and does "in X" mean in the Emacs
> session or in some other X application?

If I double-click a word in Firefox, and then say `C-y' in Emacs, I'm
not getting that word yanked in Emacs any more.

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

Re: users and selection changes

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Fri, 15 Oct 2010 12:11:08 +0200
> 
> If I double-click a word in Firefox, and then say `C-y' in Emacs, I'm
> not getting that word yanked in Emacs any more.

Even if x-select-enable-primary is non-nil?  If so, then I suggest to
file a bug report.

Re: users and selection changes

[Miles Bader]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> If the question is "why doesn't copying something in X make it end up in
> the kill ring any more?", and the answer is "set variable foo to make
> that happen again", then I'd like to know the answer.  Because I'd
> really like to get that behaviour back.

If by "copying something in X" you mean, "use `copy' menu in some app
(firefox, gnome, etc)", then it should put that stuff in the Emacs
kill-ring by default now.

If by "copying something in X" you mean, "select something in Xterm", then:

   (setq x-select-enable-primary t)

The _problem_ with setting x-select-enable-primary is that now all
_Emacs_ selections end up in the kill ring too, which is almost
certainly Not What You Want.

My idea to get around that problem (expressed on the gnu.emacs.help
newsgroup) is to add a feature that makes emacs put all selections
_except_ those originating from itself (the current Emacs process) on
the kill ring.

That, would basically make things similar to how they used to be

[I don't know if this behavior should associated with non-nil
x-select-enable-primary by default, or only upon some special value of
x-select-enable-primary, e.g. (setq x-select-enable-primary 'others).

It _is_ somewhat quirky (although very convenient) behavior, which
argues for "special setting", but on the other hand, the current
behavior of x-select-enable-primary is almost useless, so ...]

Thanks,

-Miles

-- 
Suburbia: where they tear out the trees and then name streets after them.

Re: users and selection changes

[Lars Magne Ingebrigtsen]

Miles Bader <miles@gnu.org> writes:

> If by "copying something in X" you mean, "select something in Xterm", then:
>
>    (setq x-select-enable-primary t)

Yeah, I have that, but it...  uhm.  I could have sworn that didn't work!
But it does work now.

*scratches head*

I even wrote this thing because it didn't work:

(global-set-key [(hyper y)]
		(lambda ()
		  (interactive)
		  (mouse-yank-primary (point))))

But I'm unable to not get it to work any more...  Hm.

Sorry for the noise.

> The _problem_ with setting x-select-enable-primary is that now all
> _Emacs_ selections end up in the kill ring too, which is almost
> certainly Not What You Want.

Well, it doesn't really bother me.  I don't use the mouse at all in
Emacs, so...

> My idea to get around that problem (expressed on the gnu.emacs.help
> newsgroup) is to add a feature that makes emacs put all selections
> _except_ those originating from itself (the current Emacs process) on
> the kill ring.

Sounds good to me.

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

Re: users and selection changes

[Miles Bader]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>> The _problem_ with setting x-select-enable-primary is that now all
>> _Emacs_ selections end up in the kill ring too, which is almost
>> certainly Not What You Want.
>
> Well, it doesn't really bother me.  I don't use the mouse at all in
> Emacs, so...

No, _all_ Emacs selections...

-miles

-- 
Rational, adj. Devoid of all delusions save those of observation, experience
and reflection.

Re: users and selection changes

[Lars Magne Ingebrigtsen]

Miles Bader <miles@gnu.org> writes:

>> Well, it doesn't really bother me.  I don't use the mouse at all in
>> Emacs, so...
>
> No, _all_ Emacs selections...

Are there other kinds of selections than mousey ones and the ones you
make with `M-w' or `C-k' and the like?  I mean, if you have
`transient-mark-mode' switched off.  I don't know what that one does,
but perhaps it selects stuff a lot more?

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

Re: users and selection changes

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 15 Oct 2010 16:25:02 +0200
> 
> Miles Bader <miles@gnu.org> writes:
> 
> >> Well, it doesn't really bother me.  I don't use the mouse at all in
> >> Emacs, so...
> >
> > No, _all_ Emacs selections...
> 
> Are there other kinds of selections than mousey ones and the ones you
> make with `M-w' or `C-k' and the like?  I mean, if you have
> `transient-mark-mode' switched off.

Yes, shift-selections (the ones you get by holding Shift while you use
arrow keys).

Re: users and selection changes

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

>> If by "copying something in X" you mean, "select something in Xterm", then:
>>
>>    (setq x-select-enable-primary t)
>
> Yeah, I have that, but it...  uhm.  I could have sworn that didn't work!
> But it does work now.

Hah!  For once I'm not forsworn.

In the other Emacs, `C-y' now gives me "now", and

(mouse-yank-primary (point))
=>
http://www.nytimes.com/2010/10/22/opinion/22krugman.html?_r=1&partner=rssnyt&emc=rss

This is after double-clicking the URL in the location bar in Firefox.

Anybody have any ideas why this is happening?  But only sometimes?

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

RE: users and selection changes

[Drew Adams]

> The _problem_ with setting x-select-enable-primary is that now all
> _Emacs_ selections end up in the kill ring too, which is almost
> certainly Not What You Want.

I'm on Windows, so I don't have (or need) option `x-select-enable-primary', but
I just looked at its doc string:

"Non-nil means cutting and pasting uses the primary selection."

First, one might wonder what it means by "cutting and pasting".  Is it speaking
about cutting and pasting inside Emacs or outside Emacs?  Does it really mean
kill and yank perhaps?  Does Emacs mouse-pasting and mouse-cutting count (where
the kill ring might not be involved)?  Pretty unclear, to me.

Anyway, more important is that the doc string says nothing about what you just
said, which seems like important info.  All the more so since the option name
does not suggest anything about it (the kill ring).

Seems like the doc string should say explicitly what you said: non-nil means
that all Emacs selections (including mouse selections) are copied to the kill
ring.  If that's true, I cannot believe it was not mentioned in the doc string.

BTW, the Customize :group for this option is `killing', but nothing is said for
it about killing.  And even the manual (`(emacs)Cut/Paste Other App') is
incomplete.  It says only that the option controls what gets yanked.  It does
not say explicitly that it controls what gets put on the kill ring.  Yes,
yanking only yanks kills, but this could be made clearer.

> My idea to get around that problem (expressed on the gnu.emacs.help
> newsgroup) is to add a feature that makes emacs put all selections
> _except_ those originating from itself (the current Emacs process) on
> the kill ring.

I guess you mean that all selections made outside Emacs would automatically be
added to the kill ring (but some Emacs selections could also still be added to
the kill ring).

As an option, that might be useful.  But users would need to be able to control
it.  Some users (including me) might not want everything they select outside
Emacs to end up on the kill ring.

And how would that work?  When you select some text outside Emacs, how does it
put on the Emacs kill ring?  And for which Emacs session - all of them?

> That, would basically make things similar to how they used to be

How so?  I don't recall that Emacs ever added all outside selections to the kill
ring. Or did you mean outside copies (e.g. `C-c' on Windows) instead of outside
selections (e.g. using mouse)?

> [I don't know if this behavior should associated with non-nil
> x-select-enable-primary by default, or only upon some special value of
> x-select-enable-primary, e.g. (setq x-select-enable-primary 'others).
> 
> It _is_ somewhat quirky (although very convenient) behavior, which
> argues for "special setting", but on the other hand, the current
> behavior of x-select-enable-primary is almost useless, so ...]

BTW (since you mentioned selections from the current Emacs process) - Is there
no interest in an ability to copy/paste between Emacs sessions without
necessarily affecting the kill ring?

I personally want to use the kill ring even for mouse selection, but it seems to
me that some people might want, between Emacs sessions, the same ability that
they have within a session: be able to select and paste text using the mouse,
without adding the selection to the kill ring.

Or is that already possible with Emacs on X?  I asked that question in bug #6956
but never got an answer.

IIUC, you can mouse-select in Emacs and paste to another app, and vice versa,
all without affecting the kill ring (only the primary is used by default, IIUC).
Why shouldn't you be able to treat a separate Emacs session as one of those
other apps?

Re: users and selection changes

[Stefan Monnier]

> The _problem_ with setting x-select-enable-primary is that now all
> _Emacs_ selections end up in the kill ring too, which is almost
> certainly Not What You Want.

Hmm... that's not quite what you meant, right?
In order for such a selection to end up on the kill-ring, you need to
not only select the text but also you need to then use C-y to pull the
PRIMARY selection into the kill-ring: just selecting the text (and
pasting it in some other application, for example) won't put it on the
kill-ring, AFAICT.

In my opinion, it's OK if the PRIMARY inserted by C-y also gets into the
kill-ring, even when that PRIMARY comes from ourselves: the real
problem is not the kill-ring but the C-y which should ignore PRIMARY
when it's ours.


        Stefan

Re: users and selection changes

[Chong Yidong]

Miles Bader <miles@gnu.org> writes:

> My idea to get around that problem (expressed on the gnu.emacs.help
> newsgroup) is to add a feature that makes emacs put all selections
> _except_ those originating from itself (the current Emacs process) on
> the kill ring.

That is OK as an option, but not the default.  It makes accidental
clobbering too easy; if you type C-c in another X application and select
some text, you wouldn't be able to paste the original copied text into
Emacs with C-y.  This is inconsistent with the modern X point of view,
which treats the primary selection as a fragile entity easily
overwritten as a side-effect of text-selection, and therefore unreliable
for anything except middle click mouse pastes.  Hence all nontrivial
application operations (e.g. the various Paste/Paste As/Paste Into
commands) should act on the clipboard.  If someone wants to implement
the option, feel free.

Re: Custom themes

[Stefan Monnier]

> Emacs looks for Custom themes in .emacs.d and the load path; a theme
> named "foo" is looked for in foo-theme.el.  I'm currently not sure
> whether the default selection of themes distributed with Emacs should be
> in a subdirectory in etc/, or in lisp/.

IIUC it needs to be in lisp since it's not searched for in etc.
Maybe if we call them "theme/foo.el" (similarly to "term/$TERM.el")
instead of "foo-theme.el" and don't add "theme" to load-path, we can
solve both problems at once.


        Stefan

Re: Custom themes

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> IIUC it needs to be in lisp since it's not searched for in etc.
> Maybe if we call them "theme/foo.el" (similarly to "term/$TERM.el")
> instead of "foo-theme.el" and don't add "theme" to load-path, we can
> solve both problems at once.

The original motivation for calling it foo-theme.el was so that users
can copy the theme file into .emacs.d (or wherever the load-directory
for their local Lisp files is).  That's been in place since Emacs 22, so
I'm not sure it's worthwhile to change it now.

Re: Custom themes

[Juanma Barranquero]

On Wed, Oct 13, 2010 at 04:14, Chong Yidong <cyd@stupidchicken.com> wrote:

> The original motivation for calling it foo-theme.el was so that users
> can copy the theme file into .emacs.d (or wherever the load-directory
> for their local Lisp files is).

It seems cleaner to have an .emacs.d/themes/ dir.

    Juanma

Re: Custom themes

[CHENG Gao]

*On Wed, 13 Oct 2010 12:20:37 +0200
* Also sprach Juanma Barranquero <lekktu@gmail.com>:

> On Wed, Oct 13, 2010 at 04:14, Chong Yidong <cyd@stupidchicken.com> wrote:
>
>> The original motivation for calling it foo-theme.el was so that users
>> can copy the theme file into .emacs.d (or wherever the load-directory
>> for their local Lisp files is).
>
> It seems cleaner to have an .emacs.d/themes/ dir.
>
>     Juanma

+1

How about change custom-theme-directory default to .emacs.d/theme/?

If there is a clear theme design guide (such as a list of faces to
customize), maybe some compaign can be initiated to ask users to design
their (our) own themes and post screenshots, and choose some default
themes from them.

Re: Custom themes

[Chong Yidong]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Wed, Oct 13, 2010 at 04:14, Chong Yidong <cyd@stupidchicken.com> wrote:
>
>> The original motivation for calling it foo-theme.el was so that users
>> can copy the theme file into .emacs.d (or wherever the load-directory
>> for their local Lisp files is).
>
> It seems cleaner to have an .emacs.d/themes/ dir.

OK, I'll make the change.

Re: Custom themes

[Chong Yidong]

Chong Yidong <cyd@stupidchicken.com> writes:

> Juanma Barranquero <lekktu@gmail.com> writes:
>
>> On Wed, Oct 13, 2010 at 04:14, Chong Yidong <cyd@stupidchicken.com> wrote:
>>
>>> The original motivation for calling it foo-theme.el was so that users
>>> can copy the theme file into .emacs.d (or wherever the load-directory
>>> for their local Lisp files is).
>>
>> It seems cleaner to have an .emacs.d/themes/ dir.
>
> OK, I'll make the change.

The change turns out to be more problematic than it seemed.

If we remove lisp/themes from the load path, we have to tell the themes
code how to find that directory again.  We could do

  (dolist (dir load-path)
    (locate-file "themes/foo.el" dir)
    ...)

but that means looking for a themes/ subdirectory in *all* the load-path
directories, which seems silly.  One alternative is to determine the
themes directory at the Makefile level, similar to what we do for leim;
but I don't like adding more complexity to the Makefiles just for this.
Another alternative is to put the theme files in etc/, but that's not
good either, since Lisp files ought to go in lisp/.  De-synching the
themes path from load-path also makes it more difficult for us to
provide themes via a package.

Re: Custom themes

[Juanma Barranquero]

On Thu, Oct 14, 2010 at 17:53, Chong Yidong <cyd@stupidchicken.com> wrote:

> Another alternative is to put the theme files in etc/, but that's not
> good either, since Lisp files ought to go in lisp/.  De-synching the
> themes path from load-path also makes it more difficult for us to
> provide themes via a package.

Still, IMO is the best option. It seems silly to look for theme files
in all the load path when it looks likely that many people will have
them (and prefer them) in their own directories. They are lisp, but
I'd bet most people will think of them as customization, not programs.

I think we should decouple the themes from the load path and provide a
themes-load-path (...whatever the name..) variable.

    Juanma

Re: Custom themes

[Chong Yidong]

Juanma Barranquero <lekktu@gmail.com> writes:

>> Another alternative is to put the theme files in etc/, but that's not
>> good either, since Lisp files ought to go in lisp/.
>
> Still, IMO is the best option. It seems silly to look for theme files
> in all the load path when it looks likely that many people will have
> them (and prefer them) in their own directories. They are lisp, but
> I'd bet most people will think of them as customization, not programs.
>
> I think we should decouple the themes from the load path and provide a
> themes-load-path (...whatever the name..) variable.

I see your point.  I've moved the built-in themes directory into etc/.