Custom themes

Custom themes

[Richard Stallman]

Could someone please document Custom themes in the Emacs manual?

Custom themes

[Richard M. Stallman]

Could someone please document Custom themes in the Emacs manual?

Re: Custom themes

[Luc Teirlinck]

Richard Stallman wrote:

   Could someone please document Custom themes in the Emacs manual?

I know nothing about them, but some naive questions:

Do they already work?  Are they used anywhere?  The command to create
a theme seems to be `customize-create-theme'.  Grepping seems to show
that it is not used once outside cus-theme.el, where it is defined.
Not one single theme appears to be defined in the Emacs source tree.
So it might seem too early to document them in the Emacs manual.  I
have the impression that an Emacs user who is not an Elisp programmer
needs pre-defined themes, to get any benefit from themes (but I may be
wrong).  The are not documented in the Elisp manual either.  I have no
idea whether or not it is too early to do that.

Sincerely,

Luc.

Re: Custom themes

[Luc Teirlinck]

>From my earlier reply:

   I know nothing about them, but some naive questions:

Some questions and remarks _were_ naive.  At second look
`customize-create-theme' seems to be a user level command rather than
a Lisp programmer level command, as I first thought.  Trying it out,
it seems to have a very unfinished look to it.  I still do not really
know what it is exactly trying to do.

Sincerely,

Luc.

Re: Custom themes

[Luc Teirlinck]

After _trying_ to use Custom themes, it seems totally obvious that
this is a completely unfinished package, completely unready to be used
or documented in its present form.  One obvious problem is a total
lack of documentation at any level.  That is bad enough, but there is
way worse.  In its current form, it has serious bugs.  I still do not
know what `customize-create-theme' is _trying_ to do (the buffers it
creates look incomplete, unfinished, and are of no help in trying to
figure this out).  But, by experimentation, I was able to figure out
what it currently actually does: it writes files into random
directories all over your file system without warning.  Anybody who
uses Custom themes in its current form had better also know how to use
Find to find all those files back.  If you use a command like
`customize-create-theme', you _assume_ it is going to automatically
write files into the directory in which they belong, not simply into
the current directory.

To me, this appears to be Emacs 23 or 24 stuff, assuming somebody
would be willing to finish it: thoroughly document it at all levels,
greatly improve the user interface and get rid of the bugs.

Sincerely,

Luc.

Re: Custom themes

[Richard M. Stallman]

    Some questions and remarks _were_ naive.  At second look
    `customize-create-theme' seems to be a user level command rather than
    a Lisp programmer level command, as I first thought.  Trying it out,
    it seems to have a very unfinished look to it.  I still do not really
    know what it is exactly trying to do.

I don't remember the details, but it is a matter of defining
a collection of custom settings and giving them a name.
Then you can enable them and disable them by name.

Re: Custom themes

[Richard M. Stallman]

      But, by experimentation, I was able to figure out
    what it currently actually does: it writes files into random
    directories all over your file system without warning.

That is a rather vague description of the behavior.
Perhaps you're describing a bug where it writes
a file into the wrong directory.  If so, can you fix it?

Re: Custom themes

[Luc Teirlinck]

	 But, by experimentation, I was able to figure out
       what it currently actually does: it writes files into random
       directories all over your file system without warning.

   That is a rather vague description of the behavior.
   Perhaps you're describing a bug where it writes
   a file into the wrong directory.  If so, can you fix it?

It writes a file into the current directory, which to me does
definitely not seem like the right thing to do for a command like
`customize-create-theme'.  It should write the file into the directory
where these files belong.  I can not possibly fix it, because I have
no idea what directory that is.  The user's home directory?  I do not know.

Here is a list of problems with `customize-create-theme':

1.  The buffer it creates fails to give anywhere close to appropriate
    usage guidance.

2.  The command does things that for most purposes feel like putting
    the buffer in a given major mode, except that it does not run a
    mode hook, nor `after-change-major-mode-hook'.  For instance, it
    calls `kill-all-local-variables' and `use-local-map'.  But instead
    of actually defining and calling a major mode, it kind of
    "inlines" the call to the unofficial major mode.  The buffer ends
    up "officially" in Fundamental Mode, so you can not get info about
    the "hidden" real mode, using `C-h m'.  Because of the
    `use-local-map' call the buffer does not feel like "Fundamental
    Mode".  Because after-change-major-mode-hook has not been called,
    it is not _really_ in Fundamental Mode.  It is in _no_ major mode.
    That is not good.  It could create problems, for instance for
    minor modes defined with define-global-minor-mode.

3.  If now you click on "Done", a second buffer with the tentative
    theme file appears.  It is marked modified and apparently not
    saved to disk.  I believe it should have been either saved to disk
    in the appropriate place, or there should be some message saying
    that saving the file will save it to the appropriate place (and of
    course, that message should not be a lie).

4.  It is a .el file.  The buffer should be in Emacs Lisp mode, but it
    is in Fundamental mode.

5.  You wonder what to do.  You want to save your file, so you do C-x
    C-s, what else?  But that saves it in the current directory, which
    is still the directory that was current when you called
    `customize-create-theme', which may not be an appropriate place
    for theme files.  If you do not pay attention and continue with
    other work, you may have to run `find' to find the file back.  I
    believe that the second buffer's current directory should be the
    directory for saving theme files (whatever directory that is).

Sincerely,

Luc.

Re: Custom themes

[Frank Schmitt]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Here is a list of problems with `customize-create-theme':
[cut]

And there is color-theme.el, which works nicely, is widely deployed in
the Emacs users community, there are many predefined themes and well,
it's just nice.

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: Custom themes

[Luc Teirlinck]

   And there is color-theme.el, which works nicely, is widely deployed in
   the Emacs users community, there are many predefined themes and well,
   it's just nice.

That does not seem to be included with the CVS Emacs distribution.  I
found an Emacs devel thread from about two years ago about adding it,
but that does not seem to have happened, at least, M-x locate could
not find it.

If I understood correctly color-theme.el does not use Custom
themes, because their implementation currently does not work very
well.  I also seem to understand from the thread that cus-theme.el is
indeed "unfinished".  But I could have misunderstood all or part of
this and it was (nearly) two years ago.

Sincerely,

Luc.

Re: Custom themes

[Luc Teirlinck]

>From my previous message:

  it was (nearly) two years ago.

Actually, nearly three years ago.

Sincerely,

Luc.

Re: Custom themes

[Luc Teirlinck]

Richard Stallman wrote:

   I don't remember the details, but it is a matter of defining
   a collection of custom settings and giving them a name.
   Then you can enable them and disable them by name.

I have the impression nobody knows the details, or would be able to
document them, except a very few people who probably do not read Emacs
Devel regularly.  I guess Per may know some of the details.  The first
question seems to be whether Custom themes are currently a correctly
working and fully developed feature that people might be able to use
if they knew how, or whether it is unfinished work in progress, not
really ready to be used or documented.  Is it really ready do be
documented in the manuals at this stage, assuming somebody would be
willing and able to do it?

I believe that in as far as usage goes, Custom themes are nowhere
used, definitely not in the Emacs source tree and probably not
elsewhere either, except for the `user' and `standard' internal
themes.  People want to use themes but when they look at the current
implementation and its documentation (or better, lack thereof) they
have no idea of how to use it, assuming it can be used at all (at present).

