Trying to right-align my window on startup

Trying to right-align my window on startup

[Mickey Ferguson]

On most of my systems (which are running Windows ranging from XP to Windows 7), when I start up emacs I want to right-align the window, with the top of the window set to the top of the screen and the right (or left) edge of the window touching the right (or left) edge of the screen.  I have an environment variable, emacs_alignment, that defines whether or not it should be left or right.  I wrote a function that does this nicely:

(defun align-window ()
  "fix window positioning"
  (interactive)
  (if (equal (getenv "emacs_alignment") "right")
      (align-window-right)
    (align-window-left))
  )

(defun align-window-left ()
  "align window to left window edge"
  (interactive)
  (set-frame-position (selected-frame) 0 0)
  )

(defun align-window-right ()
  "align window to right window edge"
  (interactive)
  (set-frame-position (selected-frame) -1 0)
  )

If I execute this function after emacs has started up, it works perfectly.  If I throw it into my .emacs file, it doesn't seem to do anything.  (The above code is found in MF-Init.el, which of course is also byte-compiled.)  Here is my .emacs file:

(condition-case error
    (progn
      ;;; -*-Emacs-Lisp-*-

      ; want to start editing immediately
      (setq-default inhibit-startup-message t)
      (setq-default inhibit-startup-echo-area-message t)
      (add-hook 'after-init-hook 'align-window)
     (load-library "MF-Init")
     ;;; I also tried putting (align-window) in here, but that also did nothing.
      )
  (error (progn (ding)
                (message "%s  %s"
                         "There is an error in your ~/.emacs file."
                         "Press any key to enter the debugger.")
                (discard-input)
                (sit-for 1000)
                (debug 'error error))))

Any idea how to get this function to execute properly upon the completion of every other bit of initialization?  Please reply directly to my email (Mickey dot Ferguson at CassidianCommunications dot com) since we do not have a valid news feed.  Thanks for any help you can provide!

Re: Trying to right-align my window on startup

[Eli Zaretskii]

> From: Mickey Ferguson <Mickey.Ferguson@cassidiancommunications.com>
> Date: Wed, 8 Jan 2014 20:11:30 +0000
> 
> Any idea how to get this function to execute properly upon the completion of every other bit of initialization?  Please reply directly to my email (Mickey dot Ferguson at CassidianCommunications dot com) since we do not have a valid news feed.  Thanks for any help you can provide!

Look in startup.el, and you will find there a few hooks provided by
the startup code.  Try running your code from one of those hooks.

Re: Trying to right-align my window on startup

[Eli Zaretskii]

[Let's not omit help-gnu-emacs from the addressees, ok?]

> From: Mickey Ferguson <Mickey.Ferguson@cassidiancommunications.com>
> Date: Wed, 8 Jan 2014 21:20:03 +0000
> 
> Eli, thank you for your reply.  That was a good starting point.  First, I added a message to display when my function runs.  Then I tried adding it to after-init-hook.  Didn't see the message.  I changed it to emacs-startup-hook.  I now see the message ("Ran align-window-right"), but it still doesn't move the window.  I also tried changing it from emacs-startup-hook to window-setup-hook, and again, it displays the message, indicating that it ran, but the window remains unmoved.

Why don't you try doing this by modifying frame parameters (via
add-to-list) instead?  This is how I set the position and dimensions
of my frame in my .emacs:

  (add-to-list 'default-frame-alist '(top . 0))
  (add-to-list 'default-frame-alist '(left . 140))
  (add-to-list 'initial-frame-alist '(height . 52))
  (add-to-list 'default-frame-alist '(height . 50))

I understand that in your case the numbers will have to be computed
first, but that's just a minor variation, I think.

RE: Trying to right-align my window on startup

[Mickey Ferguson]

> [Let's not omit help-gnu-emacs from the addressees, ok?]

Sorry...

>Why don't you try doing this by modifying frame parameters (via
>add-to-list) instead?  This is how I set the position and dimensions
>of my frame in my .emacs:
>
?  (add-to-list 'default-frame-alist '(top . 0))
>  (add-to-list 'default-frame-alist '(left . 140))
>  (add-to-list 'initial-frame-alist '(height . 52))
>  (add-to-list 'default-frame-alist '(height . 50))
>
>I understand that in your case the numbers will have to be computed
>first, but that's just a minor variation, I think.

The problem here is that I want a generic file that will work for multiple
screen dimensions.  A while ago I had tried going down the path you have
suggested here and just didn't know all of the screen parameters, nor how
to convert from one unit type to another.  That's why the -1 was used, as
an attempt at using emacs' knowledge of the screen's right edge location.

Re: Trying to right-align my window on startup

[Eli Zaretskii]

> From: Mickey Ferguson <Mickey.Ferguson@cassidiancommunications.com>
> CC: "help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
> Date: Thu, 9 Jan 2014 20:16:07 +0000
> 
> >Why don't you try doing this by modifying frame parameters (via
> >add-to-list) instead?  This is how I set the position and dimensions
> >of my frame in my .emacs:
> >
> ?  (add-to-list 'default-frame-alist '(top . 0))
> >  (add-to-list 'default-frame-alist '(left . 140))
> >  (add-to-list 'initial-frame-alist '(height . 52))
> >  (add-to-list 'default-frame-alist '(height . 50))
> >
> >I understand that in your case the numbers will have to be computed
> >first, but that's just a minor variation, I think.
> 
> The problem here is that I want a generic file that will work for multiple
> screen dimensions.

That's why I said that the numbers will have to be computed, and that
computation will need to take the screen dimensions into account.
Where's the contradiction? what am I missing?

RE: Trying to right-align my window on startup

[Drew Adams]

> ?  (add-to-list 'default-frame-alist '(top . 0))
> >  (add-to-list 'default-frame-alist '(left . 140))
> >  (add-to-list 'initial-frame-alist '(height . 52))
> >  (add-to-list 'default-frame-alist '(height . 50))

Sheesh.  Just use `M-x customize-option default-frame-alist'.

(And use a `custom-file', to keep Customize stuff out of your ~/.emacs.)

> The problem here is that I want a generic file that will work for
> multiple screen dimensions.  A while ago I had tried going down
> the path you have suggested here and just didn't know all of the
> screen parameters, nor how to convert from one unit type to another.
> That's why the -1 was used, as an attempt at using emacs' knowledge
> of the screen's right edge location.

Just use a negative integer (e.g. -1) to set the number of pixels
from the right or bottom edge of your screen.

See the Elisp manual, node `(elisp) Position Parameters'

Re: Trying to right-align my window on startup

[Eli Zaretskii]

> Date: Thu, 9 Jan 2014 12:32:27 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: help-gnu-emacs@gnu.org
> 
> > ?  (add-to-list 'default-frame-alist '(top . 0))
> > >  (add-to-list 'default-frame-alist '(left . 140))
> > >  (add-to-list 'initial-frame-alist '(height . 52))
> > >  (add-to-list 'default-frame-alist '(height . 50))
> 
> Sheesh.  Just use `M-x customize-option default-frame-alist'.

Sheesh, why do you care how I set up my Emacs?

Re: Trying to right-align my window on startup

[Marcin Borkowski]

Dnia 2014-01-09, o godz. 22:36:36
Eli Zaretskii <eliz@gnu.org> napisał(a):

> > Date: Thu, 9 Jan 2014 12:32:27 -0800 (PST)
> > From: Drew Adams <drew.adams@oracle.com>
> > Cc: help-gnu-emacs@gnu.org
> > 
> > > ?  (add-to-list 'default-frame-alist '(top . 0))
> > > >  (add-to-list 'default-frame-alist '(left . 140))
> > > >  (add-to-list 'initial-frame-alist '(height . 52))
> > > >  (add-to-list 'default-frame-alist '(height . 50))
> > 
> > Sheesh.  Just use `M-x customize-option default-frame-alist'.
> 
> Sheesh, why do you care how I set up my Emacs?

Agreed.  Just out of curiosity: am I the only one who *hates* when
someone or something (including M-x customize) messes up with *my*
init.el? ;)

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University

RE: Trying to right-align my window on startup

[Drew Adams]

> > > > ?  (add-to-list 'default-frame-alist '(top . 0))
> > > > >  (add-to-list 'default-frame-alist '(left . 140))
> > > > >  (add-to-list 'initial-frame-alist '(height . 52))
> > > > >  (add-to-list 'default-frame-alist '(height . 50))
> > >
> > > Sheesh.  Just use `M-x customize-option default-frame-alist'.
> >
> > Sheesh, why do you care how I set up my Emacs?
> 
> Agreed.  Just out of curiosity: am I the only one who *hates* when
> someone or something (including M-x customize) messes up with *my*
> init.el? ;)

Use variable `custom-file'.  That's what it's for.  The only thing
that messes with my init file is me.

But that does not mean that I don't take advantage of Customize's
type-checking, `:set' and `:initialize' trigger actions, etc.

This too is a common misconception about Customize.  It is _you_
who invites Customize to mess with your init file, if you don't
use `custom-file'.  Don't blame Customize for that.

(You might blame Emacs design for even letting Customize do that,
and not just raising an error if `custom-file' is not defined as
a writable file.  IOW, a design bug, so far.)

Re: Trying to right-align my window on startup

[Sebastien Vauban]

Marcin Borkowski wrote:
> Dnia 2014-01-09, o godz. 22:36:36
> Eli Zaretskii <eliz-mXXj517/zsQ@public.gmane.org> napisał(a):
>
>> > Date: Thu, 9 Jan 2014 12:32:27 -0800 (PST)
>> > From: Drew Adams <drew.adams-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
>> > Cc: help-gnu-emacs-mXXj517/zsQ@public.gmane.org
>> > 
>> > > ?  (add-to-list 'default-frame-alist '(top . 0))
>> > > >  (add-to-list 'default-frame-alist '(left . 140))
>> > > >  (add-to-list 'initial-frame-alist '(height . 52))
>> > > >  (add-to-list 'default-frame-alist '(height . 50))
>> > 
>> > Sheesh.  Just use `M-x customize-option default-frame-alist'.
>> 
>> Sheesh, why do you care how I set up my Emacs?
>
> Agreed.  Just out of curiosity: am I the only one who *hates* when
> someone or something (including M-x customize) messes up with *my*
> init.el? ;)

No, you aren't: I can't stand using Customize, as it will group all
variables together at one place, by alphabetical order (hence, not by
semantic groups), with no blank lines, and (worst for me) no comments.

Best regards,
  Seb

-- 
Sebastien Vauban

RE: Trying to right-align my window on startup

[Drew Adams]

> I can't stand using Customize, as it will group all variables
> together at one place, by alphabetical order (hence, not
> by semantic groups), with no blank lines, and (worst for me) no
> comments.

What do you care?  Why even look at that generated code?  I'd
say that if you're doing that you're probably doing something
wrong (unnecessary, and perhaps indicative of another problem).

If you keep that generated code separate from your init file,
there is no reason to bother with it whatsoever.  I probably
look at the code inside my `custom-file' at most once a year.
(And I do quite a lot of Emacs Lisp coding.)

RE: Trying to right-align my window on startup

[Mickey Ferguson]

>> The problem here is that I want a generic file that will work for 
>> multiple screen dimensions.  A while ago I had tried going down the 
>> path you have suggested here and just didn't know all of the screen 
>> parameters, nor how to convert from one unit type to another.
>> That's why the -1 was used, as an attempt at using emacs' knowledge of 
>> the screen's right edge location.
>
>Just use a negative integer (e.g. -1) to set the number of pixels from the right or bottom edge of your >screen.

The problem is not that I can't get the code to make the window move to the right position.  I've got the align-window function (below) working just fine.  The problem is that I can't get it to execute automatically upon emacs startup.  I can't figure out how or where to place it so that it executes _and works properly_.  I put it my MF-Init.el file that is loaded upon startup.  In the load of that library, it automatically sets the desired font and calls align-window.  If I just start up emacs, I see the message "Ran align-window-right" in the message area of the window, but it isn't right-aligned.  If I do a M-x load-library of that same file, it loads it (again), but this time it really does move the window to right alignment.

Any clues what I'm doing wrong, or how to solve it?

(defun align-window ()
  "fix window positioning"
  (interactive)
  (if (equal (getenv "emacs_alignment") "right")
      (align-window-right)
    (align-window-left))
  )

;;;set C-x \ (backslash) to align-window
(global-set-key "\C-x\\" 'align-window)

(defun align-window-left ()
  "align window to left window edge"
  (interactive)
  (set-frame-position (selected-frame) 0 0)
  (message "Ran align-window-left")
  )

(defun align-window-right ()
  "align window to right window edge"
  (interactive)
  (set-frame-position (selected-frame) -1 0)
  (message "Ran align-window-right")
  )

RE: Trying to right-align my window on startup

[Drew Adams]

> >Just use a negative integer (e.g. -1) to set the number of pixels
> >from the right or bottom edge of your >screen.
> 
> The problem is not that I can't get the code to make the window move
> to the right position.  I've got the align-window function (below)
> working just fine.  The problem is that I can't get it to execute
> automatically upon emacs startup.

And yet clearly you did get it to execute automatically, since it
sent the message "Ran align-window-right".

> I can't figure out how or where to place it so that it executes
> _and works properly_.  I put it my MF-Init.el file that is loaded
> upon startup.

Replace that file with one that does _only_ what you are testing.
Adding something untested to a giant sack of eels is not the way
to test that something.  (No, I cannot know that MF-Init.el is a
sack of eels.  Just a hunch.)

> In the load of that library, it automatically sets the desired
> font and calls align-window.

You are doing too much to find out about your problem.  Why throw
this test in with changing the font, checking the phase of the
moon, and mailing your mom her horoscope? ;-)

> If I just start up emacs, I see the message "Ran align-
> window-right" in the message area of the window, but it isn't right-
> aligned.

According to your code, that could happen if the `selected-frame'
is not what you think it is.  Try adding a`message' call that tells
you what the selected frame is, and its displayed buffer etc.
IOW, find out what is going on.

> If I do a M-x load-library of that same file, it loads it
> (again), but this time it really does move the window to right
> alignment.

When?  Via the command-line switch -l?  Or using M-x load-file?
Emacs startup is a whole sequence of events.  Only at a particular
point is anything displayed.  At that point there is a frame to
be selected and aligned, but not before.

> Any clues what I'm doing wrong, or how to solve it?
> 
> (defun align-window-right ()
>   "align window to right window edge"
>   (interactive)
>   (set-frame-position (selected-frame) -1 0)
>   (message "Ran align-window-right"))

I do not see the problem here (on MS Windows).

I put just (align-window-right) in an otherwise empty file foo.el
(so I don't have to set the environment var), and I ran
emacs -Q -l "c:\path\to\foo.el".  That should be pretty much
equivalent to loading foo.el as an init file.

The frame was right-aligned, and I got the message
"Ran align-window-right".  No problem.

Try that: get rid of everything extraneous from your .emacs
(comment it out).  If that works, then bisect your .emacs
recursively, to find out what was interfering with the right
behavior.

FWIW, the fact that the code you showed here includes a comment,
a key binding, and a function that picks up an environment
var, all of which are extraneous, is indicative of not trying
to pare this down, to debug it.  (You can do that before asking
here, for instance.)

`M-x comment-region', with a numeric and with a plain prefix arg,
is your friend.  Use it to locate a problem in any file you load,
including your init file.  I bind it to `C-x C-;', and I use it
all the time, to comment and uncomment a block of code.

RE: Trying to right-align my window on startup

[Mickey Ferguson]

>> I can't figure out how or where to place it so that it executes _and 
>> works properly.  I put it my MF-Init.el file that is loaded upon 
>> startup.

>Replace that file with one that does _only_ what you are testing.
>Adding something untested to a giant sack of eels is not the way to test that something.  (No, I cannot know >that MF-Init.el is a sack of eels.  Just a hunch.)

Yes, it is a sack of eels.  :-)  It's been building up for at least 20 years... most of which I added stuff based on recommendations from others, not really knowing fully what I was doing.  When it comes to elisp, I'm not usually even competent enough to be dangerous.
 
>According to your code, that could happen if the `selected-frame'
>is not what you think it is.  Try adding a `message' call that tells
>you what the selected frame is, and its displayed buffer etc.
>IOW, find out what is going on.

I'm afraid I don't even know how to do this, or even what it means to differentiate between frames.  But I have made some progress, using your isolation approach.

Here is a very pared down file I'm calling minimal.el.  I've narrowed it all down to the call to set-frame-font within big-font-mode.  As it appears below, emacs starts up and is properly right-aligned.  If I uncomment out the call to big-font-mode, which ultimately is just a call to set-frame-font, it gives the message that it ran align-window-right, but it starts up about an inch from the right edge.  (Don't ask me where I got that string for the font to use, because I don't remember.  But it does give me the best looking font [to me] for my needs.  If there is a better way to specify it that will give me the font I want, but not run into the problem I'm encountering, I'm all ears.)

===============================================================================
(defun align-window ()
  "fix window positioning"
  (interactive)
  (if (equal (getenv "emacs_alignment") "right")
      (align-window-right)
    (align-window-left))
  )

(defun align-window-left ()
  "align window to left window edge"
  (interactive)
  (set-frame-position (selected-frame) 0 0)
  (message "Ran align-window-left")
  )

(defun align-window-right ()
  "align window to right window edge"
  (interactive)
  (set-frame-position (selected-frame) -1 0)
  (message "Ran align-window-right")
  )

(defun big-font-mode ()
  "Use larger font"
  (interactive)
  (set-frame-font
   "-outline-Consolas-bold-r-normal-normal-12-90-96-96-c-*-iso10646-1"
   )
  )

 (cond
 ((eq window-system 'w32)
  (progn
;;    (big-font-mode)
    (align-window)
    )))

===============================================================================

RE: Trying to right-align my window on startup

[Drew Adams]

> Here is a very pared down file I'm calling minimal.el.

OK. Putting paring that down further, it should be enough to put
just this in your init file:

(set-frame-font
   "-outline-Consolas-bold-r-normal-normal-12-90-96-96-c-*-iso10646-1")
(set-frame-position (selected-frame) -1 0)

What I see here (on MS Windows, like you) is that this does not
work with Emacs 23.4 or 24.3.  But it does work with recent Emacs 24
development snapshots (what will become Emacs 24.4).

However, if I add a non-nil KEEP-SIZE argument for `set-frame-font'
then it works in all three versions.  That is:

(set-frame-font
   "-outline-Consolas-bold-r-normal-normal-12-90-96-96-c-*-iso10646-1"
   t)     ; <==== ADD THIS SECOND ARGUMENT
(set-frame-position (selected-frame) -1 0)

Seems like a bug has been fixed in the development version, but
perhaps someone else has a different take on that or can suggest
a workaround for the case where KEEP-SIZE is nil.

Meanwhile, if you don't care about the size or number of lines
and columns (and it sounds like you do not - you just want to
set the font), then just add the `t' argument.

RE: Trying to right-align my window on startup

[Mickey Ferguson]

Thanks for all of the help.  Any idea when 24.4 for Windows might be coming out?  Just curious.  I saw something from around the end of December that said it's "any day now".

Re: Trying to right-align my window on startup

[Eli Zaretskii]

> From: Mickey Ferguson <Mickey.Ferguson@cassidiancommunications.com>
> Date: Mon, 13 Jan 2014 23:14:03 +0000
> Accept-Language: en-US
> 
> Any idea when 24.4 for Windows might be coming out?  Just curious.

"Some time this year".  The pretest will begin in a couple of weeks.

RE: Trying to right-align my window on startup

[Drew Adams]

> That's why I said that the numbers will have to be computed, and
> that computation will need to take the screen dimensions into
> account.

Wrong.  Specifying the right edge of the frame relative to the
right screen edge is trivial, and requires no knowledge (by you)
of the screen dimensions.

A negative value for frame parameter `left' does just that.
No computation needed, for that at least.

> Where's the contradiction? what am I missing?

See above.

RE: Trying to right-align my window on startup

[Drew Adams]

> > > ?  (add-to-list 'default-frame-alist '(top . 0))
> > > >  (add-to-list 'default-frame-alist '(left . 140))
> > > >  (add-to-list 'initial-frame-alist '(height . 52))
> > > >  (add-to-list 'default-frame-alist '(height . 50))
> >
> > Sheesh.  Just use `M-x customize-option default-frame-alist'.
> 
> Sheesh, why do you care how I set up my Emacs?

Was that from your ~/.emacs, Eli?  No, in that case, I don't care.
I thought it was from someone who might not know better. ;-)

My advice, in general, is that Customize is one's friend - it helps.
Yes, that is a simplistic, general statement.  No, Customize is not
for everything.

But (IMHO) too many people ignore Customize, often because they've
gotten the impression somehow that it is for non-Lispers or wimps.
Quite the contrary, IMO.

When you can use Customize easily to get the job done, do so.
That's my advice.  When it cannot do the job, don't use it.

Re: Trying to right-align my window on startup

[Juanma Barranquero]

On Thu, Jan 9, 2014 at 10:02 PM, Drew Adams <drew.adams@oracle.com> wrote:

> But (IMHO) too many people ignore Customize, often because they've
> gotten the impression somehow that it is for non-Lispers or wimps.

I just hate its UI.

    J

poor Customize [was: Trying to right-align my window on startup]

[Drew Adams]

> > But (IMHO) too many people ignore Customize, often because
> > they've gotten the impression somehow that it is for
> > non-Lispers or wimps.
> 
> I just hate its UI.

Right.  I think no one is crazy about it.

Another thing that is unfortunate, especially because it is
related (discourages improvement attempts) is the nearly
impenetrable source code (try following it in the debugger!).

Another related thing here is the inability for users to get
reasonable help from the UI (e.g., try to find out what this
or that button/menu/whatever action actually does.

It is what it is.  Its strengths are not in the UI area.  But
its type-checking alone is worth using it, IMO.

I have even suggested that the same or similar type-checking
and other `defcustom' features be made available (for optional
use) to `defvar'.  Variables that are not user options can also
benefit from type checking, :set triggers, etc.

Re: poor Customize [was: Trying to right-align my window on startup]

[jack-mac]

Le samedi 11 janvier 2014 18:35:38 UTC+1, Drew Adams a écrit :
> 
> I have even suggested that the same or similar type-checking
> and other `defcustom' features be made available (for optional
> use) to `defvar'.  Variables that are not user options can also
> benefit from type checking, :set triggers, etc.

Could you please elaborate on ":set triggers"?

RE: poor Customize [was: Trying to right-align my window on startup]

[Drew Adams]

> > I have even suggested that the same or similar type-checking
> > and other `defcustom' features be made available (for optional
> > use) to `defvar'.  Variables that are not user options can also
> > benefit from type checking, :set triggers, etc.
> 
> Could you please elaborate on ":set triggers"?

See (elisp) `Variable Definitions'.

:set in `defcustom' specifies a function that is used to change the
option value.  It can take care of anything that needs to be done
when the value gets set.  By default (e.g., if unspecified), it
does only what `set-default' does: it sets the default value.

I used the word "trigger" loosely, to suggest that, via :set,
arbitrary code can be executed whenever the option value is set.

There are other, similar `defcustom' keywords.  In particular,
:initialize.

Re: Trying to right-align my window on startup

[Rusi]

On Saturday, January 11, 2014 8:15:05 PM UTC+5:30, Juanma Barranquero wrote:
> On Thu, Jan 9, 2014 at 10:02 PM, Drew Adams wrote:
> 
> > But (IMHO) too many people ignore Customize, often because they've
> > gotten the impression somehow that it is for non-Lispers or wimps.
> 
> 
> I just hate its UI.

If a first year student of mine cannot distinguish data and code (s)he'd get an F grade. customize does that.  Proof of that is that it throws random crud at my init file when I am not looking.  Mostly I get away by keeping the custom file as its very exclusive garbage dump.  But with all my care it still occasionally stomps my (ie my init's) toes.

So no customize is not written for wimps, its written by wimps

Of course if Drew is saying that customize is good for *exploring* options, I agree.

In defense of Customize [was: Trying to right-align my window on startup]

[Drew Adams]

> > > But (IMHO) too many people ignore Customize, often because
> > > they've gotten the impression somehow that it is for non-Lispers
> > > or wimps.
> >
> > I just hate its UI.
> 
> If a first year student of mine cannot distinguish data and code
> (s)he'd get an F grade.  customize does that.

No, it is Emacs that does that, by not requiring (or even
encouraging) the use of `custom-file', and by telling Customize to
put code in your init file by default.  That is a not-so-wise design
decision about how Emacs uses Customize.  It is not the fault of
Customize if Emacs tells it to write to your init file.

> Proof of that is that it throws random crud at my init file when
> I am not looking.

If you can find a recipe where it throws random crud at your init
file, when you are looking or not, then you will help Emacs and its
users by reporting that as a bug: `M-x report-emacs-bug'.

FWIW, I have never seen Customize "throw random crud".  And you
should avoid letting *any* generated code near your init file.  In
the case of Customize, just use `custom-file'.  Problem solved.  And
there would be no problem in the first place if you were required to
have a separate `custom-file' to use Customize.

Emacs does not by default store your bookmarks, or your elpa info,
or your thumbnail files, or your eshell info, or or any other
generated Lisp code in your init file.  Why does it still store
Customize-generated code in your init file by default?  Ask Emacs Dev.
To me, this is unwise design.

But it is certainly not Customize's fault.  If Emacs Dev decided to
store your bookmarks in your init file, you would get the same kind
of mess that you can get from Emacs mixing Customize code in with
your hand-coded init-file stuff.  It should be a no-brainer to
separate generated or automatically maintained code from user,
hand-written code.  (But whaddo I know?)

And wrt your code/data characterization: all such code is data to
the Lisp interpreter, whether you wrote it or a program wrote it,
and whether that program is Customize or the Elisp byte-compiler.

> Mostly I get away by keeping the custom file as its very exclusive
> garbage dump.  But with all my care it still occasionally stomps
> my (ie my init's) toes.

Again, report a bug.  I have never seen that.  If your `custom-file'
value points to an accessible, writable file, then I don't know of
any scenario where Emacs would write Customize stuff to your init file.

In sum, instead of vague trash-talk, please submit a bug report,
specifying just what you think happened to you.  The devil (and
understanding) is in the details.  Chicken-Little talk to scare
people away does not really help anyone.

> So no customize is not written for wimps, its written by wimps

I hardly think that Per Abrahamsen is a wimp, wrt Lisp or Emacs,
at least.  http://www.emacswiki.org/PerAbrahamsen

Of course, everything is relative - perhaps you are even less of
a programming wimp than Per, so you can judge him from on high.
That's certainly not my case.

The Customize code, and the `widget' code generally, is not easy
to read, IMO - that's a fair criticism.  And that is a big problem
in terms of improving Customize (e.g., the UI).  It is likely one
reason that the UI has been left behind to some extent.

> Of course if Drew is saying that customize is good for
> *exploring* options, I agree.

No, Customize is actually *not* so good for exploring faces and
options, IMHO.

It is good for ensuring that you change options and faces correctly,
e.g. type-correctly and wrt setting and initialization triggers
that should be applied.  It can also help to some extent wrt
choosing values (e.g. completion), even beyond ensuring their proper
types.

To tell you the truth, I never thought I'd be an apologist for
Customize.  I too used to avoid it and use only hand-coded Lisp
for all of my customizations.  And I too am no big fan of the UI
(and I have proposed and implemented some UI enhancements).  I have
probably criticized it (in concrete terms, including bug reports)
as much as anyone.

But I think that lots of people are, out of ignorance of what
Customize really is and can do, throwing the baby out with the
bathwater. You do not need to love the Customize UI to make good
use of Customize.

One place to start is to (really) learn `defcustom', in particular
:type.  IMO, too much Elisp code that uses `defcustom' does not
make good use of :type - meaning pretty much lazy and
less-than-useful typing.  (And that has included, and probably
still includes, some code that is distributed with Emacs.)

The more complex the structure of a variable's value, the more
Customize can help, regardless of whether you use its UI.

session.* files (was: In defense of Customize)

[gottlieb]

On Tue, Jan 14 2014, Drew Adams wrote:

> No, it is Emacs that does that, by not requiring (or even
> encouraging) the use of `custom-file', and by telling Customize to
> put code in your init file by default.  That is a not-so-wise design
> decision about how Emacs uses Customize.  It is not the fault of
> Customize if Emacs tells it to write to your init file.

Thank you Drew for this advice.  I looked into custom-file and now my
.emacs.d/init.el is not changed by emacs and is considerably smaller.

I then tried to clean-up .emacs.d by having all the zero-length
session.* files put somewhere else.  I looked for session in the manual
but all I found was references to desktop-save-mode, which I am not
using.  How can I have all the session.* files written to a different
directory, say ~/.emacs.d/session-files

> I hardly think that Per Abrahamsen is a wimp, wrt Lisp or Emacs,
> at least.  http://www.emacswiki.org/PerAbrahamsen

+1

thanks in advance,
allan

Re: session.* files (was: In defense of Customize)

[Peter Dyballa]

Am 14.01.2014 um 20:32 schrieb gottlieb@nyu.edu:

> How can I have all the session.* files written to a different
> directory, say ~/.emacs.d/session-files

      (require 'session)
      (add-hook 'after-init-hook 'session-initialize)
        (setq session-save-file-coding-system 'utf-8-unix))
      (setq session-save-file (format "%s/Psession-%s" desktop-dirname window-system))

I put my versions into ~/.emacs.d/Sicherungen:

(setq make-backup-files		t ;backup my files
      backup-by-copying		t ;don't clobber symlinks
      delete-old-versions	t
      kept-new-versions		6
      kept-old-versions		2
      version-control		t ;use versioned backups
      vc-make-backup-files	t ;make backups for cvs projects
      vc-follow-symlinks	t)
(setq backup-directory-alist `(("." ,@(concat user-emacs-directory "Sicherungen"))))


--
Greetings

  Pete

If you're not confused, you're not paying attention.

Re: In defense of Customize [was: Trying to right-align my window on startup]

[Phillip Lord]

Drew Adams <drew.adams@oracle.com> writes:

>> > > But (IMHO) too many people ignore Customize, often because
>> > > they've gotten the impression somehow that it is for non-Lispers
>> > > or wimps.
>> >
>> > I just hate its UI.
>> 
>> If a first year student of mine cannot distinguish data and code
>> (s)he'd get an F grade.  customize does that.
>
> No, it is Emacs that does that, by not requiring (or even
> encouraging) the use of `custom-file', and by telling Customize to
> put code in your init file by default.  That is a not-so-wise design
> decision about how Emacs uses Customize.  It is not the fault of
> Customize if Emacs tells it to write to your init file.

I also found this problematic. Nowadays I don't really have a .emacs per
se; all it does is add ~/emacs to the load-path, and then loads a file
from there.

There used to be another bug with this -- if you launched with -q
customize would refuse to save state even if you had set custom file
elsewhere. That appears to have gone now.

>
> To tell you the truth, I never thought I'd be an apologist for
> Customize.  I too used to avoid it and use only hand-coded Lisp
> for all of my customizations.  And I too am no big fan of the UI
> (and I have proposed and implemented some UI enhancements).  I have
> probably criticized it (in concrete terms, including bug reports)
> as much as anyone.

I use customize for things configuration that I don't want to sync
between machines, and hand-crafted lisp for everything else. But even
here customize is good, because the structure of the defcustom form
tells you as much as the documentation about how to set things.

I would like to have a "custom-setq" which set a var, checked to see
whether the types were correct wrt customize, then crashed if not. It
would be nice to use the knowledge of customize from lisp.

Phil

RE: In defense of Customize [was: Trying to right-align my window on startup]

[Drew Adams]

> I would like to have a "custom-setq" which set a var, checked to see
> whether the types were correct wrt customize, then crashed if not. It
> would be nice to use the knowledge of customize from lisp.

See commands `customize-set-variable' and `customize-set-value'.

(IMHO, `set-variable', which is also for setting a user variable,
should behave similarly, but it does not.)

Re: In defense of Customize [was: Trying to right-align my window on startup]

[Phillip Lord]

Drew Adams <drew.adams@oracle.com> writes:

>> I would like to have a "custom-setq" which set a var, checked to see
>> whether the types were correct wrt customize, then crashed if not. It
>> would be nice to use the knowledge of customize from lisp.
>
> See commands `customize-set-variable' and `customize-set-value'.
>
> (IMHO, `set-variable', which is also for setting a user variable,
> should behave similarly, but it does not.)
>

These don't do quite what I want. As a random example, consider this:


(defcustom pulse-flag (pulse-available-p)
  "Whether to use pulsing for momentary highlighting.
Pulsing involves a bright highlight that slowly shifts to the
background color.

If the value is nil, highlight with an unchanging color until a
key is pressed.
If the value is `never', do no coloring at all.
Any other value means to do the default pulsing behavior.

If `pulse-flag' is non-nil, but `pulse-available-p' is nil, then
this flag is ignored."
  :group 'pulse
  :type 'boolean)


Now, this is type boolean. So we can do this..


(customize-set-value 'pulse-flag nil)

and all is good. We can also do this...

(customize-set-value 'pulse-flag "wrong")

Now we have pulse-flag set to an illegal value. Of course, in this case,
it won't matter because "wrong" will be interpreted as t. But it means I
can set the variable to something which the GUI will not. I want this to
throw an error.

In this case, the ability to set an "illegal" value is actually useful,
because the :type is wrong, as legal values are t, nil or 'never
(according to the documentation) not just 'boolean. Why has this never
been discovered? I would suggest two possibilities: a) the developers
have never, ever set 'pulse-flag or b) they just used setq in their
.emacs. If the latter is true, having a way of only setting legal values
according to customize would have been helpful, because this would have
crashed, and they would have fixed it.

Phil

RE: In defense of Customize [was: Trying to right-align my window on startup]

[Drew Adams]

> >> I would like to have a "custom-setq" which set a var, checked to see
> >> whether the types were correct wrt customize, then crashed if not. It
> >> would be nice to use the knowledge of customize from lisp.
> >
> > See commands `customize-set-variable' and `customize-set-value'.
> 
> These don't do quite what I want.

See below - you might change your mind about that.

> As a random example,

It would be better to choose an example from the distributed vanilla
Emacs code.  Emacs Dev is more likely (but far from guaranteed) to
use :type wisely and write accurate doc strings than is a random
3rd-party library developer.

> consider this:
> (defcustom pulse-flag (pulse-available-p)
>   "...
> If the value is nil, ...
> If the value is `never', ...
> Any other value means ...."
>   :group 'pulse :type 'boolean)

OK, the doc does not match the :type spec.  So let's see what
the story is.

There are a couple of possibilities.

1. It could be that the intention was that the value really must
be as the doc describes it, and any other value should raise an
error. In which case, code that uses the option can and even
perhaps should depend on that.  In that case, the :type is
incorrect.

Perhaps the programmer was lazy wrt specifying :type.  See my
earlier post about that - users of defcustom should get to know
:type and do their best to use it to advantage.

2. It could be that the :type spec is correct and the doc string
is inaccurate.  Seems unlikely in this case, but could be checked
by looking at how it is used in the library that defines it.
It is checked only by `eq'uality with symbol `never' and with nil.

One might conclude that the programmer in this case was lazy or
ignorant wrt :type, or just didn't care.  It's also possible,
however, that this was the intention: a disconnect between the
actual possible values and the values users can set using
Customize.  A programmer *can* intend such a disconnect (though
in that case it might be appropriate to document that, either
in the program doc or code comments).

The code itself never sets a value of `never', so it seems
unlikely that this is intended as an internal value (especially
since it is advertised in the doc string).  Rather, it is likely
intended as a value that users can use.

Is it intentional that users *cannot* set the value to `never'
using Customize?  Dunno.

My guess in this case would be that this is yet another case of
a programmer being lazy or not sufficiently :type-savvy.  That
is all too common - in part perhaps because some tend to give
Customize a back seat, thinking it is only for wimps.  (Akin to
a certain lack of respect for users, in my book.)

My guess is that what was meant was something like this:

:type '(choice
         (const :tag "Do not color"          never)
         (const :tag "Color without pulsing" nil)
         (sexp  :tag "Color with pulsing"    t))

That lets both `M-x customize-option' and `customize-set-variable'
DTRT.  They both let you choose one of the same three "values" -
the :tags, actually.  `customize-set-variable' lets you use
completion to do that.  If you choose `Color with pulsing' then
you are prompted for a sexp that will be the value.

But hey!  That's still not good enough.  No doubt the sexp here
should not be either `nil' or `never'.  To guard against that,
the :type should use `restricted-sexp' with an appropriate
predicate, instead of just `sexp'.  You can see that things can
get complicated if the logic and use of an optin is complicated.

Whether that kind of treatment is really needed here, or whether
the last `choice' possibility could (and should) be just
(const :tag "Color with pulsing" t), would depend on what the
intention is, and thus what the code does with it.

> In this case, the ability to set an "illegal" value is actually
> useful, because the :type is wrong, 

Yes.  (Or so it seems - something is wrong, at least.)

> as legal values are t, nil or 'never (according to the
> documentation) not just 'boolean.

Yes.

> Why has this never been discovered? I would suggest two
> possibilities: a) the developers have never, ever set
> 'pulse-flag or b) they just used setq in their .emacs.

See above.  Even if they use only setq, the code and doc do
not match.  The likely answer in this case (based on a quick
check of how the variable is used) is that the developers were
either lazy wrt :type or ignorant wrt :type or did not really
care.

> If the latter is true, having a way of only setting legal
> values according to customize would have been helpful,
> because this would have crashed, and they would have fixed it.

See above.

Re: Trying to right-align my window on startup

[Emanuel Berg]

Rusi <rustompmody@gmail.com> writes:

>> I just hate its UI.
>
> If a first year student of mine cannot distinguish
> data and code (s)he'd get an F grade. customize does
> that.  Proof of that is that it throws random crud at
> my init file when I am not looking.  Mostly I get
> away by keeping the custom file as its very exclusive
> garbage dump.  But with all my care it still
> occasionally stomps my (ie my init's) toes.
>
> So no customize is not written for wimps, its written
> by wimps

Of course Customize is not "cool", and Lisp is, but
that's not the most important reason why I dislike
it. It is just so unpleasant to navigate those screens
and get an overflow of information and text, back and
forth. A couple of screens later, you have forgotten
what it was you were to customize, and even more, why
you set out to do that in the first place!

Compare that to just adding a single `setq' line in
.emacs... The English garden is only pleasant for
recreation. For work, we need French gardens, or even
better, a Japanese rock garden.

And, at one point or another, you want to write "real"
Elisp anyway (as in functions, not just settings), and
at that point, the "setq Lisp" in .emacs is a baby-step
as good as any.

At the other end of the spectrum, to just write Elisp
all day long to be more "productive", until you are so
productive, and your swords that sharp, that if you
ever were to *use* them, you would single-handedly push
back the Orc horde of Mordor! That's just an OCB trap
you should be aware of.

-- 
underground experts united:
http://user.it.uu.se/~embe8573

Re: Trying to right-align my window on startup

[Marcin Borkowski]

Dnia 2014-01-14, o godz. 01:24:34
Rusi <rustompmody@gmail.com> napisał(a):

> On Saturday, January 11, 2014 8:15:05 PM UTC+5:30, Juanma Barranquero
> wrote:
> > On Thu, Jan 9, 2014 at 10:02 PM, Drew Adams wrote:
> > 
> > > But (IMHO) too many people ignore Customize, often because they've
> > > gotten the impression somehow that it is for non-Lispers or wimps.
> > 
> > 
> > I just hate its UI.
> 
> If a first year student of mine cannot distinguish data and code
> (s)he'd get an F grade. customize does that.

How lucky that John McCarthy was not your student...

No offence, just could not resist a (maybe lame) joke.  I agree that the
distinction may be important.  My logic professor used to say: "What
does it mean that a mathematician *identifies* two things?  It means,
first of all, that he *distinguishes* them."  Maybe it's similar here.

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University

Re: Trying to right-align my window on startup

[Rusi]

On Tuesday, January 14, 2014 11:27:06 PM UTC+5:30, Marcin Borkowski wrote:
> Dnia 2014-01-14, o godz. 01:24:34
> Rusi  napisał(a):

> > On Saturday, January 11, 2014 8:15:05 PM UTC+5:30, Juanma Barranquero
> > wrote:
> > > On Thu, Jan 9, 2014 at 10:02 PM, Drew Adams wrote:
> > > > But (IMHO) too many people ignore Customize, often because they've
> > > > gotten the impression somehow that it is for non-Lispers or wimps.
> > > I just hate its UI.
> > If a first year student of mine cannot distinguish data and code
> > (s)he'd get an F grade. customize does that.

> How lucky that John McCarthy was not your student...

> No offence, just could not resist a (maybe lame) joke.  I agree that the
> distinction may be important.  My logic professor used to say: "What
> does it mean that a mathematician *identifies* two things?  It means,
> first of all, that he *distinguishes* them."  Maybe it's similar here.

He He! Yes that is so.
Some of the most notable things in CS come from such 'mixups'
- data = code in von Neumann machines
- Universal TM swallowing TMS as data
- gödels theorem
 More on my blog here
http://blog.languager.org/2012/05/recursion-pervasive-in-cs.html

But there should be some point to the mixup.

I see things like the foll in my custom-file
(custom-set-variables
  ;; custom-set-variables was added by Custom.
  ;; If you edit it by hand, you could mess it up, so be careful.
  ;; Your init file should contain only one such instance.
  ;; If there is more than one, they won't work right.

;; And I call the above crud

 '(browse-url-browser-function (quote browse-url-firefox))
 '(calendar-week-start-day 1)
  etc etc
)

If instead it contained an sexp but not valid elisp eg
((browse-url-browser-function (quote browse-url-firefox))
 (calendar-week-start-day 1))

there would be no such issue because then what could be in custom-file could not possibly be in an elisp file and vice-versa

Re: Trying to right-align my window on startup

[Emanuel Berg]

Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:

>> If a first year student of mine cannot distinguish
>> data and code (s)he'd get an F grade. customize does
>> that.
>
> How lucky that John McCarthy was not your student...
>
> No offence, just could not resist a (maybe lame)
> joke.  I agree that the distinction may be important.
> My logic professor used to say: "What does it mean
> that a mathematician *identifies* two things?  It
> means, first of all, that he *distinguishes* them."
> Maybe it's similar here.

I don't think it is so much a matter of principle or
even attitude. It is just what happens. I have not seen
that particular example first hand but it makes sense -
though I'm perhaps surprised at the impact of Emacs on
today's students :) Serious, put it this way: if one
wants to be a programmer, easy: *act* like a
programmer, and then just add *volume* (time). Lot's of
guys underestimate this. Mounting an USB-mp3-player,
using avconv to extract the sound from a YouTube video
(which you downloaded with youtube-dl), then splitting
the file with mp3splt, copying the files, and
unmounting the device - they don't want to do that,
because it is "trivial", "too easy", they don't have
the "time", so why don't use their iPods instead?
Right? *Wrong*!

-- 
underground experts united:
http://user.it.uu.se/~embe8573

Re: Trying to right-align my window on startup

[Rusi]

On Tuesday, January 14, 2014 11:27:06 PM UTC+5:30, Marcin Borkowski wrote:
> Dnia 2014-01-14, o godz. 01:24:34
> Rusi  napisał(a):

> > On Saturday, January 11, 2014 8:15:05 PM UTC+5:30, Juanma Barranquero
> > wrote:
> > > On Thu, Jan 9, 2014 at 10:02 PM, Drew Adams wrote:
> > > > But (IMHO) too many people ignore Customize, often because they've
> > > > gotten the impression somehow that it is for non-Lispers or wimps.
> > > I just hate its UI.
> > If a first year student of mine cannot distinguish data and code
> > (s)he'd get an F grade. customize does that.

> How lucky that John McCarthy was not your student...

> No offence, just could not resist a (maybe lame) joke.

Strangely a student of mine sent me this today morning -- something
I had written in an email perhaps a decade ago...
--------------------------------------

In the beginning there was the List
And the List was Program
And Program was Data
And McCarthy saw this, that it was good and called it Lisp

And then men saw this One World (footnote no women then) and decided that
"data is objects" whereas "programs are almost like us"
And they became afraid
And they decided to build a tower of the kind that had never been built
before -- a tower of types.

Re: In defense of Customize [was: Trying to right-align my window on startup]

[Rusi]

On Tuesday, January 14, 2014 11:07:34 PM UTC+5:30, Drew Adams wrote:

> Emacs does not by default store your bookmarks, or your elpa info,
> or your thumbnail files, or your eshell info, or or any other
> generated Lisp code in your init file.  Why does it still store
> Customize-generated code in your init file by default?  Ask Emacs Dev.
> To me, this is unwise design.

> But it is certainly not Customize's fault.  If Emacs Dev decided to
> store your bookmarks in your init file, you would get the same kind
> of mess that you can get from Emacs mixing Customize code in with
> your hand-coded init-file stuff.  It should be a no-brainer to
> separate generated or automatically maintained code from user,
> hand-written code.  (But whaddo I know?)

I did not know what to make of the above -- so did not comment

However my recent struggles to just set a variable in emacs (nothing
to do directly with customize) suggests that some basic emacs
infrastructure is really clunky

See the thread
Impossible to set org mode variable

In summary:
There is a variable v which shows value x as defined in file f
Look in the file f and it has value y

[Of course I am the first to admit that arcana about loaddefs, lexical vs dynamic and what not are above my head]

Re: In defense of Customize [was: Trying to right-align my window on startup]

[Emanuel Berg]

Rusi <rustompmody@gmail.com> writes:

> lexical vs dynamic and what not are above my head

In general, it is not difficult, though perhaps you
meant at a higher level.

dynamic: whenever something is mentioned, that is
looked up (so what it is depends on *when* it is looked
up, that is the "dynamic"/time part)

lexical: everything is encoded at some point, and what
you change after that, even if that influenced during
encoding, does not affect what has been encoded -
lexical, as in a heap of text

This sounds like a big deal but you never notice this
distinction. At least I don't.

-- 
underground experts united:
http://user.it.uu.se/~embe8573

Re: In defense of Customize [was: Trying to right-align my window on startup]

[Rusi]

On Saturday, January 18, 2014 10:12:26 AM UTC+5:30, Emanuel Berg wrote:
> Rusi writes:

> > lexical vs dynamic and what not are above my head

> In general, it is not difficult, though perhaps you
> meant at a higher level.

> dynamic: whenever something is mentioned, that is
> looked up (so what it is depends on *when* it is looked
> up, that is the "dynamic"/time part)

> lexical: everything is encoded at some point, and what
> you change after that, even if that influenced during
> encoding, does not affect what has been encoded -
> lexical, as in a heap of text

> This sounds like a big deal but you never notice this
> distinction. At least I don't.

Yeah I know the theory
However if you see the parallel thread "Impossible to set org mode variable"
it is almost analogous to this scenario:

You have C code like this:

int x;
x = 3;
printf("%d\n" x);

and instead of seeing 3 you see 42!!

Now how much this is due to 
- dynamic vs static
- unexpected autoload cookie sequencing
- recent library churn

Ive not been able to figure out

Re: In defense of Customize [was: Trying to right-align my window on startup]

[Christoph Wedler]

Drew Adams <drew.adams@oracle.com> writes:
[...sequence of citation does not match sequence in cited article...]

> I hardly think that Per Abrahamsen is a wimp, wrt Lisp or Emacs,
> at least.  http://www.emacswiki.org/PerAbrahamsen

Just to put the rest of this posting into context: neither do I.
Everybody who has written LaTeX documents knows that Per has done an
excellent job with AucTeX - just one example...

>> > > But (IMHO) too many people ignore Customize, often because
>> > > they've gotten the impression somehow that it is for non-Lispers
>> > > or wimps.
>> >
>> > I just hate its UI.

I do not hate Customize, but I think that Customize does not solve the
main problems many users had and have with customizing Emacs.  The UI is
just a minor point.

So which were the issues most users had with customizing Emacs before
the advent of custom.el:

 1. Exploring customization options.

    There were too many customization option to grasp (I'm not against
    having many options!), and one could not easily grasp the
    interdependence between different options.

 2. Doing the customization.

    Users had no problems using a `setq' in combination with an boolean,
    integer, string value, or a enum-like use of symbols, or a simple
    list consisting of these types.  `global-set-key' was also almost
    ok.

    They had (and have - that is the point!) a problem with having to
    define a function/form which contains the necessary customizations
    and having to add this to some hook, provide it to eval-after-load,
    or ...

 3. Re-using customization (parts) of other Emacs users (or own on other
    machine)

    Many users re-used parts of the ~/.emacs files of others.  The
    problem was that these settings were a mixture of personal setting
    (e.g. user-full-name), local / system-dependent settings
    (grep-find-command), questions of taste (face colors), etc and
    tended to grow old.


Which issues does custom.el solve?

 1. Number of options: well, nothing has changed. People are still
    overwhelmed by the sheer number of options.  People are also puzzled
    if changing some option does not have any effect, because it depends
    on other options to be set to a specific value...

    Yes, custom helps a bit with exploring these options, but actually
    mainly on the intra-package level (which Lispers could do for
    themselves by looking at the defvar in the el file).

    If I'm interested in the possibilities for auto-completing some
    symbol/word, I still have to know them: abbrev-mode, dabbrev-expand,
    complete-tag (but no corresponding imenu-...), and in a wider sense:
    ido, ...   To be fair: this is diffucult.

 2. Positive: face customizations became easier.

    Otherwise: nothing has changed much.  Yes, there is some type
    checking on the values now.  But to be honest, I do not see the
    point that people do not have to use Lisp to set the value of some
    option to some Lisp function or even sexpr.

    Setting some values in specific mode (or mode groups) is not
    possible.  Defining key and menu bindings: nothing, let alone for
    something like the mode-line, ...

 3. Positive: custom-themes could be a step in the right direction

    Negative: sharing customization settings is now actually more
    difficult, because auto-generated custom files lack comments which
    explain why default values have been changed, and because they are
    ordered alphabetically and not topic-wise. Settings which work on
    different machines are harder to do.

In short: custom.el made things a bit easier which were easy before and
does little to help with the others (and unfortunately these two are not
synonyms for "many users want to change it" and "should be left to
advanced users")

 - `gc-cons-threshold' is customizable (which non-Lisper should change
   that?), but
 - defining a keybinding for C programming requires to define a function
   which has to be added to some hook...


So instead of spending time on some UI, things would IMHO improve by the
following (doing the UI later)

 - Define top-level forms for customizations which many people want to
   do - something like

      (cus-set 'indent-tabs-mode t)
      (cus-set 'indent-tabs-mode nil :mode prog-mode)
      (cus-define-key "some binding" command :mode c-mode)

   Currently, many (mostly minor-mode) packages define their own way of
   offering something like that (see
   e.g. font-lock-maximum-decoration).  Otherwise, people have to add
   some function to some hook.

 - To handle issue 1: make less options customizable: make package
   authors define 5 good customization options, do not propose to make
   their 30 variables (user options) customizable.  These customization
   option just contain "easy" values: integer, string value, or a
   enum-like use of symbols, or a simple list consisting of these types.

   Most of these options could actually influence the values of some
   variables - something like custom-sub-themes (defined in the package)
   or something like c-style.  Advanced users could easily define their
   own custom-sub-themes / styles - "custom" and stand Elisp co-exist
   nicely.

 Regards,
 Christoph

Re: In defense of Customize [was: Trying to right-align my window on startup]

[Emanuel Berg]

Christoph Wedler <christoph.wedler@sap.com> writes:

> Just to put the rest of this posting into context:
> neither do I.  Everybody who has written LaTeX
> documents knows that Per has done an excellent job
> with AucTeX - just one example...

Not "everybody who has written LaTeX documents" know
that (but I don't contradict you as for the quality of
AUCTeX). But of course, you know there is a plain LaTeX
mode (latex-mode), and AUCTeX must be installed
explicitly (except for XEmacs).

> I do not hate Customize

I hope so :)

> 1. Exploring customization options.
>
> There were too many customization option to grasp
> (I'm not against having many options!), and one could
> not easily grasp the interdependence between
> different options.

I don't think Customize is that good for that. It is
just too much. You get lost in the jungle. To explore
Emacs capabilities and options in general, I recommend
a good (physical) *book*. Why not "Learning GNU Emacs"
by O'Reilly? [The only blunder of that book is that
they don't mention either RMAIL or Gnus, because now
"there are more modern clients for that" (i.e., outside
the Emacs world - pseudo-quote, by the way) - which is
nonsense - it doesn't matter how "modern" anything is,
what matters is that you type emails, and you type in
Emacs, and you are active in Emacs, and you write
emails about what you do.]

> They had (and have - that is the point!) a problem
> with having to define a function/form which contains
> the necessary customizations and having to add this
> to some hook, provide it to eval-after-load, or ...

That can be a problem but I don't see how that is
easier with Customize. What should be done, rather, is
that those things should be "parameterized" so you
actually *can* get that with `setq' Lisp alone.

>  3. Re-using customization (parts) of other Emacs users
> (or own on other machine)

That will always be frustrating so I think the solution
to that problem is: don't do it. To have one computer
at work, one at home, and one gadget in between, and to
run Emacs on all, and expect everything to be the same
- why do that *at all*? Why not have the same computer
at work, as at home? Why have several computers at all?
Why not have *one* computer, which behaves the way you
want it to, and when you are not there, you do
different things? If you *must* use different computers
all over, and you have accepted that, why not accept
that they *are* different, and thus the UX as well?

> 3. Positive: custom-themes could be a step in the
> right direction

Themes can be a solution to get a quick start but
equally we should encourage people to be able to
*change* what they don't like. Just like as changing
something in Linux should never equal "install another
distribution", we should instill the notion that
everything can be changed, and that without any outside
interference.

-- 
underground experts united:
http://user.it.uu.se/~embe8573

Re: In defense of Customize [was: Trying to right-align my window on startup]

[Phillip Lord]

Emanuel Berg <embe8573@student.uu.se> writes:
>>  3. Re-using customization (parts) of other Emacs users
>> (or own on other machine)
>
> That will always be frustrating so I think the solution
> to that problem is: don't do it. To have one computer
> at work, one at home, and one gadget in between, and to
> run Emacs on all, and expect everything to be the same
> - why do that *at all*? Why not have the same computer
> at work, as at home? Why have several computers at all?
> Why not have *one* computer, which behaves the way you
> want it to, and when you are not there, you do
> different things? If you *must* use different computers
> all over, and you have accepted that, why not accept
> that they *are* different, and thus the UX as well?

Just because something works for you, does not mean that it would work
for everyone. You probably have different working practices, different
work, are a different age, and have a different mind and body from me.
Computers are personal (like opinions).

I have about 5 computers, for different circumstances.

I have: 

a desktop at work, with big screens, on a sit to stand desk that I have
for a bad back

an old laptop at work, that I use for writing notes at meetings

a cheap 14in laptop at home that I use most of the time there

a desktop at home that has largely been outdated, but which I will
probably put on some shelves so I have a stand up space at home also.

a netbook which I use when travelling because it fits between my stomach
and the plane/train seat in front.



I use unison and sync my file space. Ironically, customize works very
well in this environment. I use hand-written, sync'd lisp for things on
all machines; I do not sync my .emacs (which just contains customize
code and loads my hand-written stuff). So I use customize for things I
want different on different machines.

If some one say they have a problem, telling them to realise that they
don't have that problem at all is often not helpful.

Phil

Re: In defense of Customize [was: Trying to right-align my window on startup]

[Stefan Monnier]

> a desktop at work, with big screens, on a sit to stand desk that I have
> for a bad back
> an old laptop at work, that I use for writing notes at meetings
> a cheap 14in laptop at home that I use most of the time there
> a desktop at home that has largely been outdated, but which I will
> probably put on some shelves so I have a stand up space at home also.
> a netbook which I use when travelling because it fits between my stomach
> and the plane/train seat in front.

Sounds eerily similar to my situation (except that I use my home desktop
regularly, and that the two home laptops are Thinkpads rather than
cheap/netbook).

> I use unison and sync my file space.

I prefer using DVCS to sync up my files.  Started doing that when CVS
acquired its "remote access" functionality.


        Stefan

Re: In defense of Customize [was: Trying to right-align my window on startup]

[Phillip Lord]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> for a bad back
>> an old laptop at work, that I use for writing notes at meetings
>> a cheap 14in laptop at home that I use most of the time there
>> a desktop at home that has largely been outdated, but which I will
>> probably put on some shelves so I have a stand up space at home also.
>> a netbook which I use when travelling because it fits between my stomach
>> and the plane/train seat in front.
>
> Sounds eerily similar to my situation (except that I use my home desktop
> regularly, and that the two home laptops are Thinkpads rather than
> cheap/netbook).


I used to but expensive laptops, but CPUs have got fast enough, now,
that the cheap ones are enough. And the expensive ones have gone all
SSD and I've eaten my way through every hard drive I've ever bought; so
the cheap ones are actually better.


>> I use unison and sync my file space.
>
> I prefer using DVCS to sync up my files.  Started doing that when CVS
> acquired its "remote access" functionality.

I tried that, but I dislike the explicit commit -- I move between
machines based on the rest of my life, not based on computing need. I
actually many of my DVCS working repos between machines; I might start a
feature on one machine, continue on another, then commit on a third.
Surprisingly this works, as most DVCS seem not to care which physical
machine they are on.

Phil

Re: In defense of Customize [was: Trying to right-align my window on startup]

[Stefan Monnier]

> I used to but expensive laptops, but CPUs have got fast enough, now,

I don't care about CPU speed (my Desktops have netbook-class CPUs), only
about noise, keyboard (and pointing device) and screen's DPI.

>> I prefer using DVCS to sync up my files.  Started doing that when CVS
>> acquired its "remote access" functionality.
> I tried that, but I dislike the explicit commit

For sync purpose, I have a script which does "commit+merge".
It's really the same as unison, except I have a history of changes, and
better conflict resolution.  Commits don't have any logical meaning, nor
"commit log" message in that case.

> I actually [sync?] many of my DVCS working repos between machines;

For things where I use DVCS for non-sync purpose, I typically use
a separate "work-mess" branch which I sync via "commit+merge" as above
without caring about commit messages or commit granularity.  And when
the work is ready, I move it manually onto a real branch where I "commit
properly".


        Stefan

Re: In defense of Customize [was: Trying to right-align my window on startup]

[Phillip Lord]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> I prefer using DVCS to sync up my files.  Started doing that when CVS
>>> acquired its "remote access" functionality.
>> I tried that, but I dislike the explicit commit
>
> For sync purpose, I have a script which does "commit+merge".
> It's really the same as unison, except I have a history of changes, and
> better conflict resolution.  Commits don't have any logical meaning, nor
> "commit log" message in that case.

That's an interesting idea, and I hadn't thought of it. In general, I am
not too worried about conflict resolution, since my work practices are
aimed at not getting conflicts. So, for example, I unison my ~/Mail and
use nnml. A DVCS resolution is not going to help there because it is the
conflict is between files not inside the content of files.

One day I need to write a Gnus backend which doesn't use sequential file
numbers (perhaps a time stamp would work) -- these would then merge
cleanly automatically when read at both ends. I suspect "one day" is
never going to happen.

I also sync quite large binary files (music, photos and occasionally
isos). DVCS I think wouldn't not be ideal here, since you'd get a 2x
increase in size, and deletion wouldn't decrease that.

>> I actually [sync?] many of my DVCS working repos between machines;
>
> For things where I use DVCS for non-sync purpose, I typically use
> a separate "work-mess" branch which I sync via "commit+merge" as above
> without caring about commit messages or commit granularity.  And when
> the work is ready, I move it manually onto a real branch where I "commit
> properly".

Good idea also!

Phil

Re: In defense of Customize [was: Trying to right-align my window on startup]

[Emanuel Berg]

phillip.lord@newcastle.ac.uk (Phillip Lord) writes:

> Just because something works for you, does not mean
> that it would work for everyone. You probably have
> different working practices, different work, are a
> different age, and have a different mind and body
> from me.  Computers are personal (like opinions).
>
> I have about 5 computers, for different
> circumstances.

Of course, you may have as many computers as you like.

Two things:

First, it depends on the level of consistency you
want/need. I'm close to OCB when it comes to computers,
so for me to have many computers would just be OH times
OH.

You know if you use a multicore instead of a
uniprocessor, and then a microkernel instead of a
monolithic kernel, and then put virtualization and real
time upon than, and finally you program in C++... Each
time you chose the difficult path, difficulties are not
added, they are multiplied - they just sky rocket.

It would be the same for me with several computers. The
only way I could make that work is to consider them not
shafts of a hub, but all independent. And I don't want
that because then the benefits from all the time spent
mastering *one* computer would be gone, and I would be
aware of that, and that would be frustrating.

But more importantly, I don't believe in the "always
on" productivity way of thinking. Like in trains, I
don't believe in having a laptop, I believe in having a
book or mp3 player (with for example audio tracks from
"The Computer Chronicles"). In a cottage, I believe in
fishing and chopping wood, and if you feel like it, you
can apply your analytic skills acquired from computer
work to make it more efficient, like to make it blend
with your personality.

With the *hours* people spend using gadgets today -
after they play ice hockey, when they eat, in
libraries, even when drunk at bars - you would think
they, and not we, are the programmers.

Or, in the words of Dr. Jones, "To be a good
archaeologist, you need to get out of the library."

-- 
underground experts united:
http://user.it.uu.se/~embe8573

Re: In defense of Customize [was: Trying to right-align my window on startup]

[Phillip Lord]

Emanuel Berg <embe8573@student.uu.se> writes:

> phillip.lord@newcastle.ac.uk (Phillip Lord) writes:
> It would be the same for me with several computers. The
> only way I could make that work is to consider them not
> shafts of a hub, but all independent. And I don't want
> that because then the benefits from all the time spent
> mastering *one* computer would be gone, and I would be
> aware of that, and that would be frustrating.

A computers a chunk of metal and is rarely something I consider beyond
the key issue which is where it is.


> But more importantly, I don't believe in the "always
> on" productivity way of thinking. Like in trains, I
> don't believe in having a laptop

Again, depends on what you do with a laptop. If I am travelling for
work, then I can use the time to work, or else I can listen to music and
then ignore my family when I get home while I catch up with work.

Easy decision.

Phil

Re: In defense of Customize [was: Trying to right-align my window on startup]

[Emanuel Berg]

phillip.lord@newcastle.ac.uk (Phillip Lord) writes:

> Again, depends on what you do with a laptop. If I am
> travelling for work, then I can use the time to work,
> or else I can listen to music and then ignore my
> family when I get home while I catch up with work.

Yeah, I guess it depends on the hours to travel, the
means of transportation, etc.

I have been a lot on trains and busses and I have seen
a lot of people with laptops. But I didn't see as many
people doing real work, far from it. I get the
impression that 95% of those either do that because of
boredom, or because of nervous energy, or because they
actually think it will work, each time.

I think it is much more productive to read or to listen
to mp3 lectures and documentaries, and you don't need
to be "spot on" on either. You might be a better
programmer after reading a book on dinosaurs. But I
don't think anyone benefits from getting the computer
in place, then being stressed with power, the Internet,
then checking Facebook where nothing ever happens, then
from their seats to the bathroom like Houdini (nowhere
to put the laptop), change of bus/train, do it all over
again...

But if you are on a boat from Poland to Sweden, you
have more time and space, it is another ball game.

-- 
underground experts united:
http://user.it.uu.se/~embe8573

RE: In defense of Customize [was: Trying to right-align my window on startup]

[Drew Adams]

> > I hardly think that Per Abrahamsen is a wimp, wrt Lisp or Emacs,
> > at least.  http://www.emacswiki.org/PerAbrahamsen
> 
> Just to put the rest of this posting into context: neither do I.
> Everybody who has written LaTeX documents knows that Per has done
> an excellent job with AucTeX - just one example...
> 
> >> > > But (IMHO) too many people ignore Customize, often because
> >> > > they've gotten the impression somehow that it is for non-
> >> > > Lispers or wimps.
> >> >
> >> > I just hate its UI.
> 
> I do not hate Customize, but I think that Customize does not solve
> the main problems many users had and have with customizing Emacs.

It certainly does not solve all customization needs.  Nor does
anyone claim otherwise.

> The UI is just a minor point.  So which were the issues most users
> had with customizing Emacs before the advent of custom.el:
> 
>  1. Exploring customization options.
> 
>     There were too many customization option to grasp (I'm not
>     against having many options!), and one could not easily
>     grasp the interdependence between different options.
> 
>  2. Doing the customization.
> 
>     Users had no problems using a `setq' in combination with an
>     boolean, integer, string value, or a enum-like use of symbols,
>     or a simple list consisting of these types.  `global-set-key'
>     was also almost ok.
> 
>     They had (and have - that is the point!) a problem with having
>     to define a function/form which contains the necessary
>     customizations and having to add this to some hook, provide it
>     to eval-after-load, or ...
> 
>  3. Re-using customization (parts) of other Emacs users (or own on
>     other machine)
> 
>     Many users re-used parts of the ~/.emacs files of others.  The
>     problem was that these settings were a mixture of personal
>     setting (e.g. user-full-name), local / system-dependent settings
>     (grep-find-command), questions of taste (face colors), etc and
>     tended to grow old.
> 
> Which issues does custom.el solve?
> 
>  1. Number of options: well, nothing has changed. People are still
>     overwhelmed by the sheer number of options.

I would consider that mainly a Customize UI problem.  Customize
does not provide the greatest preferences browser.  But the
various `customize-apropos*' commands help.  I suspect that not
enough users take advantage of these commands, or are even aware
of them.

[FWIW,  in Icicle mode, Emacs commands that let you choose an
option become essentially Customize browsers.  Each command
invocation provides access to any number of options and information
about them. You can match options using multiple patterns, each of
which can be a substring or regexp.  And you can show the doc for
any options you choose, on the fly while matching.]

>     People are also puzzled if changing some option does not have
>     any effect, because it depends on other options to be set to
>     a specific value...

That's not that common a problem, IMO, but it can be a real
problem nonetheless.

At least the doc of an option that depends on other options should,
and usually does, call this out.  That's not a real solution, but
it helps.

>     Yes, custom helps a bit with exploring these options, but
>     actually mainly on the intra-package level (which Lispers
>     could do for themselves by looking at the defvar in the el
>     file).

I agree that Customize does not help a lot wrt exploring options
(browsing, discovering).  I don't understand, however, why you say
that its limited help is mainly for options in the same package.

>     If I'm interested in the possibilities for auto-completing
>     some symbol/word, I still have to know them: abbrev-mode,
>     dabbrev-expand, complete-tag (but no corresponding imenu-...),
>     and in a wider sense: ido, ...   To be fair: this is diffucult.

Not sure what you're saying here.  Are you just saying that it is
not always enough to be able to match option (or command) _names_?

That's certainly true, given that the names of some are not ideal,
and especially given that different users can think in terms of
different words about them (e.g., "abbrev", "expand", "complete").

In that regard, for vanilla Emacs I would mention `apropos-doc',
which matches doc strings.  Not a panacea, but worth knowing about.

[Icicles multi-command `icicle-vardoc' does a better job of
matching doc strings and/or names of variables.]

Besides matching option names and doc strings, exploring can
benefit from being able to match custom _types_.  Matching here
can mean several things.

[There are several Icicles multi-commands (browsers) that let you
do this, each letting you type-match in different ways.  Each lets
you match the option name at the same time as the type:
* `icicle-describe-option-of-type' (show doc)
* `icicle-customize-apropos-options-of-type' (customize)
* `icicle-apropos-options-of-type' (list)
See http://www.emacswiki.org/emacs/Icicles_-_A_Propos_d'Apropos.]

>  2. Positive: face customizations became easier.
>     Otherwise: nothing has changed much.  Yes, there is some type
>     checking on the values now.  But to be honest, I do not see the
>     point that people do not have to use Lisp to set the value of
>     some option to some Lisp function or even sexpr.

Some type-checking?  There is a _lot_ of type-checking.

Or rather, the type-checking done corresponds to the :type defined.
If the writer of the defcustom was lazy and did not write a :type
declaration that specifies a type that is sufficiently narrow, then
the type-checking will be correspondingly loose. That is the main
problem with many option definitions, IMO: lazy typing.

And that can be due insufficient familiarity with :type sexps.

And there is not only type-checking but also other handling wrt
initializing and updating values, e.g., handling of :initialize
and :set triggers.

Of the problems I see users asking about wrt setting option values,
the vast majority have to do with them using setq either to set the
value to something that conflicts with the type or without also
doing what :set or :initialize calls for.  IOW, they do not treat
the option wrt its possibly complex definition, and handle it as
if it were a simple defvar.  And that gets them into trouble.

The fault here is sometimes inadequate doc, that in effect leads
the user down the garden path to a mistake, by not making clear
what the restrictions are on the option value etc.  But the fault
is also too often, IMO, with users who want to feel "Lispian" by
using setq rather than using something as "non-programmer" as the
Customize UI.  "Look Ma, no hands!"

>     Setting some values in specific mode (or mode groups) is
>     not possible.

It is only possible to the extent that the application provides
for it.  You are right that there is nothing about this that is
part of the UI.  But a library can certainly create an option
that is only useful in certain contexts or is only usable in
certain ways.

>     Defining key and menu bindings: nothing, let alone
>     for something like the mode-line, ...

Menus, no.  Keys, yes.  There are plenty of options that let
users specify key bindings.  See :type keyword `key-sequence',
for a start.

[I use my own widget (keyword) for this, which lets you specify
a command and a key sequence to bind to it or another command to
remap to it (for the minor mode).
http://www.emacswiki.org/Icicles_-_Key_Bindings#IciclesCustomizingKeysScreenshot]

Not sure what you mean by "let alone for something like the
mode-line".  But I guess you mean that it is not simple to
customize the mode line.  Agreed, beyond some basics.

If your point is that customizing Emacs is in many ways not
covered by Customize then I doubt that you will find anyone who
disagrees.  Certainly the structure of menus, keymaps generally,
font-lock-keywords, `mode-line-format', and even face specs is
complex.  That is the case in _Lisp_, and Customize offers
little-to-nothing to help in this regard.

But it should.  And so should the Lisp handling of these things
be made easier.  That might be your argument; dunno.  It is mine.

>  3. Positive: custom-themes could be a step in the right direction

Yes and no.  The real "customization" in that case is done by
the person defining the theme.  Applying a theme is only
"customization" in the weakest sense.  It counts as such, but
saying that really misses the point.

What is really missing wrt Customize here is help for _defining_
themes.  In particular, incremental, direct-manipulation ways of
turning knobs to get the colors, fonts, etc. that you want here
and there, and then pushing a button to save what you created as
a theme.  And ways to compare themes, blend them (WYSIWYG), and
undo their effects, all components together, and sets of
components, and components individually.

FWIW, that is the kind of thing that Do Re Mi tries to offer.
But those kinds of things could usefully be used as _plug-ins_
for the Customize UI, extending it in more useful,
direct-manipulation ways.  If, that is, Customize provided for
such easy plugging-in...

Currently, choosing a color, say, with the Customize UI is
pretty primitive.  Here too there are better color-choosing UIs,
but they are all relegated to remaining essentially outside
Customize.

That's OK, since it is possible for such a library to let you
save a choice you make as a custom value (i.e., so it is
recognized by Customize).  But few do that, perhaps out of
ignorance of the custom*.el code.

What is true wrt defining themes is also true wrt using
`font-lock-keywords', at least in any context where those
keyword entries are multiple or complex.  What's needed is
one or more UIs (e.g., commands) for tweaking and immediately
visualizing the effects.  See this recent StackOverflow question
and answers for a start in this direction:
http://stackoverflow.com/questions/21125658/how-to-test-font-lock-keywords-values-for-emacs-lisp-code/

>     Negative: sharing customization settings is now actually more
>     difficult, because auto-generated custom files lack comments
>     which explain why default values have been changed, and because
>     they are ordered alphabetically and not topic-wise. Settings
>     which work on different machines are harder to do.

Yes.  But there is also value in automatic handling of such things,
especially when they are complex structures.

Such generated code should of course be kept out of user init
files.  All users who use Customize at all should define option
`custom-file', to prevent Customize from using their init file.
(That should be required by Emacs, for Customize to save anything.
Emacs not doing that is asking for trouble and not doing users any
favor, IMO.)

> In short: custom.el made things a bit easier which were easy
> before and does little to help with the others (and unfortunately
> these two are not synonyms for "many users want to change it" and
> "should be left to advanced users")

I think you are underestimating :type, in particular.  But there,
the responsibility is on the programmer who uses defcustom.  If
s?he uses it only like defvar, then yes, Customize - at best -
just makes things a bit easier that were already easy.  And maybe
not even a bit easier.  If a programmer uses defcustom as if it
were defvar then, sure, users of that library might as well use setq.

But if your argument is that the most complex structures in Emacs
Lisp: menus and other keymaps, `font-lock-keywords',
`mode-line-format', and the like are not usefully accessible to
users via the Customize UI, well, that's obvious - a no-brainer.

And I agree that it is not the case that wanting or needing to
tweak such things maps only to "advanced users".  And you are right
to point this out as one of the biggest Emacs impedance mismatches:
to do something that nearly everyone might want to do (if it were
easy), you are confronted immediately with a monstrous recursively
defined list structure (sometimes with shared structure) and
hard-to-fathom doc.

>  - `gc-cons-threshold' is customizable (which non-Lisper should
>    change that?), but

Any of them might - why not?  But what's the point?  That it is
too easy to do that without Customize?  That it is too advanced
or too hard for non-Lispers to do that?  I don't follow, here.

>  - defining a keybinding for C programming requires to define a
>    function which has to be added to some hook...

Why?  I don't program in C anymore, but isn't there a keymap for
C mode that you can define the key in?

If you want to define a key in Emacs Lisp mode, you just use
(define-key THE-KEY emacs-lisp-mode-map).  No defining a function.
No use of any hook.  (Although I have seen users jump through such
hoops even when it was not necessary.)

Yes, sometimes the mode map does not exist up front, so you might
need to do as you say.  But that's not such a big deal, is it?

> So instead of spending time on some UI, things would IMHO improve
> by the following (doing the UI later)

No one is spending time working on the Customize UI, AFAIK.
That's one reason it is still so rudimentary or "old-fashioned".
And as I said earlier, one reason that no one works on it is that
its code is hard to work with (including debugging).

>  - Define top-level forms for customizations which many people
>    want to do - something like
>       (cus-set 'indent-tabs-mode t)
>       (cus-set 'indent-tabs-mode nil :mode prog-mode)
>       (cus-define-key "some binding" command :mode c-mode)

Go for it.

To me, that would be precisely "ma[king] things a bit easier which
were easy before and do[ing] little to help with the others."

I don't see those things as difficult or as things that are hanging
users up or binding them in knots of confusion.  But maybe I'm
missing something.

>    Currently, many (mostly minor-mode) packages define their own
>    way of offering something like that (see e.g.
>    font-lock-maximum-decoration).  Otherwise, people have to add
>    some function to some hook.
> 
>  - To handle issue 1: make less options customizable: make package
>    authors define 5 good customization options, do not propose to
>    make their 30 variables (user options) customizable.  These
>    customization option just contain "easy" values: integer,
>    string value, or a enum-like use of symbols, or a simple list
>    consisting of these types.

Sorry, I don't see that as solving any real problem, unless you
feel that some package authors make what should be internal
variables into user optinos.  I haven't noticed that much, but
I'm sure it can happen.

If you are just making a plea for fewer user options, and think
that many of them should instead be internal variables (presumably
not just a few bad 3rd-party packages but even options delivered
with Emacs?) then I would disagree.

There are lots of options, true.  But I don't see that most of
them, or even many of them, should not be options.

I don't see the number of options as a problem.  One should not
multiply things unnecessarily (Occam), but that does not mean
that blindly limiting things is smarter.

A variable whose value really _must_ be an integer, and which
you want users to know that they are invited to change - as a
user preference, is better off as a user option than as an
internal variable (defvar).

I've seen enough naive users setq a variable whose value must
be a symbol to a string value instead, and vice versa.

What you say there sounds only like an argument against the
notion of user option.  I disgree with that, in any case.

Any user can tweak any Lisp variable - and that's a good thing.
But it can help users to let them know about some variables
that have been designed specifically to allow for user fine
tuning (customization).  Guiding users to user options helps
them.  Making every variable essentially the same - just
another global variable - does a disservice to users.

>    Most of these options could actually influence the values
>    of some variables - something like custom-sub-themes
>    (defined in the package) or something like c-style.

Too vague to usefully respond to.  But IIUC, nothing wrong
with doing that.

Saying that in some cases (do you really mean "most"?) you
can imagine a better, more hierarchical disposition of
user-tweakable knobs is in no way an indictment of Customize
or of user options.  It says nothing about either.  You are
essentially just going on about some people misusing these
things.

That is no different from my saying that some programmers
do not bother defining good :type specs when they create
defcustoms.

But my argument is in defense of the constructs they misuse:
the problem is not the constructs but the poor use of them.

Your argument seems to be that because some programmer
creates more options than needed, or does not organize a
program's customization as efficiently as you might expect,
the fault is with the existence of user options, Customize,
and `defcustom'.  Too facile.

Don't get me wrong.  I agree with some of what you say.

But I do not see either the notion of user option or the
control over variable values offered by `defcustom' as the
problem.  Nor do I see the existence of a Customize UI as
the problem.  (It needs to be improved, not abandoned.)
Nor do I see programmatic control over saving and restoring
user preferences as the problem.  (It needs to be kept out
of user init files, not abandoned.)

To come back for a moment to the misuse of defcustom, which
I'm guessing is too often due to laziness and ignorance:
I think of that pretty much the way I think of the relative
lack of menu support provided by 3rd-party packages:

These are not the first things one writes, when coming up
with a new package.  They are typically among the last things.
You might even add documentation to that list, although
nowadays more programmers take doc more seriously, if only
because they sometimes have to.

These things are not the core of a package.  And they too
often get short shrift.  As a result of their relative lack
of attention to these things, some programmers do not bother
to learn much about building good Emacs menus or defining
good defcustoms.

The same would even be true of keymaps and font-lock-keywords,
except that features closer to the core often involve them.
They tend to be, let's say, second-class, whereas well
designed menus and user options tend to be third-class.

Re: In defense of Customize [was: Trying to right-align my window on startup]

[Christoph Wedler]

Drew Adams <drew.adams@oracle.com> writes:

>> >> > I just hate its UI.
>> 
>> I do not hate Customize, but I think that Customize does not solve
>> the main problems many users had and have with customizing Emacs.
>
> It certainly does not solve all customization needs.  Nor does
> anyone claim otherwise.

Actually, it does not solve customization needs, which could be called
basic, like binding keys to commands.  But people always mention the UI
as the main custom problem - I now believe the UI is a distraction (at
least for the moment).

>> Which issues does custom.el solve?
>> 
>>  1. Number of options: well, nothing has changed. People are still
>>     overwhelmed by the sheer number of options.

> I would consider that mainly a Customize UI problem.

I do not agree.  The problem is that we did not really define for what
we want to use Custom.  In Emacs, Emacs Lisp provides a very powerful
possibility to do the most advanced customizations.  Surely, nobody want
to define some UI-based customization functionality offering the same
amount of possibilities.

Therefore:

 - define what basic customization needs are (key binding are definitely
   part of that) - these customization should (in the end) be influenced
   by some customization UI.

 - make the customization functionilty co-exist with Emacs Lisp - if
   people have more advanced customization needs, we should _encourage_
   them to use Emacs Lisp.

   Changing gc-cons-threshold is surely an advanced customization.  And
   a lot of other options - we could de-customize all these and a casual
   user sees less customization options

We have not done that for custom.  Therefore, we do not have a
user-centric decision (which should be covered by custom, which not),
but an implementation-based one (which kind of settings are easy to
implement).
>
>>  2. Positive: face customizations became easier.
>>     Otherwise: nothing has changed much.  Yes, there is some type
>>     checking on the values now.  But to be honest, I do not see the
>>     point that people do not have to use Lisp to set the value of
>>     some option to some Lisp function or even sexpr.
>
> Some type-checking?  There is a _lot_ of type-checking.
>
> Or rather, the type-checking done corresponds to the :type defined.
> If the writer of the defcustom was lazy and did not write a :type
> declaration that specifies a type that is sufficiently narrow, then
> the type-checking will be correspondingly loose. That is the main
> problem with many option definitions, IMO: lazy typing.
>
> And that can be due insufficient familiarity with :type sexps.

I think I'm familar with that - see e.g.
   M-x customize-variable RET antlr-indent-comment RET

> And there is not only type-checking but also other handling wrt
> initializing and updating values, e.g., handling of :initialize
> and :set triggers.

Right, these two are useful.  Actually, :require is also (almost)
useful.  It would be good to have an :require-unless-nil and use that
not as part of the customization settings, but have autoload.el put that
info into some loaddefs.el.

>>     Defining key and menu bindings: nothing, let alone
>>     for something like the mode-line, ...
>
> Menus, no.  Keys, yes.  There are plenty of options that let
> users specify key bindings.  See :type keyword `key-sequence',
> for a start.
>
> [I use my own widget (keyword) for this, which lets you specify
> a command and a key sequence to bind to it or another command to
> remap to it (for the minor mode).
> http://www.emacswiki.org/Icicles_-_Key_Bindings#IciclesCustomizingKeysScreenshot]

Yes, nice packages could make use of that - but how does that affect the
global-map or c-mode-map without some Lisp code?

>>  3. Positive: custom-themes could be a step in the right direction
>
> Yes and no.  The real "customization" in that case is done by
> the person defining the theme.  Applying a theme is only
> "customization" in the weakest sense.  It counts as such, but
> saying that really misses the point.
>
> What is really missing wrt Customize here is help for _defining_
> themes.  In particular, incremental, direct-manipulation ways of
> turning knobs to get the colors, fonts, etc. that you want here
> and there, and then pushing a button to save what you created as
> a theme.  And ways to compare themes, blend them (WYSIWYG), and
> undo their effects, all components together, and sets of
> components, and components individually.

I do not agree - Lisp code for custom themes are completly ok -
actually, I do my settings by defining some custom themes (as far as
that is possible) via Lisp code.

> Such generated code should of course be kept out of user init
> files.  All users who use Customize at all should define option
> `custom-file', to prevent Customize from using their init file.
> (That should be required by Emacs, for Customize to save anything.
> Emacs not doing that is asking for trouble and not doing users any
> favor, IMO.)

Agreed.  Now everybody must set `custom-file'.

>>  - `gc-cons-threshold' is customizable (which non-Lisper should
>>    change that?), but
>
> Any of them might - why not?  But what's the point?  That it is
> too easy to do that without Customize?  That it is too advanced
> or too hard for non-Lispers to do that?  I don't follow, here.

People who want to change that are somehow interest in Lisp - what is
wrong when they use Lisp to change that value?

>>  - defining a keybinding for C programming requires to define a
>>    function which has to be added to some hook...
>
> Why?  I don't program in C anymore, but isn't there a keymap for
> C mode that you can define the key in?
>
> If you want to define a key in Emacs Lisp mode, you just use
> (define-key THE-KEY emacs-lisp-mode-map).  No defining a function.
> No use of any hook.  (Although I have seen users jump through such
> hoops even when it was not necessary.)

Exactly.  People can often forget about such hooks if they do a
require.  But then the autoloads are bit useless...

Hooks are still necessary for things like imenu-add-to-menubar.

>
> Yes, sometimes the mode map does not exist up front, so you might
> need to do as you say.  But that's not such a big deal, is it?
>
>> So instead of spending time on some UI, things would IMHO improve
>> by the following (doing the UI later)
>
> No one is spending time working on the Customize UI, AFAIK.
> That's one reason it is still so rudimentary or "old-fashioned".
> And as I said earlier, one reason that no one works on it is that
> its code is hard to work with (including debugging).
>
>>  - Define top-level forms for customizations which many people
>>    want to do - something like
>>       (cus-set 'indent-tabs-mode t)
>>       (cus-set 'indent-tabs-mode nil :mode prog-mode)
>>       (cus-define-key "some binding" command :mode c-mode)
>
> Go for it.
>
> To me, that would be precisely "ma[king] things a bit easier which
> were easy before and do[ing] little to help with the others."

Then show me the easy code for setting indent-tabs-mode to t in general
and to nil in all programming modes.

>>  - To handle issue 1: make less options customizable: make package
>>    authors define 5 good customization options, do not propose to
>>    make their 30 variables (user options) customizable.  These
>>    customization option just contain "easy" values: integer,
>>    string value, or a enum-like use of symbols, or a simple list
>>    consisting of these types.

> [...]
> If you are just making a plea for fewer user options, and think
> that many of them should instead be internal variables (presumably
> not just a few bad 3rd-party packages but even options delivered
> with Emacs?) then I would disagree.

No, I do not propose to deliever fewer user options which users could
change via Lisp.  I say that not all are useful to expose to some
customization UI.

So, that is basically a third category of global vars,.

>>    Most of these options could actually influence the values
>>    of some variables - something like custom-sub-themes
>>    (defined in the package) or something like c-style.
>
> Too vague to usefully respond to.  But IIUC, nothing wrong
> with doing that.

Look into cc-styles.cc.  c-offsets-alist, c-hanging-braces-alist etc are
all user options (they are currently customizable, too), but their
values or mostly constrolled by styles.

Generalized, I would propose that variables like these are user options,
but not customizable; in the custom UI, the user can choose a style
which then sets to above mentioned variables.

Regards,
Christoph

Re: In defense of Customize [was: Trying to right-align my window on startup]

[Stefan Monnier]

FWIW, I agree to a large extent with Christoph's criticism.

I'd be happy to see improvement in this area.

I think a good way to improve this area is to work on making it easier
to write Elisp customizations.  E.g. provide new functions/macros to make
the most common kinds of customization easier.

I guess that would mean things like "function to change a key-binding in
major mode foo" where that function takes care of delaying the
key-binding until that time where the major mode's map is
actually defined.  Part of the difficulty is to make these things "clean
and robust".


        Stefan

RE: In defense of Customize [was: Trying to right-align my window on startup]

[Drew Adams]

I don't disagree with most of what you write, Christoph.

I do disagree that there needs to be a wall separating options
that someone can change in the Customize UI and options that
one cannot.  If someone finds the UI or Lisp to be better to
use in some case, s?he should be able to use either.

IIUC, you propose such a categorization (UI-able (and Lispable)
options vs only-Lispable options) in order to help users deal
with the large number of options.

I think that the problem of an abundance of options should
be handled otherwise, by better organizing/categorizing
(and better design) of options, and by better discovery/exploration/navigation tools.

Wrt organizing/categorizing, currently we have pretty much
only custom groups.  Hierarchies that express some of the
dependencies you pointed out (e.g. mega-options, sub-options)
could help.  Tools to make clean use of those would also
help.

> >>  (cus-set 'indent-tabs-mode t)
> >>  (cus-set 'indent-tabs-mode nil :mode prog-mode)
>
> show me the easy code for setting indent-tabs-mode to t in
> general and to nil in all programming modes.

I'm probably missing your point, but doesn't something like
this do that?

(setq-default indent-tabs-mode t)
(add-hook 'prog-mode-hook
          (lambda () (setq indent-tabs-mode nil)))

I don't disagree that functions such as you describe would
be simpler, more flexible, and probably less error-prone to
use than hooks.  My point was that they make something that
is already pretty easy a bit easier.  It's only a minor point,
however, and I may be missing something in your point.

In general, I think we pretty much agree.  I certainly do not
defend Customize (the UI or the underlying functionality)
against possible _improvements_ of it.

Quite the contrary. I've wanted to see improvement for quite
a while, and have done some fiddling of my own in that regard.
(http://www.emacswiki.org/emacs/CustomizingAndSaving)
Improve it or replace it, yes; ignore it or abandon it, no.

My point in defending Customize is that I feel that people
too often do not take enough advantage of what it does have
to offer.  I've seen some pretty silly ~/.emacs code that
jumps around and through extra hoops in fragile, error-prone
ways, where the user could have just used `customize-option'
or `customize-face' to make their changes in a solid,
uncomplicated way.

And too often, I think, this happens because people are
unfamiliar with the (admittedly clunky) UI, or they think
that `setq' is always enough, or they think that using Lisp
is more fun (which it is) or less clueless, or they don't
know about `custom-file' and they worry about mixing
generated code with hand-coded code.

There are good reasons to use Lisp for many customizations.
It does not follow that there are no reasons to use Customize.

Personally, it took me a long time to start using Customize.
I did everything I needed only in Lisp.  Now I use both.
I am glad to let Customize handle the stuff it is good at.

And I think that others too can often benefit from what
Customize has to offer.  That said, if someone prefers to
customize an option like the one I pointed to, whose
default value is a large alist of key bindings, using only
setq in ~/.emacs, well, that's certainly possible.

Re: In defense of Customize [was: Trying to right-align my window on startup]

[Rusi]

On Thursday, January 30, 2014 6:53:07 PM UTC+5:30, Stefan Monnier wrote:
> FWIW, I agree to a large extent with Christoph's criticism.

> I'd be happy to see improvement in this area.

> I think a good way to improve this area is to work on making it easier
> to write Elisp customizations.  E.g. provide new functions/macros to make
> the most common kinds of customization easier.

> I guess that would mean things like "function to change a key-binding in
> major mode foo" where that function takes care of delaying the
> key-binding until that time where the major mode's map is
> actually defined.  Part of the difficulty is to make these things "clean
> and robust".

Some stray thoughts:

1. emacs is an OS
2. elisp is an imperative language

Well 1 is not true in a literal sense but its close enough

Now one of the issues in OS management is startup/daemons.

Even good old init had a way of ordering the startup scripts by prefixing
numbers.  But this was far from enough and so people are coming up with
more declarative approaches like ubuntu's upstart

See this, particularly the use-cases
https://wiki.ubuntu.com/ReplacementInit

The idea is that once some events are identified, the start/stop of services
is setup based on invariants of events rather than by explicit micro-sequencing.

Brings me to the next point -- elisp is too sequential/imperative

Of late many of my elisp problems have this flavour:
I share some parts of my init with some co-workers and things fall apart
because of some require missing or some wrong misplaced loaddefs etc.

I believe that customize as it exists cannot solve this because the
level at which it is written is too high.  As a result the imperative
underbelly of lisp keeps showing through

Re: In defense of Customize [was: Trying to right-align my window on startup]

[Emanuel Berg]

Rusi <rustompmody@gmail.com> writes:

> Brings me to the next point -- elisp is too
> sequential/imperative
>
> Of late many of my elisp problems have this flavour:
> I share some parts of my init with some co-workers
> and things fall apart because of some require missing
> or some wrong misplaced loaddefs etc.

Yeah, but that's it: making it work by wrapping it in a
clever way. If you use it in an "imperative" way, and
then it breaks, surprise surprise.

> I believe that customize as it exists cannot solve
> this because the level at which it is written is too
> high.  As a result the imperative underbelly of lisp
> keeps showing through

Of course it is possible if it is possible in Elisp. If
it is possible in one way, it is possible in another
way, that does the same. That Lisp is for everything -
imperative, functional, data markup, meta
programming... - this is what makes Lisp *great*. This
"side effect"-free hysteria of Haskell etc. is an
artistic/aesthetic construction, and it has little to
do with reality.

> 1. emacs is an OS 2. elisp is an imperative language
>
> Well 1 is not true in a literal sense but its close
> enough
>
> Now one of the issues in OS management is
> startup/daemons.
>
> Even good old init had a way of ordering the startup
> scripts by prefixing numbers.

Yes, Linux has seven runlevels, 0-6 and S. 0 is
shutdown, 1 is single user minimal (maintenance) mode
(S is plain single user mode), 2-5 are multiuser modes
which is default (and those levels can be identical),
and 6 is reboot.

In /etc/inittab, the default mode is set (usually to
2).

Each runlevel executes scripts: kill scripts are first
executed to "kill" services, then the start scripts are
executed to start services. (This is a UNIX System V
thing.)

Those scripts can be inspected with 'ls -d /etc/rc*.d'.

So, for example a reference to a startup script may
look like this:

lrwxrwxrwx 1 root  14 Jan  1  2002 S19gdm3 -> ../init.d/gdm3

For a kill script, prefix with "K" instead. The digit
to the right of S (or K) denotes the order of
execution, with the lowest number first.

If gdm3 is unwanted, it is better not to muck around
with the prefixes or otherwise rename it, instead,
follow the link and remove execution rights.

-- 
underground experts united:
http://user.it.uu.se/~embe8573

Re: In defense of Customize [was: Trying to right-align my window on startup]

[Phillip Lord]

Emanuel Berg <embe8573@student.uu.se> writes:
> Of course it is possible if it is possible in Elisp. If
> it is possible in one way, it is possible in another
> way, that does the same. That Lisp is for everything -
> imperative, functional, data markup, meta
> programming... - this is what makes Lisp *great*. This
> "side effect"-free hysteria of Haskell etc. is an
> artistic/aesthetic construction, and it has little to
> do with reality.

You can argue that this is true of everything beyond the lambda
calculus. It's not that useful an argument though.

Haskell was designed to show what you could do with a lazy functional
language, and it does that well. It is the case that you can do things
in this environment that are not possible in other languages. Whether
these are worth the constraints or not is a different issue.

Phil

Re: In defense of Customize [was: Trying to right-align my window on startup]

[Rusi]

On Friday, January 31, 2014 3:26:02 PM UTC+5:30, Phil Lord wrote:
> Emanuel Berg writes:
> > Of course it is possible if it is possible in Elisp. If
> > it is possible in one way, it is possible in another
> > way, that does the same. That Lisp is for everything -
> > imperative, functional, data markup, meta
> > programming... - this is what makes Lisp *great*. This
> > "side effect"-free hysteria of Haskell etc. is an
> > artistic/aesthetic construction, and it has little to
> > do with reality.

> You can argue that this is true of everything beyond the lambda
> calculus. It's not that useful an argument though.


I had a friend who's email signature used to be:
God made machine language; all the rest is the work of man.

At the other end of the theoretical-practical spectrum are Turing machines:
Here's Dijkstra http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD480.html

Since Turing we have the complete theory of how to manipulate bits and
is not that, what all computing boils down to? And why all that fuss
about, the problems of "the real world"? His theory proves, that all
these problems can be solved, so why bother about actually solving
them?

Re: In defense of Customize [was: Trying to right-align my window on startup]

[Emanuel Berg]

Rusi <rustompmody@gmail.com> writes:

> And why all that fuss about, the problems of "the
> real world"? His theory proves, that all these
> problems can be solved, so why bother about actually
> solving them?

Exactly, and to solve a problem, one needs to know what
exactly the problem is and what the solution should
remedy.

-- 
underground experts united:
http://user.it.uu.se/~embe8573

Re: In defense of Customize [was: Trying to right-align my window on startup]

[Emanuel Berg]

phillip.lord@newcastle.ac.uk (Phillip Lord) writes:

> You can argue that this is true of everything beyond
> the lambda calculus. It's not that useful an argument
> though.
>
> Haskell was designed to show what you could do with a
> lazy functional language, and it does that well. It
> is the case that you can do things in this
> environment that are not possible in other
> languages. Whether these are worth the constraints or
> not is a different issue.

Yeah, only those paradigms are general ways to describe
general things (perhaps Haskell is a bad example, as it
is a straight-arrow realization of an idea, or even
ideal) - nonetheless, some persons say C is for "the
computer elite, that writes Unix" (and its
software). So what to use instead? Pascal - that will
get you structured. Smalltalk and/or C++ - to get
modular, well-partitioned software, that is easy
(supposedly) to debug. Or the functional languages, be
it Haskell, Erlang, or Common Lisp, with no
side-effects, recursion, and set functions, so that the
order of execution wont matter so you get concurrent
software, with short "how-not-what" code.

There might be some truth to all that in the sense that
it is helpful to think about, and practice, but one
thing is not better than the other (especially not
speaking generally) and for 98% of all situations it
comes down to the problem, and the person solving the
problems, and the tools (rather than "paradigmatic"
methods) that [s]he uses.

So in this case, instead of discussing what can't be
done, whatever problem we have should be specified and
then I'm confident there are numerous people who can
solve it, using methods from a wide range of fields. I
don't use customize (though I don't think it is bad, it
is actually good given its scope and ungrateful task),
and I have actually no idea how Joe Emacs user fares
with setting settings, so someone else has to specify
what the exact problem is.

-- 
underground experts united:
http://user.it.uu.se/~embe8573

Re: In defense of Customize [was: Trying to right-align my window on startup]

[Rusi]

On Thursday, January 30, 2014 9:36:20 PM UTC+5:30, Drew Adams wrote:

> > >>  (cus-set 'indent-tabs-mode t)
> > >>  (cus-set 'indent-tabs-mode nil :mode prog-mode)
> > show me the easy code for setting indent-tabs-mode to t in
> > general and to nil in all programming modes.

> I'm probably missing your point, but doesn't something like
> this do that?

> (setq-default indent-tabs-mode t)
> (add-hook 'prog-mode-hook
>           (lambda () (setq indent-tabs-mode nil)))

This is what I meant by "elisp is too imperative"
Note that there is a smidgen of declarativeness in autoload and
eval-after-load.

So we do need the like of:

 (cus-set 'indent-tabs-mode t)		       
 (cus-set 'indent-tabs-mode nil :mode prog-mode)

Only I wish it were part of a more general/generic declarative infrastructure
and not an optional bolt-on like customize

Re: In defense of Customize [was: Trying to right-align my window on startup]

[Christoph Wedler]

Drew Adams <drew.adams@oracle.com> writes:

> I think that the problem of an abundance of options should be handled
> otherwise, by better organizing/categorizing (and better design) of
> options, and by better discovery/exploration/navigation tools.

And the "better organizing/categorizing (and better design) of options"
is IMHO a lot of work.  And things become more complex for the design of
a good UI for "user-centric" options if one has to be aware that the
casual user might also change "advanced" user options.

Let me come back to cc-styles.el.  IMHO, a good customization UI would
offer the user to choose a preferred style and a clever possibility to
define their own style (see below).

If users could also "UI-customize" c-hanging-braces-alist directly, the
question arises whether this has preference to the corresponding setting
of the style, what happens if the style / file changes, ...

Now to the customization of a c indentation style:

 - when customizing the indentation style, the user is presented with a
   C++ code snippet which gives direct visual feedback of the chosen
   style

 - to define a style, the user simply changes the indentation of the c++
   code snippet.  Additionally, they can provide some c++ source files
   to adopt the indention engine

This sounds complex enough, and I would not want to think of what should
happen if the user also changes some advanced indentation options.

>> >>  (cus-set 'indent-tabs-mode t)
>> >>  (cus-set 'indent-tabs-mode nil :mode prog-mode)
>>
>> show me the easy code for setting indent-tabs-mode to t in
>> general and to nil in all programming modes.
>
> I'm probably missing your point, but doesn't something like
> this do that?
>
> (setq-default indent-tabs-mode t)
> (add-hook 'prog-mode-hook
>           (lambda () (setq indent-tabs-mode nil)))

Sorry, I wasn't clear enough.  I meant the customization to be robust,
as Stefan pointed out:
 - one can easily remove this setting
 - it works well together with custom themes...

> Personally, it took me a long time to start using Customize.
> I did everything I needed only in Lisp.  Now I use both.
> I am glad to let Customize handle the stuff it is good at.

Yeah.  That was on of the reason why it took me so long to switch from
XEmacs to Emacs.  I wanted to get rid of most customizations (otherwise
I would "shadow" too much of the new good stuff).  And I wanted to do
the customization via custom - actually via hand-written custom-theme
functions.

That being said: I really like Emacs-24.3! I regret not having switched
earlier - most things are really much better.
(Exceptions: mainly dired (+dired-x), and I understand Emacs' policy
towards cl even less than I did before...)

Regards
Christoph