line-move-visual

line-move-visual

[Johan Myréen]

Could somebody please explain to me what the idea behind the new concept of 
"visual lines" in Emacs is?

Emacs has always been a "line-oriented" editor, i.e. the buffer consists of 
logical lines. These lines can occasionally wrap so that they spill over to 
the next visual line, but the main concept is still the logical line. This has 
been the mindset of Emacs users since the dawn of time. 

I was shocked to find out that this doesn't seem to be true anymore: by 
default C-n and C-p do not move to the next and previous logical lines, but 
instead place the cursor on the next or previous visible line. I find this 
totally counterintuitive. If I press C-n five times, I expect to find the 
cursor five (logical) lines down, regardless if they happen to be wrapped or 
not. It is not consistent either: why don't C-a and C-e then move to the 
beginning and end of the visual line. Or why does C-k kill until the end of 
the logical line, and not the visual line?

Yes, I know the old behaviour can be restored: after some digging I found out 
about the line-move-visual variable. Couldn't the default be nil instead of t?

Please do not forget what Gnu Emacs stands for: Generally Not Used, Except by 
Middle-Aged Computer Scientists. With changes like this you risk alienating 
the few of us that are left.

Johan Myreen
Emacs user since the mid 1980s

Re: line-move-visual

[Bastien]

Johan Myréen <jem@iki.fi> writes:

> Could somebody please explain to me what the idea behind the new concept of 
> "visual lines" in Emacs is?

Take your breath and deep into this discussion:

  http://article.gmane.org/gmane.emacs.devel/101560

I also agree the default for `line-move-visual' should be nil.
Some other developers expressed their dislike about visual line 
mode in many ways.  See this recent comment on orgmode list:

  http://article.gmane.org/gmane.emacs.orgmode/15224

> Emacs has always been a "line-oriented" editor, i.e. the buffer consists of 
> logical lines. These lines can occasionally wrap so that they spill over to 
> the next visual line, but the main concept is still the logical line. This has 
> been the mindset of Emacs users since the dawn of time. 
>
> I was shocked to find out that this doesn't seem to be true anymore: by 
> default C-n and C-p do not move to the next and previous logical lines, but 
> instead place the cursor on the next or previous visible line. I find this 
> totally counterintuitive. 

So do I.

IIRC we never had a vote about this issue - maybe it's time to have it.

> Yes, I know the old behaviour can be restored: after some digging I found out 
> about the line-move-visual variable. Couldn't the default be nil instead of t?
>
> Please do not forget what Gnu Emacs stands for: Generally Not Used, Except by 
> Middle-Aged Computer Scientists. With changes like this you risk alienating 
> the few of us that are left.

Hey!  Stay here.  I hope we'll fix this.

-- 
 Bastien

Re: line-move-visual

[Miles Bader]

Bastien <bastienguerry@googlemail.com> writes:
> IIRC we never had a vote about this issue - maybe it's time to have it.

It's almost impossible to get a representative sample of Emacs users, so
what would be the point?

Emacs is not a democracy, although the maintainers generally pay a lot
of attention to the opinions and arguments of others.  In the face of
contentious changes, it's the job of the maintainers to understand the
arguments on both sides and make a judgement call as to what the best
solution for the entire Emacs user base is.

I guess if you think you have arguments that nobody has seen before, you
could present them (it seems a bit unlikely though).

-Miles

-- 
What the fuck do white people have to be blue about!?  Banana Republic ran
out of Khakis?  The Espresso Machine is jammed?  Hootie and The Blowfish
are breaking up??!  Shit, white people oughtta understand, their job is to
GIVE people the blues, not to get them!  -- George Carlin

Re: line-move-visual

[Bastien]

Miles Bader <miles@gnu.org> writes:

> Bastien <bastienguerry@googlemail.com> writes:
>> IIRC we never had a vote about this issue - maybe it's time to have it.
>
> It's almost impossible to get a representative sample of Emacs users, so
> what would be the point?

The vote is a way to know the opinion of a subset of Emacs users.
Whether this subset is representative or not may be a good question, 
but a poll can still be useful without an answer to this question.

> Emacs is not a democracy, although the maintainers generally pay a lot
> of attention to the opinions and arguments of others.  In the face of
> contentious changes, it's the job of the maintainers to understand the
> arguments on both sides and make a judgement call as to what the best
> solution for the entire Emacs user base is.

Agreed.  A vote is a tool to help maintainers pay attention.  

> I guess if you think you have arguments that nobody has seen before, you
> could present them (it seems a bit unlikely though).

I didn't enter this discussion because basically my arguments were
already stated by others.  A vote is also great for sparing the time of
everyone: express an opinion once and let X person vote for it without
the need to express their arguments for this opinion again and again.

Anyway.  

I created a poll.  The result are send by email to me.  Would be better
to send the results to the maintainers, though - but it's just sort of a
proof of concept.

  "Should line-move-visual default to nil or t?"
   http://www.micropoll.com/akira/mpview/623312-182840

If people are interested in launching such a poll, please do so.

-- 
 Bastien

Re: line-move-visual

[Kenichi Handa]

In article <87ocrtulzd.fsf@bzg.ath.cx>, Bastien <bastienguerry@googlemail.com> writes:
> I created a poll.  The result are send by email to me.  Would be better
> to send the results to the maintainers, though - but it's just sort of a
> proof of concept.

>   "Should line-move-visual default to nil or t?"
>    http://www.micropoll.com/akira/mpview/623312-182840

Options should be "nil" and "t", or the question should be
"Should line-move-visual default to nil".

---
Kenichi Handa
handa@m17n.org

Re: line-move-visual

[Bastien]

Kenichi Handa <handa@m17n.org> writes:

> In article <87ocrtulzd.fsf@bzg.ath.cx>, Bastien <bastienguerry@googlemail.com> writes:
>> I created a poll.  The result are send by email to me.  Would be better
>> to send the results to the maintainers, though - but it's just sort of a
>> proof of concept.
>
>>   "Should line-move-visual default to nil or t?"
>>    http://www.micropoll.com/akira/mpview/623312-182840
>
> Options should be "nil" and "t", or the question should be
> "Should line-move-visual default to nil".

Er, yes.  Another try:

  http://www.micropoll.com/akira/mpview/623323-182852

-- 
 Bastien

Re: line-move-visual

[Alfred M. Szmidt]

Would it be posisble to do such a poll by email?

Re: line-move-visual

[Bastien]

"Alfred M. Szmidt" <ams@gnu.org> writes:

> Would it be posisble to do such a poll by email?

Sure.

-- 
 Bastien

Re: line-move-visual

[Scot Becker]

Good defaults are important.  They are not the answer.

Discoverability is key.  This could be done through a customize
interface, as Stephen suggests or simply through a piece of startup
documentation called "Things you might want to tweak."   This would
contain not just the  "wacky new variables that dazzle old-timers,"
but also the flip side, the so-called "crufty unixy defaults which
trip up newbies".  As well as the "defaults more for writers of
natural languages" and "defaults more for coders," and so on.

The Emacs developers take obvious care in making thoughtful defaults,
and this list takes impassioned (!) care to help them do it.  But the
real issue for a variable like this is that the user knows that it's
there and can set it to get what s/he wants with a minimum amount of
work.

There exist beginner customization helps (e.g. on the EmacsWiki or in
the many init files on the web), but I think it would be worth it to
identify a set of 10-30 variables and tweaks which are most
significant in helping new users (or new users of a given release) get
Emacs to broadly behave in ways that are congenial to them.  These can
be put into a customize buffer or a new Quick-Start-Tweaks doc (or
best: in both).  This should be taken in to the official Emacs
distribution, and linked to on the open Splash screen.

The set should include not recently-introduced, but also things of
broad impact on the user experience which broad sections of our target
audience may reasonably need one way or the other.

Scot

Vim user from 1997-2008.  Emacs user since the introduction of visual-line-mode.

Re: line-move-visual

[Eli Zaretskii]

> Date: Fri, 10 Jul 2009 09:43:37 +0100
> From: Scot Becker <scot.becker@gmail.com>
> Cc: miles@gnu.org, emacs-devel@gnu.org, jem@iki.fi,
> 	Kenichi Handa <handa@m17n.org>
> 
> Discoverability is key.  This could be done through a customize
> interface, as Stephen suggests or simply through a piece of startup
> documentation called "Things you might want to tweak."

We already have a feature that is close to that:

  Options->Customize Emacs->New Options

It asks for an old version, and presents a Customize buffer with all
options changed or introduced since that version.

Re: line-move-visual

[Lennart Borgman]

On Fri, Jul 10, 2009 at 10:57 AM, Eli Zaretskii<eliz@gnu.org> wrote:
>> Date: Fri, 10 Jul 2009 09:43:37 +0100
>> From: Scot Becker <scot.becker@gmail.com>
>> Cc: miles@gnu.org, emacs-devel@gnu.org, jem@iki.fi,
>>       Kenichi Handa <handa@m17n.org>
>>
>> Discoverability is key.  This could be done through a customize
>> interface, as Stephen suggests or simply through a piece of startup
>> documentation called "Things you might want to tweak."
>
> We already have a feature that is close to that:
>
>  Options->Customize Emacs->New Options
>
> It asks for an old version, and presents a Customize buffer with all
> options changed or introduced since that version.

Yes, that is good, but I think that Scot more asked for function to
"explain and customize options a new Emacs user might want to tweak".

I think it is a good suggestion.

Re: line-move-visual

[Bastien]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> Yes, that is good, but I think that Scot more asked for function to
> "explain and customize options a new Emacs user might want to tweak".
>
> I think it is a good suggestion.

+1

Org-mode has such a beginner's guide to customization:

  http://orgmode.org/worg/org-configs/index.php
  http://orgmode.org/worg/org-customization-guide.php

It can be a good source of inspiration.

-- 
 Bastien

Re: line-move-visual

[Scot Becker]

Right.  I know about "New Options"  It's Good, and to my mind
basically answers the OP's concern.  But I wanted to shift the
discussion slightly from just the 'new options' to 'significant
options (new or not) for which different usage scenarios might dictate
different defaults.'  Of course ANY of the user configurable variables
might count *to someone* as belonging to that category.  But it seems
that there are things that come up on this list that are genuinely
(and earnestly) disputed, since multiple defaults make sense, each for
a different (broad) portion of the Emacs community.  These should be
easier to find than they are.  This then would make the agonizing
issue of what the proper default should be a little less agonizing.

Scot


On Fri, Jul 10, 2009 at 9:57 AM, Eli Zaretskii<eliz@gnu.org> wrote:
>> Date: Fri, 10 Jul 2009 09:43:37 +0100
>> From: Scot Becker <scot.becker@gmail.com>
>> Cc: miles@gnu.org, emacs-devel@gnu.org, jem@iki.fi,
>>       Kenichi Handa <handa@m17n.org>
>>
>> Discoverability is key.  This could be done through a customize
>> interface, as Stephen suggests or simply through a piece of startup
>> documentation called "Things you might want to tweak."
>
> We already have a feature that is close to that:
>
>  Options->Customize Emacs->New Options
>
> It asks for an old version, and presents a Customize buffer with all
> options changed or introduced since that version.
>

Re: line-move-visual

[joakim]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Fri, 10 Jul 2009 09:43:37 +0100
>> From: Scot Becker <scot.becker@gmail.com>
>> Cc: miles@gnu.org, emacs-devel@gnu.org, jem@iki.fi,
>> 	Kenichi Handa <handa@m17n.org>
>> 
>> Discoverability is key.  This could be done through a customize
>> interface, as Stephen suggests or simply through a piece of startup
>> documentation called "Things you might want to tweak."
>
> We already have a feature that is close to that:
>
>   Options->Customize Emacs->New Options
>
> It asks for an old version, and presents a Customize buffer with all
> options changed or introduced since that version.
>

It would be nice to have something similar to the "skinnability feature"
some other applications have.

It would make use of Custom, and would allow to group together
Customizable features in a coherent theme.

So, the default for "line visual" would be nil in the "emacs oldtimer"
skin, and t in "emacs newbie" skin. There would also be a "Windoze for
the w*n" skin that would have cua defaults, etc.

Just as the "emacs->new options" feature, the skin feature would keep
track of defaults that are new in this particular emacs for this
particular skin.

It would also keep track of for which options the user has decided to
diverge from the customize options from the default.

The feature could also support trying out different themes. Also purely
cosmetical options like those supported by "color-theme" should be
provided.


-- 
Joakim Verona

Re: line-move-visual

[Scot Becker]

On "skinnability"   Yes.  Something like that is good, especially if
all of the changed variables can be brought together into one place
for tweaking.   I have wondered whether 'customize' is capable of
letting a user collect an arbitrary set of variables for the attention
of other users. (Seems that the groups a variable belongs to are hard
coded, though).   I'm playing with developing an 'Emacs configuration
for writers', which could benefit from this kind of thing.  And it
would be a good approach to solving the present problem of 'sensible
defaults' for different kinds of users.

Scot


On Fri, Jul 10, 2009 at 10:13 AM, <joakim@verona.se> wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> Date: Fri, 10 Jul 2009 09:43:37 +0100
>>> From: Scot Becker <scot.becker@gmail.com>
>>> Cc: miles@gnu.org, emacs-devel@gnu.org, jem@iki.fi,
>>>      Kenichi Handa <handa@m17n.org>
>>>
>>> Discoverability is key.  This could be done through a customize
>>> interface, as Stephen suggests or simply through a piece of startup
>>> documentation called "Things you might want to tweak."
>>
>> We already have a feature that is close to that:
>>
>>   Options->Customize Emacs->New Options
>>
>> It asks for an old version, and presents a Customize buffer with all
>> options changed or introduced since that version.
>>
>
> It would be nice to have something similar to the "skinnability feature"
> some other applications have.
>
> It would make use of Custom, and would allow to group together
> Customizable features in a coherent theme.
>
> So, the default for "line visual" would be nil in the "emacs oldtimer"
> skin, and t in "emacs newbie" skin. There would also be a "Windoze for
> the w*n" skin that would have cua defaults, etc.
>
> Just as the "emacs->new options" feature, the skin feature would keep
> track of defaults that are new in this particular emacs for this
> particular skin.
>
> It would also keep track of for which options the user has decided to
> diverge from the customize options from the default.
>
> The feature could also support trying out different themes. Also purely
> cosmetical options like those supported by "color-theme" should be
> provided.
>
>
> --
> Joakim Verona
>

RE: line-move-visual

[Drew Adams]

> I have wondered whether 'customize' is capable of
> letting a user collect an arbitrary set of variables for the attention
> of other users. (Seems that the groups a variable belongs to are hard
> coded, though).

Something like an `add-group' function that would let you easily add a Customize
group to a given option or face? Yes, that could be useful.