There appears to be a widely used, popular and well documented
alternative, color-theme.el.  Its problem is that it does not interact
very well with Custom: it creates "rogue" variables.

I could at least partially alleviate the worst parts of the problems
with cus-theme.el I pointed out, as long as I would know what is an
appropriate default directory for theme files.  A new customizable
variable custom-theme-directory with default the user's home directory?

Sincerely,

Luc.

Re: Custom themes

[Richard M. Stallman]

Thanks for finding the bugs in custom themes.
Would you like to fix these bugs?  They don't sound terribly
difficult to fix, and then it will be a useful feature.

We've already installed this feature, and it ought to be useful once
it works.  We might as well fix the bugs now--there's no benefit
in waiting.

Re: Custom themes

[Richard M. Stallman]

    I could at least partially alleviate the worst parts of the problems
    with cus-theme.el I pointed out, as long as I would know what is an
    appropriate default directory for theme files.  A new customizable
    variable custom-theme-directory with default the user's home directory?

Yes, but I think the default should be ~/.emacs.d.

Re: Custom themes

[Per Abrahamsen]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> I guess Per may know some of the details.  

Nope.  Jan Vroonhof wrote the code for XEmacs. I once tried to
integrate it into Emacs, but gave up.  I don't believe I was involved
when Dave Love and Alex Schroeder actually went ahead and did integrate it.  

The code desperately needs:

1. Documentation for the public API.

2. A few useful example themes.

3. An UI.

Jan Vroonhof made a presentation of Custom Themes for a workshop in
Japan, but I'm unable to find it now.

Re: Custom themes

[Luc Teirlinck]

I took a somewhat more detailed look at the Custom Themes code.  It
definitely is unfinished work that is _not_ currently in progress.
>From looking at past threads, I believe that Alex Schroeder just gave
up on it and decided that color-theme.el was the way to go.  The
problem with color-theme.el is that it bypasses Custom and creates
variables which Custom considers rogue.  I have the impression that
the new etheme.el proposed by Seong-Kook Shin does the same.

The patches below correct the five bugs I pointed out, as well as a
sixth misfeature, namely the fact that Custom was not able to find the
Custom Theme files in subdirectories of the user's home directory,
unless the user explicitly added them to load-path.

Custom themes without my patches are completely unusable, because
there is not only no documentation, but also not a single interactive
command to work with them.

After my patches, which in addition to the bug fixes make two
functions into interactive commands, Custom Themes are "kind of"
usable, but not to a degree that they would be ready to be documented
in the Emacs manual.  Too many problems remain.

I did provide all the docs in the buffers created by `M-x
custom-create-theme': now it explains how to do create a Theme file in
a way that, I believe, can be understood.  The resulting Theme file
explains how it is supposed to be used, in a way that, I hope, is
understandable to somebody who did not create the file himself.

You can interactively enable a theme and disable it again.  It works.
However, first example of a bug: if you then want to re-enable it
using `M-x require-theme', it has no effect, although you can
re-enable it by manually loading the Theme File.  (This type of
workaround works for most bugs).  I know how to fix this bug, but I do
not want to mess with the code _too_ much, because I am unsure about
its exact intentions.  Second bug.  If you load Theme1 setting VAR
from a standard value of 0 to 1, then load Theme2 setting it to 2 and
then unload Theme2, the new value is 0.  I believe that it should be
1.  To restore Theme1's values (to obtain the result I believe should
be obtained automatically by unloading Theme2), you have to again load
the Theme1 theme file manually.

There would be a lot less bugs if instead of using `require-theme' as
the main interactive Theme enabling command, one would instead use a
command that unconditionally loads the Theme file (the workaround to
most bugs is to do exactly that).  I did not implement that because
that _definitely_ does not _seem_ to be the intended use of the code
(I do not know _why_ the current code seems to insist on using the
buggish `require-theme').

Minibuffer completion for `custom-do-theme-reset' will not work well
unless a patch for minibuf.c that I will submit separately is applied.
This is a bug in minibuf.c, it has nothing to do with Custom themes.
I will discuss this separately.

I do not have the time to do any more substantial work on this, but I
believe that my patches, if installed, will at least help people to get
started.

Here are the patches.  I can install if desired.

===File ~/custom.el-diff====================================
*** custom.el	13 Apr 2005 13:49:27 -0500	1.83
--- custom.el	27 Jun 2005 17:53:50 -0500	
***************
*** 560,566 ****
  	      (t (condition-case nil (load load) (error nil))))))))
  
  (defvar custom-known-themes '(user standard)
!    "Themes that have been define with `deftheme'.
  The default value is the list (user standard).  The theme `standard'
  contains the Emacs standard settings from the original Lisp files.  The
  theme `user' contains all the the settings the user customized and saved.
