* line-move-visual @ 2009-07-09 18:12 Johan Myréen 2009-07-10 4:26 ` line-move-visual Bastien ` (3 more replies) 0 siblings, 4 replies; 59+ messages in thread From: Johan Myréen @ 2009-07-09 18:12 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-09 18:12 line-move-visual Johan Myréen @ 2009-07-10 4:26 ` Bastien 2009-07-10 4:43 ` line-move-visual Miles Bader 2009-07-10 6:12 ` line-move-visual Stephen J. Turnbull 2009-07-10 4:35 ` line-move-visual Miles Bader ` (2 subsequent siblings) 3 siblings, 2 replies; 59+ messages in thread From: Bastien @ 2009-07-10 4:26 UTC (permalink / raw) To: Johan Myréen; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-10 4:26 ` line-move-visual Bastien @ 2009-07-10 4:43 ` Miles Bader 2009-07-10 5:48 ` line-move-visual Bastien 2009-07-10 20:40 ` line-move-visual Richard Stallman 2009-07-10 6:12 ` line-move-visual Stephen J. Turnbull 1 sibling, 2 replies; 59+ messages in thread From: Miles Bader @ 2009-07-10 4:43 UTC (permalink / raw) To: Bastien; +Cc: Johan Myréen, emacs-devel 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-10 4:43 ` line-move-visual Miles Bader @ 2009-07-10 5:48 ` Bastien 2009-07-10 6:14 ` line-move-visual Kenichi Handa 2009-07-10 20:40 ` line-move-visual Richard Stallman 1 sibling, 1 reply; 59+ messages in thread From: Bastien @ 2009-07-10 5:48 UTC (permalink / raw) To: Miles Bader; +Cc: Johan Myréen, emacs-devel 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-10 5:48 ` line-move-visual Bastien @ 2009-07-10 6:14 ` Kenichi Handa 2009-07-10 6:58 ` line-move-visual Bastien 0 siblings, 1 reply; 59+ messages in thread From: Kenichi Handa @ 2009-07-10 6:14 UTC (permalink / raw) To: Bastien; +Cc: emacs-devel, jem, miles 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-10 6:14 ` line-move-visual Kenichi Handa @ 2009-07-10 6:58 ` Bastien 2009-07-10 8:13 ` line-move-visual Alfred M. Szmidt ` (2 more replies) 0 siblings, 3 replies; 59+ messages in thread From: Bastien @ 2009-07-10 6:58 UTC (permalink / raw) To: Kenichi Handa; +Cc: emacs-devel, jem, miles 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-10 6:58 ` line-move-visual Bastien @ 2009-07-10 8:13 ` Alfred M. Szmidt 2009-07-10 10:10 ` line-move-visual Bastien 2009-07-10 8:43 ` line-move-visual Scot Becker 2009-07-10 9:14 ` line-move-visual Tassilo Horn 2 siblings, 1 reply; 59+ messages in thread From: Alfred M. Szmidt @ 2009-07-10 8:13 UTC (permalink / raw) To: Bastien; +Cc: miles, emacs-devel, jem, handa Would it be posisble to do such a poll by email? ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-10 8:13 ` line-move-visual Alfred M. Szmidt @ 2009-07-10 10:10 ` Bastien 0 siblings, 0 replies; 59+ messages in thread From: Bastien @ 2009-07-10 10:10 UTC (permalink / raw) To: ams; +Cc: miles, emacs-devel, jem, handa "Alfred M. Szmidt" <ams@gnu.org> writes: > Would it be posisble to do such a poll by email? Sure. -- Bastien ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-10 6:58 ` line-move-visual Bastien 2009-07-10 8:13 ` line-move-visual Alfred M. Szmidt @ 2009-07-10 8:43 ` Scot Becker 2009-07-10 8:57 ` line-move-visual Eli Zaretskii 2009-07-10 15:56 ` line-move-visual Sean O'Rourke 2009-07-10 9:14 ` line-move-visual Tassilo Horn 2 siblings, 2 replies; 59+ messages in thread From: Scot Becker @ 2009-07-10 8:43 UTC (permalink / raw) To: Bastien; +Cc: miles, emacs-devel, jem, Kenichi Handa 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-10 8:43 ` line-move-visual Scot Becker @ 2009-07-10 8:57 ` Eli Zaretskii 2009-07-10 9:04 ` line-move-visual Lennart Borgman ` (4 more replies) 2009-07-10 15:56 ` line-move-visual Sean O'Rourke 1 sibling, 5 replies; 59+ messages in thread From: Eli Zaretskii @ 2009-07-10 8:57 UTC (permalink / raw) To: Scot Becker; +Cc: bastienguerry, emacs-devel, jem, handa, miles > 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-10 8:57 ` line-move-visual Eli Zaretskii @ 2009-07-10 9:04 ` Lennart Borgman 2009-07-10 10:32 ` line-move-visual Bastien 2009-07-10 9:08 ` line-move-visual Scot Becker ` (3 subsequent siblings) 4 siblings, 1 reply; 59+ messages in thread From: Lennart Borgman @ 2009-07-10 9:04 UTC (permalink / raw) To: Eli Zaretskii; +Cc: handa, emacs-devel, bastienguerry, jem, Scot Becker, miles 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-10 9:04 ` line-move-visual Lennart Borgman @ 2009-07-10 10:32 ` Bastien 0 siblings, 0 replies; 59+ messages in thread From: Bastien @ 2009-07-10 10:32 UTC (permalink / raw) To: Lennart Borgman Cc: handa, emacs-devel, Eli Zaretskii, jem, Scot Becker, miles 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-10 8:57 ` line-move-visual Eli Zaretskii 2009-07-10 9:04 ` line-move-visual Lennart Borgman @ 2009-07-10 9:08 ` Scot Becker 2009-07-10 9:13 ` line-move-visual joakim ` (2 subsequent siblings) 4 siblings, 0 replies; 59+ messages in thread From: Scot Becker @ 2009-07-10 9:08 UTC (permalink / raw) To: Eli Zaretskii; +Cc: bastienguerry, emacs-devel, jem, handa, miles 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. > ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-10 8:57 ` line-move-visual Eli Zaretskii 2009-07-10 9:04 ` line-move-visual Lennart Borgman 2009-07-10 9:08 ` line-move-visual Scot Becker @ 2009-07-10 9:13 ` joakim 2009-07-10 9:22 ` line-move-visual Scot Becker 2009-07-10 9:52 ` line-move-visual Miles Bader 2009-07-10 11:35 ` line-move-visual Stephen J. Turnbull 2009-07-10 15:43 ` line-move-visual Alfred M. Szmidt 4 siblings, 2 replies; 59+ messages in thread From: joakim @ 2009-07-10 9:13 UTC (permalink / raw) To: Eli Zaretskii; +Cc: handa, emacs-devel, bastienguerry, jem, Scot Becker, miles 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-10 9:13 ` line-move-visual joakim @ 2009-07-10 9:22 ` Scot Becker 2009-07-10 16:11 ` line-move-visual Drew Adams 2009-07-10 9:52 ` line-move-visual Miles Bader 1 sibling, 1 reply; 59+ messages in thread From: Scot Becker @ 2009-07-10 9:22 UTC (permalink / raw) To: joakim; +Cc: handa, emacs-devel, bastienguerry, Eli Zaretskii, jem, miles 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 > ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: line-move-visual 2009-07-10 9:22 ` line-move-visual Scot Becker @ 2009-07-10 16:11 ` Drew Adams 2009-07-10 16:22 ` line-move-visual Lennart Borgman 0 siblings, 1 reply; 59+ messages in thread From: Drew Adams @ 2009-07-10 16:11 UTC (permalink / raw) To: 'Scot Becker', joakim Cc: handa, emacs-devel, bastienguerry, 'Eli Zaretskii', jem, miles > 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.) ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-10 16:11 ` line-move-visual Drew Adams @ 2009-07-10 16:22 ` Lennart Borgman 2009-07-10 17:20 ` line-move-visual Drew Adams 0 siblings, 1 reply; 59+ messages in thread From: Lennart Borgman @ 2009-07-10 16:22 UTC (permalink / raw) To: Drew Adams Cc: handa, joakim, emacs-devel, bastienguerry, Eli Zaretskii, jem, Scot Becker, miles 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)) ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: line-move-visual 2009-07-10 16:22 ` line-move-visual Lennart Borgman @ 2009-07-10 17:20 ` Drew Adams 2009-07-10 17:40 ` line-move-visual Drew Adams 0 siblings, 1 reply; 59+ messages in thread From: Drew Adams @ 2009-07-10 17:20 UTC (permalink / raw) To: 'Lennart Borgman' Cc: handa, joakim, emacs-devel, bastienguerry, 'Eli Zaretskii', jem, 'Scot Becker', miles > >> 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: line-move-visual 2009-07-10 17:20 ` line-move-visual Drew Adams @ 2009-07-10 17:40 ` Drew Adams 0 siblings, 0 replies; 59+ messages in thread From: Drew Adams @ 2009-07-10 17:40 UTC (permalink / raw) To: 'Lennart Borgman' Cc: handa, joakim, emacs-devel, bastienguerry, 'Eli Zaretskii', jem, 'Scot Becker', miles > 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-10 9:13 ` line-move-visual joakim 2009-07-10 9:22 ` line-move-visual Scot Becker @ 2009-07-10 9:52 ` Miles Bader 2009-07-10 16:11 ` line-move-visual Drew Adams 1 sibling, 1 reply; 59+ messages in thread From: Miles Bader @ 2009-07-10 9:52 UTC (permalink / raw) To: joakim; +Cc: handa, emacs-devel, bastienguerry, Eli Zaretskii, jem, Scot Becker 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: line-move-visual 2009-07-10 9:52 ` line-move-visual Miles Bader @ 2009-07-10 16:11 ` Drew Adams 0 siblings, 0 replies; 59+ messages in thread From: Drew Adams @ 2009-07-10 16:11 UTC (permalink / raw) To: 'Miles Bader', joakim Cc: handa, emacs-devel, bastienguerry, 'Eli Zaretskii', jem, 'Scot Becker' > 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-10 8:57 ` line-move-visual Eli Zaretskii ` (2 preceding siblings ...) 2009-07-10 9:13 ` line-move-visual joakim @ 2009-07-10 11:35 ` Stephen J. Turnbull 2009-07-10 13:38 ` line-move-visual Eli Zaretskii 2009-07-10 13:56 ` line-move-visual Lennart Borgman 2009-07-10 15:43 ` line-move-visual Alfred M. Szmidt 4 siblings, 2 replies; 59+ messages in thread From: Stephen J. Turnbull @ 2009-07-10 11:35 UTC (permalink / raw) To: Eli Zaretskii; +Cc: handa, emacs-devel, bastienguerry, jem, Scot Becker, miles 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-10 11:35 ` line-move-visual Stephen J. Turnbull @ 2009-07-10 13:38 ` Eli Zaretskii 2009-07-10 16:11 ` line-move-visual Drew Adams 2009-07-11 19:34 ` line-move-visual Juri Linkov 2009-07-10 13:56 ` line-move-visual Lennart Borgman 1 sibling, 2 replies; 59+ messages in thread From: Eli Zaretskii @ 2009-07-10 13:38 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: bastienguerry, jem, scot.becker, emacs-devel > 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). ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: line-move-visual 2009-07-10 13:38 ` line-move-visual Eli Zaretskii @ 2009-07-10 16:11 ` Drew Adams 2009-07-10 18:01 ` line-move-visual Eli Zaretskii 2009-07-11 19:34 ` line-move-visual Juri Linkov 1 sibling, 1 reply; 59+ messages in thread From: Drew Adams @ 2009-07-10 16:11 UTC (permalink / raw) To: 'Eli Zaretskii', 'Stephen J. Turnbull' Cc: bastienguerry, jem, scot.becker, emacs-devel > 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'. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-10 16:11 ` line-move-visual Drew Adams @ 2009-07-10 18:01 ` Eli Zaretskii 2009-07-10 18:16 ` line-move-visual Drew Adams 0 siblings, 1 reply; 59+ messages in thread From: Eli Zaretskii @ 2009-07-10 18:01 UTC (permalink / raw) To: Drew Adams; +Cc: bastienguerry, stephen, jem, scot.becker, emacs-devel > 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: line-move-visual 2009-07-10 18:01 ` line-move-visual Eli Zaretskii @ 2009-07-10 18:16 ` Drew Adams 0 siblings, 0 replies; 59+ messages in thread From: Drew Adams @ 2009-07-10 18:16 UTC (permalink / raw) To: 'Eli Zaretskii' Cc: bastienguerry, stephen, jem, scot.becker, emacs-devel > > 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-10 13:38 ` line-move-visual Eli Zaretskii 2009-07-10 16:11 ` line-move-visual Drew Adams @ 2009-07-11 19:34 ` Juri Linkov 1 sibling, 0 replies; 59+ messages in thread From: Juri Linkov @ 2009-07-11 19:34 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel > 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/ ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-10 11:35 ` line-move-visual Stephen J. Turnbull 2009-07-10 13:38 ` line-move-visual Eli Zaretskii @ 2009-07-10 13:56 ` Lennart Borgman 2009-07-10 15:07 ` line-move-visual Scot Becker 1 sibling, 1 reply; 59+ messages in thread From: Lennart Borgman @ 2009-07-10 13:56 UTC (permalink / raw) To: Stephen J. Turnbull Cc: handa, emacs-devel, bastienguerry, Eli Zaretskii, jem, Scot Becker, miles [-- 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-10 13:56 ` line-move-visual Lennart Borgman @ 2009-07-10 15:07 ` Scot Becker 2009-07-10 20:29 ` line-move-visual Lennart Borgman 0 siblings, 1 reply; 59+ messages in thread From: Scot Becker @ 2009-07-10 15:07 UTC (permalink / raw) To: Lennart Borgman Cc: handa, emacs-devel, bastienguerry, Stephen J. Turnbull, jem, Eli Zaretskii, miles 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-10 15:07 ` line-move-visual Scot Becker @ 2009-07-10 20:29 ` Lennart Borgman 0 siblings, 0 replies; 59+ messages in thread From: Lennart Borgman @ 2009-07-10 20:29 UTC (permalink / raw) To: Scot Becker Cc: handa, emacs-devel, bastienguerry, Stephen J. Turnbull, jem, Eli Zaretskii, miles [-- 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-10 8:57 ` line-move-visual Eli Zaretskii ` (3 preceding siblings ...) 2009-07-10 11:35 ` line-move-visual Stephen J. Turnbull @ 2009-07-10 15:43 ` Alfred M. Szmidt 4 siblings, 0 replies; 59+ messages in thread From: Alfred M. Szmidt @ 2009-07-10 15:43 UTC (permalink / raw) To: Eli Zaretskii; +Cc: handa, emacs-devel, bastienguerry, jem, scot.becker, miles > 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? ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-10 8:43 ` line-move-visual Scot Becker 2009-07-10 8:57 ` line-move-visual Eli Zaretskii @ 2009-07-10 15:56 ` Sean O'Rourke 1 sibling, 0 replies; 59+ messages in thread From: Sean O'Rourke @ 2009-07-10 15:56 UTC (permalink / raw) To: emacs-devel 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) ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-10 6:58 ` line-move-visual Bastien 2009-07-10 8:13 ` line-move-visual Alfred M. Szmidt 2009-07-10 8:43 ` line-move-visual Scot Becker @ 2009-07-10 9:14 ` Tassilo Horn 2009-07-10 9:56 ` line-move-visual Miles Bader 2 siblings, 1 reply; 59+ messages in thread From: Tassilo Horn @ 2009-07-10 9:14 UTC (permalink / raw) To: Bastien; +Cc: miles, emacs-devel, jem, Kenichi Handa 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-10 9:14 ` line-move-visual Tassilo Horn @ 2009-07-10 9:56 ` Miles Bader 2009-07-10 10:22 ` line-move-visual Scot Becker 2009-07-10 10:36 ` line-move-visual Ulrich Mueller 0 siblings, 2 replies; 59+ messages in thread From: Miles Bader @ 2009-07-10 9:56 UTC (permalink / raw) To: Bastien; +Cc: Kenichi Handa, jem, emacs-devel 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] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-10 9:56 ` line-move-visual Miles Bader @ 2009-07-10 10:22 ` Scot Becker 2009-07-10 16:11 ` line-move-visual Drew Adams 2009-07-10 10:36 ` line-move-visual Ulrich Mueller 1 sibling, 1 reply; 59+ messages in thread From: Scot Becker @ 2009-07-10 10:22 UTC (permalink / raw) To: Miles Bader; +Cc: Bastien, emacs-devel, jem, Kenichi Handa 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: line-move-visual 2009-07-10 10:22 ` line-move-visual Scot Becker @ 2009-07-10 16:11 ` Drew Adams 0 siblings, 0 replies; 59+ messages in thread From: Drew Adams @ 2009-07-10 16:11 UTC (permalink / raw) To: 'Scot Becker', 'Miles Bader' Cc: 'Bastien', 'Kenichi Handa', jem, emacs-devel > 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-10 9:56 ` line-move-visual Miles Bader 2009-07-10 10:22 ` line-move-visual Scot Becker @ 2009-07-10 10:36 ` Ulrich Mueller 2009-07-10 10:56 ` line-move-visual Eli Zaretskii 1 sibling, 1 reply; 59+ messages in thread From: Ulrich Mueller @ 2009-07-10 10:36 UTC (permalink / raw) To: emacs-devel; +Cc: Bastien, Kenichi Handa, jem, Miles Bader There's another poll in the Gentoo forums: <http://forums.gentoo.org/viewtopic-t-779324.html> Ulrich ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-10 10:36 ` line-move-visual Ulrich Mueller @ 2009-07-10 10:56 ` Eli Zaretskii 2009-07-10 11:07 ` line-move-visual Christian Faulhammer 2009-07-10 11:29 ` line-move-visual Ulrich Mueller 0 siblings, 2 replies; 59+ messages in thread From: Eli Zaretskii @ 2009-07-10 10:56 UTC (permalink / raw) To: Ulrich Mueller; +Cc: miles, bastienguerry, handa, jem, emacs-devel > 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-10 10:56 ` line-move-visual Eli Zaretskii @ 2009-07-10 11:07 ` Christian Faulhammer 2009-07-10 11:29 ` line-move-visual Ulrich Mueller 1 sibling, 0 replies; 59+ messages in thread From: Christian Faulhammer @ 2009-07-10 11:07 UTC (permalink / raw) To: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-10 10:56 ` line-move-visual Eli Zaretskii 2009-07-10 11:07 ` line-move-visual Christian Faulhammer @ 2009-07-10 11:29 ` Ulrich Mueller 2009-07-10 18:15 ` line-move-visual Bastien 1 sibling, 1 reply; 59+ messages in thread From: Ulrich Mueller @ 2009-07-10 11:29 UTC (permalink / raw) To: Eli Zaretskii; +Cc: miles, bastienguerry, handa, jem, emacs-devel >>>>> 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-10 11:29 ` line-move-visual Ulrich Mueller @ 2009-07-10 18:15 ` Bastien 0 siblings, 0 replies; 59+ messages in thread From: Bastien @ 2009-07-10 18:15 UTC (permalink / raw) To: Ulrich Mueller; +Cc: miles, Eli Zaretskii, handa, jem, emacs-devel 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-10 4:43 ` line-move-visual Miles Bader 2009-07-10 5:48 ` line-move-visual Bastien @ 2009-07-10 20:40 ` Richard Stallman 2009-07-11 1:58 ` line-move-visual Stephen J. Turnbull 1 sibling, 1 reply; 59+ messages in thread From: Richard Stallman @ 2009-07-10 20:40 UTC (permalink / raw) To: Miles Bader; +Cc: bastienguerry, jem, emacs-devel 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-10 20:40 ` line-move-visual Richard Stallman @ 2009-07-11 1:58 ` Stephen J. Turnbull 2009-07-11 2:29 ` line-move-visual Miles Bader 0 siblings, 1 reply; 59+ messages in thread From: Stephen J. Turnbull @ 2009-07-11 1:58 UTC (permalink / raw) To: rms; +Cc: bastienguerry, emacs-devel, jem, Miles Bader 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-11 1:58 ` line-move-visual Stephen J. Turnbull @ 2009-07-11 2:29 ` Miles Bader 2009-07-11 2:44 ` line-move-visual Bastien 0 siblings, 1 reply; 59+ messages in thread From: Miles Bader @ 2009-07-11 2:29 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: bastienguerry, jem, rms, emacs-devel "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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-11 2:29 ` line-move-visual Miles Bader @ 2009-07-11 2:44 ` Bastien 2009-07-11 18:30 ` line-move-visual Richard Stallman 0 siblings, 1 reply; 59+ messages in thread From: Bastien @ 2009-07-11 2:44 UTC (permalink / raw) To: Miles Bader; +Cc: jem, rms, Stephen J. Turnbull, emacs-devel 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-11 2:44 ` line-move-visual Bastien @ 2009-07-11 18:30 ` Richard Stallman 0 siblings, 0 replies; 59+ messages in thread From: Richard Stallman @ 2009-07-11 18:30 UTC (permalink / raw) To: Bastien; +Cc: emacs-devel, jem, turnbull, miles - 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-10 4:26 ` line-move-visual Bastien 2009-07-10 4:43 ` line-move-visual Miles Bader @ 2009-07-10 6:12 ` Stephen J. Turnbull 2009-07-10 21:19 ` line-move-visual Johan Myréen 1 sibling, 1 reply; 59+ messages in thread From: Stephen J. Turnbull @ 2009-07-10 6:12 UTC (permalink / raw) To: Bastien; +Cc: Johan Myréen, emacs-devel 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-10 6:12 ` line-move-visual Stephen J. Turnbull @ 2009-07-10 21:19 ` Johan Myréen 2009-07-10 22:14 ` line-move-visual Scot Becker ` (2 more replies) 0 siblings, 3 replies; 59+ messages in thread From: Johan Myréen @ 2009-07-10 21:19 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-10 21:19 ` line-move-visual Johan Myréen @ 2009-07-10 22:14 ` Scot Becker 2009-07-11 1:34 ` line-move-visual Miles Bader 2009-07-11 2:46 ` line-move-visual Bastien 2 siblings, 0 replies; 59+ messages in thread From: Scot Becker @ 2009-07-10 22:14 UTC (permalink / raw) To: Johan Myréen; +Cc: Stephen J. Turnbull, emacs-devel @ 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-10 21:19 ` line-move-visual Johan Myréen 2009-07-10 22:14 ` line-move-visual Scot Becker @ 2009-07-11 1:34 ` Miles Bader 2009-07-11 2:46 ` line-move-visual Bastien 2 siblings, 0 replies; 59+ messages in thread From: Miles Bader @ 2009-07-11 1:34 UTC (permalink / raw) To: Johan Myréen; +Cc: Stephen J. Turnbull, emacs-devel 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-10 21:19 ` line-move-visual Johan Myréen 2009-07-10 22:14 ` line-move-visual Scot Becker 2009-07-11 1:34 ` line-move-visual Miles Bader @ 2009-07-11 2:46 ` Bastien 2009-07-11 5:25 ` line-move-visual Miles Bader 2 siblings, 1 reply; 59+ messages in thread From: Bastien @ 2009-07-11 2:46 UTC (permalink / raw) To: Johan Myréen; +Cc: Stephen J. Turnbull, emacs-devel 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-11 2:46 ` line-move-visual Bastien @ 2009-07-11 5:25 ` Miles Bader 2009-07-11 5:49 ` line-move-visual Kenichi Handa 2009-07-11 9:22 ` line-move-visual Bastien 0 siblings, 2 replies; 59+ messages in thread From: Miles Bader @ 2009-07-11 5:25 UTC (permalink / raw) To: Bastien; +Cc: Stephen J. Turnbull, Johan Myréen, emacs-devel 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-11 5:25 ` line-move-visual Miles Bader @ 2009-07-11 5:49 ` Kenichi Handa 2009-07-11 6:13 ` line-move-visual Miles Bader 2009-07-11 9:22 ` line-move-visual Bastien 1 sibling, 1 reply; 59+ messages in thread From: Kenichi Handa @ 2009-07-11 5:49 UTC (permalink / raw) To: Miles Bader; +Cc: bastienguerry, stephen, jem, emacs-devel 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-11 5:49 ` line-move-visual Kenichi Handa @ 2009-07-11 6:13 ` Miles Bader 0 siblings, 0 replies; 59+ messages in thread From: Miles Bader @ 2009-07-11 6:13 UTC (permalink / raw) To: Kenichi Handa; +Cc: bastienguerry, stephen, jem, emacs-devel 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-11 5:25 ` line-move-visual Miles Bader 2009-07-11 5:49 ` line-move-visual Kenichi Handa @ 2009-07-11 9:22 ` Bastien 1 sibling, 0 replies; 59+ messages in thread From: Bastien @ 2009-07-11 9:22 UTC (permalink / raw) To: Miles Bader; +Cc: Stephen J. Turnbull, Johan Myréen, emacs-devel 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-09 18:12 line-move-visual Johan Myréen 2009-07-10 4:26 ` line-move-visual Bastien @ 2009-07-10 4:35 ` Miles Bader 2009-07-10 13:31 ` line-move-visual Chong Yidong 2009-07-11 6:42 ` line-move-visual Andrey Paramonov 3 siblings, 0 replies; 59+ messages in thread From: Miles Bader @ 2009-07-10 4:35 UTC (permalink / raw) To: Johan Myréen; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-09 18:12 line-move-visual Johan Myréen 2009-07-10 4:26 ` line-move-visual Bastien 2009-07-10 4:35 ` line-move-visual Miles Bader @ 2009-07-10 13:31 ` Chong Yidong 2009-07-11 6:42 ` line-move-visual Andrey Paramonov 3 siblings, 0 replies; 59+ messages in thread From: Chong Yidong @ 2009-07-10 13:31 UTC (permalink / raw) To: Johan Myréen; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-09 18:12 line-move-visual Johan Myréen ` (2 preceding siblings ...) 2009-07-10 13:31 ` line-move-visual Chong Yidong @ 2009-07-11 6:42 ` Andrey Paramonov 2009-07-11 7:21 ` line-move-visual Teemu Likonen 3 siblings, 1 reply; 59+ messages in thread From: Andrey Paramonov @ 2009-07-11 6:42 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: line-move-visual 2009-07-11 6:42 ` line-move-visual Andrey Paramonov @ 2009-07-11 7:21 ` Teemu Likonen 0 siblings, 0 replies; 59+ messages in thread From: Teemu Likonen @ 2009-07-11 7:21 UTC (permalink / raw) To: Andrey Paramonov; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
end of thread, other threads:[~2009-07-11 19:34 UTC | newest] Thread overview: 59+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-07-09 18:12 line-move-visual Johan Myréen 2009-07-10 4:26 ` line-move-visual Bastien 2009-07-10 4:43 ` line-move-visual Miles Bader 2009-07-10 5:48 ` line-move-visual Bastien 2009-07-10 6:14 ` line-move-visual Kenichi Handa 2009-07-10 6:58 ` line-move-visual Bastien 2009-07-10 8:13 ` line-move-visual Alfred M. Szmidt 2009-07-10 10:10 ` line-move-visual Bastien 2009-07-10 8:43 ` line-move-visual Scot Becker 2009-07-10 8:57 ` line-move-visual Eli Zaretskii 2009-07-10 9:04 ` line-move-visual Lennart Borgman 2009-07-10 10:32 ` line-move-visual Bastien 2009-07-10 9:08 ` line-move-visual Scot Becker 2009-07-10 9:13 ` line-move-visual joakim 2009-07-10 9:22 ` line-move-visual Scot Becker 2009-07-10 16:11 ` line-move-visual Drew Adams 2009-07-10 16:22 ` line-move-visual Lennart Borgman 2009-07-10 17:20 ` line-move-visual Drew Adams 2009-07-10 17:40 ` line-move-visual Drew Adams 2009-07-10 9:52 ` line-move-visual Miles Bader 2009-07-10 16:11 ` line-move-visual Drew Adams 2009-07-10 11:35 ` line-move-visual Stephen J. Turnbull 2009-07-10 13:38 ` line-move-visual Eli Zaretskii 2009-07-10 16:11 ` line-move-visual Drew Adams 2009-07-10 18:01 ` line-move-visual Eli Zaretskii 2009-07-10 18:16 ` line-move-visual Drew Adams 2009-07-11 19:34 ` line-move-visual Juri Linkov 2009-07-10 13:56 ` line-move-visual Lennart Borgman 2009-07-10 15:07 ` line-move-visual Scot Becker 2009-07-10 20:29 ` line-move-visual Lennart Borgman 2009-07-10 15:43 ` line-move-visual Alfred M. Szmidt 2009-07-10 15:56 ` line-move-visual Sean O'Rourke 2009-07-10 9:14 ` line-move-visual Tassilo Horn 2009-07-10 9:56 ` line-move-visual Miles Bader 2009-07-10 10:22 ` line-move-visual Scot Becker 2009-07-10 16:11 ` line-move-visual Drew Adams 2009-07-10 10:36 ` line-move-visual Ulrich Mueller 2009-07-10 10:56 ` line-move-visual Eli Zaretskii 2009-07-10 11:07 ` line-move-visual Christian Faulhammer 2009-07-10 11:29 ` line-move-visual Ulrich Mueller 2009-07-10 18:15 ` line-move-visual Bastien 2009-07-10 20:40 ` line-move-visual Richard Stallman 2009-07-11 1:58 ` line-move-visual Stephen J. Turnbull 2009-07-11 2:29 ` line-move-visual Miles Bader 2009-07-11 2:44 ` line-move-visual Bastien 2009-07-11 18:30 ` line-move-visual Richard Stallman 2009-07-10 6:12 ` line-move-visual Stephen J. Turnbull 2009-07-10 21:19 ` line-move-visual Johan Myréen 2009-07-10 22:14 ` line-move-visual Scot Becker 2009-07-11 1:34 ` line-move-visual Miles Bader 2009-07-11 2:46 ` line-move-visual Bastien 2009-07-11 5:25 ` line-move-visual Miles Bader 2009-07-11 5:49 ` line-move-visual Kenichi Handa 2009-07-11 6:13 ` line-move-visual Miles Bader 2009-07-11 9:22 ` line-move-visual Bastien 2009-07-10 4:35 ` line-move-visual Miles Bader 2009-07-10 13:31 ` line-move-visual Chong Yidong 2009-07-11 6:42 ` line-move-visual Andrey Paramonov 2009-07-11 7:21 ` line-move-visual Teemu Likonen
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).