And for those who don't want to mess with any Lisp, Customize could have a
button or whatever to let you add a group for an option/face or for all of the
options and faces in the current Customize buffer.

I agree that this kind of thing would help users "package" things together,
including for sharing. The fact that the set of Customize groups for an
option/face is pretty much hard-coded is a (minor) limitation.

(OTOH, if we provide that, be prepared for more worms in the can. But I still
think it's a good idea.)

Re: line-move-visual

[Lennart Borgman]

On Fri, Jul 10, 2009 at 6:11 PM, Drew Adams<drew.adams@oracle.com> wrote:
>> I have wondered whether 'customize' is capable of
>> letting a user collect an arbitrary set of variables for the attention
>> of other users. (Seems that the groups a variable belongs to are hard
>> coded, though).
>
> Something like an `add-group' function that would let you easily add a Customize
> group to a given option or face? Yes, that could be useful.

    (custom-add-to-group 'my-group 'my-variable 'custom-variable))

RE: line-move-visual

[Drew Adams]

> >> I have wondered whether 'customize' is capable of
> >> letting a user collect an arbitrary set of variables for 
> >> the attention of other users. (Seems that the groups a
> >> variable belongs to are hard coded, though).
> >
> > Something like an `add-group' function that would let you 
> > easily add a Customize group to a given option or face?
> > Yes, that could be useful.
> 
>     (custom-add-to-group 'my-group 'my-variable 'custom-variable))

Well, whaddya know?! Forgot about it, I guess.

So all that's missing in this regard is an easy, non-Lisp way for users to do
the same thing - e.g. a button in Customize.

And then perhaps a good way for users to share their groups (a la skins). Maybe
just create an EmacsWiki page (e.g. GroupsAsSkins) where people can upload their
groups to share.

But that would mean also having Customize produce a `custom-add-to-group' entry
when you add a group to an option, so you could then extract that code from your
custom-file to share.

RE: line-move-visual

[Drew Adams]

> And then perhaps a good way for users to share their groups 
> (a la skins). Maybe just create an EmacsWiki page (e.g.
> GroupsAsSkins) where people can upload their groups to share.
> 
> But that would mean also having Customize produce a 
> `custom-add-to-group' entry when you add a group to an option,
> so you could then extract that code from your custom-file to share.

Or maybe there already is a function that, given a Customize group name, returns
a list of all options and faces in that group (directly, not by inheritance)?

If so, then people could use that to get the list for a given "skin", and upload
it for others to see (or to try, by mapping over it using
`custom-add-to-group').

I thought maybe `custom-group-members' would do that, but it seems to list only
groups (even with nil GROUPS-ONLY), not options and faces.

Re: line-move-visual

[Miles Bader]

joakim@verona.se writes:
> It would be nice to have something similar to the "skinnability feature"
> some other applications have.
>
> It would make use of Custom, and would allow to group together
> Customizable features in a coherent theme.
>
> So, the default for "line visual" would be nil in the "emacs oldtimer"
> skin, and t in "emacs newbie" skin. There would also be a "Windoze for
> the w*n" skin that would have cua defaults, etc.

The name "skin" may be a misnomer, as typically they're basically
all-or-nothing groups of settings.

I don't think that's a good idea, nor is is a good idea to automatically
change lots of defaults without user-participation -- while we want to
allow the user to customize things easily, there's _also_ some advantage
if they stick to the standard defaults, both for the user (in his
ability to come to terms with emacs in the long term, and be part of the
emacs community), and for Emacs maintainers.

So, instead of changing lots of settings en-masse, (which would tend to
leave the user a bit ignorant of what just happened), how about just
having simple themed customization groups ("get off my lawn", "windows
luser", ...), which present focused groups of settings for the user to
tweak at his pleasure -- but, crucially, don't actually any tweaking for
him.

-Miles

-- 
Erudition, n. Dust shaken out of a book into an empty skull.

RE: line-move-visual

[Drew Adams]

> The name "skin" may be a misnomer, as typically they're basically
> all-or-nothing groups of settings.
> 
> I don't think that's a good idea, nor is is a good idea to 
> automatically change lots of defaults without user-participation
> -- while we want to allow the user to customize things easily,
> there's _also_ some advantage if they stick to the standard
> defaults, both for the user (in his ability to come to terms
> with emacs in the long term, and be part of the
> emacs community), and for Emacs maintainers.

FWIW, I agree.

Re: line-move-visual

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > We already have a feature that is close to that:
 > 
 >   Options->Customize Emacs->New Options
 > 
 > It asks for an old version, and presents a Customize buffer with all
 > options changed or introduced since that version.

This is good, but the crucial feature that improves discoverability is
the ability for the user to identify changes to classic behavior,
which is not necessarily all the new options.  Presumably the majority
of options that appear here relate to behavior of newly added
libraries, that don't represent a change to existing behavior.

Also, that must be a pretty big set of options if you compare, say, v
23 to v 21.

Re: line-move-visual

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Scot Becker <scot.becker@gmail.com>,
>     bastienguerry@googlemail.com,
>     emacs-devel@gnu.org,
>     jem@iki.fi,
>     handa@m17n.org,
>     miles@gnu.org
> Date: Fri, 10 Jul 2009 20:35:49 +0900
> 
> Also, that must be a pretty big set of options if you compare, say, v
> 23 to v 21.

It's very big even if you compare to 22.3.  But that's Emacs, I don't
see how anything can be done about the sheer quantity of new features
in a major release.

What bothers me a lot is that there doesn't seem to be a good way of
finding options relevant to some topic.  The various `apropos'
commands we have are ad-hoc and rely on strings in symbol names or
documentation.  What is missing is the ability to associate keywords
with symbols, akin to index entries we put in manuals.  But first and
foremost, someone will have to come up with a useful set of keywords
(those used by finder.el are not even close).

RE: line-move-visual

[Drew Adams]

> What bothers me a lot is that there doesn't seem to be a good way of
> finding options relevant to some topic.  The various `apropos'
> commands we have are ad-hoc and rely on strings in symbol names or
> documentation.  What is missing is the ability to associate keywords
> with symbols, akin to index entries we put in manuals.  But first and
> foremost, someone will have to come up with a useful set of keywords
> (those used by finder.el are not even close).

The words in doc strings serve pretty well as (ad-hoc) keywords -
`apropos-documentation'.

Re: line-move-visual

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <bastienguerry@googlemail.com>, <jem@iki.fi>, <scot.becker@gmail.com>,
>         <emacs-devel@gnu.org>
> Date: Fri, 10 Jul 2009 09:11:44 -0700
> 
> > What bothers me a lot is that there doesn't seem to be a good way of
> > finding options relevant to some topic.  The various `apropos'
> > commands we have are ad-hoc and rely on strings in symbol names or
> > documentation.  What is missing is the ability to associate keywords
> > with symbols, akin to index entries we put in manuals.  But first and
> > foremost, someone will have to come up with a useful set of keywords
> > (those used by finder.el are not even close).
> 
> The words in doc strings serve pretty well as (ad-hoc) keywords -
> `apropos-documentation'.

Not well enough, IMO.

RE: line-move-visual

[Drew Adams]

> > The words in doc strings serve pretty well as (ad-hoc) keywords -
> > `apropos-documentation'.
> 
> Not well enough, IMO.

Right. You need `icicle-vardoc'. ;-)

http://www.emacswiki.org/emacs/Icicles_-_Multi-Completions

Re: line-move-visual

[Juri Linkov]

> What bothers me a lot is that there doesn't seem to be a good way of
> finding options relevant to some topic.  The various `apropos'
> commands we have are ad-hoc and rely on strings in symbol names or
> documentation.  What is missing is the ability to associate keywords
> with symbols, akin to index entries we put in manuals.  But first and
> foremost, someone will have to come up with a useful set of keywords
> (those used by finder.el are not even close).

I started working on a dynamic keyword system where the first step was
porting the current finder.el to Info.  I'll post a patch very soon.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: line-move-visual

[Lennart Borgman]

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

On Fri, Jul 10, 2009 at 1:35 PM, Stephen J. Turnbull<stephen@xemacs.org> wrote:
> Eli Zaretskii writes:
>
>  > We already have a feature that is close to that:
>  >
>  >   Options->Customize Emacs->New Options
>  >
>  > It asks for an old version, and presents a Customize buffer with all
>  > options changed or introduced since that version.
>
> This is good, but the crucial feature that improves discoverability is
> the ability for the user to identify changes to classic behavior,
> which is not necessarily all the new options.

Here is a try to structure this in a custom buffer. It is not like
"skins" right now, but that could be added later.

I have set some new defaults, like showing the help links underlined
and making the "tabable". I think they should look and behave like
that.

Also I have cut out part from help-make-xrefs that someone put a
common on saying

   ;; The following should probably be abstracted out.

So I did that and suggest using that for widgets.

Do "M-x customize-for-new-user" to test and tell me what you think.
Please ignore that nothing in the custom buffer created works at the
moment... ;-)

[-- Attachment #2: cus-new-user.el --]
[-- Type: text/plain, Size: 16198 bytes --]

;;; cus-new-user.el --- Customize some important options
;;
;; Author: Lennart Borgman (lennart O borgman A gmail O com)
;; Created: 2009-07-10 Fri
;; Version: 0.2
;; Last-Updated: 2009-07-10 Fri
;; URL:
;; Keywords:
;; Compatibility:
;;
;; Features that might be required by this library:
;;
;;   None
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Commentary:
;;
;;    Customize significant options for which different user
;;    environment expectations might dictate different defaults.
;;
;;    After an idea of Scot Becker on Emacs Devel.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Change log:
;;
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; This program is free software; you can redistribute it and/or
;; modify it under the terms of the GNU General Public License as
;; published by the Free Software Foundation; either version 3, or
;; (at your option) any later version.
;;
;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
;; General Public License for more details.
;;
;; You should have received a copy of the GNU General Public License
;; along with this program; see the file COPYING.  If not, write to
;; the Free Software Foundation, Inc., 51 Franklin Street, Fifth
;; Floor, Boston, MA 02110-1301, USA.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Code:

;;(customize-for-new-user)
;;;###autoload
(defun customize-for-new-user (&optional name)
  "Show special customization page for new user.
"
  (interactive)
  ;;(setq debug-on-error t)
  ;;(setq buffer-read-only t)
  (require 'cus-edit)
  (let ((inhibit-read-only t)
        fill-pos)
    (pop-to-buffer (custom-get-fresh-buffer (or name "*Customizations for New Users*")))
    (Custom-mode)
    (erase-buffer)
    (setq fill-pos (point))
    (widget-insert
     "Below are some custom options that new users often may want to
tweak since they may make Emacs a bit more like what they expect from using other software in their environment.

Since Emacs runs in many environment and an Emacs user may use
several of them it is hard to decide by default what a user
wants/expects.  Therefor you are given the possibility to easily
do those changes here.

Note that this is just a collection of normal custom options.
There are no new options here.

")
    (fill-region fill-pos (point))

    ;; Normal custom buffer header
    (let ((init-file (or custom-file user-init-file)))
      ;; Insert verbose help at the top of the custom buffer.
      (when custom-buffer-verbose-help
        (widget-insert "Editing a setting changes only the text in this buffer."
                       (if init-file
                           "
To apply your changes, use the Save or Set buttons.
Saving a change normally works by editing your init file."
                         "
Currently, these settings cannot be saved for future Emacs sessions,
possibly because you started Emacs with `-q'.")
                       "\nFor details, see ")
        (widget-create 'custom-manual
                       :tag "Saving Customizations"
                       "(emacs)Saving Customizations")
        (widget-insert " in the ")
        (widget-create 'custom-manual
                       :tag "Emacs manual"
                       :help-echo "Read the Emacs manual."
                       "(emacs)Top")
        (widget-insert "."))
      (widget-insert "\n")
      ;; The custom command buttons are also in the toolbar, so for a
      ;; time they were not inserted in the buffer if the toolbar was in use.
      ;; But it can be a little confusing for the buffer layout to
      ;; change according to whether or nor the toolbar is on, not to
      ;; mention that a custom buffer can in theory be created in a
      ;; frame with a toolbar, then later viewed in one without.
      ;; So now the buttons are always inserted in the buffer.  (Bug#1326)
;;;    (when (not (and (bound-and-true-p tool-bar-mode) (display-graphic-p)))
      (if custom-buffer-verbose-help
          (widget-insert "\n
 Operate on all settings in this buffer that are not marked HIDDEN:\n"))
      (let ((button (lambda (tag action active help icon)
                      (widget-insert " ")
                      (if (eval active)
                          (widget-create 'push-button :tag tag
                                         :help-echo help :action action))))
            (commands custom-commands))
        (apply button (pop commands)) ; Set for current session
        (apply button (pop commands)) ; Save for future sessions
        (if custom-reset-button-menu
            (progn
              (widget-insert " ")
              (widget-create 'push-button
                             :tag "Reset buffer"
                             :help-echo "Show a menu with reset operations."
                             :mouse-down-action 'ignore
                             :action 'custom-reset))
          (widget-insert "\n")
          (apply button (pop commands)) ; Undo edits
          (apply button (pop commands)) ; Reset to saved
          (apply button (pop commands)) ; Erase customization
          (widget-insert "  ")
          (pop commands) ; Help (omitted)
          (apply button (pop commands)))) ; Exit
      (widget-insert "\n\n")

      ;;;;;;;;;;;;;;;;;;;;;;;;;;;;
      ;; Editor emulator level

      (widget-insert "\n")
      (setq fill-pos (point))
      (widget-insert
"Emacs can emulate some common editing behaviours (and some uncommon too).
For the most common ones you can decide if you want to use them here:
")
      (fill-region fill-pos (point))
      (cusnu-mark-part-desc fill-pos (point))
      (widget-insert "\n")

      ;; CUA Mode
      (cusnu-insert-options '((cua-mode custom-variable)))

      ;; Viper Mode
      (widget-insert "\n")
      (widget-insert (propertize "Viper Mode" 'face 'custom-variable-tag))
      (widget-insert ":")
      (setq fill-pos (point))
      (widget-insert "
   Viper is currently set up in a special way, please see the
   command `viper-mode'.
")
      (fill-region fill-pos (point))

      (cusnu-make-xrefs)
      )))

(defun cusnu-mark-part-desc (beg end)
  (let ((ovl (make-overlay beg end)))
    (overlay-put ovl 'face 'highlight)))

(defun cusnu-make-xrefs (&optional beg end)
  (save-restriction
    (when (or beg end)
      (unless beg (setq beg (point-min)))
      (unless end (setq end (point-max)))
      (narrow-to-region beg end))
    (goto-char (point-min))
    (cusnu-help-insert-xrefs 'cusnu-help-xref-button)))

(defun cusnu-help-xref-button (match-number type &rest args)
  (let ((beg (match-beginning match-number))
        (end (match-end match-number)))
  (if nil
      (let ((ovl (make-overlay beg end)))
        (overlay-put ovl 'face 'highlight))
    (let ((tag (match-string match-number))
          (wid-type (cond
                     ((eq type 'help-variable)
                      'variable-link)
                     ((eq type 'help-function)
                      'function-link)
                     ((eq type 'help-info)
                      'custom-manual)
                     (t nil)))
          )
      (when wid-type
        (delete-region beg end)
        (backward-char)
        ;;(tag action active help icon)
        (widget-create wid-type
                       ;;tag
                       :tag tag
                       :keymap custom-mode-link-map
                       :follow-link 'mouse-face
                       :button-face 'custom-link
                       :mouse-face 'highlight
                       :pressed-face 'highlight
                       ;;:help-echo help
                       )))))
    )

;; Override default ... ;-)
(define-widget 'documentation-link 'link
  "Link type used in documentation strings."
  ;;:tab-order -1
  :help-echo "Describe this symbol"
  :button-face 'custom-link
  :action 'widget-documentation-link-action)

(defun cusnu-xref-niy (&rest ignore)
  (message "Not implemented yet"))

(defun cusnu-describe-function (wid &rest ignore)
  (let ((fun (widget-get wid :what))
        )
    (describe-function fun)))

(defun cusnu-help-insert-xrefs (help-xref-button)
  ;; The following should probably be abstracted out.
  (unwind-protect
      (progn
        ;; Info references
        (save-excursion
          (while (re-search-forward help-xref-info-regexp nil t)
            (let ((data (match-string 2)))
              (save-match-data
                (unless (string-match "^([^)]+)" data)
                  (setq data (concat "(emacs)" data))))
              (funcall help-xref-button 2 'help-info data))))
        ;; URLs
        (save-excursion
          (while (re-search-forward help-xref-url-regexp nil t)
            (let ((data (match-string 1)))
              (funcall help-xref-button 1 'help-url data))))
        ;; Mule related keywords.  Do this before trying
        ;; `help-xref-symbol-regexp' because some of Mule
        ;; keywords have variable or function definitions.
        (if help-xref-mule-regexp
            (save-excursion
              (while (re-search-forward help-xref-mule-regexp nil t)
                (let* ((data (match-string 7))
                       (sym (intern-soft data)))
                  (cond
                   ((match-string 3) ; coding system
                    (and sym (coding-system-p sym)
                         (funcall help-xref-button 6 'help-coding-system sym)))
                   ((match-string 4) ; input method
                    (and (assoc data input-method-alist)
                         (funcall help-xref-button 7 'help-input-method data)))
                   ((or (match-string 5) (match-string 6)) ; charset
                    (and sym (charsetp sym)
                         (funcall help-xref-button 7 'help-character-set sym)))
                   ((assoc data input-method-alist)
                    (funcall help-xref-button 7 'help-character-set data))
                   ((and sym (coding-system-p sym))
                    (funcall help-xref-button 7 'help-coding-system sym))
                   ((and sym (charsetp sym))
                    (funcall help-xref-button 7 'help-character-set sym)))))))
        ;; Quoted symbols
        (save-excursion
          (while (re-search-forward help-xref-symbol-regexp nil t)
            (let* ((data (match-string 8))
                   (sym (intern-soft data)))
              (if sym
                  (cond
                   ((match-string 3)  ; `variable' &c
                    (and (or (boundp sym) ; `variable' doesn't ensure
                                        ; it's actually bound
                             (get sym 'variable-documentation))
                         (funcall help-xref-button 8 'help-variable sym)))
                   ((match-string 4)   ; `function' &c
                    (and (fboundp sym) ; similarly
                         (funcall help-xref-button 8 'help-function sym)))
                   ((match-string 5) ; `face'
                    (and (facep sym)
                         (funcall help-xref-button 8 'help-face sym)))
                   ((match-string 6)) ; nothing for `symbol'
                   ((match-string 7)
;;;  this used:
;;; 			  #'(lambda (arg)
;;; 			      (let ((location
;;; 				     (find-function-noselect arg)))
;;; 				(pop-to-buffer (car location))
;;; 				(goto-char (cdr location))))
                    (funcall help-xref-button 8 'help-function-def sym))
                   ((and
                     (facep sym)
                     (save-match-data (looking-at "[ \t\n]+face\\W")))
                    (funcall help-xref-button 8 'help-face sym))
                   ((and (or (boundp sym)
                             (get sym 'variable-documentation))
                         (fboundp sym))
                    ;; We can't intuit whether to use the
                    ;; variable or function doc -- supply both.
                    (funcall help-xref-button 8 'help-symbol sym))
                   ((and
                     (or (boundp sym)
                         (get sym 'variable-documentation))
                     (or
                      (documentation-property
                       sym 'variable-documentation)
                      (condition-case nil
                          (documentation-property
                           (indirect-variable sym)
                           'variable-documentation)
                        (cyclic-variable-indirection nil))))
                    (funcall help-xref-button 8 'help-variable sym))
                   ((fboundp sym)
                    (funcall help-xref-button 8 'help-function sym)))))))
        ;; An obvious case of a key substitution:
        (save-excursion
          (while (re-search-forward
                  ;; Assume command name is only word and symbol
                  ;; characters to get things like `use M-x foo->bar'.
                  ;; Command required to end with word constituent
                  ;; to avoid `.' at end of a sentence.
                  "\\<M-x\\s-+\\(\\sw\\(\\sw\\|\\s_\\)*\\sw\\)" nil t)
            (let ((sym (intern-soft (match-string 1))))
              (if (fboundp sym)
                  (funcall help-xref-button 1 'help-function sym)))))
        ;; Look for commands in whole keymap substitutions:
        (save-excursion
          ;; Make sure to find the first keymap.
          (goto-char (point-min))
          ;; Find a header and the column at which the command
          ;; name will be found.

          ;; If the keymap substitution isn't the last thing in
          ;; the doc string, and if there is anything on the
          ;; same line after it, this code won't recognize the end of it.
          (while (re-search-forward "^key +binding\n\\(-+ +\\)-+\n\n"
                                    nil t)
            (let ((col (- (match-end 1) (match-beginning 1))))
              (while
                  (and (not (eobp))
                       ;; Stop at a pair of blank lines.
                       (not (looking-at "\n\\s-*\n")))
                ;; Skip a single blank line.
                (and (eolp) (forward-line))
                (end-of-line)
                (skip-chars-backward "^ \t\n")
                (if (and (>= (current-column) col)
                         (looking-at "\\(\\sw\\|\\s_\\)+$"))
                    (let ((sym (intern-soft (match-string 0))))
                      (if (fboundp sym)
                          (funcall help-xref-button 0 'help-function sym))))
                (forward-line))))))
    ;;(set-syntax-table stab)
    ))

(defun cusnu-insert-options (options)
  (buffer-disable-undo)
  (setq custom-options
	(if (= (length options) 1)
	    (mapcar (lambda (entry)
		      (widget-create (nth 1 entry)
				     :documentation-shown t
				     :custom-state 'unknown
				     :tag (custom-unlispify-tag-name
					   (nth 0 entry))
				     :value (nth 0 entry)))
		    options)
	  (let ((count 0)
		(length (length options)))
	    (mapcar (lambda (entry)
		      (prog2
			  (message "Creating customization items ...%2d%%"
				   (/ (* 100.0 count) length))
			  (widget-create (nth 1 entry)
					 :tag (custom-unlispify-tag-name
					       (nth 0 entry))
					 :value (nth 0 entry))
			(setq count (1+ count))
			(unless (eq (preceding-char) ?\n)
			  (widget-insert "\n"))
			(widget-insert "\n")))
		    options))))
  (unless (eq (preceding-char) ?\n)
    (widget-insert "\n"))
  )

(provide 'cus-new-user)
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; cus-new-user.el ends here

Re: line-move-visual

[Scot Becker]

Lennart,

That was quick!   I think a library like that would do a lot, since
you could create custom customization buffers for all the purposes we
have discussed.  I like it.  Of course for a new user, the
customization buffer itself is quite 'busy', but that's not a problem
we can do anything about at the moment.  And the sooner they warm up
to it, probably the better for them, since it's one of the better
forms we have of interface discoverability at the moment.

I tried adding new variables to customize, which seems to work. I
assume it's possible to add documentation by adding  it between the
commands.  And typical lisp logic to only present some options if
we're on a certain OS, or have a certain package loaded.

This is really nice, Lennart.   I assume it's far too late to include
something like this in v. 23.1, but I could imagine various
'customization groups' making it into a future version.  If I manage
to produce an Emacs 'customization package for writers.'  I will most
certainly use this (especially if line-move-visual gets set to nil!)
.
So aside from the ongoing need to pick good defaults, how well does
something like this address the discoverability issue?  What do the
rest of you think?

Scot

Re: line-move-visual

[Lennart Borgman]

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

On Fri, Jul 10, 2009 at 5:07 PM, Scot Becker<scot.becker@gmail.com> wrote:
> Lennart,
>
> That was quick!   I think a library like that would do a lot, since
> you could create custom customization buffers for all the purposes we
> have discussed.  I like it.  Of course for a new user, the
> customization buffer itself is quite 'busy', but that's not a problem
> we can do anything about at the moment.  And the sooner they warm up
> to it, probably the better for them, since it's one of the better
> forms we have of interface discoverability at the moment.
>
> I tried adding new variables to customize, which seems to work. I
> assume it's possible to add documentation by adding  it between the
> commands.  And typical lisp logic to only present some options if
> we're on a certain OS, or have a certain package loaded.
>
> This is really nice, Lennart.   I assume it's far too late to include
> something like this in v. 23.1, but I could imagine various
> 'customization groups' making it into a future version.  If I manage
> to produce an Emacs 'customization package for writers.'  I will most
> certainly use this (especially if line-move-visual gets set to nil!)
> .
> So aside from the ongoing need to pick good defaults, how well does
> something like this address the discoverability issue?  What do the
> rest of you think?


Pointing out some important options is perhaps good. Also exporting
"my important options/my skin options" is probably good. See the new
version below (a working version).

I guess it is not ready, but maybe a discussion point at least.

[-- Attachment #2: cus-new-user.el --]
[-- Type: text/plain, Size: 23181 bytes --]

;;; cus-new-user.el --- Customize some important options
;;
;; Author: Lennart Borgman (lennart O borgman A gmail O com)
;; Created: 2009-07-10 Fri
;; Version: 0.2
;; Last-Updated: 2009-07-10 Fri
;; URL:
;; Keywords:
;; Compatibility:
;;
;; Features that might be required by this library:
;;
;;   None
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Commentary:
;;
;;    Customize significant options for which different user
;;    environment expectations might dictate different defaults.
;;
;;    After an idea of Scot Becker on Emacs Devel.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Change log:
;;
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; This program is free software; you can redistribute it and/or
;; modify it under the terms of the GNU General Public License as
;; published by the Free Software Foundation; either version 3, or
;; (at your option) any later version.
;;
;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
;; General Public License for more details.
;;
;; You should have received a copy of the GNU General Public License
;; along with this program; see the file COPYING.  If not, write to
;; the Free Software Foundation, Inc., 51 Franklin Street, Fifth
;; Floor, Boston, MA 02110-1301, USA.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;; Code:

;;(customize-for-new-user)
;;;###autoload
(defun customize-for-new-user (&optional name)
  "Show special customization page for new user.
"
  (interactive)
  ;;(setq debug-on-error t)
  ;;(setq buffer-read-only t)
  (require 'cus-edit)
  (let ((inhibit-read-only t)
        fill-pos)
    (pop-to-buffer (custom-get-fresh-buffer (or name "*Customizations for New Users*")))
    (buffer-disable-undo)
    (Custom-mode)
    (erase-buffer)
    (setq fill-pos (point))
    (widget-insert
     "Below are some custom options that new users often may want to
tweak since they may make Emacs a bit more like what they expect from using other software in their environment.

Since Emacs runs in many environment and an Emacs user may use
several of them it is hard to decide by default what a user
wants/expects.  Therefor you are given the possibility to easily
do those changes here.

Note that this is just a collection of normal custom options.
There are no new options here.

")
    (fill-region fill-pos (point))

    ;; Normal custom buffer header
    (let ((init-file (or custom-file user-init-file)))
      ;; Insert verbose help at the top of the custom buffer.
      (when custom-buffer-verbose-help
        (widget-insert "Editing a setting changes only the text in this buffer."
                       (if init-file
                           "
To apply your changes, use the Save or Set buttons.
Saving a change normally works by editing your init file."
                         "
Currently, these settings cannot be saved for future Emacs sessions,
possibly because you started Emacs with `-q'.")
                       "\nFor details, see ")
        (widget-create 'custom-manual
                       :tag "Saving Customizations"
                       "(emacs)Saving Customizations")
        (widget-insert " in the ")
        (widget-create 'custom-manual
                       :tag "Emacs manual"
                       :help-echo "Read the Emacs manual."
                       "(emacs)Top")
        (widget-insert "."))
      (widget-insert "\n")
      ;; The custom command buttons are also in the toolbar, so for a
      ;; time they were not inserted in the buffer if the toolbar was in use.
      ;; But it can be a little confusing for the buffer layout to
      ;; change according to whether or nor the toolbar is on, not to
      ;; mention that a custom buffer can in theory be created in a
      ;; frame with a toolbar, then later viewed in one without.
      ;; So now the buttons are always inserted in the buffer.  (Bug#1326)
;;;    (when (not (and (bound-and-true-p tool-bar-mode) (display-graphic-p)))
      (if custom-buffer-verbose-help
          (widget-insert "\n
 Operate on all settings in this buffer that are not marked HIDDEN:\n"))
      (let ((button (lambda (tag action active help icon)
                      (widget-insert " ")
                      (if (eval active)
                          (widget-create 'push-button :tag tag
                                         :help-echo help :action action))))
            (commands custom-commands))
        (apply button (pop commands)) ; Set for current session
        (apply button (pop commands)) ; Save for future sessions
        (if custom-reset-button-menu
            (progn
              (widget-insert " ")
              (widget-create 'push-button
                             :tag "Reset buffer"
                             :help-echo "Show a menu with reset operations."
                             :mouse-down-action 'ignore
                             :action 'custom-reset))
          (widget-insert "\n")
          (apply button (pop commands)) ; Undo edits
          (apply button (pop commands)) ; Reset to saved
          (apply button (pop commands)) ; Erase customization
          (widget-insert "  ")
          (pop commands) ; Help (omitted)
          (apply button (pop commands)))) ; Exit
      (widget-insert "\n\n")

      ;;;;;;;;;;;;;;;;;;;;;;;;;;;;
      ;; Editor emulator level

      (widget-insert "\n")
      (setq fill-pos (point))
      (widget-insert
"Emacs can emulate some common editing behaviours (and some uncommon too).
For the most common ones you can decide if you want to use them here:
")
      (fill-region fill-pos (point))
      (cusnu-mark-part-desc fill-pos (point))

      ;; CUA Mode
      (cusnu-insert-options '((cua-mode custom-variable)))

      ;; Viper Mode
      (widget-insert "\n")
      (widget-insert (propertize "Viper" 'face 'custom-variable-tag))
      (widget-insert ":")
      (setq fill-pos (point))
      (widget-insert "
   Viper is currently set up in a special way, please see the
   command `viper-mode'.  You can use custom to set up most of
   it.  However if you want to load Viper at startup you must
   explicitly include \(require 'viper) in your .emacs.
")
      (fill-region fill-pos (point))

      ;; Viper Mode
      (backward-delete-char 1)
      (cusnu-insert-options '((viper-mode custom-variable)))

      ;;;;;;;;;;;;;;;;;;;;;;;;;;;;
      ;; OS specific

      (widget-insert "\n")
      (setq fill-pos (point))
      (widget-insert (format "OS specific options (%s): \n" system-type))
      (fill-region fill-pos (point))
      (cusnu-mark-part-desc fill-pos (point))

      (if cusno-insert-os-spec-fun
          (funcall cusno-insert-os-spec-fun)
       (widget-insert "No OS specific customizations.\n"))

      ;;;;;;;;;;;;;;;;;;;;;;;;;;;;
      ;; Disputed settings

      (widget-insert "\n")
      (setq fill-pos (point))
      (widget-insert
"Some old time Emacs users want to change the options below:
")
      (fill-region fill-pos (point))
      (cusnu-mark-part-desc fill-pos (point))

      (cusnu-insert-options '((global-visual-line-mode custom-variable)))
      (cusnu-insert-options '((word-wrap custom-variable)))
      (cusnu-insert-options '((blink-cursor-mode custom-variable)))
      (cusnu-insert-options '((tool-bar-mode custom-variable)))
      (cusnu-insert-options '((tooltip-mode custom-variable)))
      ;;(cusnu-insert-options '((initial-scratch-message custom-variable)))

      (widget-insert "\n")
      (setq fill-pos (point))
      (widget-insert
"My skin options - for exporting custom options to other users (or yourself on another computer)")
      (fill-region fill-pos (point))
      (cusnu-mark-part-desc fill-pos (point))

      (widget-insert "\n")
      (cusnu-insert-options '((cusnu-my-skin-options custom-variable)))
      (widget-insert "\n")
      (widget-create 'push-button
                     :tag "Export my skin options"
                     :action (lambda (&rest ignore)
                               (let ((use-dialog-box nil))
                                 (call-interactively 'cusnu-export-my-skin-options))))

      ;; Finish setup buffer
      (mapc 'custom-magic-reset custom-options)
      (cusnu-make-xrefs)
      (widget-setup)
      (buffer-enable-undo)
      (goto-char (point-min)))))

(defvar cusno-insert-os-spec-fun nil)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Example on Emacs+Emacw32
(when (boundp 'emacsw32-version)
  (defun cusnu-emacsw32-show-custstart (&rest args)
    (emacsw32-show-custstart))
  (setq cusno-insert-os-spec-fun 'cusnu-insert-emacsw32-specific-part)
  (defun cusnu-insert-emacsw32-specific-part ()
    (cusnu-insert-options '((w32-meta-style custom-variable)))
    (widget-insert "\n")
    (widget-insert (propertize "EmacsW32" 'face 'custom-variable-tag))
    (widget-insert "
   Easy setup for Emacs+EmacsW32.")
    (widget-insert "\n   ")
    (widget-create 'push-button :tag "Customize EmacsW32"
                   ;;:help-echo help
                   :action 'cusnu-emacsw32-show-custstart)
    (widget-insert "\n")))
;; End example
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

(defun cusnu-mark-part-desc (beg end)
  (let ((ovl (make-overlay beg end)))
    (overlay-put ovl 'face 'highlight)))

(defun cusnu-make-xrefs (&optional beg end)
  (save-restriction
    (when (or beg end)
      (unless beg (setq beg (point-min)))
      (unless end (setq end (point-max)))
      (narrow-to-region beg end))
    (let ((here (point)))
      (goto-char (point-min))
      (cusnu-help-insert-xrefs 'cusnu-help-xref-button)
      (goto-char here))))

(defun widget-info-link-action (widget &optional event)
  "Open the info node specified by WIDGET."
  (info-other-window (widget-value widget)))

(defun widget-documentation-string-value-create (widget)
  ;; Insert documentation string.
  (let ((doc (widget-value widget))
	(indent (widget-get widget :indent))
	(shown (widget-get (widget-get widget :parent) :documentation-shown))
	(start (point)))
    (if (string-match "\n" doc)
	(let ((before (substring doc 0 (match-beginning 0)))
	      (after (substring doc (match-beginning 0)))
	      button)
	  (when (and indent (not (zerop indent)))
	    (insert-char ?\s indent))
	  (insert before ?\s)
	  (widget-documentation-link-add widget start (point))
	  (setq button
		(widget-create-child-and-convert
		 widget (widget-get widget :visibility-widget)
		 :help-echo "Show or hide rest of the documentation."
		 :on "Hide Rest"
		 :off "More"
		 :always-active t
		 :action 'widget-parent-action
		 shown))
	  (when shown
	    (setq start (point))
	    (when (and indent (not (zerop indent)))
	      (insert-char ?\s indent))
	    (insert after)
	    (widget-documentation-link-add widget start (point))
            (cusnu-make-xrefs start (point))
            )
	  (widget-put widget :buttons (list button)))
      (when (and indent (not (zerop indent)))
	(insert-char ?\s indent))
      (insert doc)
      (widget-documentation-link-add widget start (point))))
  (insert ?\n))
(defun cusnu-help-xref-button (match-number type what &rest args)
  (let ((beg (match-beginning match-number))
        (end (match-end match-number)))
  (if nil
      (let ((ovl (make-overlay beg end)))
        (overlay-put ovl 'face 'highlight))
    (let* ((tag (match-string match-number))
           (value what)
            (wid-type (cond
                       ((eq type 'help-variable)
                        'variable-link)
                       ((eq type 'help-function)
                        'function-link)
                       ((eq type 'help-info)
                        'custom-manual)
                       (t nil)))
          )
      (when wid-type
        (delete-region beg end)
        (backward-char)
        ;;(tag action active help icon)
        (widget-create wid-type
                       ;;tag
                       :value value
                       :tag tag
                       :keymap custom-mode-link-map
                       :follow-link 'mouse-face
                       :button-face 'custom-link
                       :mouse-face 'highlight
                       :pressed-face 'highlight
                       ;;:help-echo help
                       )))))
    )

;; Override default ... ;-)
(define-widget 'documentation-link 'link
  "Link type used in documentation strings."
  ;;:tab-order -1
  :help-echo "Describe this symbol"
  :button-face 'custom-link
  :action 'widget-documentation-link-action)

(defun cusnu-xref-niy (&rest ignore)
  (message "Not implemented yet"))

(defun cusnu-describe-function (wid &rest ignore)
  (let ((fun (widget-get wid :what))
        )
    (describe-function fun)))

(defun cusnu-help-insert-xrefs (help-xref-button)
  ;; The following should probably be abstracted out.
  (unwind-protect
      (progn
        ;; Info references
        (save-excursion
          (while (re-search-forward help-xref-info-regexp nil t)
            (let ((data (match-string 2)))
              (save-match-data
                (unless (string-match "^([^)]+)" data)
                  (setq data (concat "(emacs)" data))))
              (funcall help-xref-button 2 'help-info data))))
        ;; URLs
        (save-excursion
          (while (re-search-forward help-xref-url-regexp nil t)
            (let ((data (match-string 1)))
              (funcall help-xref-button 1 'help-url data))))
        ;; Mule related keywords.  Do this before trying
        ;; `help-xref-symbol-regexp' because some of Mule
        ;; keywords have variable or function definitions.
        (if help-xref-mule-regexp
            (save-excursion
              (while (re-search-forward help-xref-mule-regexp nil t)
                (let* ((data (match-string 7))
                       (sym (intern-soft data)))
                  (cond
                   ((match-string 3) ; coding system
                    (and sym (coding-system-p sym)
                         (funcall help-xref-button 6 'help-coding-system sym)))
                   ((match-string 4) ; input method
                    (and (assoc data input-method-alist)
                         (funcall help-xref-button 7 'help-input-method data)))
                   ((or (match-string 5) (match-string 6)) ; charset
                    (and sym (charsetp sym)
                         (funcall help-xref-button 7 'help-character-set sym)))
                   ((assoc data input-method-alist)
                    (funcall help-xref-button 7 'help-character-set data))
                   ((and sym (coding-system-p sym))
                    (funcall help-xref-button 7 'help-coding-system sym))
                   ((and sym (charsetp sym))
                    (funcall help-xref-button 7 'help-character-set sym)))))))
        ;; Quoted symbols
        (save-excursion
          (while (re-search-forward help-xref-symbol-regexp nil t)
            (let* ((data (match-string 8))
                   (sym (intern-soft data)))
              (if sym
                  (cond
                   ((match-string 3)  ; `variable' &c
                    (and (or (boundp sym) ; `variable' doesn't ensure
                                        ; it's actually bound
                             (get sym 'variable-documentation))
                         (funcall help-xref-button 8 'help-variable sym)))
                   ((match-string 4)   ; `function' &c
                    (and (fboundp sym) ; similarly
                         (funcall help-xref-button 8 'help-function sym)))
                   ((match-string 5) ; `face'
                    (and (facep sym)
                         (funcall help-xref-button 8 'help-face sym)))
                   ((match-string 6)) ; nothing for `symbol'
                   ((match-string 7)
;;;  this used:
;;; 			  #'(lambda (arg)
;;; 			      (let ((location
;;; 				     (find-function-noselect arg)))
;;; 				(pop-to-buffer (car location))
;;; 				(goto-char (cdr location))))
                    (funcall help-xref-button 8 'help-function-def sym))
                   ((and
                     (facep sym)
                     (save-match-data (looking-at "[ \t\n]+face\\W")))
                    (funcall help-xref-button 8 'help-face sym))
                   ((and (or (boundp sym)
                             (get sym 'variable-documentation))
                         (fboundp sym))
                    ;; We can't intuit whether to use the
                    ;; variable or function doc -- supply both.
                    (funcall help-xref-button 8 'help-symbol sym))
                   ((and
                     (or (boundp sym)
                         (get sym 'variable-documentation))
                     (or
                      (documentation-property
                       sym 'variable-documentation)
                      (condition-case nil
                          (documentation-property
                           (indirect-variable sym)
                           'variable-documentation)
                        (cyclic-variable-indirection nil))))
                    (funcall help-xref-button 8 'help-variable sym))
                   ((fboundp sym)
                    (funcall help-xref-button 8 'help-function sym)))))))
        ;; An obvious case of a key substitution:
        (save-excursion
          (while (re-search-forward
                  ;; Assume command name is only word and symbol
                  ;; characters to get things like `use M-x foo->bar'.
                  ;; Command required to end with word constituent
                  ;; to avoid `.' at end of a sentence.
                  "\\<M-x\\s-+\\(\\sw\\(\\sw\\|\\s_\\)*\\sw\\)" nil t)
            (let ((sym (intern-soft (match-string 1))))
              (if (fboundp sym)
                  (funcall help-xref-button 1 'help-function sym)))))
        ;; Look for commands in whole keymap substitutions:
        (save-excursion
          ;; Make sure to find the first keymap.
          (goto-char (point-min))
          ;; Find a header and the column at which the command
          ;; name will be found.

          ;; If the keymap substitution isn't the last thing in
          ;; the doc string, and if there is anything on the
          ;; same line after it, this code won't recognize the end of it.
          (while (re-search-forward "^key +binding\n\\(-+ +\\)-+\n\n"
                                    nil t)
            (let ((col (- (match-end 1) (match-beginning 1))))
              (while
                  (and (not (eobp))
                       ;; Stop at a pair of blank lines.
                       (not (looking-at "\n\\s-*\n")))
                ;; Skip a single blank line.
                (and (eolp) (forward-line))
                (end-of-line)
                (skip-chars-backward "^ \t\n")
                (if (and (>= (current-column) col)
                         (looking-at "\\(\\sw\\|\\s_\\)+$"))
                    (let ((sym (intern-soft (match-string 0))))
                      (if (fboundp sym)
                          (funcall help-xref-button 0 'help-function sym))))
                (forward-line))))))
    ;;(set-syntax-table stab)
    ))

(defun cusnu-insert-options (options)
  (widget-insert "\n")
  (setq custom-options
        (append
         (if (= (length options) 1)
             (mapcar (lambda (entry)
                       (widget-create (nth 1 entry)
                                      ;;:documentation-shown t
                                      :custom-state 'unknown
                                      :tag (custom-unlispify-tag-name
                                            (nth 0 entry))
                                      :value (nth 0 entry)))
                     options)
           (let ((count 0)
                 (length (length options)))
             (mapcar (lambda (entry)
                       (prog2
                           (message "Creating customization items ...%2d%%"
                                    (/ (* 100.0 count) length))
                           (widget-create (nth 1 entry)
                                          :tag (custom-unlispify-tag-name
                                                (nth 0 entry))
                                          :value (nth 0 entry))
                         (setq count (1+ count))
                         (unless (eq (preceding-char) ?\n)
                           (widget-insert "\n"))
                         (widget-insert "\n")))
                     options)))
         custom-options))
  (unless (eq (preceding-char) ?\n)
    (widget-insert "\n"))
  )

(define-widget 'custom-symbol 'symbol
  "A Custom option."
  :prompt-match (lambda (sym) (get sym 'custom-type))
  :prompt-history 'widget-variable-prompt-value-history
  :complete-function (lambda ()
		       (interactive)
		       (lisp-complete-symbol (lambda (sym) (get sym 'custom-type))))
  :tag "Custom option")

(defcustom cusnu-my-skin-options nil
  "My custum options.
You can export these to a file with
`cusnu-export-my-skin-options' so that others can use them."
  :type '(repeat custom-symbol)
  )

(defun cusnu-export-my-skin-options (file)
  "Export to file FILE custom options in `cusnu-my-skin-options'."
  (interactive "FTo file: ")
  (when (file-exists-p file)
    (error "File %s already exists" file))
  (let ((buf (find-file file))
        start)
    (with-current-buffer buf
      (erase-buffer)
      (insert (format-time-string ";; Here are my default options values %Y-%m-%d.\n"))
      (insert
";; Eval this elisp file to test them and then do
;;
;;    M-x customize-save-customized
;;
;; if you want to keep them.
;;
;; Here are the options I have choosen to export:\n")
      (insert (format ";;(customize-set-variable 'cusnu-my-skin-options\n"))
      (setq start (point))
      (insert (format ";;        %S)\n\n" cusnu-my-skin-options))
      (emacs-lisp-mode)
      (fill-region start (point))
      (dolist (opt cusnu-my-skin-options)
        (let ((my-val (car-safe
                       (or (get opt 'saved-value)
                           (get opt 'customized-value)))))
          (when my-val
            (insert (format "(customize-set-variable '%s %S)\n" opt my-val)))))
      )))

(provide 'cus-new-user)
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; cus-new-user.el ends here

Re: line-move-visual

[Alfred M. Szmidt]

   > Discoverability is key.  This could be done through a customize
   > interface, as Stephen suggests or simply through a piece of
   > startup documentation called "Things you might want to tweak."

   We already have a feature that is close to that:

     Options->Customize Emacs->New Options

Maybe it is a good idea to add it to the startup-buffer?

Re: line-move-visual

[Sean O'Rourke]

Just to chime in, 

Scot Becker <scot.becker@gmail.com> writes:
> Discoverability is key.

Indeed.  The "antinews" node in the Emacs info is useful here,
but it would be nice for it to include links for how to undo
major and/or controversial recent changes.  There's a chance it
would shorten these kinds of discussions if there were an
obvious place to look for controversial changes, which also
explained how to revert them.  Just for reference, here's the
relevant section of my .emacs [1] (not all of those changed
with 21.x, and most Emacs changes are more good than bad, but
I've been reverting a few things for a long time).

Sean

[1]

;; Undo some of the suck of version 21.x
(blink-cursor-mode		0)
(tool-bar-mode			0)
(when (fboundp 'tooltip-mode)
  (tooltip-mode			0))
(with-current-buffer (get-buffer-create "*scratch*")
  (setq buffer-offer-save nil))
(setq
 line-move-visual		nil
 initial-scratch-message	nil)

Re: line-move-visual

[Tassilo Horn]

Bastien <bastienguerry@googlemail.com> writes:

Hi!

>> Options should be "nil" and "t", or the question should be "Should
>> line-move-visual default to nil".
>
> Er, yes.  Another try:
>
>   http://www.micropoll.com/akira/mpview/623323-182852

I'm missing this vote option:

  Yes and no.  Either it should be disabled completely, or full
  visual-line-mode should be enabled by default.  These inconsistencies
  between visual lines with C-n/C-p and logical lines with C-k/C-e/C-e
  are the worst-case default.

Bye,
Tassilo

Re: line-move-visual

[Miles Bader]

Tassilo Horn <tassilo@member.fsf.org> writes:
> I'm missing this vote option:
>
>   Yes and no.  Either it should be disabled completely, or full
>   visual-line-mode should be enabled by default.  These inconsistencies
>   between visual lines with C-n/C-p and logical lines with C-k/C-e/C-e
>   are the worst-case default.

BTW, I really hope that vote page points to the discussion threads about
this stuff (which discuss, for instance, exactly the above issue...).

Ok, I know even if it does, people won't bother to read anyof it and
will vote with their gut.  Sigh...

-Miles

-- 
The automobile has not merely taken over the street, it has dissolved the
living tissue of the city.  Its appetite for space is absolutely insatiable;
moving and parked, it devours urban land, leaving the buildings as mere
islands of habitable space in a sea of dangerous and ugly traffic.
[James Marston Fitch, New York Times, 1 May 1960]

Re: line-move-visual

[Scot Becker]

by Miles:
...simple themed customization groups ("get off my lawn", "windows
luser", ...), which present focused groups of settings for the user to
tweak at his pleasure

Sure, that'd be great. And fair enough with 'coaching users through
incremental changes' rather than 'changing a raft of things in one
fell swoop'.   A few helpful additions would be that (1) there would
be a way for users to create such customization groups for
distribution to other users.  They wouldn't be hard-coded, like
today's customization groups (apparently are).

And (2) ideally there'd be the opportunity to optionally include
extended user documentation in amongst the variables to give guidance
beyond what one might find in the docstrings.  The docstrings can be a
bit minimal if what you want to do is explain the significance of
various choices to a user who is only now encountering some new
concept lying behind a variable.

Lastly, it would be nice to have a way for such customization groups
to specify: "If external library X is available, customize variable
ext-lib-X-groovy, and fail gracefully if not ("If you had optional
package X loaded, you would also be able to customize these variables
here:")

This way it would be useful for the present purpose, as well as for
package writers who want to draw attention to a set of variables whose
interaction with their package the user might want to consider.  It
could also be useful for my  "Emacs for writers" config-file disto,
and someone else's "Emacs for coders in functional languages"
config-distro, etc.

And your names are great (get off my lawn and windows luser).

Scot

RE: line-move-visual

[Drew Adams]

> A few helpful additions would be that (1) there would
> be a way for users to create such customization groups for
> distribution to other users.  They wouldn't be hard-coded, like
> today's customization groups (apparently are).

Yes; see my other reply. It would help to make it easier for users to group
options (and faces).

> And (2) ideally there'd be the opportunity to optionally include
> extended user documentation in amongst the variables to give guidance
> beyond what one might find in the docstrings.  The docstrings can be a
> bit minimal if what you want to do is explain the significance of
> various choices to a user who is only now encountering some new
> concept lying behind a variable.

That's OK, but it's the sharing of such annotations that is most helpful. Your
adding helpful info to a doc string locally doesn't help me understand it better
where I am.

It's helpful to send a bug report with the suggestion, so it can be incorporated
for others to see too. The problem with that is that the official doc must be a
one-size-fits-all, to some extent.

An alternative is to share your extra doc using Emacs Wiki.

One possibility might be (_might_ be - just thinking out loud) to have a doc
string link to an EmacsWiki page that details only that variable, function, or
whatever. This would be somewhat like a doc string link to the manual, but the
difference is that anyone can participate in any way in editing the wiki page.

Just half-baked food for thought.

Re: line-move-visual

[Ulrich Mueller]

There's another poll in the Gentoo forums:
<http://forums.gentoo.org/viewtopic-t-779324.html>

Ulrich

Re: line-move-visual

[Eli Zaretskii]

> Date: Fri, 10 Jul 2009 12:36:48 +0200
> From: Ulrich Mueller <ulm@gentoo.org>
> Cc: Bastien <bastienguerry@googlemail.com>, Kenichi Handa <handa@m17n.org>,
> 	jem@iki.fi, Miles Bader <miles@gnu.org>
> 
> There's another poll in the Gentoo forums:
> <http://forums.gentoo.org/viewtopic-t-779324.html>

But there doesn't seem to be a way of voting there without some extra
fuss.

Re: line-move-visual

[Christian Faulhammer]

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

Hi,

Eli Zaretskii <eliz@gnu.org>:

> > Date: Fri, 10 Jul 2009 12:36:48 +0200
> > From: Ulrich Mueller <ulm@gentoo.org>
> > Cc: Bastien <bastienguerry@googlemail.com>, Kenichi Handa
> > <handa@m17n.org>, jem@iki.fi, Miles Bader <miles@gnu.org>
> > 
> > There's another poll in the Gentoo forums:
> > <http://forums.gentoo.org/viewtopic-t-779324.html>
> 
> But there doesn't seem to be a way of voting there without some extra
> fuss.

 If you are a Gentoo user you should have an account...it is an
internal vote in the end if we disregard upstream's defaults.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: line-move-visual

[Ulrich Mueller]

>>>>> On Fri, 10 Jul 2009, Eli Zaretskii wrote:

>> There's another poll in the Gentoo forums:
>> <http://forums.gentoo.org/viewtopic-t-779324.html>

> But there doesn't seem to be a way of voting there without some
> extra fuss.

Yes, because as you already see from the list of options, it's
primarily intended for Gentoo users (registration to our forums is
open for everyone though). But I thought that its outcome might be
interesting for the readers of this list.

Ulrich

Re: line-move-visual

[Bastien]

Ulrich Mueller <ulm@gentoo.org> writes:

>>>>>> On Fri, 10 Jul 2009, Eli Zaretskii wrote:
>
>>> There's another poll in the Gentoo forums:
>>> <http://forums.gentoo.org/viewtopic-t-779324.html>
>
>> But there doesn't seem to be a way of voting there without some
>> extra fuss.
>
> Yes, because as you already see from the list of options, it's
> primarily intended for Gentoo users (registration to our forums is
> open for everyone though). But I thought that its outcome might be
> interesting for the readers of this list.

I think it is.  If a poll is a tool for maintainers to make their
choice, several polls are just several tools, all interesting.

-- 
 Bastien

Re: line-move-visual

[Richard Stallman]

    Emacs is not a democracy, although the maintainers generally pay a lot
    of attention to the opinions and arguments of others.  In the face of
    contentious changes, it's the job of the maintainers to understand the
    arguments on both sides and make a judgement call as to what the best
    solution for the entire Emacs user base is.

This is true.  However, polling the users is a good way for the
maintainers to learn how users think about a proposed change.

Re: line-move-visual

[Stephen J. Turnbull]

Richard Stallman writes:

 > However, polling the users is a good way for the maintainers to
 > learn how users think about a proposed change.

The problem is that the pollsters rarely design the poll in a way that
encourages thinking at all, let alone conveying the line of thought to
the pollster.  And pollsters generally just report the numerical
results.

Eg, the Gentoo poll is actually a sort of non-binding vote, as I
understand it.  For their purposes, it makes sense to just report
numerical results, and they do allow comments.  A quick perusal of the
comments resulted in zero interesting content beyond the votes (there
was a long subthread that depended on the misconception that LaTeX
source is divided into paragraphs by newlines, the rest of the
comments just reiterated "I do/don't like the feature").  I don't
think it is of much interest to the Emacs maintainers.

If you want to encourage use of polls, then you should set standards
for design and reporting of these polls.

Re: line-move-visual

[Miles Bader]

"Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp> writes:
>  > However, polling the users is a good way for the maintainers to
>  > learn how users think about a proposed change.
>
> The problem is that the pollsters rarely design the poll in a way that
> encourages thinking at all, let alone conveying the line of thought to
> the pollster.  And pollsters generally just report the numerical
> results.

I seem to recall that Richard has said in the past that the most useful
part of polls was not really any numerical tally, but the comments
people made; it can be useful tool in getting input from people that
aren't normally part of the discussion.

For the reasons you state, and others, of course, mere "votes" (without
a kind of rigor and scope which is more or less impossible for us to
achieve) seem almost useless.

-Miles

-- 
Cat, n. A soft, indestructible automaton provided by nature to be kicked when
things go wrong in the domestic circle.

Re: line-move-visual

[Bastien]

Miles Bader <miles@gnu.org> writes:

> For the reasons you state, and others, of course, mere "votes" (without
> a kind of rigor and scope which is more or less impossible for us to
> achieve) seem almost useless.

What about:

- have a poll by email on the emacs mailing list, which lets people
  add their comments; 

- and have as many other polls as possible on any medium (web forum,
  etc.) and don't presume about their relevance before we have them;

?

IMHO, we have had too many comments and too few figures.  Let's go
pragmatic.  I really look forward the maintainers comments on this.

-- 
 Bastien

Re: line-move-visual

[Richard Stallman]

    - have a poll by email on the emacs mailing list, which lets people
      add their comments; 

When we did polls, we announced them on info-gnu-emacs and anywhere
else that seemed useful, to reach the broadest group of Emacs users.

But we did not do them "on" any mailing list.  We asked users to send
their responses to a special address which dumped mail into a file.
We checked the answers at the end.

We always asked people to say why they prefer a certain behavior,
rather than just voting for or against.  And sometimes we suggested
more than two options.

    - and have as many other polls as possible on any medium (web forum,
      etc.) and don't presume about their relevance before we have them;

It makes no sense to have multiple (different) polls about one topic.
It is easier and better to annouce the one poll in multiple places.

Re: line-move-visual

[Stephen J. Turnbull]

Bastien writes:
 > Johan Myréen <jem@iki.fi> writes:

 > > Could somebody please explain to me what the idea behind the new
 > > concept of "visual lines" in Emacs is?

What's new about it?  It's been around for decades, even in Emacs for
a decade or so (long-lines mode). :-)  It's only new as a default.

As Bastien says, here's the long explanation:

 > Take your breath and deep into this discussion:
 > 
 >   http://article.gmane.org/gmane.emacs.devel/101560

 > > Yes, I know the old behaviour can be restored: after some digging
 > > I found out about the line-move-visual variable. Couldn't the
 > > default be nil instead of t?
 > >
 > > Please do not forget what Gnu Emacs stands for: Generally Not
 > > Used, Except by Middle-Aged Computer Scientists.

The "idea" behind this change is to fix that. :-)

 > > With changes like this you risk alienating the few of us that are
 > > left.

Hey!  Not that way!  By attracting a New Generation of users who have
never seen the "carriage" that "carriage return" refers to.  "What,
were typewriters horse-powered?" ;-)

Sure, a lot of us agree that this isn't what we want, at least at
first, but Miles is fairly typical as a long-time user who finds it
"rather convenient".  So in some sense the "right way" to fix this is
not by refusing to change the defaults, but by making newly variable
behaviors like this one more discoverable.  How about a custom group
called "customizations-we-have-recently-introduced", with subgroups of
the form "in-version-XX.YY", and "version-XX.YY" tags for the previous
behavior if different from default?

It also ought to be possible to revert to "classic Emacs" behavior,
for values of "classic" that are user-defined. :-)

The "recently introduced" idea would be trivial to implement.  In
fact, here's an implementation:

(defgroup customizations-we-have-recently-introduced nil
  "A list of customizations introduced recently, by version of Emacs.

Each customization in this group has a value tagged \"classic\" to make it
easy for users to revert to older behavior after trying the new behavior and
deciding they do not like it."
  :version "23.2")

(defgroup introduced-in-version-23.2 nil
  "Customizations introduced in Emacs version 23.2."
  :group 'customizations-we-have-recently-introduced
  :version "23.2")

This implementation is obviously buggy, I seem to have forgotten some
members. :-)  But nevermind, the bugs can be fixed incrementally. :-)

"Reverting to classic Emacs" could be implemented approximately by
providing a toggle that returned all customizations on a page to the
pre-customizability values.  I say "approximately" because (1) it's
not clear that's what the user means by "classic behavior"; there are
probably some "obvious wins", and IMHO *the* classic behavior of Emacs
par excellance is to make it possible to incorporate obvious wins in
your own environment, easily and cleanly.  Reverting those blindly
would be unfortunate.  (2) Some of the new customizations don't have
values that correspond exactly to any "classic" Emacs.  (3) There will
be interactions, and disentangling those probably will require effort
on the part of the programmers of the feature implementations.

Re: line-move-visual

[Johan Myréen]

On Friday 10 July 2009 09:12:23 Stephen J. Turnbull wrote:

> Hey!  Not that way!  By attracting a New Generation of users who have
> never seen the "carriage" that "carriage return" refers to.  "What,
> were typewriters horse-powered?" ;-)

Ok, I seem to have stirred up some conversation here, and at the same time 
made me appear a grumpy old man. I hope to present more rational 
arguments in this message.

I still haven't quite figured out what the goal here is:

(1)  to keep the mental model of a buffer containing logical lines, but change 
the behaviour of C-n when moving within occasional continued lines

or

(2)  to move away from the "lines" model to a "paragraph" model, where there 
are no logical lines, but Emacs presents the paragraph using visual lines, 
like a word processor does

If (2) is the goal then ok, the behaviour of C-n makes sense. But you should 
go all the way and change the behaviour of C-a, C-e, C-k and probably a lot of 
other stuff too. You should also get rid of the continuation marks, and make 
the lines wrap at a more sensible place than the right edge of the window. 
Wrapping should also occur at word boundaries.

Also note that you can't completely get rid of the lines model: programming 
language source code files consist of (logical) lines. The above mentioned New 
Generation users who haven't seen the "carriage" still bang on their Carriage 
Return keys even in more modern environments than Emacs, like Eclipse or 
Visual Studio.

If (1) is the goal, I don't see how this change makes editing that much more 
convenient. Continued lines are normally quite rare, and I find movement by 
visual lines to be both nonintuitive and inconsistent with the behaviour of C-
a and C-e. (By the way, if the behaviour of C-e would be changed to respect 
visual lines, what would it do--move the insertion point _in front_ of the 
last character of the visual line?)

Johan Myreen

Re: line-move-visual

[Scot Becker]

@ Johan

Yes, thanks for stirring up this conversation.

I would have thought that 'the goal here' should be conceived as a
third option: making both linewise and paragraph-wise work possible,
each in its appropriate setting (or for the users who want it). In
coding, working linewise makes the most sense.  In writing natural
language texts, it's an unsemantic cludge, which we made work for a
while.  (We still need to output hardwrapped paragraphs for certain
purposes, but that can be a matter of export.)

It makes sense that many people want to see a dual default.  Code
should work linewise, unless you don't want it to, text should
soft-wrap (as with v-l-m), except when you don't want it to.  The
current default doesn't do that AFAIK, and you're not the only one
that doesn't like that.

So the introduction of visual-line-mode and line-move-visual is (I
don't think) intended to move towards any new mental model, but rather
to make a new one possible.  Exactly how the defaults are set up is a
separate matter.  Some (like me) will like a dual default, depending
on the mode.  Others will want consistent behaviour across modes.
Since the options will be there for either, we need ways to make it
easy for the user to identify what they want, where they want it, and
to understand any implications of their choices they may not easily
think of.  That can be done with good purpose-written documentation,
or with some kind of assisted settings modification mechanism like the
'custom' customize buffers which Lennnart has hacked up.

@Lennart,

I like it.  It could be a matter of my Emacs installation
(emacs-snapshot on ubuntu) but the Info link doesn't go through to
"Easy Customization", though I have the node.  Likewise the links to
the cua-mode function, give the error "You didn't specify a function."
 Otherwise, the new version seems like it would work for assembling
custom lists of settings for users to consider.

Thanks also for drawing our attention to
      (custom-add-to-group 'my-group 'my-variable 'custom-variable))
This seems like another way to accomplish something similar, if I'm
not mistaken.

Scot

Re: line-move-visual

[Miles Bader]

Please go read the past threads, all of the points you bring up have
been discussed before, at great length.

-Miles

-- 
Corporation, n. An ingenious device for obtaining individual profit without
individual responsibility.

Re: line-move-visual

[Bastien]

Johan Myréen <jem@iki.fi> writes:

> If (2) is the goal then ok, the behaviour of C-n makes sense. But you should 
> go all the way and change the behaviour of C-a, C-e, C-k and probably a lot of 
> other stuff too. You should also get rid of the continuation marks, and make 
> the lines wrap at a more sensible place than the right edge of the window. 
> Wrapping should also occur at word boundaries.

There are two problems: (1) the inconsistency you are pointing at
between C-n/C-p and C-a/C-e (Tassilo also mentioned this) and (2)
whether `line-move-visual' should default to nil.

Solving (1) would be good, and the two issues are independant.

-- 
 Bastien

Re: line-move-visual

[Miles Bader]

Bastien <bastienguerry@googlemail.com> writes:
> There are two problems: (1) the inconsistency you are pointing at
> between C-n/C-p and C-a/C-e (Tassilo also mentioned this) and (2)
> whether `line-move-visual' should default to nil.
>
> Solving (1) would be good, and the two issues are independant.

Please read the previous discussions.

The "C-n/C-p and C-a/C-e inconsistency" of the default settings is intentional.

Having used the current defaults for a fairly long period, and of course
"traditional" emacs for untold eons before that, I've come to the
conclusion that Chong made the right choice.

I get annoyed sometimes too by C-n/C-p's behavior -- but the traditional
behavior annoyed me _more_ often.  I think there is _no_ setting which
will please all people, or even one person all the time, but the current
compromise seems to be pretty decent.

I know some people will feel different "annoyance tradeoffs" than me,
but for those complaining about the change, I at least hope you've given
yourself some time to get used to it -- way too often, people seem to
fire off a flame about some change about 34 seconds after they've
installed the new version implementing it!

-Miles

-- 
Patience, n. A minor form of despair, disguised as a virtue.

Re: line-move-visual

[Kenichi Handa]

In article <87iqhzokpd.fsf@catnip.gol.com>, Miles Bader <miles@gnu.org> writes:

> The "C-n/C-p and C-a/C-e inconsistency" of the default settings is intentional.

> Having used the current defaults for a fairly long period, and of course
> "traditional" emacs for untold eons before that, I've come to the
> conclusion that Chong made the right choice.

> I get annoyed sometimes too by C-n/C-p's behavior -- but the traditional
> behavior annoyed me _more_ often.  I think there is _no_ setting which
> will please all people, or even one person all the time, but the current
> compromise seems to be pretty decent.

If we need two different operations, the normal way is to
use two different keys.

I'm using <up> and <down> (arrow keys) for visual line move,
and C-p and C-n for logical line move.  At least, this
setting please myself all the time.

I'm also using <C-left> and <C-right> for
beginning-of-visual-line and end-of-visual-line
respectively.  This is very convenient too.

---
Kenichi Handa
handa@m17n.org

Re: line-move-visual

[Miles Bader]

Kenichi Handa <handa@m17n.org> writes:
> I'm using <up> and <down> (arrow keys) for visual line move,
> and C-p and C-n for logical line move.  At least, this
> setting please myself all the time.

I actually used to do this myself -- I had my own "visual line move"
commands, bound to C-S-p / C-S-n.

However even that was annoying, mostly because since wrapped lines are
in fact, rare, I would almost always first do the wrong thing and then
have to correct it:  C-p, end up in the wrong place, curse, move back
down with C-n, and then visually move up again with C-S-p.

In other words, despite knowing about the issue and having my fingers
trained for over 20 years using traditional C-p, _still_ I would often
instinctively expect visual behavior.  It was a palpable relief when
Emacs adopted its current behavior.

-Miles

-- 
Guilt, n. The condition of one who is known to have committed an indiscretion,
as distinguished from the state of him who has covered his tracks.

Re: line-move-visual

[Bastien]

Miles Bader <miles@gnu.org> writes:

> Bastien <bastienguerry@googlemail.com> writes:
>> There are two problems: (1) the inconsistency you are pointing at
>> between C-n/C-p and C-a/C-e (Tassilo also mentioned this) and (2)
>> whether `line-move-visual' should default to nil.
>>
>> Solving (1) would be good, and the two issues are independant.
>
> Please read the previous discussions.
>
> The "C-n/C-p and C-a/C-e inconsistency" of the default settings is intentional.
>
> Having used the current defaults for a fairly long period, and of course
> "traditional" emacs for untold eons before that, I've come to the
> conclusion that Chong made the right choice.
>
> I get annoyed sometimes too by C-n/C-p's behavior -- but the traditional
> behavior annoyed me _more_ often.  I think there is _no_ setting which
> will please all people, or even one person all the time, but the current
> compromise seems to be pretty decent.
>
> I know some people will feel different "annoyance tradeoffs" than me,
> but for those complaining about the change, I at least hope you've given
> yourself some time to get used to it -- way too often, people seem to
> fire off a flame about some change about 34 seconds after they've
> installed the new version implementing it!

I don't read any argument against an official poll, and this is just
what I'm asking for.

PS: I've been using this default for a while.  Since I'm using a lot
of macros, I had to switch to (setq line-move-visual nil) because I
didn't to use M-x visual-line-mode to turn it off each time.

-- 
 Bastien

Re: line-move-visual

[Miles Bader]

Johan Myréen <jem@iki.fi> writes:
> Could somebody please explain to me what the idea behind the new concept of 
> "visual lines" in Emacs is?

To incite flames by infuriated users.

As a side-benefit of course, it's rather convenient.

-Miles
Emacs user since '83

-- 
Bacchus, n. A convenient deity invented by the ancients as an excuse for
getting drunk.

Re: line-move-visual

[Chong Yidong]

Johan Myréen <jem@iki.fi> writes:

> Please do not forget what Gnu Emacs stands for: Generally Not Used,
> Except by Middle-Aged Computer Scientists.  With changes like this you
> risk alienating the few of us that are left.

I think you misunderestimate the population of Emacs users.

Re: line-move-visual

[Andrey Paramonov]

Johan Myréen <jem <at> iki.fi> writes:
> Couldn't the default be nil instead of t?

I'm sure many users (especially younger ones ;-) would appreciate the idea of
Visual Lines mode. However, making it default would expose some current
usability problems, like this one:

http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=3695

From this point, you may wish to not enable the Visual Lines mode by default
until it matures (23.1 ?).

Andrey Paramonov

Re: line-move-visual

[Teemu Likonen]

On 2009-07-11 06:42 (UTC), Andrey Paramonov wrote:

> I'm sure many users (especially younger ones ;-) would appreciate the
> idea of Visual Lines mode. However, making it default would expose
> some current usability problems, like this one:
>
> http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=3695
>
> From this point, you may wish to not enable the Visual Lines mode by
> default until it matures (23.1 ?).

I think this discussion is mostly about variable line-move-visual.
Anyway, even though I like global line-move-visual=t indeed the feature
isn't completely mature yet. These both bugs appear only when
line-move-visual=t and are present in 23.0.96 and 23.1.50:

    "next-line and previous-line don't keep the column in text-scale-mode"
    http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=3668

    "Strange cursor movement in truncation mode"
    http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=3805