--- 560,566 ----
  	      (t (condition-case nil (load load) (error nil))))))))
  
  (defvar custom-known-themes '(user standard)
!    "Themes that have been defined with `deftheme'.
  The default value is the list (user standard).  The theme `standard'
  contains the Emacs standard settings from the original Lisp files.  The
  theme `user' contains all the the settings the user customized and saved.
***************
*** 926,931 ****
--- 926,944 ----
  (defvar custom-loaded-themes nil
    "Themes in the order they are loaded.")
  
+ (defcustom custom-theme-directory
+   (if (eq system-type 'ms-dos)
+ 	 ;; MS-DOS cannot have initial dot.
+ 	 "~/_emacs.d/"
+       "~/.emacs.d/")
+   "Directory in which Custom theme files should be written.
+ `require-theme' searches this directory in addition to load-path.
+ The command `customize-create-theme' writes the files it produces
+ into this directory."
+   :type 'string
+   :group 'customize
+   :version "22.1")
+ 
  (defun custom-theme-loaded-p (theme)
    "Return non-nil when THEME has been loaded."
    (memq theme custom-loaded-themes))
***************
*** 949,956 ****
  by `custom-make-theme-feature'."
    ;; Note we do no check for validity of the theme here.
    ;; This allows to pull in themes by a file-name convention
!   (require (or (get theme 'theme-feature)
! 	       (custom-make-theme-feature theme))))
  
  (defun custom-remove-theme (spec-alist theme)
    "Delete all elements from SPEC-ALIST whose car is THEME."
--- 962,973 ----
  by `custom-make-theme-feature'."
    ;; Note we do no check for validity of the theme here.
    ;; This allows to pull in themes by a file-name convention
!   (interactive "SAdd theme: ")
!   (let ((load-path (if (file-directory-p custom-theme-directory)
! 		       (cons custom-theme-directory load-path)
! 		     load-path)))
!     (require (or (get theme 'theme-feature)
! 		 (custom-make-theme-feature theme)))))
  
  (defun custom-remove-theme (spec-alist theme)
    "Delete all elements from SPEC-ALIST whose car is THEME."
***************
*** 970,975 ****
--- 987,994 ----
  face is set to the `user' theme.
  
  See `custom-known-themes' for a list of known themes."
+   (interactive
+    (list (intern (completing-read "Theme to remove: " custom-known-themes))))
    (let (spec-list)
      (mapatoms (lambda (symbol)
  		;; This works even if symbol is both a variable and a
============================================================

===File ~/cus-theme.el-diff=================================
*** cus-theme.el	17 Apr 2005 15:28:09 -0500	1.8
--- cus-theme.el	27 Jun 2005 18:56:42 -0500	
***************
*** 31,36 ****
--- 31,48 ----
  (eval-when-compile
    (require 'wid-edit))
  
+ (define-derived-mode custom-new-theme-mode nil "New-Theme"
+   "Major mode for the buffer created by `customize-create-theme'.
+ Do not call this mode function yourself.  It is only meant for internal
+ use by `customize-create-theme'."
+   (set-keymap-parent custom-new-theme-mode-map widget-keymap))
+ (put 'custom-new-theme-mode 'mode-class 'special)
+ 
+ (defvar custom-theme-name)
+ (defvar custom-theme-variables)
+ (defvar custom-theme-faces)
+ (defvar custom-theme-description)
+ 
  ;;;###autoload
  (defun customize-create-theme ()
    "Create a custom theme."
***************
*** 38,52 ****
    (if (get-buffer "*New Custom Theme*")
        (kill-buffer "*New Custom Theme*"))
    (switch-to-buffer "*New Custom Theme*")
!   (kill-all-local-variables)
    (make-local-variable 'custom-theme-name)
    (make-local-variable 'custom-theme-variables)
    (make-local-variable 'custom-theme-faces)
    (make-local-variable 'custom-theme-description)
-   (let ((inhibit-read-only t))
-     (erase-buffer))
    (widget-insert "This buffer helps you write a custom theme elisp file.
! This will help you share your customizations with other people.\n\n")
    (widget-insert "Theme name: ")
    (setq custom-theme-name
  	(widget-create 'editable-field
--- 50,72 ----
    (if (get-buffer "*New Custom Theme*")
        (kill-buffer "*New Custom Theme*"))
    (switch-to-buffer "*New Custom Theme*")
!   (let ((inhibit-read-only t))
!     (erase-buffer))
!   (custom-new-theme-mode)
    (make-local-variable 'custom-theme-name)
    (make-local-variable 'custom-theme-variables)
    (make-local-variable 'custom-theme-faces)
    (make-local-variable 'custom-theme-description)
    (widget-insert "This buffer helps you write a custom theme elisp file.
! This will help you share your customizations with other people.
! 
! Just insert the names of all variables and faces you want the theme
! to include.  Then clicking mouse-2 or pressing RET on the [Done] button
! will write a theme file that sets all these variables and faces to their
! current values.  It will write that file into the directory given by the
! variable `custom-theme-directory', usually \"~/.emacs.d/\".
! 
! To undo all your edits to the buffer, use the [Reset] button.\n\n")
    (widget-insert "Theme name: ")
    (setq custom-theme-name
  	(widget-create 'editable-field
***************
*** 81,87 ****
       			   (bury-buffer))
       		 "Bury Buffer")
    (widget-insert "\n")
-   (use-local-map widget-keymap)
    (widget-setup))
  
  (defun custom-theme-write (&rest ignore)
--- 101,106 ----
***************
*** 90,98 ****
--- 109,144 ----
  	(variables (widget-value custom-theme-variables))
  	(faces (widget-value custom-theme-faces)))
      (switch-to-buffer (concat name "-theme.el"))
+     (emacs-lisp-mode)
+     (unless (file-exists-p custom-theme-directory)
+       (make-directory (file-name-as-directory custom-theme-directory) t))
+     (setq default-directory custom-theme-directory)
      (setq buffer-file-name (expand-file-name (concat name "-theme.el")))
      (let ((inhibit-read-only t))
        (erase-buffer))
+     (insert (format ";; This file is the Custom theme file for the theme %s.
+ 
+ ;; If enabled, it sets the variables and faces listed below to the given
+ ;; values.  To enable it, type `M-x require-theme RET %s'.
+ ;; To reset all variables and faces back to their prior values, type
+ ;; `M-x custom-do-theme-reset RET %s'.
+ 
+ ;; You can also write `(require-theme %s)' in your .emacs file.
+ ;; If you do that before the `custom-set-variables' and `custom-set-faces'
+ ;; forms, any values explicitly given in these forms take precedence.
+ ;; If you write it after these forms, the theme takes precedence.
+ 
+ ;; For the above to work, this file should be in a directory in `load-path',
+ ;; or in the directory given by `custom-theme-directory' (usually
+ ;; \"~/.emacs.d/\"), which is the directory in which `custom-theme-create'
+ ;; writes the theme files it produces.
+ 
+ ;; *Please note*: this feature is experimental and needs more work.
+ ;; In Emacs 22, it does not work very well, unless you do only very
+ ;; basic things.  It is expected to work better in future Emacs versions.
+ ;; In situations where `require-theme' does not seem to work, you can
+ ;; just directly load this theme file to get the intended results.\n\n"
+ 		    name name name name name))
      (insert "(deftheme " name)
      (when doc
        (newline)
***************
*** 100,106 ****
      (insert  ")\n")
      (custom-theme-write-variables name variables)
      (custom-theme-write-faces name faces)
!     (insert "\n(provide-theme '" name ")\n")))
  
  (defun custom-theme-write-variables (theme vars)
    "Write a `custom-theme-set-variables' command for THEME.
--- 146,153 ----
      (insert  ")\n")
      (custom-theme-write-variables name variables)
      (custom-theme-write-faces name faces)
!     (insert "\n(provide-theme '" name ")\n")
!     (save-buffer)))
  
  (defun custom-theme-write-variables (theme vars)
    "Write a `custom-theme-set-variables' command for THEME.
============================================================

Re: Custom themes

[Luc Teirlinck]

Note that, after my patches, the bugs in the Custom Theme machinery
that I am aware of _only_ occur after unloading previously loaded
themes.  I could point out more explicitly in my docs that this is the
only problem.  I believe that neither color-theme.el nor etheme.el
even attempt to undo a previously loaded theme, so maybe that ability
is not that important anyway.  If you do not attempt to unload themes,
then Custom themes work pretty well after my patches.  (And _in very
basic situations_, unloading works well too.)

Sincerely,

Luc.

Re: Custom themes

[Stefan Monnier]

> So it might seem too early to document them in the Emacs manual.

I think the main reason why they're unused is that they're
completely undocumented.  I'd love to see some rough documentation for it.
It will hopefully help us all better understand the feature and improve it
(especially the UI part).

I think even a somewhat incorrect documentation would be a good thing
because it would hopefully give us bug-reports that'll help us improve both
the code and the doc.


        Stefan

Re: Custom themes

[Luc Teirlinck]

Stefan Monnier wrote:

   > So it might seem too early to document them in the Emacs manual.

   I think the main reason why they're unused is that they're
   completely undocumented.  I'd love to see some rough documentation for it.

In the patches I sent, I provided documentation in the buffers created
by `custom-create-theme'.  If people decide that after my patches it
works reliably enough for their purposes to be ready to be documented
in the Emacs manual, I could document it there.  Probably most people
will only test my patches _after_ they are applied, so I would propose
to apply them rather soon.  I will at least wait until Richard has had
time to comment.

   It will hopefully help us all better understand the feature and improve it
   (especially the UI part).

I believe my patches add some improvement to the UI part.  But I
believe that there also is the problem of bugs in the basic code.

   I think even a somewhat incorrect documentation would be a good thing
   because it would hopefully give us bug-reports that'll help us improve both
   the code and the doc.

The bugs seem numerous and the basic philosophy behind Custom Themes
is not clear.  I believe that the present code is the result of two
people _independently_ porting XEmacs code.  The result looks like
three superimposed implementation philosophies fighting with each
other.  In the text accompanying my patch, I pointed out two bugs
remaining after my patches.  I can easily fix at least one of the two,
but not without adding a fourth conflicting implementation philosophy,
which I want to avoid.  I only fixed the bugs I believed I could fix
without doing that.

I do not understand at all the philosophy behind using a `require'
type interface to adding themes rather than an unconditional load type
philosophy.

If I had to implement themes from scratch, my philosophy would be that
if two loaded themes conflict, then the most recently added one takes
precedence.  If you remove the most recently added theme, then the
theme added just before that one becomes "top dog".  This would seem
simple and intuitive.  This requires unconditional loading as the
basic theme adding operation.  But the current code desperately seems
to want to implement something else.  I have no idea why or what the
"something else" could possibly be.

I do not use XEmacs and I do not know whether the XEmacs version is
actually in active use and works according to some consistent
philosophy.  I do not know how important compatibility with XEmacs in
the Emacs Custom Themes implementation.

My patches mainly improve the UI.  They avoid touching the basic
implementation philosophy (which I do not understand, assuming there
is one).  Hence, they can not fix the bugs in that implementation.

Sincerely,

Luc.

Re: Custom themes

[Luc Teirlinck]

Stefan Monnier wrote:

   I think even a somewhat incorrect documentation would be a good thing
   because it would hopefully give us bug-reports that'll help us improve both
   the code and the doc.

I believe that the documentation I wrote is correct.

However, the problems that remain after my patches were somewhat
overstated in my original patch.  I propose to apply my patch with
this original paragraph:

;; *Please note*: this feature is experimental and needs more work.
;; In Emacs 22, it does not work very well, unless you do only very
;; basic things.  It is expected to work better in future Emacs versions.
;; In situations where `require-theme' does not seem to work, you can
;; just directly load this theme file to get the intended results.\n\n"

replaced with this:

;; *Please note*: this feature is experimental and needs more work.
;; In Emacs 22, everything should work fine if you only add and never
;; remove themes.  But removing themes only works seamlessly in very
;; basic situations.  In more complex usage, it may not work as expected.
;; For instance, after removing themes, `require-theme' might not produce
;; the expected results for themes that have already been added before.
;; In such situations, you can just directly load the theme file to get
;; the intended results.\n\n"

Sincerely,

Luc.

Re: Custom themes

[Luc Teirlinck]

In the patch I sent:

;; You can also write `(require-theme %s)' in your .emacs file.

should of course be:

;; You can also write `(require-theme '%s)' in your .emacs file.

(I forgot the ').

In as far as this .emacs type use of Custom Themes is concerned,
everything works fine and essentially already worked fine before my
patches, except for the total lack of documentation and the fact that
the UI for creating theme files, `custom-create-theme' had several
problems that are now fixed.  If this would be the main use, then that
use is _definitely_ ready to be documented in the Emacs manual.

My patches also add interactive use of Custom themes, by adding
interactive declarations.  This could actually be considered a new
feature instead of a bug or doc fix, since prior to my patches, there
were no interactive commands enabling you to manipulate Custom
Themes, so you could not use Custom Themes interactively at all.  This
type of use, especially unloading themes is the type that could be
classified as "unfinished" or "experimental" and in need of
substantial improvement.

There _was_ support for interactive use before my patches (_all_
I did was adding interactive declarations to existing functions).  But
this support appears to be unfinished.

Problems with interactive use after my patches are varied but seem to
fall into three types given by the examples below.  The first type can
be fixed without replacing requiring by unconditional loading as the
basic theme enabling command, the second type seems to require this
replacement and doing so also would fix the type 1 problems, the
third type requires more fundamental changes.

VAR has standard value 0, Theme1 sets it to 1, Theme2 to 2.

Example 1:

Require Theme1. VAR is 1. Good.  Unload Theme1.  Var is 0.  Perfect.
Require Theme1 again.  No effect, because Theme1 is still provided.

This problem could be fixed by adding:

  (setq custom-loaded-themes (delq theme custom-loaded-themes))
  (setq features (delq (get theme 'theme-feature) features)))

to the end of `custom-do-theme-reset', that is without replacing
`require-theme' by unconditional loading as the basic Theme enabling
command.  But replacing `require-theme' by unconditional loading fixes
it as well and also fixes Example 2.

Example 2:

Require Theme1. VAR is 1. Good. Require Theme2.  VAR is 2.  Good.
Require Theme1 again.  No effect, because Theme1 is already provided.
I would expect to be able to use this to reset VAR to 1.  Basically,
this type of use does require replacing requiring by loading as the
basic interactive theme enabling mechanism.

Example 3:

Require Theme1.  VAR is 1.  Require Theme2.  VAR is 2.  Unload Theme2.
VAR is 0.  I expected it to be 1.  I believe that making it be 1
requires fundamental changes, it would not just result from replacing
`require-theme' by loading.  Again, if you try to manually correct by
requiring Theme1 again, it has no effect.  Loading manually _will_
correct.

Sincerely,

Luc.

Re: Custom themes

[Richard M. Stallman]

    Note that, after my patches, the bugs in the Custom Theme machinery
    that I am aware of _only_ occur after unloading previously loaded
    themes.

What does it mean to "unload" a theme?  I can't find anything in the
code that refers to such an operation.

Re: Custom themes

[Luc Teirlinck]

So here is what I am going to do.

I keep require-theme as the basic theme enabling mechanism and do
_not_ replace it by unconditional loading.  I implement the solutions
specified below to my three problems.  I will install soon.  Then
people can try it out and see whether the entire stuff, including
interactive use, works well enough for documentation in the Emacs manual.

   VAR has standard value 0, Theme1 sets it to 1, Theme2 to 2.

   Example 1:

   Require Theme1. VAR is 1. Good.  Unload Theme1.  Var is 0.  Perfect.
   Require Theme1 again.  No effect, because Theme1 is still provided.

   This problem could be fixed by adding:

     (setq custom-loaded-themes (delq theme custom-loaded-themes))
     (setq features (delq (get theme 'theme-feature) features)))

   to the end of `custom-do-theme-reset',

I will do exactly that.

   Example 2:

   Require Theme1.  VAR is 1. Good.  Require Theme2.  VAR is 2.  Good.
   Require Theme1 again.  No effect, because Theme1 is already provided.
   I would expect to be able to use this to reset VAR to 1.  Basically,
   this type of use does require replacing requiring by loading as the
   basic interactive theme enabling mechanism.

I will tell people in the docs that they need to manually load the
file containing Theme1 if they are in this situation and that is what
they want.  If people turn out to be often in this situation, we could
provide a third interactive command to make this more convenient.

   Example 3:

   Require Theme1.  VAR is 1.  Require Theme2.  VAR is 2.  Unload Theme2.
   VAR is 0.

After reading the docstring more carefully, this appears to be
intentional, so I am going to leave it unchanged.  Manually reloading
the file containing Theme1 will be the recommended solution for people
who actually wanted the "setting VAR to 1" type behavior.

Sincerely,

Luc.

Re: Custom themes

[Richard M. Stallman]

    I think even a somewhat incorrect documentation would be a good thing
    because it would hopefully give us bug-reports that'll help us improve both
    the code and the doc.

I agree completely.  Meanwhile, I think Luc's latest fixes make it
work well enough to be useful.  So let's document it, and people
can start using it.

Re: Custom themes

[Luc Teirlinck]

Unfortunately, after taking a closer look at it, things are way worse
than I originally thought.  It does not appear that there is _any_
support for undoing the requiring of an individual theme in the
current code.  You can apparently more or less undo all themes
together (although you have to ask to undo one single theme to get
that effect), but one can not undo just one particular theme.

The function `custom-do-theme-reset' does not do what I thought it
did.  I was mislead by its docstring.  That docstring is terrible.

    "Undo all settings defined by THEME.

  A variable remains unchanged if its property `theme-value' does not
  contain a value for THEME.  A face remains unchanged if its property
  `theme-face' does not contain a value for THEME.  In either case, all
  settings for THEME are removed from the property and the variable or
  face is set to the `user' theme.

The docstring contadicts itself.  A variable remains _un_changed if...
A face remains _un_changed if...  In either case, the variable or face
_is_ changed to the 'user' theme.  Which of the two?  What happens in
other cases?  Not only do both statements in the docstring say
opposite things, they are _both_ wrong.

What really happens is that _all_ variables and faces get reset to the
user theme whenever they _have_ a `theme-value' or `theme-face'
property, _regardless_ of whether the `theme-value' or `theme-face'
property contains a value for THEME or not.  What the function does is
setting _everything_ back to the `user' theme, that is, it undoes the
effects of all loaded themes, regardless of the value of THEME.

Fixing this function or most related stuff in the Custom Themes code
seems hopeless.  This function's code (and much of the related code)
appears to be as incoherent as its docstring.  The entire Custom
themes implementation appears to be completely unfinished at best.

However, the _enabling_ of Custom themes actually appears to work.
What I could do is install the following revised version of my
patches.  I believe this version is now sufficiently tested.

===File ~/cus-theme.el-diff=================================
*** cus-theme.el	17 Apr 2005 15:28:09 -0500	1.8
--- cus-theme.el	28 Jun 2005 20:33:02 -0500	
***************
*** 31,36 ****
--- 31,48 ----
  (eval-when-compile
    (require 'wid-edit))
  
+ (define-derived-mode custom-new-theme-mode nil "New-Theme"
+   "Major mode for the buffer created by `customize-create-theme'.
+ Do not call this mode function yourself.  It is only meant for internal
+ use by `customize-create-theme'."
+   (set-keymap-parent custom-new-theme-mode-map widget-keymap))
+ (put 'custom-new-theme-mode 'mode-class 'special)
+ 
+ (defvar custom-theme-name)
+ (defvar custom-theme-variables)
+ (defvar custom-theme-faces)
+ (defvar custom-theme-description)
+ 
  ;;;###autoload
  (defun customize-create-theme ()
    "Create a custom theme."
***************
*** 38,52 ****
    (if (get-buffer "*New Custom Theme*")
        (kill-buffer "*New Custom Theme*"))
    (switch-to-buffer "*New Custom Theme*")
!   (kill-all-local-variables)
    (make-local-variable 'custom-theme-name)
    (make-local-variable 'custom-theme-variables)
    (make-local-variable 'custom-theme-faces)
    (make-local-variable 'custom-theme-description)
-   (let ((inhibit-read-only t))
-     (erase-buffer))
    (widget-insert "This buffer helps you write a custom theme elisp file.
! This will help you share your customizations with other people.\n\n")
    (widget-insert "Theme name: ")
    (setq custom-theme-name
  	(widget-create 'editable-field
--- 50,72 ----
    (if (get-buffer "*New Custom Theme*")
        (kill-buffer "*New Custom Theme*"))
    (switch-to-buffer "*New Custom Theme*")
!   (let ((inhibit-read-only t))
!     (erase-buffer))
!   (custom-new-theme-mode)
    (make-local-variable 'custom-theme-name)
    (make-local-variable 'custom-theme-variables)
    (make-local-variable 'custom-theme-faces)
    (make-local-variable 'custom-theme-description)
    (widget-insert "This buffer helps you write a custom theme elisp file.
! This will help you share your customizations with other people.
! 
! Just insert the names of all variables and faces you want the theme
! to include.  Then clicking mouse-2 or pressing RET on the [Done] button
! will write a theme file that sets all these variables and faces to their
! current global values.  It will write that file into the directory given
! by the variable `custom-theme-directory', usually \"~/.emacs.d/\".
! 
! To undo all your edits to the buffer, use the [Reset] button.\n\n")
    (widget-insert "Theme name: ")
    (setq custom-theme-name
  	(widget-create 'editable-field
***************
*** 81,87 ****
       			   (bury-buffer))
       		 "Bury Buffer")
    (widget-insert "\n")
-   (use-local-map widget-keymap)
    (widget-setup))
  
  (defun custom-theme-write (&rest ignore)
--- 101,106 ----
***************
*** 90,98 ****
--- 109,143 ----
  	(variables (widget-value custom-theme-variables))
  	(faces (widget-value custom-theme-faces)))
      (switch-to-buffer (concat name "-theme.el"))
+     (emacs-lisp-mode)
+     (unless (file-exists-p custom-theme-directory)
+       (make-directory (file-name-as-directory custom-theme-directory) t))
+     (setq default-directory custom-theme-directory)
      (setq buffer-file-name (expand-file-name (concat name "-theme.el")))
      (let ((inhibit-read-only t))
        (erase-buffer))
+     (insert (format ";; This file is the Custom theme file for the theme %s.
+ 
+ ;; If enabled, it sets the variables and faces listed below to the given
+ ;; values.  To enable it, type `M-x require-theme RET %s',
+ ;; or just load this file.
+ 
+ ;; You can also write `(require-theme '%s)' (or load
+ ;; this file) in your .emacs file.  If you do that before the
+ ;; `custom-set-variables' and `custom-set-faces' forms, any values
+ ;; explicitly given in these forms take precedence.  If you write it
+ ;; after these forms, the theme takes precedence.
+ 
+ ;; For the command `require-theme' to work, this file should be in a
+ ;; directory in `load-path', or in the directory given by
+ ;; `custom-theme-directory' (usually \"~/.emacs.d/\"), which is the
+ ;; directory in which `custom-theme-create' writes the theme files it
+ ;; produces.
+ 
+ ;; Requiring a theme that is already loaded has no effect.  You have to
+ ;; load this file directly if you want to reinstall settings that got
+ ;; overridden.\n\n"
+ 		    name name name))
      (insert "(deftheme " name)
      (when doc
        (newline)
***************
*** 100,106 ****
      (insert  ")\n")
      (custom-theme-write-variables name variables)
      (custom-theme-write-faces name faces)
!     (insert "\n(provide-theme '" name ")\n")))
  
  (defun custom-theme-write-variables (theme vars)
    "Write a `custom-theme-set-variables' command for THEME.
--- 145,152 ----
      (insert  ")\n")
      (custom-theme-write-variables name variables)
      (custom-theme-write-faces name faces)
!     (insert "\n(provide-theme '" name ")\n")
!     (save-buffer)))
  
  (defun custom-theme-write-variables (theme vars)
    "Write a `custom-theme-set-variables' command for THEME.
============================================================

===File ~/custom.el-diff====================================
*** custom.el	13 Apr 2005 13:49:27 -0500	1.83
--- custom.el	28 Jun 2005 19:36:19 -0500	
***************
*** 560,566 ****
  	      (t (condition-case nil (load load) (error nil))))))))
  
  (defvar custom-known-themes '(user standard)
!    "Themes that have been define with `deftheme'.
  The default value is the list (user standard).  The theme `standard'
  contains the Emacs standard settings from the original Lisp files.  The
  theme `user' contains all the the settings the user customized and saved.
--- 560,566 ----
  	      (t (condition-case nil (load load) (error nil))))))))
  
  (defvar custom-known-themes '(user standard)
!    "Themes that have been defined with `deftheme'.
  The default value is the list (user standard).  The theme `standard'
  contains the Emacs standard settings from the original Lisp files.  The
  theme `user' contains all the the settings the user customized and saved.
***************
*** 926,931 ****
--- 926,944 ----
  (defvar custom-loaded-themes nil
    "Themes in the order they are loaded.")
  
+ (defcustom custom-theme-directory
+   (if (eq system-type 'ms-dos)
+ 	 ;; MS-DOS cannot have initial dot.
+ 	 "~/_emacs.d/"
+       "~/.emacs.d/")
+   "Directory in which Custom theme files should be written.
+ `require-theme' searches this directory in addition to load-path.
+ The command `customize-create-theme' writes the files it produces
+ into this directory."
+   :type 'string
+   :group 'customize
+   :version "22.1")
+ 
  (defun custom-theme-loaded-p (theme)
    "Return non-nil when THEME has been loaded."
    (memq theme custom-loaded-themes))
***************
*** 949,956 ****
  by `custom-make-theme-feature'."
    ;; Note we do no check for validity of the theme here.
    ;; This allows to pull in themes by a file-name convention
!   (require (or (get theme 'theme-feature)
! 	       (custom-make-theme-feature theme))))
  
  (defun custom-remove-theme (spec-alist theme)
    "Delete all elements from SPEC-ALIST whose car is THEME."
--- 962,973 ----
  by `custom-make-theme-feature'."
    ;; Note we do no check for validity of the theme here.
    ;; This allows to pull in themes by a file-name convention
!   (interactive "SAdd theme: ")
!   (let ((load-path (if (file-directory-p custom-theme-directory)
! 		       (cons custom-theme-directory load-path)
! 		     load-path)))
!     (require (or (get theme 'theme-feature)
! 		 (custom-make-theme-feature theme)))))
  
  (defun custom-remove-theme (spec-alist theme)
    "Delete all elements from SPEC-ALIST whose car is THEME."
============================================================

Re: Custom themes

[Richard M. Stallman]

    If I had to implement themes from scratch, my philosophy would be that
    if two loaded themes conflict, then the most recently added one takes
    precedence.

That sounds like a good approach.  I see a few approaches that
could make sense:

1. Most recent takes priority.
2. Let user specify the priority order.
3. Don't allow loading themes that conflict.
4. Ask the user what to do, each time there is a conflict.

I am not sure which of these is best.  Are there other apps that allow
loading multiple themes at once?  If so, how do they handle this?

      If you remove the most recently added theme, then the
    theme added just before that one becomes "top dog".  This would seem
    simple and intuitive.

Yes.

      This requires unconditional loading as the
    basic theme adding operation.

I do not understand "unconditional loading".  Could you explain
what you mean by that?

    I do not use XEmacs and I do not know whether the XEmacs version is
    actually in active use and works according to some consistent
    philosophy.  I do not know how important compatibility with XEmacs in
    the Emacs Custom Themes implementation.

It is not crucial, unless they want to work with us on this.
Don't worry about it.

    replaced with this:

    ;; *Please note*: this feature is experimental and needs more work.
    ;; In Emacs 22, everything should work fine if you only add and never
    ;; remove themes.  But removing themes only works seamlessly in very
    ;; basic situations.  In more complex usage, it may not work as expected.
    ;; For instance, after removing themes, `require-theme' might not produce
    ;; the expected results for themes that have already been added before.
    ;; In such situations, you can just directly load the theme file to get
    ;; the intended results.\n\n"

That is good.

Re: Custom themes

[Luc Teirlinck]

Richard Stallman wrote:

   That sounds like a good approach.  I see a few approaches that
   could make sense:

   1. Most recent takes priority.
   2. Let user specify the priority order.
   3. Don't allow loading themes that conflict.
   4. Ask the user what to do, each time there is a conflict.

It would appear that "unrequiring" of individual themes does not
currently work after all, as I already pointed out.  In that case,
just allowing to require or load implements (1): Most recent wins.

   I do not understand "unconditional loading".  Could you explain
   what you mean by that?

`require-theme' checks whether the theme already has been loaded, by
checking whether it is a member of `features'.  In other words, it
works just like a regular require.  If it is already in features,
`require-theme' does nothing.  By "unconditional loading", I mean
just loading the file without checking anything.  My latest patches
just mention both possibilities and let the user decide.

I believe that a really natural and intuitive implementation of
unrequiring individual themes (in fact just implementing _any_
unrequiring of individual themes) requires a lot more work.  The
current Custom Themes code does not appear to come close to succeeding
in implementing _any_ form of individual unrequiring.  My original
impression that it did was erroneous.  I doubt that the current Custom
themes code even can be used as a _basis_ for that.

Sincerely,

Luc.

Re: Custom themes

[Richard M. Stallman]

    Unfortunately, after taking a closer look at it, things are way worse
    than I originally thought.  It does not appear that there is _any_
    support for undoing the requiring of an individual theme in the
    current code.  You can apparently more or less undo all themes
    together (although you have to ask to undo one single theme to get
    that effect), but one can not undo just one particular theme.

That sounds easy to solve.  Suppose you have enabled themes A, B and
C.  To undo theme A, you undo them all, then reapply B and C.

    The docstring contadicts itself.  A variable remains _un_changed if...
    A face remains _un_changed if...  In either case, the variable or face
    _is_ changed to the 'user' theme.  Which of the two?  What happens in
    other cases?  Not only do both statements in the docstring say
    opposite things, they are _both_ wrong.

Can you fix that doc string to be accurate?

Then you could easily implement a command to undo one theme
using the method I suggested above.

Re: Custom themes

[Luc Teirlinck]

Richard Stallman wrote:

   Can you fix that doc string to be accurate?

   Then you could easily implement a command to undo one theme
   using the method I suggested above.

It seems impossible to figure out what custom-do-theme-reset is really
_trying_ to do, and custom-do-theme-reset is used in other functions,
so I can not just change it to do something that makes sense to me.
What it actually does is complex (the technical details are involved)
and seems to make no sense whatsoever.  This is ported XEmacs code.
What the function apparently wants to do is "exactly the same thing as
what the XEmacs function does, whatever that is".  It seems to me that
what happened is that the person who ported the code did not fully
understand what the XEmacs function does.  This seems to explain both
the apparent lack of consistency of the code itself, and the
inconsistency of the docs.

The situation with Custom themes is a lot worse that I thought
yesterday.  I discovered two new bugs, one so serious that it makes
the Custom themes feature unusable.  It is nearly guaranteed that even
if those two bugs could be solved plenty of others remain.  The Custom
Themes code seems to have been incorrectly ported from XEmacs, to a
degree that it is presently completely dysfunctional.

It is nearly impossible to understand incorrectly ported code, unless
you know the package that was ported.  It _is_ possible for me to
debug cus-theme.el, even though it has many bugs, because it is
originally designed code.  You can guess the original design and make
the code behave like it.  However, the themes code in custom.el is
ported code.  In this incorrectly ported code, the original design
seems to be destroyed by the incorrect porting.  You can only know it
by studying the package that was ported.

Repairing and debugging the themes code means correcting the porting
errors and finishing off the porting task.  I never used XEmacs, I do
not have it installed.  I do not know anything about the differences
between the Emacs and XEmacs versions of Elisp.  I know nothing about
the actual XEmacs version of Custom themes.  I do not know how it
works, whether it works (without excessive bugs), whether it is
actually used by people and, if so, how it is used.

I am absolutely not the right person to work on this.  Somebody who is
interested in Emacs development, but who is familiar with XEmacs
Custom Themes should finish this off.  "Finishing it off" seems to be
a substantial task.

Sincerely,

Luc.

Re: Custom themes

[David Kastrup]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> The situation with Custom themes is a lot worse that I thought
> yesterday.  I discovered two new bugs, one so serious that it makes
> the Custom themes feature unusable.  It is nearly guaranteed that
> even if those two bugs could be solved plenty of others remain.  The
> Custom Themes code seems to have been incorrectly ported from
> XEmacs, to a degree that it is presently completely dysfunctional.
>
> It is nearly impossible to understand incorrectly ported code,
> unless you know the package that was ported.  It _is_ possible for
> me to debug cus-theme.el, even though it has many bugs, because it
> is originally designed code.  You can guess the original design and
> make the code behave like it.  However, the themes code in custom.el
> is ported code.  In this incorrectly ported code, the original
> design seems to be destroyed by the incorrect porting.  You can only
> know it by studying the package that was ported.
>
> Repairing and debugging the themes code means correcting the porting
> errors and finishing off the porting task.  I never used XEmacs, I
> do not have it installed.  I do not know anything about the
> differences between the Emacs and XEmacs versions of Elisp.  I know
> nothing about the actual XEmacs version of Custom themes.  I do not
> know how it works, whether it works (without excessive bugs),
> whether it is actually used by people and, if so, how it is used.
>
> I am absolutely not the right person to work on this.  Somebody who
> is interested in Emacs development, but who is familiar with XEmacs
> Custom Themes should finish this off.  "Finishing it off" seems to
> be a substantial task.

I seem to remember from discussions on XEmacs-beta that this feature
is not widely used or recognized by XEmacs developers, so it is
possible that the overall quality of the original code on XEmacs (if
it indeed originates there) is not much better than what you have at
hand at the moment.

I do think that having custom themes would be quite desirable: users
could select a default site theme, for example, and override parts of
it with other themes.

If the design of the API is sound, it might be the sanest choice to
eventually come up with an implementation from scratch if the
situation is as bad as you describe, and just document the current
implementation of being a draft, and documenting where it is still
defective.  If there are doubts about the API to be implementable at
all, we should probably remove theme support altogether from Emacs 22:
there is no sense in getting people used to interfaces that can and
will not be fixed or implemented.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Custom themes

[David Kastrup]

"Richard M. Stallman" <rms@gnu.org> writes:

>     If I had to implement themes from scratch, my philosophy would be that
>     if two loaded themes conflict, then the most recently added one takes
>     precedence.
>
> That sounds like a good approach.  I see a few approaches that
> could make sense:
>
> 1. Most recent takes priority.
> 2. Let user specify the priority order.
> 3. Don't allow loading themes that conflict.

3 is out as far as I can see.  The whole point of themes is that they
are overriding the "standard" theme, so conflict management is one of
the main points of themes.

>       This requires unconditional loading as the
>     basic theme adding operation.
>
> I do not understand "unconditional loading".  Could you explain what
> you mean by that?

I guess that a theme, when required, will get reloaded even if it has
been loaded previously.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Custom themes

[Per Abrahamsen]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> I do not use XEmacs and I do not know whether the XEmacs version is
> actually in active use and works according to some consistent
> philosophy.  I do not know how important compatibility with XEmacs in
> the Emacs Custom Themes implementation.

If you manage to massage custom themes into a practically working
state, that will be the only such version of "custom themes" in
existence as far as I know.

I.e. your version will be the de-facto standard.

Re: Custom themes

[Richard M. Stallman]

    It seems impossible to figure out what custom-do-theme-reset is really
    _trying_ to do

You said it resets all themes.  That sounds like a good definition.
Please take that as the purpose of the function.

    What the function apparently wants to do is "exactly the same thing as
    what the XEmacs function does, whatever that is".

It makes no difference what the "function apparently wants to do".
You have a clear purpose in mind.  Make the code fit that purpose, and
it will work.  There is no need to worry about former confused ideas
that you have replaced with a clear idea.

    The situation with Custom themes is a lot worse that I thought
    yesterday.  I discovered two new bugs, one so serious that it makes
    the Custom themes feature unusable.

Would you please report them (or, even better, fix them)?

    Repairing and debugging the themes code means correcting the porting
    errors and finishing off the porting task.  I never used XEmacs, I do
    not have it installed.  

It is not necessary to know anything about XEmacs to make this code
work.

Re: Custom themes

[Richard M. Stallman]

    It seems impossible to figure out what custom-do-theme-reset is really
    _trying_ to do

You said it resets all themes.  That sounds like a good definition.
Please take that as the purpose of the function.

    What the function apparently wants to do is "exactly the same thing as
    what the XEmacs function does, whatever that is".

It makes no difference what the "function apparently wants to do".
You have a clear purpose in mind.  Make the code fit that purpose, and
stop wasting your own time worrying about what someone else thought.

    The situation with Custom themes is a lot worse that I thought
    yesterday.  I discovered two new bugs, one so serious that it makes
    the Custom themes feature unusable.

Please report them (or fix them).

    Repairing and debugging the themes code means correcting the porting
    errors and finishing off the porting task.  I never used XEmacs, I do
    not have it installed.  

It is irrelevant anyway.

    I am absolutely not the right person to work on this.

You've done fine so far, studying the code and fixing it.  Your only
problem is that you don't believe that this is the right thing to do.

Re: Custom themes

[Luc Teirlinck]

David Kastrup wrote:

   I guess that a theme, when required, will get reloaded even if it has
   been loaded previously.

With the current code, they do _not_ get reloaded when already loaded.
If I would re-implement it, they would be reloaded.

Sincerely,

Luc.

Re: Custom themes

[Richard M. Stallman]

    With the current code, they do _not_ get reloaded when already loaded.
    If I would re-implement it, they would be reloaded.

If that's the easiest way to get correct functioning, please do it.

Re: Custom themes

[Richard M. Stallman]

    With the current code, they do _not_ get reloaded when already loaded.
    If I would re-implement it, they would be reloaded.

How about making that fix?  It should pretty easy.

Re: Custom themes

[Luc Teirlinck]

Richard Stallman wrote:

       With the current code, they do _not_ get reloaded when already loaded.
       If I would re-implement it, they would be reloaded.

   How about making that fix?  It should pretty easy.

It is not at all as trivial as it seems.  The current Custom themes
code is not adapted to that.

Sincerely,

Luc.

Custom themes

[Richard M. Stallman]

Would someone please test the new custom themes code
and fix, or at least report, the bugs?

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

[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

[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

[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

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

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

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

[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

[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

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

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