* 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ 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; 165+ 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] 165+ messages in thread
[parent not found: <alpine.OSX.2.00.1006031053170.77397@hsinghsing.panda.com>]
[parent not found: <hu925r$1b$1@north.jnrs.ja.net>]
[parent not found: <alpine.OSX.2.00.1006031431510.77397@hsinghsing.panda.com>]
* Re: line-move-visual [not found] ` <alpine.OSX.2.00.1006031431510.77397@hsinghsing.panda.com> @ 2010-06-04 7:59 ` Uday S Reddy [not found] ` <87pr07qjio.fsf@thinkpad.tsdh.de> 2010-06-04 17:52 ` line-move-visual Mark Crispin 2010-06-04 13:20 ` line-move-visual sable 1 sibling, 2 replies; 165+ messages in thread From: Uday S Reddy @ 2010-06-04 7:59 UTC (permalink / raw) To: help-gnu-emacs On 6/3/2010 11:11 PM, Mark Crispin wrote: > > I wasted hours trying to figure out what the hell was wrong with my > file, or my terminal emulator window, or my system. The fact that the > problem went away on a different system added further confusion. It was > only when I did ESC <n> CTRL/N and saw that it moved me the wrong number > of lines, but only on one system, that I realized that emacs changed. > And that's when I did ESC X describe-key CTRL/N and read about > line-mode-visual, although it did not mention that this was now the > default. > > Surprise. Grr. Having used Emacs for some 30 years myself, I always expect a few surprises with a new major version of Emacs. It takes me a few months to read through all the change logs and the new manual sections to become comfortable with all the new and changed features. Our sys admins realize that it takes time to get up to speed with a new version of Emacs, and generally install the new version along side the old version. They maintain the two for several months before removing the old version. Sometimes when there are significant new features, the old version just stays, because several users are uncomfortable with the new version. The good thing about free software is that you can do that! I would say your ire should be directed at your downstream distributions which don't seem to understand what a version change means to users. An Emacs major version upgrade should never be done as part of a "routine" update. They should never be installing Emacs without the news file. And, you can't assume that you can reliably use a new version without reading through the change log at least. Reading through the emacs-developers list yesterday, I also discovered that there is an Options -> Customize -> New Options menu, which asks you for an old version number and lists all the new options that have been added since then. That may be a good way to figure out what has changed. --- As I said before, the line-move-visual setting has been a complex decision for the developers. I have a virtual folder of "visual" messages from the emacs-developers list, which shows some 40+ threads over the last couple of years, with each one having been extremely contentious. I am still trying to figure out what it all means. It would help the rest of us if you could tell us what problem you ran into with the default setting of line-move-visual, and why it is important for what you do. Cheers, Uday ^ permalink raw reply [flat|nested] 165+ messages in thread
[parent not found: <87pr07qjio.fsf@thinkpad.tsdh.de>]
* Re: line-move-visual [not found] ` <87pr07qjio.fsf@thinkpad.tsdh.de> @ 2010-06-04 11:24 ` Uday S Reddy 2010-06-04 12:49 ` line-move-visual Tassilo Horn [not found] ` <hualdf$eln$1@north.jnrs.ja.net> 1 sibling, 1 reply; 165+ messages in thread From: Uday S Reddy @ 2010-06-04 11:24 UTC (permalink / raw) To: help-gnu-emacs On 6/4/2010 9:39 AM, Tassilo Horn wrote: > > For normal editing, I like visual-line-mode sometimes (for example when > working on a TeX document with colleagues, which write paragraphs one > one single line). With that, *all* motion commands operate on visual > lines. Its default is off. Just curiious. If they write whole paragraphs as lines, how do they do version control? Cheers, Uday ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-04 11:24 ` line-move-visual Uday S Reddy @ 2010-06-04 12:49 ` Tassilo Horn 2010-06-09 19:51 ` line-move-visual Joseph Brenner 0 siblings, 1 reply; 165+ messages in thread From: Tassilo Horn @ 2010-06-04 12:49 UTC (permalink / raw) To: help-gnu-emacs Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> writes: >> For normal editing, I like visual-line-mode sometimes (for example >> when working on a TeX document with colleagues, which write >> paragraphs one one single line). With that, *all* motion commands >> operate on visual lines. Its default is off. > > Just curiious. If they write whole paragraphs as lines, how do they > do version control? It's a good style to write short and to the point paragraphs. But still, the diffs are usually a bit larger than with hard line breaks. But on docs I write with hard breaks after 79 chars, my diffs are also bigger than they must be, cause I cannot refrain from pressing M-q when editing something in the middle of a paragraph. ;-) Anyway, when writing text I've never felt the need to use version control for anything except collaborative but sequential editing and backup. I can't even imagine forking some document, writing an "experimental" paragraph and merging that back to trunk some time later. ;-) Bye, Tassilo ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-04 12:49 ` line-move-visual Tassilo Horn @ 2010-06-09 19:51 ` Joseph Brenner 2010-06-09 20:22 ` line-move-visual Brendan Halpin 2010-06-10 1:23 ` line-move-visual Stefan Monnier 0 siblings, 2 replies; 165+ messages in thread From: Joseph Brenner @ 2010-06-09 19:51 UTC (permalink / raw) To: help-gnu-emacs Tassilo Horn <tassilo@member.fsf.org> writes: > Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> writes: > >>> For normal editing, I like visual-line-mode sometimes (for example >>> when working on a TeX document with colleagues, which write >>> paragraphs one one single line). With that, *all* motion commands >>> operate on visual lines. Its default is off. >> >> Just curiious. If they write whole paragraphs as lines, how do they >> do version control? > > It's a good style to write short and to the point paragraphs. But > still, the diffs are usually a bit larger than with hard line breaks. A subject I wonder about some times is why we don't have whitespace insensitive diffs. That one simple change could make the tab wars go away. > Anyway, when writing text I've never felt the need to use version > control for anything except collaborative but sequential editing and > backup. I can't even imagine forking some document, writing an > "experimental" paragraph and merging that back to trunk some time > later. ;-) Oddly enough, it seems that the features we use for code development are something like what Ted Nelson wanted for writing text back when he was first thinking about hypertext, Xanadu, etc. He really wanted "complex intercomparison" of multiple versions. I gather that he was envisioning a style of writing where you write a document in multiple possible ways, and then try to decide which one is best. This has never struck me as one of his better ideas... but on the other hand, wikipedia would be much less useable without it's history and diff features. ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-09 19:51 ` line-move-visual Joseph Brenner @ 2010-06-09 20:22 ` Brendan Halpin 2010-06-10 1:23 ` line-move-visual Stefan Monnier 1 sibling, 0 replies; 165+ messages in thread From: Brendan Halpin @ 2010-06-09 20:22 UTC (permalink / raw) To: help-gnu-emacs On Wed, Jun 09 2010, Joseph Brenner wrote: > A subject I wonder about some times is why we don't have whitespace > insensitive diffs. I know it's not the same, but I get great mileage out of "C-u M-x compare-windows", to say nothing of ediff. Brendan -- Brendan Halpin, Department of Sociology, University of Limerick, Ireland Tel: w +353-61-213147 f +353-61-202569 h +353-61-338562; Room F2-025 x 3147 mailto:brendan.halpin@ul.ie http://www.ul.ie/sociology/brendan.halpin.html ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-09 19:51 ` line-move-visual Joseph Brenner 2010-06-09 20:22 ` line-move-visual Brendan Halpin @ 2010-06-10 1:23 ` Stefan Monnier 1 sibling, 0 replies; 165+ messages in thread From: Stefan Monnier @ 2010-06-10 1:23 UTC (permalink / raw) To: help-gnu-emacs > A subject I wonder about some times is why we don't have whitespace > insensitive diffs. You might want to try the diff-refine-hunk command, or to set diff-auto-refine-mode to t. I wrote this while working on LaTeX documents where diffs tend to be difficult to read because of all the refilling. It won't "simplify" the diff in any sense, but it will highlight the words that have been added/changed/removed which is not bad. Of course, ediff gives you similar results, so if you like ediff's interface that's another option (I personally find ediff a bit too heavyweight, so I only use it for particular circumstances, but otherwise prefer smerge-mode and diff-mode to look at changes and handle merges). Stefan ^ permalink raw reply [flat|nested] 165+ messages in thread
[parent not found: <hualdf$eln$1@north.jnrs.ja.net>]
* Re: line-move-visual [not found] ` <hualdf$eln$1@north.jnrs.ja.net> @ 2010-06-04 13:00 ` Tassilo Horn 2010-06-04 14:51 ` line-move-visual Stefan Monnier [not found] ` <871vcmhq79.fsf@wivenhoe.ul.ie> 0 siblings, 2 replies; 165+ messages in thread From: Tassilo Horn @ 2010-06-04 13:00 UTC (permalink / raw) To: help-gnu-emacs Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> writes: >> With line-move-visual set to t (the default), only vertical motion >> commands use visual lines, but for example C-a / C-e still use >> logical lines. From my point of view, that's a silly compromise. > > Agreed. That means that line-move-visual is not doing what it says on > the box. I don't see a compelling reason why C-n and C-p should move > by "visual lines" outside of visual-line-mode. Perhaps it was a bad > idea. I remember that people (including RMS) tested line-move-visual and concluded that this is ok, but full visual-line-mode would be too radical. > In the emacs-developers list, I see that line-move-visual came first > and visual-line-mode was invented later. I'm not completely sure about that. >> But all visual line behavior break keyboard macros. Define a macro, >> then change your window size (so that lines are differently visually >> wrapped), and *bang* your macro messes up your text. It's semantics >> change with the frame/window size. That's silly. > > If these macros are dealing with visual-line-mode then I wonder what > yo do that is sensitive to the line length. > > If they are dealing with normal text with line breaks, then perhaps > all that you need to do is to use forward-line instead of next-line? Well, the save solution is to enable `truncate-lines' (M-x toggle-truncate-lines) before defining and executing a keyboard macro. Then lines aren't wrapped, and there's no difference between logical and visual lines anymore. IMO, that should be done automatically. But others argue, that a keyboard macro should act exactly as doing the same stuff manually. Then it's correct that a macro executed with VLM on or line-move-visual set to t behaves differently depending on how text is visualized, which includes window width, font size and other pitfalls you haven' thought about... Bye, Tassilo ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-04 13:00 ` line-move-visual Tassilo Horn @ 2010-06-04 14:51 ` Stefan Monnier 2010-06-04 20:53 ` line-move-visual Tassilo Horn [not found] ` <871vcmhq79.fsf@wivenhoe.ul.ie> 1 sibling, 1 reply; 165+ messages in thread From: Stefan Monnier @ 2010-06-04 14:51 UTC (permalink / raw) To: help-gnu-emacs > IMO, that should be done automatically. But others argue, that a > keyboard macro should act exactly as doing the same stuff manually. Then There's a tension here, indeed: OT1H keyboard macros only record a sequence of keys, so they should really be equivalent to having the user hit the same keys in the same order, but OTOH they correspond to mechanical execution, i.e. to code, so they need simple&reliable semantics in order to work well. As Emacs commands tend to get more complex over time (more DWIMish, usually), we have more cases of commands that should really only ever be used interactively because they require the user to see the result before making the next step. This tension for keyboard macros is made evident if you ever try to turn a keyboard macro into a piece of Elisp code. A job which would seem simple enough that a little Elisp package could do it for you, right? I would encourage people to try and write up a new keyboard-macro package which would be closer to writing Elisp code: instead of recording keys, it would record commands, and would do so in a submode where DWIMish things (line-move-visual, abbrev-mode, auto-fill-mode, ... you name it) are disabled. Stefan ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-04 14:51 ` line-move-visual Stefan Monnier @ 2010-06-04 20:53 ` Tassilo Horn 0 siblings, 0 replies; 165+ messages in thread From: Tassilo Horn @ 2010-06-04 20:53 UTC (permalink / raw) To: help-gnu-emacs Stefan Monnier <monnier@iro.umontreal.ca> writes: Hi Stefan, > I would encourage people to try and write up a new keyboard-macro > package which would be closer to writing Elisp code: instead of > recording keys, it would record commands, and would do so in a submode > where DWIMish things (line-move-visual, abbrev-mode, auto-fill-mode, > ... you name it) are disabled. Sounds like a very good idea. But for the time being, it would be a good to have some before/after-kbd-macro-hooks that one could use to prepare a safe environment and switch back to whatever was before. Bye, Tassilo ^ permalink raw reply [flat|nested] 165+ messages in thread
[parent not found: <871vcmhq79.fsf@wivenhoe.ul.ie>]
[parent not found: <hub2ss$is4$1@north.jnrs.ja.net>]
* Re: line-move-visual [not found] ` <hub2ss$is4$1@north.jnrs.ja.net> @ 2010-06-04 14:45 ` Brendan Halpin 0 siblings, 0 replies; 165+ messages in thread From: Brendan Halpin @ 2010-06-04 14:45 UTC (permalink / raw) To: help-gnu-emacs On Fri, Jun 04 2010, Uday S Reddy wrote: > The visual-line-mode is supposed to be more general, and is meant to replace the longlines-mode eventually. Interesting. Using window-width to determine where to word-wrap seems arguably more consistent with other software than using fill-column, but I have to say I prefer the latter. Brendan -- Brendan Halpin, Department of Sociology, University of Limerick, Ireland Tel: w +353-61-213147 f +353-61-202569 h +353-61-338562; Room F2-025 x 3147 mailto:brendan.halpin@ul.ie http://www.ul.ie/sociology/brendan.halpin.html ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual [not found] ` <871vcmhq79.fsf@wivenhoe.ul.ie> [not found] ` <hub2ss$is4$1@north.jnrs.ja.net> @ 2010-06-04 17:49 ` Xah Lee 2010-06-04 18:18 ` line-move-visual Mark Crispin 1 sibling, 1 reply; 165+ messages in thread From: Xah Lee @ 2010-06-04 17:49 UTC (permalink / raw) To: help-gnu-emacs On Jun 4, 6:39 am, brendan.hal...@ul.ie (Brendan Halpin) wrote: > Attempted thread-jack: why use visual-line-mode instead of > longlines-mode? longlines-mode has serious bugs, i believe still so even i haven't used it since emacs 23.1 a year or 2 ago. basically, whenever large chunk of text is inserted or removed in a buffer (either manually, or sometimes automatically by commands such as patch and version control etc), then the text will be screwed up... missing parts or something i forgot. there are 1 or more bug reports of it in emacs bug track. If i recall correctly, the situation is that it's hard to fix, because longlines- mode was a hack for lack of visual line move, and i think it is done by basically just inserting line-breaks in the background but display and save it otherwise. (i haven't actually looked at the code though) the visual line move feature is a critical feature in emacs. Before emacs 23, there are a few packages or code that tries to introduce the visual line move feature (see emacswiki), and longlines-mode is one of them. However, because it is such a fundamental feature, it is hard for a 3rd-party elisp package to get it correct. They all have major problems... i think Emacs 23.2's move by visual line feature is great because: • it fixed a frequently asked feature. (e.g. i think ALL editors/IDEs after mid 1990s, move by visual line ) • it fixed a issue that 3rd party elisp packages cannot address well. Btw, who actually coded the visual line mode? I can't find the info. I like to document it in my emacs pages. -------------------------------------------------- Personally, i find moving by visual line is not just a good feature, but a critical one, with consequences that effect the evolution of language design and thinking, long term. The hard-coded lines is fundamentally introduced by unix and C gang, and brain damaged a whole generation of coders. I've written about 7 essays addressing this point in the past 10 years. See: • Xah on Programing Languages http://xahlee.org/Periodic_dosage_dir/comp_lang.html See the articles under the Formatting section. Each of these is written in a different context, but they essentially discuss the same thing. That is, the importance of separating appearance/formatting from semantic or logical structure. Here's a synapses on how each article relates to the line move visual issue. ------------------------------ • The Harm of Hard-wrapping Lines http://xahlee.org/UnixResource_dir/writ/hard-wrap.html A introduction. (written as a diatribe ) ------------------------------ • Tabs versus Spaces in Source Code http://xahlee.org/UnixResource_dir/writ/tabs_vs_spaces.html introduces the idea as semantic based formatting vs hard-coded formatting. ------------------------------ • Plain-Text Email Fetish http://xahlee.org/UnixResource_dir/writ/plain_text.html • Unix, RFC, and Line Truncation http://xahlee.org/UnixResource_dir/writ/truncate_line.html Shows some connection of the hard-coded habit from unix. ------------------------------ • A Simple Lisp Code Formatter http://xahlee.org/emacs/lisp_formatter.html A example of what actually can happen when hard-coded formatting hasn't become the conventional thought. ------------------------------ • A Text Editor Feature: Extend Selection By Semantic Unit http://xahlee.org/emacs/syntax_tree_walk.html Another example of what could happen if unix didn't made people to think about hard-coded short lines. ------------------------------ • Fundamental Problems of Lisp http://xahlee.org/UnixResource_dir/writ/lisp_problems.html Half of the essay, discuss the above issues with respect to lisp the language, and consequences. Xah ∑ http://xahlee.org/ ☄ ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-04 17:49 ` line-move-visual Xah Lee @ 2010-06-04 18:18 ` Mark Crispin 2010-06-04 19:19 ` line-move-visual Xah Lee 0 siblings, 1 reply; 165+ messages in thread From: Mark Crispin @ 2010-06-04 18:18 UTC (permalink / raw) To: help-gnu-emacs On Fri, 4 Jun 2010, Xah Lee posted: > Personally, i find moving by visual line is not just a good feature, > but a critical one, with consequences that effect the evolution of > language design and thinking, long term. The hard-coded lines is > fundamentally introduced by unix and C gang, and brain damaged a whole > generation of coders. This is why UNIX and C accomplish things. They were based upon accomplishing something useful rather than promoting an ideology. It sounds like Microsoft Word is more suitable for the sort of work that you do. Perhaps you ought to use Word instead of seeking to make emacs become more like Word. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-04 18:18 ` line-move-visual Mark Crispin @ 2010-06-04 19:19 ` Xah Lee [not found] ` <alpine.OSX.2.00.1006041829210.77397@hsinghsing.panda.com> 0 siblings, 1 reply; 165+ messages in thread From: Xah Lee @ 2010-06-04 19:19 UTC (permalink / raw) To: help-gnu-emacs hi Mark Crispin, On Jun 4, 11:18 am, Mark Crispin <m...@panda.com> wrote: > This is why UNIX and C accomplish things. They were based upon > accomplishing something useful rather than promoting an ideology. maybe you shouldn't use emacs? Emacs is main part of GNU's Not Unix, and the whole lisp culture and thinking is contrary to unix and C. > It sounds like Microsoft Word is more suitable for the sort of work that > you do. Perhaps you ought to use Word instead of seeking to make emacs > become more like Word. speaking of Microsoft Word, i wait for dinosaurs like u to die. The question is, can we recruit enough new generation of coders to emacs fast enough before emacs extinguishes. LOL! Xah ∑ http://xahlee.org/ ☄ ^ permalink raw reply [flat|nested] 165+ messages in thread
[parent not found: <alpine.OSX.2.00.1006041829210.77397@hsinghsing.panda.com>]
[parent not found: <089883ee-0a63-4cb4-a0ec-d2fe4e71cc03@y18g2000prn.googlegroups.com>]
* Re: line-move-visual [not found] ` <089883ee-0a63-4cb4-a0ec-d2fe4e71cc03@y18g2000prn.googlegroups.com> @ 2010-06-06 9:53 ` Uday S Reddy 2010-06-06 9:39 ` line-move-visual David Kastrup 0 siblings, 1 reply; 165+ messages in thread From: Uday S Reddy @ 2010-06-06 9:53 UTC (permalink / raw) To: help-gnu-emacs On 6/5/2010 11:28 PM, Xah Lee wrote: > I respect your recognized contribution to humanity as a computer > programer. However, not sure if you are aware, that i've argued with > well known emacs and lisp old timers for the past 10 years Thank God that some civility has returned to this thread! > to argue, first let's be precise what we are arguing about. Here's few > points: > > • emacs 23's introduction of line-move-visual feature is good (or > bad). > > • emacs 23's default of line-move-visual t good (or bad) > > • the very concep of move by screen line is good (or bad). No, I don't think that these are the questions that this debate is about. (When we start debating what the debate is about, we should realize that we are hopelessly knotted up in circles!) Emacs 23 has a *visual line mode* and a *logical line mode* (the default mode that you have whenever the visual-line-mode is /not/ turned on). Everybody understands and expects that C-n moves by visual line in the visual line mode. The question is, do you want it to move by visual line or logical line in the *logical line mode*? Let me repeat: do you want C-n to move by visual line or logical in the *logical line mode*? In the megabytes of debate that has gone on on this issue, I haven't seen a single point mentioned as to why it should move by visual line in the logical line mode. Yet, that is the default in Emacs 23! Worse, it *changes* the semantics of C-n which as, Mark Crispin points out, has been here the 70's. So, there are three things that an old-timer is annoyed about: 1. Change of established semantics. 2. Inconsistency. 3. Pointlessness. Coupled with these real technical issues, there are the attitudinal problems of holier-than-thou, smarter-than-thou and modern-than-thou and what have you. In another part of this thread, we have also seen the astonishing idea that the developers don't have to care about what the users want/need. If that is the attitude that open source developers take, then I will be the first to give up open source! Cheers, Uday ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-06 9:53 ` line-move-visual Uday S Reddy @ 2010-06-06 9:39 ` David Kastrup [not found] ` <hug5rv$6d2$1@north.jnrs.ja.net> ` (2 more replies) 0 siblings, 3 replies; 165+ messages in thread From: David Kastrup @ 2010-06-06 9:39 UTC (permalink / raw) To: help-gnu-emacs Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> writes: > Coupled with these real technical issues, there are the attitudinal > problems of holier-than-thou, smarter-than-thou and modern-than-thou > and what have you. Everybody is free to join the discussions on the Emacs developer lists. Those who choose not to help with the work don't get to criticize the results. A common democratic principle. > In another part of this thread, we have also seen the astonishing idea > that the developers don't have to care about what the users > want/need. If that is the attitude that open source developers take, > then I will be the first to give up open source! An excellent idea. The Free Software Foundation cares principally about free software, not open source. Open source sports the notion of creating superior software by significantly different processes than common. Free software is based on the premise of empowering the recipient of software to change and adapting it according to his own needs. Pampering to the needs of users who are not interested in changing and adapting the software according to their needs is not a major priority. Feel free to fork any free software which does not behave like you want it: you have the power. You are not dependent on upstream developers. If you tie yourself to distribution channels that take this power from you effectively, you are doing it by choice. If you think you are in a suitable majority, tell your distribution channel to change the upstream decision for you if you don't feel like discussing this in a civilized manner on the developer discussion lists created for that purpose. -- David Kastrup ^ permalink raw reply [flat|nested] 165+ messages in thread
[parent not found: <hug5rv$6d2$1@north.jnrs.ja.net>]
* Re: line-move-visual [not found] ` <hug5rv$6d2$1@north.jnrs.ja.net> @ 2010-06-06 15:21 ` Tassilo Horn 2010-06-07 8:19 ` line-move-visual Uday S Reddy 2010-06-06 15:43 ` line-move-visual Alain Ketterlin ` (2 subsequent siblings) 3 siblings, 1 reply; 165+ messages in thread From: Tassilo Horn @ 2010-06-06 15:21 UTC (permalink / raw) To: help-gnu-emacs Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> writes: Hi Uday, > In this particular instance, the customization needed is not a big > deal: set line-move-visual to nil. Almost everybody can do it. But > the time they had to spend in discovering that they needed to change > it is what has been significant. IMO, the first thing a new emacs user should learn is using the help facilities. So after seeing that `C-n' moved point not to the next (logical) line as it always did should be a reflexive `C-h C-n': ,----[ C-h k C-n ] | C-n runs the command next-line, which is an interactive compiled Lisp function | in `simple.el'. | | It is bound to C-n, <down>. | | (next-line &optional ARG TRY-VSCROLL) | | Move cursor vertically down ARG lines. | [...] | If the variable `line-move-visual' is non-nil, this command moves | by display lines. Otherwise, it moves by buffer lines, without | taking variable-width characters or continued lines into account. | [...] | | If you are thinking of using this in a Lisp program, consider | using `forward-line' instead. It is usually easier to use | and more reliable (no dependence on goal column, etc.). `---- > (In fact, after this thread started, I began to wonder if VM might be > vulnerable to the problem as well, and went and checked if there were > calls to next-line anywhere. There were three of them!) As you can see in the docs above, `next-line' wasn't the right function to call from lisp even before visual line movement. > By the way, I think that the Emacs 23 visual-line-mode and word > wrapping are a great addition to Emacs. A civilized way of dealing > with longlines has long been needed. But the default setting of > line-move-visual is an independent issue to that. I agree with all of that. Bye, Tassilo ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-06 15:21 ` line-move-visual Tassilo Horn @ 2010-06-07 8:19 ` Uday S Reddy [not found] ` <m2fx0z46wj.fsf@gmail.com> 0 siblings, 1 reply; 165+ messages in thread From: Uday S Reddy @ 2010-06-07 8:19 UTC (permalink / raw) To: help-gnu-emacs On 6/6/2010 4:21 PM, Tassilo Horn wrote: >> In this particular instance, the customization needed is not a big >> deal: set line-move-visual to nil. Almost everybody can do it. But >> the time they had to spend in discovering that they needed to change >> it is what has been significant. > > IMO, the first thing a new emacs user should learn is using the help > facilities. So after seeing that `C-n' moved point not to the next > (logical) line as it always did should be a reflexive `C-h C-n': Note that we are talking about the old emacs users, not the new ones. (The C-n compromise was apparently made to help the new Emacs users!) An old emacs user might see a long logical line only very rarely, and he might take quite a while to realize that anything had changed. As Mark Crispin explained, he had to purposefully go looking for it by doing M-<large number> C-n on a number of Emacs versions to discover that something had changed. I had to hear of Mark's experience before I started suspecting that there could be vulnerabilities in VM. (I accept that using `next-line' in elisp code is not a clever thing to do, but we live in the world of "free software" where lots of people contribute.) How much elisp code might still be there that has this vulnerability? We won't know. Just as an experiment, I went to the emacs-23.2 lisp directory and did a grep for next-line. There were 91 hits. How many of them are safe? I myself noticed the changed C-n very quickly because I work with Emacs debugger a lot, where long lines are common. First I thought it was kind of cute, then I got annoyed because I had to find new ways of skipping over bytecode pieces that span lots of lines, and now I am alarmed as I think of the vulnerabilities that might exist in elisp code. If I used keyboard macros a whole lot (which I don't), then I would have been even more affected. However, it didn't occur to me that I could freely set `line-move-visual' to nil and all the problems would disappear. I thought that the setting was probably mixed up with word wrapping and visual-line-mode and all that stuff that I care about. It was only after Stefan himself said: "Yes, it's inconsistent, yes, it's a compromise, no not everybody likes it. Then (setq line-move-visual nil) in your .emacs and live happily ever after." ... only then did I understand that the emacs devs had done a completely pointless thing that I could easily revert. Cheers, Uday ^ permalink raw reply [flat|nested] 165+ messages in thread
[parent not found: <m2fx0z46wj.fsf@gmail.com>]
* Re: line-move-visual [not found] ` <m2fx0z46wj.fsf@gmail.com> @ 2010-06-07 16:20 ` Stefan Monnier 0 siblings, 0 replies; 165+ messages in thread From: Stefan Monnier @ 2010-06-07 16:20 UTC (permalink / raw) To: help-gnu-emacs > The byte-compiler already warns about uses of next-line because it > rarely makes sense to use next-line in lisp code anyway (forward-line is > usually more appropriate, especially for parsing). So it's very likely > that the remaining occurrences have been inspected by developers very > carefully. Not sure about "very" since we've had some bug reports after the warnings were fixed, but yes. BTW my grep only finds 22 occurrences (in Emacs trunk rather 23.2, but the difference should be small). Stefan ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual [not found] ` <hug5rv$6d2$1@north.jnrs.ja.net> 2010-06-06 15:21 ` line-move-visual Tassilo Horn @ 2010-06-06 15:43 ` Alain Ketterlin 2010-06-07 21:30 ` line-move-visual Joost Kremers 2010-06-06 18:17 ` line-move-visual Mark Crispin 2010-06-07 8:46 ` line-move-visual Tim X 3 siblings, 1 reply; 165+ messages in thread From: Alain Ketterlin @ 2010-06-06 15:43 UTC (permalink / raw) To: help-gnu-emacs Sorry to break the thread, but... The message I'm following up to has been sent from Thunderbird with format=flowed, i.e., it contains very long lines, much longer than the usual 80-column text. It's painful to read, cite in replies, etc. Is there any way to make gnus reformat such messages to make them fit the standard Usenet width? My current gnus config is the absolute minimum. Any help is welcome, even if it takes the form of a few keywords to help me search the doc. Thanks, -- Alain. P/S: I've removed comp.lang.lisp from the Newsgroups: ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-06 15:43 ` line-move-visual Alain Ketterlin @ 2010-06-07 21:30 ` Joost Kremers 0 siblings, 0 replies; 165+ messages in thread From: Joost Kremers @ 2010-06-07 21:30 UTC (permalink / raw) To: help-gnu-emacs Alain Ketterlin wrote: > The message I'm following up to has been sent from Thunderbird with > format=flowed, i.e., it contains very long lines, much longer than the > usual 80-column text. It's painful to read, cite in replies, etc. then that's not actually format=flowed. format=flowed means that the text is still wrapped, but each line ends in a space followed by a newline. the receiving client can then choose to reformat the message. But paragraphs without line breaks (i.e., unwrapped) is *not* format=flowed. -- Joost Kremers joostkremers@yahoo.com Selbst in die Unterwelt dringt durch Spalten Licht EN:SiS(9) ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual [not found] ` <hug5rv$6d2$1@north.jnrs.ja.net> 2010-06-06 15:21 ` line-move-visual Tassilo Horn 2010-06-06 15:43 ` line-move-visual Alain Ketterlin @ 2010-06-06 18:17 ` Mark Crispin [not found] ` <4C0C466E.3000803@thadlabs.com> 2010-06-07 8:46 ` line-move-visual Tim X 3 siblings, 1 reply; 165+ messages in thread From: Mark Crispin @ 2010-06-06 18:17 UTC (permalink / raw) To: help-gnu-emacs On Sun, 6 Jun 2010, Uday S Reddy posted: > In this particular instance, the customization needed is not a big deal: set > line-move-visual to nil. Almost everybody can do it. But the time they had > to spend in discovering that they needed to change it is what has been > significant. An additional significant burden is the need to update .emacs files on dozens of machines in order to keep common functionality. There is a huge scalability problem. There are things that you can do to avoid 2^n synchronization, such as designating one system as having the "master" copy from which all others are updated. But then, each time you encounter a problem on a "slave" that necessitates a change to the slave, you must: [1] make the corresponding change to the master [2] test on the master [3] test on at least one other slave [4] push the update from the master to all other slaves The fun and laughter proceeds apace if you don't have access to the master at that point of time. Then you have to make a note that you needed this change, and subsequently find that note when you can get to the master again. And all this presumes that it's a set that is harmless in old versions. The true joy comes in when the change has an unintended bad effect in some other slave and you didn't catch it in step [3]. The best case wastes a great deal of time, repeated for each affected user. The worst case is a nightmare. Part of the maturing process is learning to recognize when a simple cookbook solution is neither simple nor cookbook nor solution. > (In fact, after this thread started, I began to wonder if VM > might be vulnerable to the problem as well, and went and checked if there > were calls to next-line anywhere. There were three of them!) I hope that you didn't have any corrupted files as a result. > It is not for nothing that we have ideas like standards and > backward-compatibility. It didn't seem to me that the discussion on the > developers list showed much appreciation to these issues, despite them having > been raised repeatedly. A clueless developer is a very bad thing. > By the way, I think that the Emacs 23 visual-line-mode and word wrapping are > a great addition to Emacs. A civilized way of dealing with longlines has > long been needed. But the default setting of line-move-visual is an > independent issue to that. Let me be clear; I have no objection whatsoever to the feature having been added and made available. The issue is it having been made the default, particularly in modes where it is pointless. It is also important to realize that there are many editors that handle long lines in a "civilized" way. However, in certain circumstances, it is desirable and necessary to handle long lines the "uncivilized" way; and it is a feature of emacs that it can do that. No amount of raving about how the "civilized" way is better will change those circumstances. The only effect of enforcing the "civilized" way is to render emacs unsuitable for those applications. For example, I have a scripted procedure which depends upon emacs' "uncivilized" behavior. It is followed by individuals who never use emacs for any other reason. I have no control over what version they use, but that had always been alright since every program that ever called itself emacs worked the same way with it. Until now. I don't know what I'm going to about that procedure. I'm probably going to have to write a program and/or a sed script to replace it. This is unfortunate, since an advantage of the emacs method was that the user could see what the procedure was doing. All because of clueless developers who broke emacs in version 23. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. ^ permalink raw reply [flat|nested] 165+ messages in thread
[parent not found: <4C0C466E.3000803@thadlabs.com>]
* Re: line-move-visual [not found] ` <4C0C466E.3000803@thadlabs.com> @ 2010-06-07 2:53 ` Mark Crispin 0 siblings, 0 replies; 165+ messages in thread From: Mark Crispin @ 2010-06-07 2:53 UTC (permalink / raw) To: help-gnu-emacs On Sun, 6 Jun 2010, Thad Floryan posted: > This is OT so I'll keep it short. Similar braindamage recently with > Fedora where a developer stated "I don't particularly care how UNIX > has always worked." Wow. I've dealt with broken "improvements" in RedHat/Fedora before; they don't seem to have a very good review process for functionality changes. The two that I remember the most are making flock() return ENOLCK for an NFS file (instead of no-op) and getaddrinfo() doing a reverse DNS lookup for the ai_canonname return value. In both cases, the developer insisted that the change was a "fix", never mind all the applications that were broken by it. Eventually, both of these changes were reverted after a huge hue and cry. This one takes the cake. I don't know which amazes me more, the fact that such an ill-conceived change was made in the first place, or the developer's reaction when called to account. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual [not found] ` <hug5rv$6d2$1@north.jnrs.ja.net> ` (2 preceding siblings ...) 2010-06-06 18:17 ` line-move-visual Mark Crispin @ 2010-06-07 8:46 ` Tim X 2010-06-07 16:23 ` line-move-visual Stefan Monnier 3 siblings, 1 reply; 165+ messages in thread From: Tim X @ 2010-06-07 8:46 UTC (permalink / raw) To: help-gnu-emacs Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> writes: > On 6/6/2010 10:39 AM, David Kastrup wrote: > >> Free software is based on the premise of empowering the recipient of >> software to change and adapting it according to his own needs. >> >> Pampering to the needs of users who are not interested in changing and >> adapting the software according to their needs is not a major priority. >> >> Feel free to fork any free software which does not behave like you want >> it: you have the power. You are not dependent on upstream developers. > > Good point. But not all users have the time or the ability to do their own changing or forking or even significant customization. Allowing the *possibility* of users to change things is not the same as *expecting* them to change things. > > In this particular instance, the customization needed is not a big deal: set line-move-visual to nil. Almost everybody can do it. But the time they had to spend in discovering that they needed to change it is what has been significant. (In fact, after this thread started, I began to wonder if VM might be vulnerable to the problem as well, and went and checked if there were calls to next-line anywhere. There were three of them!) > The change was clearly documented in the NEWS file, which also explained how to restore the old behavior. Any user who upgrades to a new version and is too lazy to check the NEWS file (and the PROBLEMS file for that matter), especially after observing unexpected or different behavior gets what they deserve. Tim -- tcross (at) rapttech dot com dot au ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-07 8:46 ` line-move-visual Tim X @ 2010-06-07 16:23 ` Stefan Monnier 2010-06-09 20:23 ` line-move-visual Joseph Brenner 0 siblings, 1 reply; 165+ messages in thread From: Stefan Monnier @ 2010-06-07 16:23 UTC (permalink / raw) To: help-gnu-emacs > The change was clearly documented in the NEWS file, which also explained > how to restore the old behavior. Admittedly, this file is loong. We should probably try to make a "revert to old defaults" section somewhere so it's easier to find those things. Stefan ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-07 16:23 ` line-move-visual Stefan Monnier @ 2010-06-09 20:23 ` Joseph Brenner 0 siblings, 0 replies; 165+ messages in thread From: Joseph Brenner @ 2010-06-09 20:23 UTC (permalink / raw) To: help-gnu-emacs Stefan Monnier <monnier@iro.umontreal.ca> writes: >> The change was clearly documented in the NEWS file, which also explained >> how to restore the old behavior. > > Admittedly, this file is loong. We should probably try to make > a "revert to old defaults" section somewhere so it's easier to find > those things. Actually... if you're planning of having a section like that, I'd suggest there's already a bigger problem. ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-06 9:39 ` line-move-visual David Kastrup [not found] ` <hug5rv$6d2$1@north.jnrs.ja.net> @ 2010-06-07 8:39 ` Tim X 2010-06-10 10:12 ` line-move-visual Uday S Reddy 2010-06-09 21:38 ` line-move-visual Joseph Brenner 2 siblings, 1 reply; 165+ messages in thread From: Tim X @ 2010-06-07 8:39 UTC (permalink / raw) To: help-gnu-emacs David Kastrup <dak@gnu.org> writes: > Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> writes: > >> Coupled with these real technical issues, there are the attitudinal >> problems of holier-than-thou, smarter-than-thou and modern-than-thou >> and what have you. > > Everybody is free to join the discussions on the Emacs developer lists. > Those who choose not to help with the work don't get to criticize the > results. A common democratic principle. > Common democratic principal! What a load of crap. Anyone can criticise any decision at any time. Whether the maintainers want to take any notice is another matter. For the record, I dislike the default of enabling move by visual lines rather than logical ones. However, as it is trivial to revert behavior back to the old default, this whole thread is largely poinless moaning that is unlikely to change anything. I do agree that if you are someone who is going to get upset about changes that you don't agree with, then you should participate in the devel discussions. If you don't want to, then you are just going to have to suck it up and either accept it or use something else. Moaning about it without putting in any effort to find out why the change was made and what discussions took place indicates low emotional maturity and/or someone who just wants to have a childish dummy spit because somehting in their world changed without their permission. Despite the fact I don't agree witht he change in default behavior, I also want to make it very clear, I DO NOT support what has been posted regarding the motivation, care and competancy of the emacs developers and maintainers. To those of you who have done this I would say that making all sorts of assumptions regarding the motivations and considerations of the devel team without actually looking at what discussions did take place is an unjustified and unwarranted attack on those few people who put in the hard word to develop and maintain this free software. It is a cheap dishonarable swipe. It lumps all the developers together as if they are all in agreement regarding every change made and ignores the effort put in to try and get the right outcome and do the difficult job of balancing many different views. If you don't like what they have done, either a) get on the devel list and present a case and maybe build support to have the default changed., b) Make the trivial config change to restore the old behavior and move on C) Use an old version and maintain it yourself the way you want d) Give up and go away. Tim -- tcross (at) rapttech dot com dot au ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-07 8:39 ` line-move-visual Tim X @ 2010-06-10 10:12 ` Uday S Reddy 2010-06-10 13:43 ` line-move-visual Stefan Monnier 2010-06-10 16:57 ` line-move-visual Mark Crispin 0 siblings, 2 replies; 165+ messages in thread From: Uday S Reddy @ 2010-06-10 10:12 UTC (permalink / raw) To: help-gnu-emacs >> Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> writes: >> >>> Coupled with these real technical issues, there are the attitudinal >>> problems of holier-than-thou, smarter-than-thou and modern-than-thou >>> and what have you. > > Despite the fact I don't agree witht he change in default behavior, I > also want to make it very clear, I DO NOT support what has been > posted regarding the motivation, care and competancy of the emacs > developers and maintainers. To those of you who have done this I would > say that making all sorts of assumptions regarding the motivations and > considerations of the devel team without actually looking at what > discussions did take place is an unjustified and unwarranted attack on > those few people who put in the hard word to develop and maintain this > free software. It is a cheap dishonarable swipe. It lumps all the > developers together as if they are all in agreement regarding every > change made and ignores the effort put in to try and get the right > outcome and do the difficult job of balancing many different views. Oh, dear! Sorry for the misunderstanding. I didn't mean to imply that the Emacs developers have shown the "attitudinal problems" that I mentioned. It had more to do with the attitudes expressed by some of the "spokesmen" here (in Joseph Brenner's good words). In themselves, the devs have been nothing less than professional and polite, either here or on the emacs-devel list. They do an incredible amount of work, quite silently, and we all owe a great debt of gratitude to them! The thinking behind the line-move-visual decision went something like this. If C-n moves by logical lines then the new users would be confused. If it moves by visual lines then the experienced users would be bothered. But we have a flag whereby experienced users can revert to the old behavior. The new users won't know enough to set a flag. So, let us go with the default that helps out the new users. See this thread for example: http://thread.gmane.org/gmane.emacs.devel/101551/focus=101560 or tens of other threads that discussed line-move-visual. I don't think there is any reason to attribute arrogance or carelessness on the part of the developers in reaching that decision. At worst, it was a technical mistake in thinking that both the defaults are equally bad. Or, perhaps an error of judgement that the experienced users will know enough to change the default. --- Now that this thread has gone for this long and still seems to have some life left, why don't we come up with some constructive ideas? I have a few of them here, mostly colored by my experience with maintaining VM. The first suggestion I have is that the Emacs developers can find a way to consult the user community about potential changes. It is not reasonable to expect that all users should take part in the developers discussion in order to provide their input. It seems like an additional imposition on top of all the work that the developers already do, but having an open discussion about visible behavior changes ahead of time can save from unnecessary heartburn later on. I do this kind of thing regularly for VM. See this discussion for example: http://groups.google.com/group/gnu.emacs.vm.info/browse_thread/thread/1297bd3ab1de78d9/2361a430ee7e7bc3?lnk=raot#2361a430ee7e7bc3 The second suggestion, which Stefan seems to be thinking about already, is to clearly label changes in the NEWS file. This is also something I have been doing in VM. See, for example, the NEWS file here: https://launchpad.net/vm/+download I am constantly irritated by the fact that some of the downstream distributions omit the the NEWS files from installations. I have resorted to putting the NEWS file as an independent download on the web site so that the downstream users can get it directly. I think we should try and impress upon the downstream guys the importance of NEWS files. A third suggestion is that we should start thinking of Emacs as mission-critical software. "Text editor" is a lousy description which has long been out of date. It is really platform on which a number of critical services are delivered, for development of projects or for running of teams and organizations. A lot rides on it and any changes that potentially cause corruption of files or data can be quite serious. Finally, and I might be a bit OTT here, I think we should think of free software as community-owned software. It is not developer-owned software (despite the aberration caused by the existence of FSF as a copyright-owner). Lots of people contribute, and they come and go. The software will live on for long after they are gone. Free software isn't "free-to-fork" software, even though the right to fork exists as a last resort and as a foundation for everything else. If that right needs to be exercised, it is a signal that the community-ownership of the software has broken down and that is not good for any of us. Cheers, Uday ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-10 10:12 ` line-move-visual Uday S Reddy @ 2010-06-10 13:43 ` Stefan Monnier 2010-06-10 15:17 ` line-move-visual Uday S Reddy ` (3 more replies) 2010-06-10 16:57 ` line-move-visual Mark Crispin 1 sibling, 4 replies; 165+ messages in thread From: Stefan Monnier @ 2010-06-10 13:43 UTC (permalink / raw) To: help-gnu-emacs > The thinking behind the line-move-visual decision went something like > this. If C-n moves by logical lines then the new users would be > confused. If it moves by visual lines then the experienced users would > be bothered. But we have a flag whereby experienced users can revert to > the old behavior. The new users won't know enough to set a flag. So, > let us go with the default that helps out the new users. See this > thread for example: Choosing defaults is very difficult indeed. You can never please everyone. In this specific case, I'm the main guy to blame: I wrote the original patch for line-move-visual (oddly enough, since it touches parts of the code I still am not at all familiar with), mostly because it seemed it would be important for proper support of word-wrap (which I didn't care for much, but many users cared about it). After writing the patch, I tried it out, mostly for debugging purposes, and much to my surprise I discovered that I actually liked it. Yes, it occasionally doesn't do what I want, but in practice, it does what I want more often than the previous case: - when no line wraps, it either makes no difference, or it works slightly better because it correctly accounts for variable-pitch fonts. - when lines are long (typically the "single-line paragraph" text coming from people who either use word-wrap or longlines-mode or an editor that behaves similarly, but can also happen in many other cases like binary files, or mechanically-generated files), the new behavior is much better (how did you move to "that spot I see about 10 visual-lines down from point" in a single logical line in previous Emacsen?). - when the buffer mostly fits without wrapping, except for a few exceptions, then yes, the new behavior is less good for those wrapped-lines. In my particular case, such lines are usually (very minor) bugs anyway, so it's not that important, but I understand that some people get annoyed. And of course, if you use C-100 C-n instead of M-g M-g 100 RET to move to the line 100 (I personally use C-s 100 instead ;-), you'll be disappointed, and if you use keyboard macros you'll also be disappointed. Depending on your particular circumstances, the second case will only rarely happen whereas the third will be very common, so you'll be really annoyed. Sorry about that. Please (setq line-move-visual nil) in your .emacs and/or try to come up with some idea how we could keep the advantages in cases 1 and 2 without suffering in case 3. Stefan ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-10 13:43 ` line-move-visual Stefan Monnier @ 2010-06-10 15:17 ` Uday S Reddy 2010-06-10 19:53 ` line-move-visual Stefan Monnier 2010-06-10 15:44 ` line-move-visual despen ` (2 subsequent siblings) 3 siblings, 1 reply; 165+ messages in thread From: Uday S Reddy @ 2010-06-10 15:17 UTC (permalink / raw) To: help-gnu-emacs Stefan Monnier wrote: > Choosing defaults is very difficult indeed. You can never please > everyone. In this specific case, I'm the main guy to blame: I wrote the > original patch for line-move-visual (oddly enough, since it touches > parts of the code I still am not at all familiar with), mostly because > it seemed it would be important for proper support of word-wrap (which > I didn't care for much, but many users cared about it). Isn't word-wrap the ideal solution for dealing with the single-line paragraphs that you mention in the second bullet point below? > > Yes, it occasionally doesn't do what I want, but in practice, it does > what I want more often than the previous case: > - when no line wraps, it either makes no difference, or it works > slightly better because it correctly accounts for > variable-pitch fonts. > - when lines are long (typically the "single-line paragraph" text coming > from people who either use word-wrap or longlines-mode or an editor > that behaves similarly, but can also happen in many other cases like > binary files, or mechanically-generated files), the new behavior is > much better (how did you move to "that spot I see about 10 > visual-lines down from point" in a single logical line in > previous Emacsen?). > - when the buffer mostly fits without wrapping, except for a few > exceptions, then yes, the new behavior is less good for those > wrapped-lines. In my particular case, such lines are usually (very > minor) bugs anyway, so it's not that important, but I understand that > some people get annoyed. And of course, if you use C-100 C-n instead > of M-g M-g 100 RET to move to the line 100 (I personally use C-s 100 > instead ;-), you'll be disappointed, and if you use keyboard macros > you'll also be disappointed. > > Depending on your particular circumstances, the second case will only > rarely happen whereas the third will be very common, so you'll be > really annoyed. Sorry about that. Please (setq line-move-visual nil) > in your .emacs and/or try to come up with some idea how we could keep > the advantages in cases 1 and 2 without suffering in case 3. If line-move-visual is nil by default, the users that care about 1 and 2 can set it to t, can't they? It is the same issue from the other side of the fence. They don't need the default set in a particular way to get their behaviour. Moreover, the people dealing with single-line paragraphs (me being one of them) will normally use visual-line-mode, which does visual line motion anyway. So, they are not affected by the default at all. So, this particular decision doesn't seem to be all that difficult. Cheers, Uday ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-10 15:17 ` line-move-visual Uday S Reddy @ 2010-06-10 19:53 ` Stefan Monnier 0 siblings, 0 replies; 165+ messages in thread From: Stefan Monnier @ 2010-06-10 19:53 UTC (permalink / raw) To: help-gnu-emacs >> Choosing defaults is very difficult indeed. You can never please >> everyone. In this specific case, I'm the main guy to blame: I wrote the >> original patch for line-move-visual (oddly enough, since it touches >> parts of the code I still am not at all familiar with), mostly because >> it seemed it would be important for proper support of word-wrap (which >> I didn't care for much, but many users cared about it). > Isn't word-wrap the ideal solution for dealing with the single-line > paragraphs that you mention in the second bullet point below? Only for the display part: it doesn't help navigation. > So, this particular decision doesn't seem to be all that difficult. Leaving line-move-visual as nil would have been an easy decision to satisfy old users who already like Emacs. But setting it to t (without switching all the way to visual-line-mode) seemed like a good compromise. Given the reactions we've seen since Emacs-23.1 was released, I don't regret the decision. Stefan ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-10 13:43 ` line-move-visual Stefan Monnier 2010-06-10 15:17 ` line-move-visual Uday S Reddy @ 2010-06-10 15:44 ` despen 2010-06-10 22:02 ` line-move-visual Tassilo Horn 2010-06-10 22:48 ` line-move-visual Evans Winner 3 siblings, 0 replies; 165+ messages in thread From: despen @ 2010-06-10 15:44 UTC (permalink / raw) To: help-gnu-emacs Stefan Monnier <monnier@iro.umontreal.ca> writes: >> The thinking behind the line-move-visual decision went something like >> this. If C-n moves by logical lines then the new users would be >> confused. If it moves by visual lines then the experienced users would >> be bothered. But we have a flag whereby experienced users can revert to >> the old behavior. The new users won't know enough to set a flag. So, >> let us go with the default that helps out the new users. See this >> thread for example: > > Choosing defaults is very difficult indeed. You can never please > everyone. In this specific case, I'm the main guy to blame: Good, then I have something to contribute to this thread. Nice work and I support the idea of making this a default. For me, it was easy to spot the new behavior, and I assumed I would find a description and override in the NEWS file. So far I've found no reason to do so. I hope the complainers get a full refund of all the money they paid for your hard work and nothing else. ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-10 13:43 ` line-move-visual Stefan Monnier 2010-06-10 15:17 ` line-move-visual Uday S Reddy 2010-06-10 15:44 ` line-move-visual despen @ 2010-06-10 22:02 ` Tassilo Horn 2010-06-10 23:56 ` line-move-visual Uday S Reddy 2010-06-10 22:48 ` line-move-visual Evans Winner 3 siblings, 1 reply; 165+ messages in thread From: Tassilo Horn @ 2010-06-10 22:02 UTC (permalink / raw) To: help-gnu-emacs Stefan Monnier <monnier@iro.umontreal.ca> writes: > - when no line wraps, it either makes no difference, or it works > slightly better because it correctly accounts for > variable-pitch fonts. > - when lines are long [...], the new behavior is much better (how did > you move to "that spot I see about 10 visual-lines down from point" in > a single logical line in previous Emacsen?). I agree, and with the macro exception I'm in favour of operating on visual lines by default. But what I don't understand is why there are two levels of operating on visual lines: line-move-visual and visual-line-mode. IMO, the former is confusing, because C-a/e (and probably others) still operate on logical lines. I guess, that's because VLM is more invasive, i.e. keys get bound to new functions. But then, why not drop VLM altogether and make `move-beginning/end-of-line' obey line-move-visual, too? Bye, Tassilo ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-10 22:02 ` line-move-visual Tassilo Horn @ 2010-06-10 23:56 ` Uday S Reddy 0 siblings, 0 replies; 165+ messages in thread From: Uday S Reddy @ 2010-06-10 23:56 UTC (permalink / raw) To: help-gnu-emacs On 6/10/2010 11:02 PM, Tassilo Horn wrote: > > I guess, that's because VLM is more invasive, i.e. keys get bound to new > functions. Hi Tassilo, Can you or anybody else give us some examples of how visual-line-mode is invasive? I haven't been able to understand this point. Cheers, Uday ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-10 13:43 ` line-move-visual Stefan Monnier ` (2 preceding siblings ...) 2010-06-10 22:02 ` line-move-visual Tassilo Horn @ 2010-06-10 22:48 ` Evans Winner 3 siblings, 0 replies; 165+ messages in thread From: Evans Winner @ 2010-06-10 22:48 UTC (permalink / raw) To: help-gnu-emacs In my opinion, the question should never be what new users of Emacs want. What new users want is an editor that is 5% better than notepad.exe because that is per-force the limit of their imagination. They generally do no know 1% of what Emacs can do, so are not in a position to intelligently decide what the defaults should be. They /should/ want to rely on experienced users for that, and they should be willing to spend the extra tiny bit of effort up-front to learn the reasoning behind it. If they aren't, then Emacs isn't for them. Let them go. Changing defaults to whatever makes the least friction for those who switch to Emacs is not a service to new users; the principle is that people tend to stick with what they learn first, so dumbed-down defaults produces dumbed-down users, who will, after a few months or years, show up on emacs-devel demanding even more dumbed-down defaults, because that would make it even easier for the next generation of Microsoft/IBM/CUA refugees. It sometimes surprises me to find that even some experienced users of Emacs don't use and even sometimes don't know how to use keyboard macros. The name Emacs does, after all, come from the phrase "Editor MACroS." It is a fundamental part of the user experience. The question with regards to new users and line-move-visual is whether the slight savings in initial cognitive friction comes and the price of making it more difficult for new users to learn to create and use typical line-at-a-time-type keyboard macros. I don't claim to know the answer to this particular question, but I think the principle above is the right one to consider in this kind of case. ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-10 10:12 ` line-move-visual Uday S Reddy 2010-06-10 13:43 ` line-move-visual Stefan Monnier @ 2010-06-10 16:57 ` Mark Crispin 2010-06-10 18:38 ` line-move-visual Uday S Reddy 2010-06-10 19:57 ` line-move-visual Stefan Monnier 1 sibling, 2 replies; 165+ messages in thread From: Mark Crispin @ 2010-06-10 16:57 UTC (permalink / raw) To: help-gnu-emacs On Thu, 10 Jun 2010, Uday S Reddy posted: > A third suggestion is that we should start thinking of Emacs as > mission-critical software. It amazes me that anyone would think otherwise. > It is really platform on which a > number of critical services are delivered, for development of projects > or for running of teams and organizations. A lot rides on it and any > changes that potentially cause corruption of files or data can be quite > serious. As the kids say, "well, duh!" This discussion is rapidly leading to "is free software suitable as mission-critical software?". Some people would be more comfortable is the answer is "no". Then they don't have to deal with the responsibility of mission-critical software. > Finally, and I might be a bit OTT here, I think we should think of free > software as community-owned software. It is not developer-owned > software (despite the aberration caused by the existence of FSF as a > copyright-owner). The notion of "community-owned software" works as ideology, but not as reality. If emacs was really community-owned software, I as a community member could revert the change in the official distribution sources. And then there could be revert wars ala Wikipedia. That existed once upon a time in the mid-1970s, at MIT (the ITS systems) and elsewhere. It didn't end well. The dichotomy between "the cathedral and the bazaar" that ESR postulated doesn't really exist. The full-fledged bazaar option doesn't scale and never actually happened. It's just two types of cathedrals, one run by a pope and the other run by a board of laymen. But even the laymen become power-corrupted. > Free software isn't > "free-to-fork" software, even though the right to fork exists as a last > resort and as a foundation for everything else. If that right needs to > be exercised, it is a signal that the community-ownership of the > software has broken down and that is not good for any of us. That is certainly true. Again, BSD serves as an example. Another sign of a process breakdown is when a developer's answer to user complaints about changes in a new version is "so just run the old version". The need to revert to an old version means that the new version is broken. The corrolary to this is that the standard developer's answer to complaints about bugs in an old version is "upgrade to the new version". This only works if the upgrade is a viable option. Developers can't have it both ways. If they create a new version that is unacceptable to some portion of the user community, they they have effectively forked the software. Responsible developers figure this out after a while. It takes maturity. Generally, they want their users to be using one, and only one, version; and they do what is necessary to ensure that there are no barriers to upgrade. Since user interface surprise is a barrier to upgrade, they make sure there aren't any such surprises. In the real world, people get fired for inflicting surprises in mission-critical software. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-10 16:57 ` line-move-visual Mark Crispin @ 2010-06-10 18:38 ` Uday S Reddy 2010-06-11 23:56 ` line-move-visual Mark Crispin 2010-06-10 19:57 ` line-move-visual Stefan Monnier 1 sibling, 1 reply; 165+ messages in thread From: Uday S Reddy @ 2010-06-10 18:38 UTC (permalink / raw) To: help-gnu-emacs Mark Crispin wrote: > The notion of "community-owned software" works as ideology, but not as > reality. If emacs was really community-owned software, I as a community > member could revert the change in the official distribution sources. > And then there could be revert wars ala Wikipedia. Exactly! By "community-owned", I don't mean community-developed. There needs to be control and discipline etc in the development team. Otherwise, there will be chaos, and mission-critical fitness will go out of the window. By community ownership, I only mean that all the people that have a stake in the system have a voice in the matter and we all feel ownership of the system. When the community is divided, as seems to be the case on this issue, the developers have to make a decision and move on. In any case, I think we have reached a point where you and Stefan need to talk to each other directly and sort it out. In my humble opinion, it is easy to argue that the current default was ill-chosen. But it is not so easy to argue that it should be changed. If we change it, then we face all the same issues all over again affecting the other users that are depending on the current default. So, it seems best to leave things as they are and make a note of all the lessons learned. > But even the laymen become power-corrupted. I think that is a bit of an exaggeration. They have a responsibility to bear and sometimes they get carried away. > Since user interface surprise is a barrier to upgrade, they make sure > there aren't any such surprises. Yes, that point is well-made. But, the same argument now suggests that the default should not be changed yet again. Cheers, Uday ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-10 18:38 ` line-move-visual Uday S Reddy @ 2010-06-11 23:56 ` Mark Crispin 2010-06-12 0:17 ` line-move-visual Wojciech Meyer 2010-06-12 4:18 ` line-move-visual Tim X 0 siblings, 2 replies; 165+ messages in thread From: Mark Crispin @ 2010-06-11 23:56 UTC (permalink / raw) To: help-gnu-emacs On Thu, 10 Jun 2010, Uday S Reddy posted: > By community ownership, I only mean that all the people that have a stake in > the system have a voice in the matter and we all feel ownership of the > system. When the community is divided, as seems to be the case on this > issue, the developers have to make a decision and move on. The problem is that nobody ever asked the existing users whether or not they wanted this global change foisted upon them. Rather, it was done unilaterally, and the individuals responsible are saying "See! Some people like it! It was a good change." This sort of thing happened in the past as well. The difference was that there was accountability in the past that is absent today. > In my humble opinion, it is > easy to argue that the current default was ill-chosen. But it is not so easy > to argue that it should be changed. If we change it, then we face all the > same issues all over again affecting the other users that are depending on > the current default. So, it seems best to leave things as they are and make > a note of all the lessons learned. I agree that we are probably screwed, and royally so. I have a new task on my list: replace emacs in the procedures for my target audience since emacs is no longer suitable for that purpose. I simply can not tell these users "make sure that you set line-move-visual to nil"; they would have no clue what that means. More likely than not, I will end up being obliged to write a program for the task; and there will be one less way those users will be exposed to emacs. One of the advantages of the "software tools" mindset of the past was that you did not have to write a program for every task. Instead, you could leverage the existing tools. That falls apart when those tools are corrupted so that they no longer can be relied upon to produce predictable results. >> But even the laymen become power-corrupted. > I think that is a bit of an exaggeration. They have a responsibility to bear > and sometimes they get carried away. Every young programmer wants to put his own mark on things. The problem is that these changes are frequently ill-considered and sometimes have bad consequences. >> Since user interface surprise is a barrier to upgrade, they make sure there >> aren't any such surprises. > Yes, that point is well-made. But, the same argument now suggests that the > default should not be changed yet again. Yup. We're probably screwed. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-11 23:56 ` line-move-visual Mark Crispin @ 2010-06-12 0:17 ` Wojciech Meyer 2010-06-13 17:23 ` line-move-visual Mark Crispin 2010-06-12 4:18 ` line-move-visual Tim X 1 sibling, 1 reply; 165+ messages in thread From: Wojciech Meyer @ 2010-06-12 0:17 UTC (permalink / raw) To: help-gnu-emacs Mark Crispin <mrc@panda.com> writes: > On Thu, 10 Jun 2010, Uday S Reddy posted: >> By community ownership, I only mean that all the people that have a >> stake in the system have a voice in the matter and we all feel >> ownership of the system. When the community is divided, as seems to >> be the case on this issue, the developers have to make a decision >> and move on. Well it is certainly possible, one can use mailing list and the NEWS file, which was suggested before. > This sort of thing happened in the past as well. The difference was > that there was accountability in the past that is absent today. What sort of acountability, I think unhappy `customers' is enough punishment. > I have a new task on my list: replace emacs in the procedures for my > target audience since emacs is no longer suitable for that purpose. I > simply can not tell these users "make sure that you set > line-move-visual to nil"; they would have no clue what that means. > More likely than not, I will end up being obliged to write a program > for the task; and there will be one less way those users will be > exposed to emacs. What kind of Emacs users are they? Isn't possible to place on every machine a stub containing: (setq line-move-visual nil). > > One of the advantages of the "software tools" mindset of the past was > that you did not have to write a program for every task. Instead, you > could leverage the existing tools. That falls apart when those tools > are corrupted so that they no longer can be relied upon to produce > predictable results. It is ever more true now. > >>> But even the laymen become power-corrupted. >> I think that is a bit of an exaggeration. They have a >> responsibility to bear and sometimes they get carried away. > > Every young programmer wants to put his own mark on things. The > problem is that these changes are frequently ill-considered and > sometimes have bad consequences. There is nothing wrong in being young and creative, that makes often things better. Young people often do care more about things then Senior Architects, they are also more flexible for changes. The reason why this setting wasn't kept by default is to fix the fundamental problem, without additional cost of keeping this setting hidden. People have full rights to receive the fixes like this, as you have full rights to complain about them. This is part of the game, IMHO Emacs does not change that often, and really keeps things the same, just because there is nothing to fix apart from things that need to be changed in order to guarantee future of Emacs. Wojciech ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-12 0:17 ` line-move-visual Wojciech Meyer @ 2010-06-13 17:23 ` Mark Crispin 2010-06-13 20:56 ` line-move-visual Alan Mackenzie 0 siblings, 1 reply; 165+ messages in thread From: Mark Crispin @ 2010-06-13 17:23 UTC (permalink / raw) To: help-gnu-emacs On Sat, 12 Jun 2010, Wojciech Meyer posted: > Well it is certainly possible, one can use mailing list and the NEWS > file, which was suggested before. Please read the first chapter of the Hitchhiker's Guide to the Galaxy to understand the flaw in that reasoning. >> This sort of thing happened in the past as well. The difference was >> that there was accountability in the past that is absent today. > What sort of acountability, I think unhappy `customers' is enough > punishment. Apparently not, if the "customers" are told that it's their fault for not being on the development list. > What kind of Emacs users are they? Isn't possible to place on every > machine a stub containing: (setq line-move-visual nil). There include people who never use emacs, except to follow the procedure that I outline (which is literally a cookbook "do these steps exactly"). I have no control or access to the machines in question. Perhaps I should have written a program to begin with. But it was so much simpler to leverage upon emacs back in the days when emacs had a reliable interface. Now that it no longer does, I'm now forced to write the program. > There is nothing wrong in being young and creative, that makes often > things better. Young people often do care more about things then Senior > Architects, they are also more flexible for changes. Yes, but they lack the wisdom and experience of their elders. This in turn leads them to address complex problems with simple solutions that backfire (sometimes disastrously). > The reason why this setting wasn't kept by default is to fix the > fundamental problem, Yeah, right. The "fundamental problem" that CTRL/A, CTRL/E, CTRL/N, CTRL/P, etc. moved to predictable places in the file no matter what the screen width, and thus could be relied upon for a cookbook procedure. We can't have predictability and reliability. We have to do pretty-pretty to be just like Word, and destroy the one attribute that made emacs superior to other choices. Bletch. This wouldn't have been a problem had the arrow keys been changed to the new semantics and CTRL-A/E/N/P been left alone. The new semantics are even arguably right for arrow keys (although I would go further and say that they should also treat tabs as the equivalent number of spaces). It isn't as if we're still in the 1970s and have keyboards without arrow keys. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-13 17:23 ` line-move-visual Mark Crispin @ 2010-06-13 20:56 ` Alan Mackenzie 2010-06-14 0:42 ` line-move-visual Jim Diamond ` (2 more replies) 0 siblings, 3 replies; 165+ messages in thread From: Alan Mackenzie @ 2010-06-13 20:56 UTC (permalink / raw) To: help-gnu-emacs In comp.emacs Mark Crispin <mrc@panda.com> wrote: > On Sat, 12 Jun 2010, Wojciech Meyer posted: >> Well it is certainly possible, one can use mailing list and the NEWS >> file, which was suggested before. > Please read the first chapter of the Hitchhiker's Guide to the Galaxy to > understand the flaw in that reasoning. Please feel free to suggest a way the development team could have canvassed users, particularly the vast majority who don't keep up with project mailing lists. It seems like a difficult problem. > Apparently not, if the "customers" are told that it's their fault for > not being on the development list. It seems like a difficult problem. >> What kind of Emacs users are they? Isn't possible to place on every >> machine a stub containing: (setq line-move-visual nil). > There include people who never use emacs, except to follow the procedure > that I outline (which is literally a cookbook "do these steps exactly"). > I have no control or access to the machines in question. > Perhaps I should have written a program to begin with. But it was so much > simpler to leverage upon emacs back in the days when emacs had a reliable > interface. Now that it no longer does, I'm now forced to write the > program. It seems you're exaggerating your predicament ever so slightly. I'd guess you could code up the replacement program (in elisp? in sed? in whatever?) in less time than you've spent discussing the problem here. It's far from obvious that this change (line-visual-mode being set) is a Bad Thing. Without it, moving around things like log files with 300 character lines was an utter pain. I'd suggest it was more of a pain than the one you're suffering, because it hit users using Emacs in its principal way of working, rather than in special cases in some obscure feature (keyboard macros). since Emacs 23, I haven't felt any need whatsoever to restore l-v-m to nil, and I haven't seen anybody else asking for it. >> There is nothing wrong in being young and creative, that makes often >> things better. Young people often do care more about things then >> Senior Architects, they are also more flexible for changes. > Yes, but they lack the wisdom and experience of their elders. This in > turn leads them to address complex problems with simple solutions that > backfire (sometimes disastrously). Hence the best team for writing something contains both stuck-in-the-groove maturity and feckless youth. Not that the Emacs team is lacking in solid wisdom. >> The reason why this setting wasn't kept by default is to fix the >> fundamental problem, > Yeah, right. The "fundamental problem" that CTRL/A, CTRL/E, CTRL/N, > CTRL/P, etc. moved to predictable places in the file no matter what the > screen width, and thus could be relied upon for a cookbook procedure. Now you've got to take screen width into account. Big deal. And it was dashed near impossible to move easily to the middle of long, long lines. I suspect this need to be commoner than using keyboard macros on long lines. > We can't have predictability and reliability. We have to do > pretty-pretty to be just like Word, and destroy the one attribute that > made emacs superior to other choices. You're exaggerating at least a little bit here. There are lots and lots of attributes that make Emacs superior, some of them in contention with some others. You could easily enough amend your instructions, prefixing them with "M-: (setq visual-line-mode nil)". Or you could rewrite the thing (what does it do, exactly?) in elisp or whatever. > Bletch. > This wouldn't have been a problem had the arrow keys been changed to > the new semantics and CTRL-A/E/N/P been left alone. The new semantics > are even arguably right for arrow keys (although I would go further and > say that they should also treat tabs as the equivalent number of > spaces). It isn't as if we're still in the 1970s and have keyboards > without arrow keys. The arrow keys are a long way away from the home position on the keyboard. You're surely not suggesting rebinding those four key sequences to something else? > -- Mark -- -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-13 20:56 ` line-move-visual Alan Mackenzie @ 2010-06-14 0:42 ` Jim Diamond 2010-06-14 10:49 ` line-move-visual Uday S Reddy [not found] ` <m2k4q18od5.fsf@softwarematters.org> 2 siblings, 0 replies; 165+ messages in thread From: Jim Diamond @ 2010-06-14 0:42 UTC (permalink / raw) To: help-gnu-emacs On 2010-06-13 at 17:56 ADT, Alan Mackenzie <acm@muc.de> wrote: > In comp.emacs Mark Crispin <mrc@panda.com> wrote: >> This wouldn't have been a problem had the arrow keys been changed to >> the new semantics and CTRL-A/E/N/P been left alone. The new semantics >> are even arguably right for arrow keys (although I would go further and >> say that they should also treat tabs as the equivalent number of >> spaces). It isn't as if we're still in the 1970s and have keyboards >> without arrow keys. > The arrow keys are a long way away from the home position on the > keyboard. You're surely not suggesting rebinding those four key > sequences to something else? Why not? Presumably (*) the idea of having long lines and moving to the next visual line (as the default) is to placate word-processor refugees, who are probably used to using arrow keys (regardless of how far they are from the home position) and not interested in using Ctrl-A,E,N,P. (*) Wild speculation, since I didn't read the discussion on the developer list. Mea culpa. Jim ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-13 20:56 ` line-move-visual Alan Mackenzie 2010-06-14 0:42 ` line-move-visual Jim Diamond @ 2010-06-14 10:49 ` Uday S Reddy 2010-06-14 17:16 ` line-move-visual Alan Mackenzie 2010-06-15 9:26 ` line-move-visual Tim X [not found] ` <m2k4q18od5.fsf@softwarematters.org> 2 siblings, 2 replies; 165+ messages in thread From: Uday S Reddy @ 2010-06-14 10:49 UTC (permalink / raw) To: help-gnu-emacs Alan Mackenzie wrote: > It's far from obvious that this change (line-visual-mode being set) is a > Bad Thing. Without it, moving around things like log files with 300 > character lines was an utter pain. I'd suggest it was more of a pain > than the one you're suffering, because it hit users using Emacs in its > principal way of working, rather than in special cases in some obscure feature > (keyboard macros). If line-move-visual was nil by default, would you have been able to set it to t in order to move around the log files? Cheers, Uday ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-14 10:49 ` line-move-visual Uday S Reddy @ 2010-06-14 17:16 ` Alan Mackenzie 2010-06-14 17:34 ` line-move-visual Uday S Reddy 2010-06-15 9:26 ` line-move-visual Tim X 1 sibling, 1 reply; 165+ messages in thread From: Alan Mackenzie @ 2010-06-14 17:16 UTC (permalink / raw) To: help-gnu-emacs In comp.emacs Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> wrote: > Alan Mackenzie wrote: >> It's far from obvious that this change (line-visual-mode being set) is >> a Bad Thing. Without it, moving around things like log files with 300 >> character lines was an utter pain. I'd suggest it was more of a pain >> than the one you're suffering, because it hit users using Emacs in its >> principal way of working, rather than in special cases in some obscure >> feature (keyboard macros). > If line-move-visual was nil by default, would you have been able to set > it to t in order to move around the log files? WADR, that's a silly question. This entire thread has been solely about default settings, as are many discussions on the devlopers' mailing list. However, the fact is that I didn't actually set line-visual-mode in any Emacs before 23. That suggests I either wasn't aware of this setting, or the pain it caused me, whilst real, didn't cross some sort of (fairly high) threshold. I honestly can't remember any more. When using Emacs as a full screen editor (how it's used most of the time), a key binding is needed to go to the next/previous visual line. Using C-p/C-n (or <up>/<down>) seems as good a choice as any. > Cheers, > Uday -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-14 17:16 ` line-move-visual Alan Mackenzie @ 2010-06-14 17:34 ` Uday S Reddy 0 siblings, 0 replies; 165+ messages in thread From: Uday S Reddy @ 2010-06-14 17:34 UTC (permalink / raw) To: help-gnu-emacs Alan Mackenzie wrote: > >> If line-move-visual was nil by default, would you have been able to set >> it to t in order to move around the log files? > > WADR, that's a silly question. This entire thread has been solely about > default settings, as are many discussions on the devlopers' mailing list. Sorry if it sounded silly. The setting of the default to t was precisely targeted to help people like you. Neither the setting nor the functionality existed before Emacs 23. So, you didn't miss anything. But, after having added this functionality, I think the developers believed that people like you might not have been able to discover the new functionality on your own, unless it was made the default. Are you agreeing with that assessment? Other than changing defaults, is there some other form of "advertising" the Emacs devs could have used to bring it to your attention? Cheers, Uday ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-14 10:49 ` line-move-visual Uday S Reddy 2010-06-14 17:16 ` line-move-visual Alan Mackenzie @ 2010-06-15 9:26 ` Tim X 2010-06-15 13:49 ` line-move-visual Stefan Monnier 1 sibling, 1 reply; 165+ messages in thread From: Tim X @ 2010-06-15 9:26 UTC (permalink / raw) To: help-gnu-emacs Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> writes: > Alan Mackenzie wrote: > >> It's far from obvious that this change (line-visual-mode being set) is a >> Bad Thing. Without it, moving around things like log files with 300 >> character lines was an utter pain. I'd suggest it was more of a pain >> than the one you're suffering, because it hit users using Emacs in its >> principal way of working, rather than in special cases in some obscure feature >> (keyboard macros). > > If line-move-visual was nil by default, would you have been able to set it to > t in order to move around the log files? > This sentiment I agree with. The default for line-move-visual should have been nil not t, especially as there are some things that still need more thought (i.e. macros) and if for no other reason, to give maintainers of other packages time to fix potentially broken code. The introduciton of this facility was in itself a good idea. How it has been introduced was not. Tim -- tcross (at) rapttech dot com dot au ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-15 9:26 ` line-move-visual Tim X @ 2010-06-15 13:49 ` Stefan Monnier [not found] ` <87sk4n3ocs.fsf@rapttech.com.au> 0 siblings, 1 reply; 165+ messages in thread From: Stefan Monnier @ 2010-06-15 13:49 UTC (permalink / raw) To: help-gnu-emacs > more thought (i.e. macros) and if for no other reason, to give > maintainers of other packages time to fix potentially broken code. I don't know of any bug caused by this. Stefan "of course, it probably wouldn't have been reported to us, and often third-party package authors prefer to workaround problems than contact us to try and have them addressed" ^ permalink raw reply [flat|nested] 165+ messages in thread
[parent not found: <87sk4n3ocs.fsf@rapttech.com.au>]
* Re: line-move-visual [not found] ` <87sk4n3ocs.fsf@rapttech.com.au> @ 2010-06-16 14:43 ` Stefan Monnier 0 siblings, 0 replies; 165+ messages in thread From: Stefan Monnier @ 2010-06-16 14:43 UTC (permalink / raw) To: help-gnu-emacs > I think keyboard macros are a potential source of problems. Unless I'm > missing somehting, a macro recorded while line-move-visual is enabled > and then playedback when it is not could easily exhibit different > behavior. A keyboard macro only records the keys you hit. So, not only the above will do something odd, but if you record a keyboard macro in your foo.el buffer and then play it back in a Dired buffer ... better make backups first. > However, to what extent this potential issue would actually arise in > reality is questionable. For one thing, most users are unlikely to be > setting/unsetting line-move-visual frequently. Also, the same issue can The problem with line-move-visual and keyboard macros, is that if you record your macro on a piece of that text that fits just fine without line-wrapping, and then play it somewhere where lines are wrapped, you may find your macro doesn't do what you wanted any more. In itself, this is no big deal, but it's easy for people to forget (or to not know) about this detail because line-movement has been "mostly logical" for many years. Stefan ^ permalink raw reply [flat|nested] 165+ messages in thread
[parent not found: <m2k4q18od5.fsf@softwarematters.org>]
[parent not found: <jwvaaqxbcca.fsf-monnier+gnu.emacs.help@gnu.org>]
* Re: line-move-visual [not found] ` <jwvaaqxbcca.fsf-monnier+gnu.emacs.help@gnu.org> @ 2010-06-15 6:54 ` Pascal J. Bourguignon 2010-06-15 8:42 ` line-move-visual Uday S Reddy 2010-06-20 17:08 ` line-move-visual B. T. Raven 1 sibling, 1 reply; 165+ messages in thread From: Pascal J. Bourguignon @ 2010-06-15 6:54 UTC (permalink / raw) To: help-gnu-emacs Stefan Monnier <monnier@iro.umontreal.ca> writes: >>> principal way of working, rather than in special cases in some obscure >>> feature (keyboard macros). >> Keyboard macros are far from obscure. > > Indeed. > >>> And it was dashed near impossible to move easily to the middle of >>> long, long lines. >> C-u <some number> right-arrow > > How convenient! > Say you're in a window and want to go down 3 visual lines on the same > long logical line. What number do you use? Ok, let's make it easier > and say that you happen to know that the window is 76-chars wide. > So 76 by 3? quick? quick? 240. You can refine later. > Now let's do that again but with 13 lines, where you don't actually know > it's "13": you first have to count it. Let's say you can't even count the lines! You can always, and only with emacs, type: M-: (forward-char (/ (- (progn (end-of-line) (point)) (progn (beginning-of-line) (point))) 2)) RET > The best I could come up with, is C-76 C-f and then C-x z z z ... until > you reach the line. > Now this all becomes a lot more interesting once you add word-wrap into > the mix, or TABs, or bytes displayed \NNN, or the presence of various > fonts and/or font-sizes on that long line, or variable-pitch fonts, ... Well, C-f C-n is all you need. I mean, keep C-f pressed until the cursor reaches the column you want, you don't even need to count 76. And keep C-n pressed until the cursor reaches the line you want. > Stefan "who reached for the mouse in all those cases, tho > typically only after first unconsciously hitting C-n > a few times and then realizing that C-n jumped way > further than intended" WFM. So far. -- __Pascal Bourguignon__ http://www.informatimago.com/ ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-15 6:54 ` line-move-visual Pascal J. Bourguignon @ 2010-06-15 8:42 ` Uday S Reddy 2010-06-15 9:30 ` line-move-visual David Kastrup ` (5 more replies) 0 siblings, 6 replies; 165+ messages in thread From: Uday S Reddy @ 2010-06-15 8:42 UTC (permalink / raw) To: help-gnu-emacs On 6/15/2010 7:54 AM, Pascal J. Bourguignon wrote: > > Well, C-f C-n is all you need. I mean, keep C-f pressed until the > cursor reaches the column you want, you don't even need to count > 76. And keep C-n pressed until the cursor reaches the line you want. Except that pressing control-key for that long with your pinky is a health risk! But I feel this discussion is tangential. Most of us accept that visual line movement is a /good/ idea and we find it useful in lots of contexts. We are grateful for Stefan & co for thinking of it and implementing it. The question is really whether it should have been made the default. Every time I narrowed down to that issue in this thread, the participants have fallen silent (first Xah Lee then Tim Cross, Alan Mackenzie and Stefan himself). I guess there is no good answer to it. There is no need for us to beat a dead horse. If the developers accept that it is a bad idea to introduce backward-incompatible changes for flimsy reasons, Emacs will be a more useful system for all of us than it currently is. Fortunately, nothing major is going to fall apart as a result of `next-line' changing its meaning. But I hope that we can arrest this trend right here so that we don't have to put up with more pain in future. Cheers, Uday ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-15 8:42 ` line-move-visual Uday S Reddy @ 2010-06-15 9:30 ` David Kastrup 2010-06-15 9:38 ` line-move-visual Tim X ` (4 subsequent siblings) 5 siblings, 0 replies; 165+ messages in thread From: David Kastrup @ 2010-06-15 9:30 UTC (permalink / raw) To: help-gnu-emacs Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> writes: > The question is really whether it should have been made the default. > > Every time I narrowed down to that issue in this thread, the > participants have fallen silent (first Xah Lee then Tim Cross, Alan > Mackenzie and Stefan himself). I guess there is no good answer to it. There is no simple answer. And there is no point in working on the aspects of a complex answer where it is not relevant. The relevant place is the developer list. > There is no need for us to beat a dead horse. If the developers > accept that it is a bad idea to introduce backward-incompatible > changes for flimsy reasons, Emacs will be a more useful system for all > of us than it currently is. That's beating a dead horse, and an imaginary one as well. > Fortunately, nothing major is going to fall apart as a result of > next-line' changing its meaning. But I hope that we can arrest this > trend right here so that we don't have to put up with more pain in > future. You are not going to stop development of Emacs single-handedly, and you will not be "arresting" any trend without working with developers when the design decisions are being discussed and made. Venting may be fun, but it will not change things. -- David Kastrup ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-15 8:42 ` line-move-visual Uday S Reddy 2010-06-15 9:30 ` line-move-visual David Kastrup @ 2010-06-15 9:38 ` Tim X 2010-06-15 13:45 ` line-move-visual Stefan Monnier ` (3 subsequent siblings) 5 siblings, 0 replies; 165+ messages in thread From: Tim X @ 2010-06-15 9:38 UTC (permalink / raw) To: help-gnu-emacs Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> writes: > On 6/15/2010 7:54 AM, Pascal J. Bourguignon wrote: > > The question is really whether it should have been made the default. > > Every time I narrowed down to that issue in this thread, the participants have > fallen silent (first Xah Lee then Tim Cross, Alan Mackenzie and Stefan > himself). I guess there is no good answer to it. > WTF. I believe I've responded to every single one of your posts directed to me. I've lost count of how many times I've posted in this thread saying that I DO NOT AGREE WITH IT BEING MADE THE DEFAULT. I agree with the functionality and I agree with introducing changes that change the existing semantics of next-line etc in order to provide the valuable addition of visual line editing (which BTW I seem to remember you or Mark rejecting outright). I suggest you need to take some of your own advice and go back and read the posts again. Tim -- tcross (at) rapttech dot com dot au ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-15 8:42 ` line-move-visual Uday S Reddy 2010-06-15 9:30 ` line-move-visual David Kastrup 2010-06-15 9:38 ` line-move-visual Tim X @ 2010-06-15 13:45 ` Stefan Monnier 2010-06-15 13:57 ` line-move-visual David Kastrup [not found] ` <hv8gvf$98o$1@north.jnrs.ja.net> 2010-06-15 16:51 ` line-move-visual Alan Mackenzie ` (2 subsequent siblings) 5 siblings, 2 replies; 165+ messages in thread From: Stefan Monnier @ 2010-06-15 13:45 UTC (permalink / raw) To: help-gnu-emacs > Every time I narrowed down to that issue in this thread, the participants > have fallen silent (first Xah Lee then Tim Cross, Alan Mackenzie and Stefan > himself). I guess there is no good answer to it. I did give you the answer: I tried it and found to my surprise that I liked it, so I suggested it and people said "no way", then they tried it and some people hated it, while others really liked it. So in the end it was a judgment call, and I decided that the added convenience of being able to deal with very-long-lines without having to change mode was more important. I.e. I decided that case 3 (in my earlier long post about it) was less common and less important. Stefan ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-15 13:45 ` line-move-visual Stefan Monnier @ 2010-06-15 13:57 ` David Kastrup [not found] ` <jwvbpbb6oyk.fsf-monnier+gnu.emacs.help@gnu.org> [not found] ` <hv8gvf$98o$1@north.jnrs.ja.net> 1 sibling, 1 reply; 165+ messages in thread From: David Kastrup @ 2010-06-15 13:57 UTC (permalink / raw) To: help-gnu-emacs Stefan Monnier <monnier@iro.umontreal.ca> writes: >> Every time I narrowed down to that issue in this thread, the participants >> have fallen silent (first Xah Lee then Tim Cross, Alan Mackenzie and Stefan >> himself). I guess there is no good answer to it. > > I did give you the answer: I tried it and found to my surprise that I > liked it, so I suggested it and people said "no way", then they tried > it and some people hated it, while others really liked it. > > So in the end it was a judgment call, and I decided that the added > convenience of being able to deal with very-long-lines without having > to change mode was more important. I.e. I decided that case 3 (in my > earlier long post about it) was less common and less important. I should think that changing to logical mode when recording and replaying macros would be an improvement. I can't imagine anybody wanting visual mode in that case. There is already one such change: vertical movement does not use vscroll in order to go smoothly through vertical material when macro recording or playback is active. -- David Kastrup ^ permalink raw reply [flat|nested] 165+ messages in thread
[parent not found: <jwvbpbb6oyk.fsf-monnier+gnu.emacs.help@gnu.org>]
* Re: line-move-visual [not found] ` <jwvbpbb6oyk.fsf-monnier+gnu.emacs.help@gnu.org> @ 2010-06-16 18:04 ` David Kastrup 0 siblings, 0 replies; 165+ messages in thread From: David Kastrup @ 2010-06-16 18:04 UTC (permalink / raw) To: help-gnu-emacs Stefan Monnier <monnier@iro.umontreal.ca> writes: >> I should think that changing to logical mode when recording and >> replaying macros would be an improvement. I can't imagine anybody >> wanting visual mode in that case. > > I remember we discussed it and somehow it got rejected. I can't > remember the reason for it, and I personally don't care much either way > (my macros tend to use C-[aefb], and sexp-based movement but not much > C-[np]). > >> There is already one such change: vertical movement does not use vscroll >> in order to go smoothly through vertical material when macro recording >> or playback is active. > > Didn't know about that. Can you point me to the relevant piece of code? See around the ;; But don't vscroll in a keyboard macro. comment in lisp/simple.el: ;; This is like line-move-1 except that it also performs ;; vertical scrolling of tall images if appropriate. ;; That is not really a clean thing to do, since it mixes ;; scrolling with cursor motion. But so far we don't have ;; a cleaner solution to the problem of making C-n do something ;; useful given a tall image. (defun line-move (arg &optional noerror to-end try-vscroll) (unless (and auto-window-vscroll try-vscroll ;; Only vscroll for single line moves (= (abs arg) 1) ;; But don't vscroll in a keyboard macro. (not defining-kbd-macro) (not executing-kbd-macro) (line-move-partial arg noerror to-end)) (set-window-vscroll nil 0 t) (if line-move-visual (line-move-visual arg noerror) (line-move-1 arg noerror to-end)))) -- David Kastrup ^ permalink raw reply [flat|nested] 165+ messages in thread
[parent not found: <hv8gvf$98o$1@north.jnrs.ja.net>]
[parent not found: <hv8iog$313e$1@colin2.muc.de>]
* Re: line-move-visual [not found] ` <hv8iog$313e$1@colin2.muc.de> @ 2010-06-15 19:37 ` Leo 2010-06-15 21:04 ` line-move-visual Uday S Reddy 1 sibling, 0 replies; 165+ messages in thread From: Leo @ 2010-06-15 19:37 UTC (permalink / raw) To: help-gnu-emacs On 2010-06-15 20:02 +0100, Alan Mackenzie wrote: Let's forget about this line-move-visual. It has happened and just turned it off in your site-start.el for good or even patch emacs source locally to get rid of it. It was targeting potential new users. I think what would be interesting is to clean up the mess in elisp. We have cl and eieio that provide half-assed compatibility for common lisp. Why not use the real thing instead by rebasing emacs onto common lisp and gradually phase out elisp? That would bring in some good new users to the community. Leo ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual [not found] ` <hv8iog$313e$1@colin2.muc.de> 2010-06-15 19:37 ` line-move-visual Leo @ 2010-06-15 21:04 ` Uday S Reddy 2010-06-16 15:33 ` line-move-visual Alan Mackenzie 1 sibling, 1 reply; 165+ messages in thread From: Uday S Reddy @ 2010-06-15 21:04 UTC (permalink / raw) To: help-gnu-emacs Alan Mackenzie wrote: > >> You can set your own defaults in your .emacs to get the behaviour you >> like and so can all the other people. > > This garbage again. When we're talking only about the best settings for > defaults, going on about .emacs is stupid. Interesting. When I raised the issue of defaults in the developers list, I was advised by Stefan to set my own default. Apparently, he didn't think it was stupid to do so. When I said this morning that you had fallen silent, my meaning was that you did not provide an answer. Calling the question "silly" or "stupid" does not amount to an answer, does it? Why don't you leave it to Stefan to speak for himself? I am sure that Stefan and I are able to have a perfectly normal, professional conversation without your help. Cheers, Uday ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-15 21:04 ` line-move-visual Uday S Reddy @ 2010-06-16 15:33 ` Alan Mackenzie 2010-06-17 8:51 ` line-move-visual Uday S Reddy 0 siblings, 1 reply; 165+ messages in thread From: Alan Mackenzie @ 2010-06-16 15:33 UTC (permalink / raw) To: help-gnu-emacs In comp.emacs Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> wrote: > Alan Mackenzie wrote: >>> You can set your own defaults in your .emacs to get the behaviour you >>> like and so can all the other people. >> This garbage again. When we're talking only about the best settings >> for defaults, going on about .emacs is stupid. > Interesting. When I raised the issue of defaults in the developers > list, I was advised by Stefan to set my own default. Apparently, he > didn't think it was stupid to do so. Not whilst addressing somebody wearing a user's hat. It's a stupid distraction for the maintainers whilst pondering defaults. > When I said this morning that you had fallen silent, my meaning was > that you did not provide an answer. Calling the question "silly" or > "stupid" does not amount to an answer, does it? It can do. There are questions which can be used to derail a discussion, should the questioner wish this. I have a suspicion this is one of your aims here. If you're not trolling, then please accept my apologies and carefully review your posts to see where that impression came from. > Why don't you leave it to Stefan to speak for himself? I am sure that > Stefan and I are able to have a perfectly normal, professional > conversation without your help. Yet more snide remarks, yes? I'm not going to rise to it this time. > Cheers, > Uday -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-16 15:33 ` line-move-visual Alan Mackenzie @ 2010-06-17 8:51 ` Uday S Reddy 0 siblings, 0 replies; 165+ messages in thread From: Uday S Reddy @ 2010-06-17 8:51 UTC (permalink / raw) To: help-gnu-emacs On 6/16/2010 4:33 PM, Alan Mackenzie wrote: > > It can do. There are questions which can be used to derail a discussion, > should the questioner wish this. I have a suspicion this is one of your > aims here. If you're not trolling, then please accept my apologies and > carefully review your posts to see where that impression came from. I wasn't trolling. Apology accepted. Cheers, Uday ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual [not found] ` <hv8gvf$98o$1@north.jnrs.ja.net> [not found] ` <hv8iog$313e$1@colin2.muc.de> @ 2010-06-16 14:33 ` Stefan Monnier 1 sibling, 0 replies; 165+ messages in thread From: Stefan Monnier @ 2010-06-16 14:33 UTC (permalink / raw) To: help-gnu-emacs > Judgment call is ok, and none of us can claim that we are perfect at that. > But what concerns me is that after seeing all the discussion here, you still > maintain that you "don't regret the decision" because a lot of people like > it. So, are you opening Emacs to potentially unsafe changes in an effort to > get people to like it? Getting people to like Emacs is one of the goals, of course. But I tend to think more of "what would be the best settings for most users" (note that I said "best", not "least controversial", nor "easiest to adapt to"). Of course, this has to be balanced against "don't alienate existing users" (which is also spelled "preserve backward compatibility of the UI"). For the same kind of reason, Emacs-24 will change the way minor-modes react when called with a nil argument (in Emacs-23, it toggles the mode, in Emacs-24 it turns it ON unconditionally). In this case, this doesn't change the UI (when called interactively, the arg is never nil), but for some users, their .emacs will end up doing something else than what they intended. This was deemed OK, because for many more users this change will make their .emacs DTRT (i.e. it will silently fix a lurking bug in their config), and it also makes it easier to add minor modes on hooks, without having to rely on the existence of a turn-on-foo-mode or the use of the more verbose (lambda () (foo-mode 1)). I know some people will complain. We always hear them a lot more than those who benefit from such changes. > You also haven't acknowledged that Emacs gets used as a platform on which > other services are delivered, such as programming environments or mail > clients. Your response only touches upon the use of Emacs for personal text > editing. Imagine, for instance, that your favourite mail client happened to > use `next-line' instead of `forward-line' somewhere in handling the mail > headers. The byte-compiler flags this, luckily. > It could damage the mail folders irretrievably over a period of time > before it ever gets noticed. Is that kind of trouble an appropriate > price to pay for the "convenience" you talk about? Every Emacs release brings in incompatibilities for Elisp code, many of which aren't ever flagged by the byte-compiler. So this particular `next-line' change for Elisp code is but one of many other such problems, and experience has shown it was not particularly serious. Stefan ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-15 8:42 ` line-move-visual Uday S Reddy ` (2 preceding siblings ...) 2010-06-15 13:45 ` line-move-visual Stefan Monnier @ 2010-06-15 16:51 ` Alan Mackenzie 2010-06-16 12:43 ` line-move-visual David Kastrup 2010-06-15 19:17 ` line-move-visual Xah Lee [not found] ` <4C17FE36.30102@thadlabs.com> 5 siblings, 1 reply; 165+ messages in thread From: Alan Mackenzie @ 2010-06-15 16:51 UTC (permalink / raw) To: help-gnu-emacs In comp.emacs Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> wrote: > On 6/15/2010 7:54 AM, Pascal J. Bourguignon wrote: > But I feel this discussion is tangential. Most of us accept that > visual line movement is a /good/ idea and we find it useful in lots of > contexts. We are grateful for Stefan & co for thinking of it and > implementing it. > The question is really whether it should have been made the default. Yes. That is a very difficult question. Most contentious issues discussed on the developers' list are about changing defaults. This was one of these. > Every time I narrowed down to that issue in this thread, the > participants have fallen silent (first Xah Lee then Tim Cross, Alan > Mackenzie and Stefan himself). I guess there is no good answer to it. Ooh, talk about trolling! ;-) I have "fallen silent" because I've nothing much fresh to say. > There is no need for us to beat a dead horse. If the developers accept > that it is a bad idea to introduce backward-incompatible changes for > flimsy reasons, Emacs will be a more useful system for all of us than > it currently is. Normally I'd find myself arguing strongly in the camp of the "traditionalists" when fighting over a change in defaults. For this particular change, I'm ambivalent. The hassle with directly editing long lines is, I believe, more painful than that of navigating keyboard macros through them. Somebody had to decide this issue, and that somebody was Stefan. I think, on balance, he made the right choice. I wouldn't have been complaining if he had decided the opposite. > Fortunately, nothing major is going to fall apart as a result of > `next-line' changing its meaning. But I hope that we can arrest this > trend right here so that we don't have to put up with more pain in > future. "Trend"? You are getting polemic! Emacs will continue to evolve steadily, and some of the changes will cause you minor pain, as they will me. You're surely used to tweaking your .emacs on every major release, so what's new? > Cheers, > Uday -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-15 16:51 ` line-move-visual Alan Mackenzie @ 2010-06-16 12:43 ` David Kastrup 0 siblings, 0 replies; 165+ messages in thread From: David Kastrup @ 2010-06-16 12:43 UTC (permalink / raw) To: help-gnu-emacs Alan Mackenzie <acm@muc.de> writes: > In comp.emacs Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> wrote: > >> Every time I narrowed down to that issue in this thread, the >> participants have fallen silent (first Xah Lee then Tim Cross, Alan >> Mackenzie and Stefan himself). I guess there is no good answer to >> it. > > Ooh, talk about trolling! ;-) I have "fallen silent" because I've > nothing much fresh to say. Huh? Did you think that a discussion involves anything apart from everybody repeating himself until all but one have given up? Are you old-fashioned or what? -- David Kastrup ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-15 8:42 ` line-move-visual Uday S Reddy ` (3 preceding siblings ...) 2010-06-15 16:51 ` line-move-visual Alan Mackenzie @ 2010-06-15 19:17 ` Xah Lee [not found] ` <4C17FE36.30102@thadlabs.com> 5 siblings, 0 replies; 165+ messages in thread From: Xah Lee @ 2010-06-15 19:17 UTC (permalink / raw) To: help-gnu-emacs On Jun 15, 1:42 am, Uday S Reddy <uDOTsDOTre...@cs.bham.ac.uk> wrote: > On 6/15/2010 7:54 AM, Pascal J. Bourguignon wrote: > > > > > Well, C-f C-n is all you need. I mean, keep C-f pressed until the > > cursor reaches the column you want, you don't even need to count > > 76. And keep C-n pressed until the cursor reaches the line you want. > > Except that pressing control-key for that long with your pinky is a health risk! > > But I feel this discussion is tangential. Most of us accept that visual line > movement is a /good/ idea and we find it useful in lots of contexts. We are > grateful for Stefan & co for thinking of it and implementing it. > > The question is really whether it should have been made the default. > > Every time I narrowed down to that issue in this thread, the participants have > fallen silent (first Xah Lee then Tim Cross, Alan Mackenzie and Stefan > himself). I guess there is no good answer to it. i find it great that line-move-visual defaults to t. And i find it good that nothing else is changed about Ctrl+n, with the result that it just move lines visually in emacs 23.x. All things considered. I thought about it for a while when you presented a perspective of what we are arguing about. But the more i think about it, the more the conclusion above. i find many discussions here silly... writing here takes a lot time. Typically, just 2 posts take out the whole day. Same as elsewhere in mailing lists or private communication with co-workers in a company... Answering a few emails or exchanging opinions takes out the whole day... i find it silly that Mark Crispin insists this is so bad or breaks backward compatibility or his attacks on commercial software and opinions on certain “FOSS” or “FUD” jargons ... etc. It'd be endless flame war to argue one way or another. Usually fruitless. but i enjoyed the thread anyway. I enjoyed having to cite my essays, enjoyed knowing about Mark Crispin, enjoyed to have learned who contributed the code for the line-move-visual feature. (in fact spent a hour or two to link to home pages of all i found who contributed major features in 23.x) If i have more time at leisure, i'd sure enjoy throwing flames to annoy Mark and few of you acquaintances. LOL. maybe we can start another flamewar of a diff subject. I'm quite annoyed that emacs 23.2 has chosen the trivial espresso mode as the javascript mode and screwed Steve Yegg's far much ambitious, talented, and revolutionary and modern and WORKING js mode the js2-mode that includes a on-the-fly js language parser. I attribute it to the now bureaucratic inefficiency of gnu.org management... i was on the gnu dev list when this thread was discussed, was rather pissed that the espresso mode author young 20 something bigshot talking shit about how emacs font lock myth this or that. I can write a espresso mode myself in a day. But i doubt most who have coded elisp for 10 years can pull off Steve's js2-mode. Not me. Xah ∑ http://xahlee.org/ ☄ ^ permalink raw reply [flat|nested] 165+ messages in thread
[parent not found: <4C17FE36.30102@thadlabs.com>]
* Re: line-move-visual [not found] ` <4C17FE36.30102@thadlabs.com> @ 2010-06-15 22:45 ` Xah Lee 2010-06-15 23:31 ` line-move-visual Thad Floryan 2010-06-16 14:52 ` line-move-visual Stefan Monnier 0 siblings, 2 replies; 165+ messages in thread From: Xah Lee @ 2010-06-15 22:45 UTC (permalink / raw) To: help-gnu-emacs On Jun 15, 3:27 pm, Thad Floryan <t...@thadlabs.com> wrote: > On 6/15/2010 1:42 AM, Uday S Reddy wrote: > > > On 6/15/2010 7:54 AM, Pascal J. Bourguignon wrote: > > >> Well, C-f C-n is all you need. I mean, keep C-f pressed until the > >> cursor reaches the column you want, you don't even need to count > >> 76. And keep C-n pressed until the cursor reaches the line you want. > > > Except that pressing control-key for that long with your pinky is a > > health risk! > > [...] > > That's why remapping the [Caps Lock] to be a [Ctrl] is very useful. > swapping Caps Lock with Ctrl is not good. • Why You Should Not Swap Caps Lock With Control http://xahlee.org/emacs/swap_CapsLock_Ctrl.html plain text version follows: ------------------------------------------------------------------------ Why You Should Not Swap Caps Lock With Control Xah Lee, 2008-07-10 Swapping the Caps Lock key with the Control key is one of the bad advice in keyboarding. It's one of the myth that perpetuate bad practice. It does damage to your finger's health. Here are the reasons why: * On a typical PC keyboard of today, the Caps Lock is the most difficult modifier key to press, and is pressed by the weakest finger pinky. The Control key can be easily pressed with palm. * It makes the left pinky do 2 pinkies's work. (try to pick out your right Shift key and type for a week and see how you feel) * It forces the left hand to strain into spider legs positions. Or, it forces your right hand to flies about wildly if the letter key is near the middle of the keyboard (example: CapsLock+T, CapsLock+G, CapsLock+B). * It renders many Ctrl+‹key› spots void, since now with only one pinky many otherwise good Ctrl+‹key› spots are hard to use. * The left hand now constantly shift from home position. The above assumes that you do TOUCH TYPE. If you do not touch type, you really need to learn that first before you can talk about hand health. The above also assumes that you are using a full sized keyboard, not the keyboard on laptops. If you are stuck with a laptop computer keys, then you need to get a full PC keyboard first. Prolonged typing on laptop sized computer is sure way to damage your hands. -------------------------------------------------- Good Tips * If you use the Ctrl key much more frequently than Alt, then do swap them. Because, Alt is much easy to press, with the thumb. (See: How To Swap Caps Lock, Alt, Control Keys On Windows, How to Swap Modifier Keys on OS X) * Buy a keyboard with Control on both sides of keyboard. * Buy a keyboard such that the modifier keys are placed symmetrically with respect to F and J keys. (That is, the distance between Left Control to F should be the same as right Control to J.) * Press modifier keys using both hands, in the same way of using Shift key in touch typing. If the letter is on the left side, use the Ctrl key on the right side, and vice versa. * On most full sized PC keyboard, it's very easy to use palm or semi-fist to press Control key. Do this and save the Pinky. -------------------------------------------------- Why You Should Not Swap Caps Lock With Control Among tech geeking circles, it's widely recommended like a dogma, to swap Caps Lock and Ctrl keys. However, remapping Control to Caps Lock seriously violates some basic ergonomic principles. In touch typing, modifiers comes in pairs, such as Shift. The accepted ergonomic way to press them is using one hand to press the modifier and the other to press the letter key. You can see how it is otherwise by disabling one of the Shift key. With just one modifier, you are heavily handicapped. As a example, try this exercise: TYPE THIS SENTENCE WITH ONLY THE LEFT SHIFT KEY AND WITHOUT USING CAPS LOCK. Quickly, you'll see the pain. Similar is with other modifier keys such as Alt and Ctrl. The reason they are not noticed only because they are seldom used. However, in emacs, it is heavily used. So, by mapping Ctrl to the Caps Lock key, you put a severe handicap by putting all work into the left pinky, and restrict the number of keys you can comfortably use with Ctrl. The reason that many tech geekers still recommend it is because the Ctrl key is traditionally on the corner of keyboard and rather difficult to press. Also, many keyboards does not have right Ctrl. So, in a sense, Caps Lock as Ctrl is a improvement. It is especially a good solution on laptop's keyboards. There are 2 ways to remedy the problem of pressing of Ctrl. One is to buy a good keyboard that has big Alt and Ctrl keys, and on both sides of the keyboard, and symmetrically placed with respect to your thumbs when hands in home position. (some keyboards, such as Apple keyboard, has the right side modifiers far to the right, rendering them unusable for touch typing) Microsoft's ergonomic keyboard are very good with respect to this, and also vast majority of generic PC keyboards. The other way is to learn to type the corner Ctrl by pressing down your palm or semi fist, instead of poking it with your pinky. This can be comfortably done on most PC keyboards. (See: photo of generic PC keyboard) To see which is better, you can type this sentence and press Ctrl for every letter. (do it outside of emacs) You can quickly find out which way is better for you. The above assumes you touch type. If you don't, some tips may not apply, and you really should learn touch typing first. -------------------------------------------------- Anecdotes vs Ergonomics Joel wrote: «... do not use two fingers on the same hand at the same time, except in emergencies. ...». YSK wrote: «Seriously? I do this all the time. Some of my favorite (non-emacs) shortcuts include stuff like C-M-S-e, all done with my left hand. Is that bad?». -------------------------------- One Modifier Key Yes and no. In general, if you just have one modifier key and one letter key, the proper touch typing guidline is to use one hand on the modifier and the other on the letter. Choose the modifier on the other side of the letter key. You can test this out. Try to type this whole sentence in captical letters (but without using Caps Lock). First, try it using just the left Shift key. Then try it using the touch type guidline as above. You'll see how using single hand creates pain. Similarly, you can try the above with the Control key as modifier. -------------------------------- Multiple Modifier Keys When you have multiple modifier, it gets a bit more complex and the rule applies less. Ultimately, there are several factors involved. For example, the keyboard hardware is not well designed due to historical reasons. (See: Keyboard Hardware Design Flaws) Secondly, many keyboards such as Apple's that has the right hand side's modifier far to the right, making them less usable for touch type. Lastly, the principles of ergonomics presumes you are doing the task repeatitively for a prolonged time. Else it doesn't apply. For example, for vast majority of computer users (say 95%), they only type maybe for 1 hour per day, and there's not much activity of continued typing more than 5 min. Lots of professional programers don't even touch type; partly because heavy duty data-entry is not really part of programing. And when it comes to Control key, or multiple modifiers, they are not used that much often, so whichever works for you is ok. However, this does not mean it's completely a personal issue without any scientific criterion on what is better. For example, of all the styles and anecdotes you hear about how you should press modifier, you can easily test them out and find the better one, by say, force yourself to continuously operate it for 10 min using one way, then do the same test with another way. You'll quickly see which one is more tiring and which is faster with less effort. Xah ∑ http://xahlee.org/ ☄ ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-15 22:45 ` line-move-visual Xah Lee @ 2010-06-15 23:31 ` Thad Floryan 2010-06-16 3:30 ` line-move-visual Evans Winner 2010-06-16 23:23 ` line-move-visual Chris F.A. Johnson 2010-06-16 14:52 ` line-move-visual Stefan Monnier 1 sibling, 2 replies; 165+ messages in thread From: Thad Floryan @ 2010-06-15 23:31 UTC (permalink / raw) To: help-gnu-emacs On 6/15/2010 3:45 PM, Xah Lee wrote: > On Jun 15, 3:27 pm, Thad Floryan <t...@thadlabs.com> wrote: >> On 6/15/2010 1:42 AM, Uday S Reddy wrote: >> >>> On 6/15/2010 7:54 AM, Pascal J. Bourguignon wrote: >>>> Well, C-f C-n is all you need. I mean, keep C-f pressed until the >>>> cursor reaches the column you want, you don't even need to count >>>> 76. And keep C-n pressed until the cursor reaches the line you want. >>> Except that pressing control-key for that long with your pinky is a >>> health risk! >>> [...] >> That's why remapping the [Caps Lock] to be a [Ctrl] is very useful. >> > > swapping Caps Lock with Ctrl is not good. > > • Why You Should Not Swap Caps Lock With Control > http://xahlee.org/emacs/swap_CapsLock_Ctrl.html > [...] Your opinion which neither I nor 100,000s of others share -- you stand alone. A [Ctrl] to the left of [A] is natural and what I've been using since the mid-1960s with absolutely NO problems or RSI whatsoever beginning with a TTY ASR33 and continuing with a Datapoint 3300, DEC VT100, Datamedia DT80 and others along the way to today. Mapping and using the [Caps Lock] as a [Ctrl] to the immediate left of [A] is no different than the ["] to the immediate right of [;] re: pinkies. The (dumb) PC standard of a [Ctrl] key at the lower-left of a keyboard is ridiculous and WILL cause pinky problems if one uses Emacs as an editor and bash as a shell. ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-15 23:31 ` line-move-visual Thad Floryan @ 2010-06-16 3:30 ` Evans Winner 2010-06-16 16:14 ` line-move-visual Xah Lee 2010-06-16 23:23 ` line-move-visual Chris F.A. Johnson 1 sibling, 1 reply; 165+ messages in thread From: Evans Winner @ 2010-06-16 3:30 UTC (permalink / raw) To: help-gnu-emacs ,------ Thad Floryan wrote ------ | Your opinion which neither I nor 100,000s of others | share -- you stand alone. Not alone. I've read similar advice in the past. What I would like to try is a situation in which holding down SPC and then hitting something else causes SPC to act like Control. But if nothing is hit along with SPC then it sends a Space character on key-up. Obviously this would have the drawback that one could not get repeated spaces by holding down the space key, but I would like to at least experiment with it. I don't know if it is possible to map the keys that way, though. I've looked into it a bit, but not figured it out. Failing that, I do use Caps-Lock and Control swapped and have for some time. It doesn't seem terribly harmful to me. The idea of palming the Control key is interesting, but it seems as if it would require tiny hands to really do comfortably. For me, I do have to move my hands awkwardly from the home row to do that, whereas I don't really have to move from the home row to hit the key to the left of `A'. Maybe it was all the piano playing back in the day, but my fifth finger moves the slight bit sideways pretty fluently. ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-16 3:30 ` line-move-visual Evans Winner @ 2010-06-16 16:14 ` Xah Lee 0 siblings, 0 replies; 165+ messages in thread From: Xah Lee @ 2010-06-16 16:14 UTC (permalink / raw) To: help-gnu-emacs On Jun 15, 8:30 pm, Evans Winner <tho...@unm.edu> wrote: > ,------ Thad Floryan wrote ------ > | Your opinion which neither I nor 100,000s of others > | share -- you stand alone. > > Not alone. I've read similar advice in the past. > > What I would like to try is a situation in which holding > down SPC and then hitting something else causes SPC to act > like Control. But if nothing is hit along with SPC then it > sends a Space character on key-up. Obviously this would > have the drawback that one could not get repeated spaces by > holding down the space key, but I would like to at least > experiment with it. I don't know if it is possible to map > the keys that way, though. I've looked into it a bit, but > not figured it out. > > Failing that, I do use Caps-Lock and Control swapped and > have for some time. It doesn't seem terribly harmful to me. > The idea of palming the Control key is interesting, but it > seems as if it would require tiny hands to really do > comfortably. For me, I do have to move my hands awkwardly > from the home row to do that, whereas I don't really have to > move from the home row to hit the key to the left of `A'. > Maybe it was all the piano playing back in the day, but my > fifth finger moves the slight bit sideways pretty fluently. whether you can use the palm edge to hit control key depends on your keyboard of course. On vast majority of generic PC keyboard, that can be trivially done, regardless if you have large or small hands. You can see picts of several keyboards here, including a generic PC one that's usually just $6. • Computer Keyboards Gallery http://xahlee.org/emacs/keyboards.html you can also see a pict and video of the Daz Keyboard, which follows the standard generic PC keyboard shape: • The Idiocy of Hacker Keyboards http://xahlee.org/emacs/keyboards_hacker_idiocy.html you can also see the classic IBM keyboard there with its huge Control key. it is so easy to hit with the palm. Just push down your palm and you hit it. Almost easier than pressing keys with index finger on the home row. Xah ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-15 23:31 ` line-move-visual Thad Floryan 2010-06-16 3:30 ` line-move-visual Evans Winner @ 2010-06-16 23:23 ` Chris F.A. Johnson 1 sibling, 0 replies; 165+ messages in thread From: Chris F.A. Johnson @ 2010-06-16 23:23 UTC (permalink / raw) To: help-gnu-emacs On 2010-06-15, Thad Floryan wrote: ... > The (dumb) PC standard of a [Ctrl] key at the lower-left of a keyboard is > ridiculous and WILL cause pinky problems if one uses Emacs as an editor and > bash as a shell. I have no problems using the Ctrl keys (left and right) with emacs and bash. I also have the CapsLock key as Ctrl, but I never use it; the change is mostly to disable CapsLock, which I have never used, and which is annoying when hit accidentally. -- Chris F.A. Johnson, <http://cfajohnson.com> Author: Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress) Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress) ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-15 22:45 ` line-move-visual Xah Lee 2010-06-15 23:31 ` line-move-visual Thad Floryan @ 2010-06-16 14:52 ` Stefan Monnier [not found] ` <87r5k6sqg2.fsf@unm.edu> 1 sibling, 1 reply; 165+ messages in thread From: Stefan Monnier @ 2010-06-16 14:52 UTC (permalink / raw) To: help-gnu-emacs > The above assumes that you do TOUCH TYPE. If you do not touch type, > you really need to learn that first before you can talk about hand > health. Another way to look at it: if you have hand-health problems, first try to unlearn to touch-type. Stefan "who doesn't touch type" ^ permalink raw reply [flat|nested] 165+ messages in thread
[parent not found: <87r5k6sqg2.fsf@unm.edu>]
* Re: line-move-visual [not found] ` <87r5k6sqg2.fsf@unm.edu> @ 2010-06-17 2:25 ` Stefan Monnier 2010-06-17 3:51 ` line-move-visual Chris F.A. Johnson 2010-06-17 9:03 ` line-move-visual Uday S Reddy 1 sibling, 1 reply; 165+ messages in thread From: Stefan Monnier @ 2010-06-17 2:25 UTC (permalink / raw) To: help-gnu-emacs > I would be very interested if you were willing to expand on this. > Do you mean to say that touch typing is unhealthy in general, or just > more pragmatically that if it hurts when you do X, then don't do X? Just that I've known several people who suffered from RSI and several people who can't touch-type and the two sets are disjoint. A correlation between the two is expected (people who type a lot are more likely to know how to touch-type), but the fact that the two sets are actually disjoint is I think more than a coincidence. If you look at people who don't touch-type (like me), you'll see their hands move a lot, so their arms work more and their hands and fingers work less. Stefan ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-17 2:25 ` line-move-visual Stefan Monnier @ 2010-06-17 3:51 ` Chris F.A. Johnson 0 siblings, 0 replies; 165+ messages in thread From: Chris F.A. Johnson @ 2010-06-17 3:51 UTC (permalink / raw) To: help-gnu-emacs On 2010-06-17, Stefan Monnier wrote: >> I would be very interested if you were willing to expand on this. >> Do you mean to say that touch typing is unhealthy in general, or just >> more pragmatically that if it hurts when you do X, then don't do X? > > Just that I've known several people who suffered from RSI and several > people who can't touch-type and the two sets are disjoint. > A correlation between the two is expected (people who type a lot are > more likely to know how to touch-type), but the fact that the two sets > are actually disjoint is I think more than a coincidence. > > If you look at people who don't touch-type (like me), you'll see their > hands move a lot, so their arms work more and their hands and fingers > work less. The home position for a touch typist is an awkward one, and, I suspect, contributes significantly to wrist problems. I've been using a typewriter for 50 years, and for the last 30 I have almost lived at one, both at work and at home, but still don't touch type. I have had no problems with my wrists. -- Chris F.A. Johnson, <http://cfajohnson.com> Author: Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress) Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress) ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual [not found] ` <87r5k6sqg2.fsf@unm.edu> 2010-06-17 2:25 ` line-move-visual Stefan Monnier @ 2010-06-17 9:03 ` Uday S Reddy 2010-06-20 18:42 ` line-move-visual B. T. Raven 1 sibling, 1 reply; 165+ messages in thread From: Uday S Reddy @ 2010-06-17 9:03 UTC (permalink / raw) To: help-gnu-emacs On 6/16/2010 8:55 PM, Evans Winner wrote: > ,------ Stefan Monnier wrote ------ > > | Another way to look at it: if you have hand-health > | problems, first try to unlearn to touch-type. > > I would be very interested if you were willing to expand on > this. Do you mean to say that touch typing is unhealthy in > general, or just more pragmatically that if it hurts when > you do X, then don't do X? As somebody that does touch typing and have had heavy RSI problems, I can throw some light on this. Touch typing is perfectly fine normal text, but it wasn't designed for Emacs. The heavy use of the little finger for Control and Meta keys puts undue load on it. Keyboards that had single Control or Meta keys worsened the problem by making the hands stretch over long distances. As part of my recovery from RSI, I had to retrain myself to avoid the use of Control/Meta keys for long periods (for instance by using the arrow keys or the mouse), and also to get away from the "home position" when needed so that I can use other fingers for Control/Meta keys. I am now perfectly fine for typing normal text, but I get sore tendons when I have to do TeX/LaTeX. They make a heavy use of '\' which is placed on lousy positions on most keyboards. Cheers, Uday ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-17 9:03 ` line-move-visual Uday S Reddy @ 2010-06-20 18:42 ` B. T. Raven 0 siblings, 0 replies; 165+ messages in thread From: B. T. Raven @ 2010-06-20 18:42 UTC (permalink / raw) To: help-gnu-emacs Uday S Reddy wrote: > On 6/16/2010 8:55 PM, Evans Winner wrote: >> ,------ Stefan Monnier wrote ------ > >> >> | Another way to look at it: if you have hand-health >> | problems, first try to unlearn to touch-type. >> >> I would be very interested if you were willing to expand on >> this. Do you mean to say that touch typing is unhealthy in >> general, or just more pragmatically that if it hurts when >> you do X, then don't do X? > > As somebody that does touch typing and have had heavy RSI problems, I > can throw some light on this. > > Touch typing is perfectly fine normal text, but it wasn't designed for > Emacs. The heavy use of the little finger for Control and Meta keys puts > undue load on it. Keyboards that had single Control or Meta keys > worsened the problem by making the hands stretch over long distances. Either Keytweak (w32) or xmodmap (Gnu-Linux) can swap all modifier (or most other) keys. An important consideration in the keyboard layout is that it be strictly bilaterally symetrical, so that modifier keys are used exactly the way shift keys are. E.g. Right-shift, a to make A, right-control, a to go to beginning of line, and the same for all other combos: right-control x left-control f to find-file. [On Dvorak layout]It may sound unworkable until you try it. Bottom row is (left to right) super, alt, ctl spacebar ctl, alt, super. Even more comfortable would be slpit spacebar with backspace on left half. Since the process of moving a tiny plastic dome down 1/4 inch doesn't require any vigorous motion (unlike for instance in playing the piano) it might even be useful to move the shift key between ctl and left-space-bar (backspace). This could be accomplished by stealing from space-bar real estate and moving it half a key to the right. This optimum (for me anyway) layout would be: Super[1] Alt[1] Ctl[1] Shift[1] Backspace[2] Space[2] Shift[1] Ctl[1] Alt[1] Super[1] (Numbers are widths in standard alpha keywidth units) Now all modifier keys are on the same row and the keyboard can be played instead of worked. Remember, the key justs sends a scancode; it doesn't have to move any heavy metal around. > > As part of my recovery from RSI, I had to retrain myself to avoid the > use of Control/Meta keys for long periods (for instance by using the > arrow keys or the mouse), and also to get away from the "home position" > when needed so that I can use other fingers for Control/Meta keys. But the RSI is caused either by a key layout inappropriate to the application or by grueling gruntwork like typing from hard-copy, data input, or dictaphone transcription. If a sane keyboard layout is a temptation to work too hard then we'll just have to add a subroutine to get out of the chair every 15 minutes to say prayers, thumb wrestle, or what have you. > > I am now perfectly fine for typing normal text, but I get sore tendons > when I have to do TeX/LaTeX. They make a heavy use of '\' which is > placed on lousy positions on most keyboards. Try putting |\ on the Caps Lock key. The dash-underscore is already in a good place for Emacs on the Dvorak layout. In my dream keyboard (vide supra) the open and close parentheses could be mapped to Right-Shift back-space and Left-Shift Space, respectively. Such a keyboard would cost about $5 to manufacture and would be worth $200 to me. Ed > > Cheers, > Uday > > ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual [not found] ` <jwvaaqxbcca.fsf-monnier+gnu.emacs.help@gnu.org> 2010-06-15 6:54 ` line-move-visual Pascal J. Bourguignon @ 2010-06-20 17:08 ` B. T. Raven 1 sibling, 0 replies; 165+ messages in thread From: B. T. Raven @ 2010-06-20 17:08 UTC (permalink / raw) To: help-gnu-emacs Stefan Monnier wrote: >>> principal way of working, rather than in special cases in some obscure >>> feature (keyboard macros). >> Keyboard macros are far from obscure. > > Indeed. > >>> And it was dashed near impossible to move easily to the middle of >>> long, long lines. >> C-u <some number> right-arrow Or more conveniently: C-s <some chars> [C-s ad libitum] RET > > How convenient! > Say you're in a window and want to go down 3 visual lines on the same > long logical line. What number do you use? Ok, let's make it easier > and say that you happen to know that the window is 76-chars wide. > So 76 by 3? quick? quick? > Now let's do that again but with 13 lines, where you don't actually know > it's "13": you first have to count it. > The best I could come up with, is C-76 C-f and then C-x z z z ... until > you reach the line. > > Now this all becomes a lot more interesting once you add word-wrap into > the mix, or TABs, or bytes displayed \NNN, or the presence of various > fonts and/or font-sizes on that long line, or variable-pitch fonts, ... > > Clearly visual line movement is really handy in such long lines. > So rather than "C-u <some number> right-arrow", the better answer would > have been: M-x visual-line-mode RET C-n ... > > > Stefan "who reached for the mouse in all those cases, tho > typically only after first unconsciously hitting C-n > a few times and then realizing that C-n jumped way > further than intended" Or, since text editors are trying to wean themselves of everything that smacks of word processing, it might be better to follow Mark Crispin's suggestion to make line-move-visual default to nil and to bind the up -down arrow keys to long-lines navigation. Ed ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-11 23:56 ` line-move-visual Mark Crispin 2010-06-12 0:17 ` line-move-visual Wojciech Meyer @ 2010-06-12 4:18 ` Tim X 2010-06-12 4:37 ` line-move-visual Evans Winner [not found] ` <huvsd5$8pm$1@north.jnrs.ja.net> 1 sibling, 2 replies; 165+ messages in thread From: Tim X @ 2010-06-12 4:18 UTC (permalink / raw) To: help-gnu-emacs Mark Crispin <mrc@panda.com> writes: > On Thu, 10 Jun 2010, Uday S Reddy posted: >> By community ownership, I only mean that all the people that have a stake in >> the system have a voice in the matter and we all feel ownership of the >> system. When the community is divided, as seems to be the case on this >> issue, the developers have to make a decision and move on. > > The problem is that nobody ever asked the existing users whether or not they > wanted this global change foisted upon them. Rather, it was done > unilaterally, and the individuals responsible are saying "See! Some people > like it! It was a good change." > This is not really correct. The change was discussed in a forum that is open to anyone who is interested. More accurately, a criticism could be that it wasn't discussed in the correct forum. However, that in itself is extremely difficult to identify. For example, how would most of the users feel if every discussion regarding emacs development, even if restricted to discussions that directly impact on basic/core behavior (however that would be defined). was posted to this list? I suspect that many would be irritated as this is supposed to be an emacs help forum, not a discussion forum for developments. A possible solution would be to ensure a page is maintained on the emacs wiki that discussed some of the proposed developments, especailly those that may be contentious. A regular post could go to this list pointing to the relevant page. This would possibly let those who are interested know about propsed changes and enable them to participate. Of course this won't reach everyone and there will still be some who are surprised by changes and possibly get upset. This is unavoidable. All that can be done is to make it clear what forums are available and try harder to get wider discussion, particularly with changes that are likely to have a big impact. > This sort of thing happened in the past as well. The difference was that > there was accountability in the past that is absent today. > >> In my humble opinion, it is easy to argue that the current default was >> ill-chosen. But it is not so easy to argue that it should be changed. If >> we change it, then we face all the same issues all over again affecting the >> other users that are depending on the current default. So, it seems best to >> leave things as they are and make a note of all the lessons learned. > > I agree that we are probably screwed, and royally so. > > I have a new task on my list: replace emacs in the procedures for my target > audience since emacs is no longer suitable for that purpose. I simply can not > tell these users "make sure that you set line-move-visual to nil"; they would > have no clue what that means. More likely than not, I will end up being > obliged to write a program for the task; and there will be one less way those > users will be exposed to emacs. > Why not just set it back to its previous default in a site startup file? Most distributions already have one of these - all that is required is a single line! > One of the advantages of the "software tools" mindset of the past was that you > did not have to write a program for every task. Instead, you could leverage > the existing tools. That falls apart when those tools are corrupted so that > they no longer can be relied upon to produce predictable results. > >>> But even the laymen become power-corrupted. >> I think that is a bit of an exaggeration. They have a responsibility to >> bear and sometimes they get carried away. > > Every young programmer wants to put his own mark on things. The problem is > that these changes are frequently ill-considered and sometimes have bad > consequences. > Even well considered changes can have bad consequences. Hindsight is a wonderful thing! This personal attack you continue to make on the developers is very tiresome. Emacs is developed by a large range of people. They vary in age, vary in location and native language and vary in experience. Not many of them are regular posters to this list. You seem to be under the illusion that the developers are some closed powerful group sitting in a room somewhere together making random changes. GNU Emacs is open to anyone who wants to get involved. Patches and improvements come from all over the place - some are minor, some are major, some accepted and some rejected. Changes are discussed in an open forum that anyone can participate in. Valid points have been raised regarding the change in default behavior and possibly the developers may consider ways to improve discussion and communication (though I'm not sure how aware they are since this discussion has occured largely on the wrong forum). Nothing is gained by continued attacks. If you still feel the need to whinge, then perhaps you might show the backbone to actualy make your accusations to the developers and perhaps both get some real facts and just possibly contribute to improving how future changes are handled. >>> Since user interface surprise is a barrier to upgrade, they make sure there >>> aren't any such surprises. >> Yes, that point is well-made. But, the same argument now suggests that the >> default should not be changed yet again. > > Yup. We're probably screwed. > Your arguments all suggest an environment where interfaces never change. This just doesn't exist and never has. Frequently improvements and new functionality require changes to existing interfaces, both programming and user. This is the reason most programs have a major and minor revision number. It gives an end user an idea of how the program may have changed. It is also why any professional setup will put new software through evaluation and testing before putting it into production. This can result in considerable maintenance overheads, but cannot be avoided. It is also why many vendors, such as Red hat and Ubuntu provide versions that are extremely stable and supported for extended periods of time where the only changes/updates are for critical security fixes. As a professional, I'm sure, when deciding to upgrade a major version of some key software, you checked out the release notes to familiarise yourself with what has changed and any known problems and used this information to formulate your test plan that wold ensure no nasty surprises in your production environments. Luckily, the emacs developers made sure this was all clearly documented and where the changes involved modified defaults, clearly explained how to reset tot he previous default. Tim -- tcross (at) rapttech dot com dot au ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-12 4:18 ` line-move-visual Tim X @ 2010-06-12 4:37 ` Evans Winner 2010-06-12 8:30 ` line-move-visual David Kastrup 2010-06-12 20:09 ` line-move-visual Joseph Brenner [not found] ` <huvsd5$8pm$1@north.jnrs.ja.net> 1 sibling, 2 replies; 165+ messages in thread From: Evans Winner @ 2010-06-12 4:37 UTC (permalink / raw) To: help-gnu-emacs ,------ Tim X wrote ------ | For example, how would most of the users feel if every | discussion regarding emacs development, even if | restricted to discussions that directly impact on | basic/core behavior (however that would be defined). was | posted to this list? I suspect that many would be | irritated as this is supposed to be an emacs help forum, | not a discussion forum for developments. Actually I think that would be a great idea -- I think that's exactly what ought to be done. I have read a number of posts on the devel list discussing the question of how to communicate with Emacs users about things like proposed changes to defaults. Most of the messages on the devel list would not be relevant here -- only a tiny fraction, and readers can always ignore threads that don't interest them. They could have subject lines that were the equivalent of "[RFC] Blah blah." I agree that there is a limit to what complaining about it after the fact can accomplish, but it is also true that most users can't realistically monitor such a high-traffic, and generally technical list like emacs-devel. Posting the occasional thread here about proposed changes might get useful feedback, since a lot of people do monitor gnu.emacs.help. ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-12 4:37 ` line-move-visual Evans Winner @ 2010-06-12 8:30 ` David Kastrup 2010-06-12 8:40 ` line-move-visual Evans Winner 2010-06-12 9:30 ` line-move-visual Uday S Reddy 2010-06-12 20:09 ` line-move-visual Joseph Brenner 1 sibling, 2 replies; 165+ messages in thread From: David Kastrup @ 2010-06-12 8:30 UTC (permalink / raw) To: help-gnu-emacs Evans Winner <thorne@unm.edu> writes: > ,------ Tim X wrote ------ > | For example, how would most of the users feel if every > | discussion regarding emacs development, even if > | restricted to discussions that directly impact on > | basic/core behavior (however that would be defined). was > | posted to this list? I suspect that many would be > | irritated as this is supposed to be an emacs help forum, > | not a discussion forum for developments. > > Actually I think that would be a great idea -- I think > that's exactly what ought to be done. It would mean mechanically routing the developer list here. That's nonsensical. Anybody really wanting this sort of mixup can tell his newsreader to create a virtual group that does it. -- David Kastrup ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-12 8:30 ` line-move-visual David Kastrup @ 2010-06-12 8:40 ` Evans Winner 2010-06-12 9:30 ` line-move-visual Uday S Reddy 1 sibling, 0 replies; 165+ messages in thread From: Evans Winner @ 2010-06-12 8:40 UTC (permalink / raw) To: help-gnu-emacs ,------ David Kastrup wrote ------ | It would mean mechanically routing the developer list | here. That's nonsensical. Anybody really wanting this | sort of mixup can tell his newsreader to create a | virtual group that does it. You didn't read what I wrote very carefully. ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-12 8:30 ` line-move-visual David Kastrup 2010-06-12 8:40 ` line-move-visual Evans Winner @ 2010-06-12 9:30 ` Uday S Reddy 2010-06-12 12:30 ` line-move-visual Tim X 1 sibling, 1 reply; 165+ messages in thread From: Uday S Reddy @ 2010-06-12 9:30 UTC (permalink / raw) To: help-gnu-emacs On 6/12/2010 9:30 AM, David Kastrup wrote: > It would mean mechanically routing the developer list here. That's > nonsensical. Anybody really wanting this sort of mixup can tell his > newsreader to create a virtual group that does it. No, not really. The discussion that needs to be routed here is about potential changes to the user's manual. How those changes are *implemented* can continue to stay on the developer list. Evans suggested "RFC" which I think is a great term for these kinds of things. Ideas that add bits to the user's manual can also be brought here, perhaps selectively. For instance, there is a discussion going on there right now about how to deliver "bidirectional text" editing, for buffers that intermix English and Arabic, say. There are lots of tricky issues there about key bindings and functionality. The discussion is impoverished by the dearth of people that actually do bidirectional editing. I don't see why that discussion could not be brought here, where there is some chance of running into people that might actually do bidirectional editing and who might provide valuable input. In any organization, virtual or real, there are decisions that should be taken by small groups of people and there are decisions that can benefit from broad participation. The organizations that can't figure out the difference usually decline over time. Cheers, Uday ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-12 9:30 ` line-move-visual Uday S Reddy @ 2010-06-12 12:30 ` Tim X 0 siblings, 0 replies; 165+ messages in thread From: Tim X @ 2010-06-12 12:30 UTC (permalink / raw) To: help-gnu-emacs Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> writes: > On 6/12/2010 9:30 AM, David Kastrup wrote: > >> It would mean mechanically routing the developer list here. That's >> nonsensical. Anybody really wanting this sort of mixup can tell his >> newsreader to create a virtual group that does it. > > No, not really. > > The discussion that needs to be routed here is about potential changes to the > user's manual. How those changes are *implemented* can continue to stay on > the developer list. Evans suggested "RFC" which I think is a great term for > these kinds of things. > > Ideas that add bits to the user's manual can also be brought here, perhaps > selectively. For instance, there is a discussion going on there right now > about how to deliver "bidirectional text" editing, for buffers that intermix > English and Arabic, say. There are lots of tricky issues there about key > bindings and functionality. The discussion is impoverished by the dearth of > people that actually do bidirectional editing. I don't see why that > discussion could not be brought here, where there is some chance of running > into people that might actually do bidirectional editing and who might provide > valuable input. > > In any organization, virtual or real, there are decisions that should be taken > by small groups of people and there are decisions that can benefit from broad > participation. The organizations that can't figure out the difference usually > decline over time. > My only concern here is with identification of what should and should not be posted in g.e.h as well as on the developer mail list. While I think Evans suggestion is worth consideration, I still see it failing because it relies too much on everyone doing the 'right thing' and as can be seen from this discussion, knowing what is the right thing is not that straight-forward. However, discussions on possibilities are certainly worthwhile and essentila to finding the right balance. Tim -- tcross (at) rapttech dot com dot au ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-12 4:37 ` line-move-visual Evans Winner 2010-06-12 8:30 ` line-move-visual David Kastrup @ 2010-06-12 20:09 ` Joseph Brenner 2010-06-13 1:41 ` line-move-visual Tim X 2010-06-13 10:36 ` line-move-visual David Kastrup 1 sibling, 2 replies; 165+ messages in thread From: Joseph Brenner @ 2010-06-12 20:09 UTC (permalink / raw) To: help-gnu-emacs Evans Winner <thorne@unm.edu> writes: > Tim X wrote: > | For example, how would most of the users feel if every > | discussion regarding emacs development, even if > | restricted to discussions that directly impact on > | basic/core behavior (however that would be defined). was > | posted to this list? I suspect that many would be > | irritated as this is supposed to be an emacs help forum, > | not a discussion forum for developments. > > Actually I think that would be a great idea -- I think > that's exactly what ought to be done. Some software projects publish summaries of what's been happening on the developers list. If you can find a volunteer to do the job, these weekly newsletters are obviously a good thing to have. But this isn't the solution to the problem at hand. > I have read a number of posts on the devel list discussing the > question of how to communicate with Emacs users about things like > proposed changes to defaults. The right answer is that you should not be changing the defaults. If we really can't convince the developers that they need to respect backwards compatibility, an actual solution to the problem might be something like creating a switch that needs to be flipped on to get the new whizzy behavior, something like: (setq modernize-emacs t) You then recommend that the default ~/.emacs for *new* users should include that line. Existing users should never have their existing ~/.emacs over-written the default, so they should only see the old behavior (unless, of course, they choose to add that line). Documentation for "modernize-emacs" should make it clear that it's under development, and that for the immediate future at least, the behavior it imposes may change. Doing something like this would be far better than the current practices, though it's obviously not perfect. Problems include: o A third-party developer may be suprised by the need to ask users not to flip on "modernize-emacs", and may have to write code to shut it off and live with some user confusion when the "modernized" behavior goes away temporarily. o It's effectively a project fork that at the very least complicates documentation and testing. > I agree that there is a limit to what complaining about it > after the fact can accomplish, If you minimize UI changes, then these complaints are minimized. If you eliminate UI changes, then these complaints are eliminated. ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-12 20:09 ` line-move-visual Joseph Brenner @ 2010-06-13 1:41 ` Tim X 2010-06-13 10:22 ` line-move-visual Uday S Reddy 2010-06-13 10:36 ` line-move-visual David Kastrup 1 sibling, 1 reply; 165+ messages in thread From: Tim X @ 2010-06-13 1:41 UTC (permalink / raw) To: help-gnu-emacs Joseph Brenner <doom@kzsu.stanford.edu> writes: > Evans Winner <thorne@unm.edu> writes: >> Tim X wrote: >> | For example, how would most of the users feel if every >> | discussion regarding emacs development, even if >> | restricted to discussions that directly impact on >> | basic/core behavior (however that would be defined). was >> | posted to this list? I suspect that many would be >> | irritated as this is supposed to be an emacs help forum, >> | not a discussion forum for developments. >> >> Actually I think that would be a great idea -- I think >> that's exactly what ought to be done. > > Some software projects publish summaries of what's been > happening on the developers list. If you can find a volunteer > to do the job, these weekly newsletters are obviously a good > thing to have. > A good idea if someone is prepared to step up and do it. > But this isn't the solution to the problem at hand. > >> I have read a number of posts on the devel list discussing the >> question of how to communicate with Emacs users about things like >> proposed changes to defaults. > > The right answer is that you should not be changing the defaults. I tend to agree that defaults should usually not change. However, you cannot anticipate all possible situations and should avoid absolutes. Defaults should only change after serious consideration and discussion and should be as inclusive of users as possible. However, they should not be treated as sacred and can never be changed. > > If we really can't convince the developers that they need to respect > backwards compatibility, an actual solution to the problem might > be something like creating a switch that needs to be flipped on to > get the new whizzy behavior, something like: > > (setq modernize-emacs t) > > You then recommend that the default ~/.emacs for *new* users should > include that line. > > Existing users should never have their existing ~/.emacs over-written > the default, so they should only see the old behavior (unless, of > course, they choose to add that line). > > Documentation for "modernize-emacs" should make it clear that it's > under development, and that for the immediate future at least, > the behavior it imposes may change. > > Doing something like this would be far better than the current > practices, though it's obviously not perfect. Problems include: > > o A third-party developer may be suprised by the need to ask > users not to flip on "modernize-emacs", and may have to > write code to shut it off and live with some user confusion > when the "modernized" behavior goes away temporarily. > > o It's effectively a project fork that at the very least > complicates documentation and testing. > >> I agree that there is a limit to what complaining about it >> after the fact can accomplish, > > If you minimize UI changes, then these complaints are minimized. > If you eliminate UI changes, then these complaints are eliminated. Again, we need to be very wary of any absolute such as UI will never chnage or defaults can never change. We live in an environment that changes and need to be able to adapt. It would be a mistake to eliminate UI changes. There have been a number of improvements in the emacs UI over the last couple of versions. Many of htem I don't like, such as using dialog boxes for find file and yes-no questions if you use the menu etc, but many others, think they are excellent improvements that helps emacs reamin current and of interest to new developers (who are important as some of them will likely be future dev/maintainers). You also have things like the current work on bi-directional editing, which will obviously be a UI change. The developments in handling various character encodings also had some impact on the UI. Many of these were positive and some of them were important and some are necessary. Change is not the issue. Change can be positive and is necessary. The issue is managing that change. Any attempt to enforce a static unchanging environment will fail. Tim -- tcross (at) rapttech dot com dot au ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-13 1:41 ` line-move-visual Tim X @ 2010-06-13 10:22 ` Uday S Reddy 2010-06-13 10:51 ` line-move-visual David Kastrup ` (3 more replies) 0 siblings, 4 replies; 165+ messages in thread From: Uday S Reddy @ 2010-06-13 10:22 UTC (permalink / raw) To: help-gnu-emacs On 6/13/2010 2:41 AM, Tim X wrote: > Change is not the issue. Change can be positive and is necessary. The > issue is managing that change. Any attempt to enforce a static > unchanging environment will fail. You are demolishing a strawman. None of us ever said that change is unnecessary. The thought that was in my mind when I wrote the previous message is better expressed as follows: In the OS & network protocols world /where Mark Crispin comes from/ things can never change essentially. So, Mark has every right to blow up when things have changed essentially. Emacs devs needed that lesson and, judging from Stefan's last post, I think they continue to need it. Do you disagree? (Don't be too focused on surface niceties and etiquette and all that. Different people have different ways of expressing themselves. The substance is what matters in the end.) The reason that things can never change in the OS & network protocols world is that all the services interface to other systems and services. So, if you change one thing, however inconsequential it might seem, you can end up breaking everything. Somebody once told me that, if you want to change one line of code in the kernel of an on-board computer system, you have to produce thousands of pages of documentation analyzing how it will affect everything else on the aircraft. It is so hard to do it that it is almost never done. In the Emacs world, it is easy to think that we are delivering services to the human user, who is clever enough to figure things out. Emacs is a /text editor/ after all. So, change is ok. But the problem is that Emacs is not just a text editor any more. Unbeknownst to the developers, or perhaps even known to them in some instances, it is being used as a critical system component in other applications or services. Emacs has certainly earned the right to be such a component. It is some 30-40 years old. Its core is rock solid. Who has ever had a file corrupted by Emacs? (On the other hand, I have had files corrupted by file servers sold by even reputable companies.) We use Emacs for email in VM, which I regard as mission-critical, because all hell can break loose if a mail folder gets corrupted or somebody can't read their email. We regularly use Emacs to develop code with all kinds additional functionality from editing modes and interfaces to code repositories. If something goes wrong there, other developed software can break, with untold consequences. I am dying to figure out what application Mark Crispin is putting Emacs to that makes it so hard for him to accommodate the line-move-visual change. So, changes that can potentially break things are *not* ok. We don't have to be as diligent as the on-board kernel hackers, but we certainly have to be a lot more careful than we seem to be at the moment. Emacs devs have to grow up into this real world. Changing the meaning of next-line has consequences far beyond what the Emacs devs have been able to grasp. I have mentioned previously that I found three calls to `next-line' in VM. They were not in VM core, in third party contributions, but try telling that to somebody whose mail folder gets corrupted! Emacs devs might say one should never have used `next-line' in elisp code, but that is not really good enough, is it? Emacs manual never said one *must not* use next-line in elisp code. It only said that there are better ways of doing it. So, an elisp programmer cannot be faulted for using `next-line'. (As an aside, Microsoft used to say that the problems faced by the users with Windows weren't their fault but rather those of third party device drivers. Microsoft had hoisted complicated protocols on the device driver writers, who couldn't manage them properly. Microsoft has now developed sophisticated driver verification tools - some of the best in the field - to verify that the device drivers satisfy the protocols. Good for them! And good for the users!) Imagine what I have to say in the next release notes of VM: "Emacs 23 has introduced an incompatible change to the meaning of `next-line' which can cause folder corruption. This release of VM is the first safe version of VM for use with Emacs 23". This doesn't stop other users still using older versions of VM from facing folder corruption. Nor will it stop some downstream distribution from packaging an old version of VM with the later version of Emacs. Is that the kind of situation we want to be in? Stefan says, perhaps half-jokingly, that he never uses Emacs while being root. Does RMS think the same? Do all the trustees of FSF accept that Emacs is unfit to be used while being root? What other Gnu software is similarly unfit to be used as root? Mark Crispin's criticism has to be taken seriously, even if it comes with a heavy dose of vitriole, because he is a top-level systems programmer who knows better. When you say that this change has been around for a year and no complaints were raised, you are not being clear about how software changes are propagated. It takes years for changes to go through the pipeline of downstream distributions and even longer for users to upgrade their systems. Smart users who want to play safe are always careful to let the dust settle before upgrading. Our local sys admins haven't even installed Emacs 23.1 yet on our departmental machines. That will probably happen during this summer. If I was a normal user, rather than a developer, I would have probably taken an additional year or so to make the switch. So, these late complaints are the most important ones. They come from the more serious and conservative users. Emacs devs are going to have to face the heat for quite a while to come. Mark Crispin is not satisfied with Stefan's response. Neither am I, to tell you the truth. When says, "Given the reactions we've seen since Emacs-23.1 was released, I don't regret the decision", he is indicating that he is happy to play to the gallery, and quite an uninformed gallery at that. When I asked "do you want C-n to move by logical line or visual line in the logical line mode", the gallery has been silent. If this is the measure of support needed to introduce incompatible changes in Emacs, then Emacs does seem to be in trouble! Cheers, Uday ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-13 10:22 ` line-move-visual Uday S Reddy @ 2010-06-13 10:51 ` David Kastrup 2010-06-13 11:32 ` line-move-visual Uday S Reddy 2010-06-14 0:46 ` line-move-visual Tim X ` (2 subsequent siblings) 3 siblings, 1 reply; 165+ messages in thread From: David Kastrup @ 2010-06-13 10:51 UTC (permalink / raw) To: help-gnu-emacs Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> writes: > So, Mark has every right to blow up when things have changed > essentially. Emacs devs needed that lesson and, judging from Stefan's > last post, I think they continue to need it. Do you disagree? I should think that if your attitude towards Emacs developers seemed a bit less similar to manipulating unthinking apes into doing useful tricks according to your bidding, you might get a better return for the amount of stuff you write. If you want some response from the developers, the right way is to talk with them like normal human beings would rather than trying to view them as laboratory rats and discuss your findings about their reactions with other superior life forms. If you have questions about the intent behind a post of Stefan, the person to ask is Stefan. And trying to get a consensus about Stefan and other developers needing further lessons is not what I consider a discourse worthy for respectful human beings. The question is not how to manipulate Emacs developers into doing things the way you'd like them to do. The question is how to argue against the priorities and reasons (readily accessible in the developer list archives) that lead to the current decision, and come up with additional data that may shift the balance. "It makes obnoxious and insolent people raise a stink elsewhere" is, at least in my book, not a particularly important consideration for choosing defaults. So there is not much to be gained by you and in particular Mark trying to increase their efforts in that area. -- David Kastrup ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-13 10:51 ` line-move-visual David Kastrup @ 2010-06-13 11:32 ` Uday S Reddy 0 siblings, 0 replies; 165+ messages in thread From: Uday S Reddy @ 2010-06-13 11:32 UTC (permalink / raw) To: help-gnu-emacs On 6/13/2010 11:51 AM, David Kastrup wrote: > > If you want some response from the developers, the right way is to talk > with them like normal human beings would rather than trying to view them > as laboratory rats and discuss your findings about their reactions with > other superior life forms. > > If you have questions about the intent behind a post of Stefan, the > person to ask is Stefan. Hmm. A bit unfair, but good point. I will. > The question is not how to manipulate Emacs developers into doing things > the way you'd like them to do. The question is how to argue against the > priorities and reasons (readily accessible in the developer list > archives) that lead to the current decision, and come up with additional > data that may shift the balance. Ok, I have indicated how the change to the semantics of `next-line' affects VM and perhaps other similar packages. Mark, if you are still around, can you tell us how it affects you? Why kind of users do you have and why can't set line-move-visual to nil? Cheers, Uday ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-13 10:22 ` line-move-visual Uday S Reddy 2010-06-13 10:51 ` line-move-visual David Kastrup @ 2010-06-14 0:46 ` Tim X [not found] ` <hv4nkd$quq$1@north.jnrs.ja.net> 2010-06-14 4:48 ` line-move-visual Tim X [not found] ` <m2iq5nw4pj.fsf@gmail.com> 3 siblings, 1 reply; 165+ messages in thread From: Tim X @ 2010-06-14 0:46 UTC (permalink / raw) To: help-gnu-emacs Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> writes: > On 6/13/2010 2:41 AM, Tim X wrote: > >> Change is not the issue. Change can be positive and is necessary. The >> issue is managing that change. Any attempt to enforce a static >> unchanging environment will fail. > > You are demolishing a strawman. None of us ever said that change is > unnecessary. The thought that was in my mind when I wrote the previous > message is better expressed as follows: > Not at all. It was suggested that mature reliable software that is maintained by competant, mature and experienced programmers /never/ changes its interface. This implies that change is not only unnecessary, but cannot occur in a mature system. The implication was that because visual line mode changes the interface, the developers and maintainers were immature, inexperienced and arrogant. I reject this assertion that interfaces cannot change and that any change in an interface automatically means the software is immature, unreliable and/or maintained by incompetant developers. I would go further and argue that in some situations, changing the interface is actually the correct and responsible thing to do. Changing the interface is not the problem, it is how that change is implemented that is the issue. If we accept a generalisation that interfaces cannot change, we run the risk of artificially constraining possibilities and fail to focus on the important challenge of establishing processes that will allow the itnerface to develop and mature without undesirable side effects. Arguing that the interface can never change is over simplifying the situation and encourages a mindsset where change is feared and raises the real possiblity that the software will stagnate and fail to either keep pace with evolving technology or user expectations. > > In the OS & network protocols world /where Mark Crispin comes from/ things can > never change essentially. I don't disagree. Different domains have different constraints. However, just because the domain someone works in has specific constraints does not mean that those constraints should be automatically applied to other domains. > So, Mark has every right to blow up when things have changed essentially. > Emacs devs needed that lesson and, judging from Stefan's last post, I think > they continue to need it. Do you disagree? (Don't be too focused on surface > niceties and etiquette and all that. Different people have different ways of > expressing themselves. The substance is what matters in the end.) I have stated repeatably that I agree that making visual line mode the default was a mistake. I also agree that the maintainers probably need to create better channels of communication to get more feedback from end users. I totally disagree with the arguments that introduction of visual line mode was a mistake. I totally disagree with the persoanl attacks on the developers and insinuations regarding their maturity, competance and experience and charges of arrogance. I totally disagree with absolutes such as interfaces should never change and defaults should never change. I do accept that interfaces should be treated in a very conservative manner and that any change should be considered extremely carefully. I even have trouble coming up with an example that wold support changing of defaults. However, I see a big difference between saying that we should be very conservative regarding change in these areas and saying that these areas should /never/ change. I expect some will respond with "well yes, there are exceptions where change would be OK if blah blah" etc and "you are being too literal, there are always exceptions to the rule" etc. In which case, I would say that it is better to be clearer regarding what is meant. Avoid setting up 'rules' that deal in absolutes which distract from core issues and create false constraints. Say that interfaces and defaults should be treated extremely conservatively and should not change without clear justification. Once we accept that change is possible in this respect, we can then focus on how to assess when a change to the interface is justified, how such changes should be implemented, how end users should be consulted and how to roll the change out. Denying that change is possible means that we don't properly consider the implications of the change and don't establish propper processes for dealing with it. [snip] > In the Emacs world, it is easy to think that we are delivering services to the > human user, who is clever enough to figure things out. Emacs is a /text > editor/ after all. So, change is ok. But the problem is that Emacs is not > just a text editor any more. Unbeknownst to the developers, or perhaps even > known to them in some instances, it is being used as a critical system > component in other applications or services. Emacs has certainly earned the > right to be such a component. It is some 30-40 years old. Its core is rock > solid. Who has ever had a file corrupted by Emacs? (On the other hand, I > have had files corrupted by file servers sold by even reputable > companies.) I have had files currupted by emacs and I have had files currupted by VM. In both cases, they were bugs in production versions. However, given that I've been using emacs pretty much all day, everyday for 15 years, I do consider it very stable. > We use Emacs for email in VM, which I regard as mission-critical, because all > hell can break loose if a mail folder gets corrupted or somebody can't read > their email. We regularly use Emacs to develop code with all kinds additional > functionality from editing modes and interfaces to code repositories. If > something goes wrong there, other developed software can break, with untold > consequences. I have had VM fail on a number of occasions and have had it currupt my mail folder at least once. Yes, it has been mostly very stable and reliable. However, problems/bugs do occur regardless of how mission critical you assume it is. Likewise, you cannot make assumptions regarding how mission critical developers view a system based on a bug or single decision. > I am dying to figure out what application Mark Crispin is > putting Emacs to that makes it so hard for him to accommodate the > line-move-visual change. To be honest, while I believe Mark raised a valid issue regarding visual line mode being the default, I think he over reacted and his somewhat personal attacks on the emacs developer community only distracted form the important issues he raised. There have been a couple of suggestions regarding how he can work around the issue, which he does not seem to respond to and I suspect that he may be "throwing the baby out with the bath water". > So, changes that can potentially break things are > *not* ok. Sounds nice, but the reality is that any change can potentially break things. We can certainly establish processes that help mitigate this. However, we need to first accept that change is possible and sometimes needed in order to then establish these processes. This is why I reject the claim that the interface should never change and/or defaults should never change. > We don't have to be as diligent as the on-board kernel hackers, but > we certainly have to be a lot more careful than we seem to be at the moment. > Emacs devs have to grow up into this real world. I still think this is all being wildly over stated. We are talking about one change largely implemented by one developer. We cannot make assumptions about all the developers and what they do or do not need based on a single change. Consider the substantial interface changes that have occured between emacs 22 and emacs 23. Given how stable emacs has remained despite all these changes, I would suggest the developers need to be congratulated for doing an excellent job. There has been a lot of theorizing about how badly visual line mode will break things, but I've not actually seen much evidence of people who are using visual line mode experiencing problems. Furthermore, if you disable visual line mode, the impact is absolutely nil. The issue is not that visual line mode was a mistake, but rather that it was introduced as a default and that implications of doing so were not well thought out, especially with respect to keyboard macros etc and that this change in default was not adequately communicated. > > Changing the meaning of next-line has consequences far beyond what the Emacs > devs have been able to grasp. I have mentioned previously that I found three > calls to `next-line' in VM. They were not in VM core, in third party > contributions, but try telling that to somebody whose mail folder gets > corrupted! Emacs devs might say one should never have used `next-line' in > elisp code, but that is not really good enough, is it? Emacs manual never > said one *must not* use next-line in elisp code. It only said that there are > better ways of doing it. So, an elisp programmer cannot be faulted for using > next-line'. > [snip] > > Imagine what I have to say in the next release notes of VM: "Emacs 23 has > introduced an incompatible change to the meaning of `next-line' which can > cause folder corruption. This release of VM is the first safe version of VM > for use with Emacs 23". This doesn't stop other users still using older > versions of VM from facing folder corruption. Nor will it stop some > downstream distribution from packaging an old version of VM with the later > version of Emacs. Is that the kind of situation we want to be in? There is nothing new here. We have always been in this position. Look at the emacs NEWS files. They contain a section on incompatible lisp changes. There is always the potential for existing packages to break with new versions of emacs and it isn't uncommon for packages to need changes in order to work with a new major version. I also think your over stating the situation. The potential problem only occurs if you enable visual line mode. > > Stefan says, perhaps half-jokingly, that he never uses Emacs while being root. > Does RMS think the same? Do all the trustees of FSF accept that Emacs is > unfit to be used while being root? What other Gnu software is similarly unfit > to be used as root? Mark Crispin's criticism has to be taken seriously, even > if it comes with a heavy dose of vitriole, because he is a top-level systems > programmer who knows better. Mark's criticism regarding visual line mode being the default is valid. His heavy does of vitriole against the whole emacs developer community is not. As I don't know him and have not worked with him, I cannot judge his credentials as a programmer and would never presume to do so. > > When you say that this change has been around for a year and no complaints > were raised, you are not being clear about how software changes are > propagated. It takes years for changes to go through the pipeline of > downstream distributions and even longer for users to upgrade their systems. > Smart users who want to play safe are always careful to let the dust settle > before upgrading. Our local sys admins haven't even installed Emacs 23.1 yet > on our departmental machines. That will probably happen during this summer. > If I was a normal user, rather than a developer, I would have probably taken > an additional year or so to make the switch. So, these late complaints are > the most important ones. They come from the more serious and conservative > users. Emacs devs are going to have to face the heat for quite a while to > come. > That is a fair point. However, I would also suggest that many of the experienced and active users are also the first ones to adopt or trial emacs versions. At work, I run emacs 23.1. However, at home and for most of my personal development work, I run the latest development system, which I upgrade at least once a week. > Mark Crispin is not satisfied with Stefan's response. Neither am I, to tell > you the truth. When says, "Given the reactions we've seen since Emacs-23.1 > was released, I don't regret the decision", he is indicating that he is happy > to play to the gallery, and quite an uninformed gallery at that. When I asked > "do you want C-n to move by logical line or visual line in the logical line > mode", the gallery has been silent. If this is the measure of support needed > to introduce incompatible changes in Emacs, then Emacs does seem to be in > trouble! > That isn't how I interpreted Stefan's response at all. My interpretation was that he believes, based on feedback, that many users found visual line mode a beneficial new feature, but he acknowledges that it hasn't come without some problems. I don't understand why you are asking if C-n should move by logical line or visual line in logical line mode. Isn't this what the difference is between the two modes? In logical line mode, the behavior is exactly the same as it has always been - C-n moves by logical line. In visual line mode, it moves by visual line. I don't see any issue here and there is no evidence anywhere that I am aware of that proposes any changes to line movement when not in visual line mode. There are two issues I am aware of where it appears there has been a lack of in-depth analysis. The first and I think most serious is the impact of visual line mode on existing saved keyboard macros. More thought is required in this area. Personally, I would be inclined to somehow restrict macros in such a way that they won't work if the buffer is in a different line mode to the one it was in when the macro was defined. The second issue, which /may/ be a problem is the impact of next-line in packages people use while also using visual line mode. I would suggest that both of these are enough justification for not setting visual line mode as the default - at least not yet. It definitely should have been introduced as an optional non-default feature. Tim -- tcross (at) rapttech dot com dot au ^ permalink raw reply [flat|nested] 165+ messages in thread
[parent not found: <hv4nkd$quq$1@north.jnrs.ja.net>]
* Re: line-move-visual [not found] ` <hv4nkd$quq$1@north.jnrs.ja.net> @ 2010-06-15 9:20 ` Tim X 2010-06-15 11:29 ` line-move-visual Uday S Reddy 0 siblings, 1 reply; 165+ messages in thread From: Tim X @ 2010-06-15 9:20 UTC (permalink / raw) To: help-gnu-emacs Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> writes: > On 6/14/2010 1:46 AM, Tim X wrote: > >> Not at all. It was suggested that mature reliable software that is >> maintained by competant, mature and experienced programmers /never/ >> changes its interface. This implies that change is not only unnecessary, >> but cannot occur in a mature system.... I reject this assertion that >> interfaces cannot change and that any change in an interface >> automatically means the software is immature, unreliable and/or >> maintained by incompetant developers. I would go further and argue that >> in some situations, changing the interface is actually the correct and >> responsible thing to do. > > Sorry, Tim. Your rejection would carry some weight if you mentioned the > situations where changing the interface is "the correct and responsible" thing > to do. > > You also seem to believe that the `line-move-visual' issue did not present > such a situation where changing the interface was the correct and responsible > thing to do. So, I am not sure what your point is, other than providing some > political support to the developers. > OK, fair criticism. I have muddied the waters too much by trying to address to many issues in a sigle thread. I should probably have put things in different threads to avoid confusion. I also should have been more careful with some terminology and phrasing. I will attempt to clarify. The issues I've tried to address are 1. The suggestion that interfaces for mature software packages never change and that such change means the software is immature or poorly maintained. 2. The issue of line-move-visual and whether it in itself is a bad idea or whether the way it was implemented was a mistake 3. The frequently personal, overly general and somewhat arrogant criticisms of emacs maintainers based largely on unsubstantiated assumptions. 1. While we would like to believe interfaces of mature software packages never change, this simply isn't reality. If it were, we would always have backwards compatibility, which we don't. Likewise, it would not be necessary for programs to use version numbering schemes that incorporate this information. For example, the Apache scheme uses a format of 'x.y.z' where 'x' indicates significant interface changes that are not backwards compatible, 'y' indicates a version with interface changes that are extensions and are backwards compatible and 'z' indicates a patch. In this context, interface can refer to either API changes or UI changes. While I cannot think of specific examples of interface changes in emacs, I can certainly recall changes in many other mature packages. For example, Apache has changed the interface for external modules, Java has changed its interface for core classes, Microsoft has changed some of its low level OS interfaces, breaking backwards compatibility for 16 bit programs and Linux has changed its interface in a number of areas. With this last one, I have run into issues with a driver I used to use that is no longer compatible with current 2.6.x kernels. I have maintained that interface changes are not something that should be done unnecessarily. The interface should be treated conservatively and changes should be avoided where possible. However, I think it is a mistake to ignore or deny the possibility of interface change because doing so results in failing to understand and consider the consequences. This is necessary to know how to properly manage such changes and minimize impact. It is also necessary because different domains have different requirements and constraints. For these reasons, I reject blanket statements that say the interface of mature software packages must never change. > Regarding your questions, yes, I do regard /all/ changes to *existing* > behavior of mature software systems as bad. Under exceptional circumstances, > they could be the *lesser evil* and then we accept them as being unfortunately > necessary. > Right. However, this doesn't fit with the claim of /never/ changing or with the simplistic view that a change in interface indicates software that is immature. > This does not mean that you can't add new features or extend the existing > behavior. Extend it as much as you please, without changing what already > exists. > Agree. Extension is not what I would call change as it doesn't usually affect backwards compatibility. However, in some cases, most notably user interfaces, extensions and enhancements can be seen as a change that breaks backwards compatibility because it modifies the interface to such an extent that the user feels they no longer recognize it or know how to use the system despite the fact core operations and APIs have not been modified. However, this is an edge case. Adding functionality etc usually doesn't have the level of impact as modifying what already exists. > The Emacs NEWS file currently does not make any distinction between *changes*, > meaning changes to the existing behavior, and *extensions* (or improvements or > new features). All of them are generically labelled as "Changes" (meaning > changes to the software system, not changes to the behavior of features). > This is probably a hangover from the time when the file might have been called > a ChangeLog, rather than NEWS. Please don't confuse "changes" in this generic > sense to be actual changes. > Hmmm, I don't think I agree. While it could be possible to improve the labelling, its nowhere as bad as you indicate. Here are the top level headings from the current NEWS file for the dev version (these basic headings have been in all the NEWS files I've seen for the past 15 years) * Installation Changes in Emacs 24.1 * Startup Changes in Emacs 24.1 * Changes in Emacs 24.1 * Editing Changes in Emacs 24.1 * Changes in Specialized Modes and Packages in Emacs 24.1 * New Modes and Packages in Emacs 24.1 * Incompatible Lisp Changes in Emacs 24.1 * Lisp changes in Emacs 24.1 * Changes in Emacs 24.1 on non-free operating systems >> That isn't how I interpreted Stefan's response at all. My interpretation >> was that he believes, based on feedback, that many users found visual >> line mode a beneficial new feature, but he acknowledges that it hasn't >> come without some problems. >> >> I don't understand why you are asking if C-n should move by logical line >> or visual line in logical line mode. Isn't this what the difference is >> between the two modes? In logical line mode, the behavior is exactly the >> same as it has always been - C-n moves by logical line. In visual line >> mode, it moves by visual line. I don't see any issue here and there is >> no evidence anywhere that I am aware of that proposes any changes to >> line movement when not in visual line mode. > > These two paragraphs suggest that you don't really know what the issue is. > Perhaps you should read the manual sections on line-move-visual and > visual-line-mode and try them out before discussing them? > That was poor expression and haste on my part. I meant line-move-visual and not visual-line-mode. I suspect the confusion is with the general use of 'mode' and the emacs specific definition of a buffer mode. After what you wrote, I thought it would be a good idea to check my facts and experiment a bit. My understanding wasn't too far off the mark. I would suggest you have a look at the code for visual-line-mode as it uses line-move-visual - essentially, setting it to t locally in the buffer when you turn the mode on. If it was nil before starting visual-line-mode, it sets it back to nil when you turn off the mode. So, it seems that visual-line-mode uses line-move-visual to alter the next line/previous line definitions when in visual line mode. I still don't understand the question you referred to when you wrote "When I asked "do you want C-n to move by logical line or visual line in the logical line mode", the gallery has been silent." Perhaps I don't understand what you mean by logical line mode. My interpretation was that logical line mode referred to what some would call the 'traditional' default mode that emacs had until v23 i.e. C-n and Cp moved to the next and previous lines where a line would be defined by standard eol characters. If you had line wrap on for a long line that filled 10 visual lines in your window, a single C-n would move down to the 11th visual line i.e. C-n moves to next logical line. In visual line mode or with line-move-visual enabled, C-n would move to the second visual screen line i.e. you would have to do multiple C-n to get past the 'logical line'. For convenience of argument, since visual line mode uses line-move-visual, lets just call it visual line mode. Noting that I expect all the possible problems that line-move-visual would cause with macros will also exist if you are using visual line mode as they both redefine the movement semantics in the same way. From this perspective, for me, the semantics of the movement keys are what determine which mode you are operating in. It makes no sense to ask if C-n should move by logical lines or visual lines in logical line mode because moving by logical lines is what defines logical line mode. If you move by visual lines, your not in logical line mode, your in visual line mode (using the term mode in its general sense, not its emacs sense). So, I still don't understand your question and I suspect I'm not alone. This could explain the lack of response to your question and provides an alternative to your rather negative and somewhat arrogant assertion regarding an 'ill informed gallery'. A failure to illicit a response to a question can easily be due to the way it is presented and does not in itself tell you anything about the audience. To again make my position clear. I believe that setting line-move-visual to t by default was a mistake. I believe the introduction of the ability to change the semantics of line movement is a good addition, despite some of the negative consequences and the fact that I think there is still some work to be done to handle things like macros in a reliable consistent manner. This ability to change the movement semantics has enabled improved support for a number of activities, many of which have been mentioned elsewhere in this thread. I agree that its introduction does come with some pain, but I think its worth it. From a theoretical basis, I can see where some of the concerns are coming from, but I've yet to hear of an actual example where the change has caused the cataclysmic disasters that have been predicted. I think despite some valid points, things have been over stated. Which brings me to my final issue and the one that actually dragged me into this thread. The arrogance, derogatory comments about the emacs maintainers, sweeping generalizations and assumptions regarding everything from their personal motivations, experience, egos and even age has been quite outrageous. Arrogant claims of teaching them lessons and demands for more accountability etc have been over the top and all of this due essentially to one poor decision to change the default behavior. There has been no recognition for all the recent improvements in font handling, support for GTK, dbus, etc, X window support enhancements, emacsclient improvements, improved and extended support for different character encodings, support for larger buffers and much more. I'm quite amazed at the development and improvements we have been seeing. Remember how slow it was to go from emacs 20 to 21? Remember the constant frustrations of an emacs that frequently ran into limitations that other systems didn't experience? I think the work that has been done over the last few years has been quite remarkable. > > I hope you understand the issue better now. If you still think this is an > acceptable change, let us know. I understood it before, thank you master! I hope you now understand my position better! Tim -- tcross (at) rapttech dot com dot au ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-15 9:20 ` line-move-visual Tim X @ 2010-06-15 11:29 ` Uday S Reddy 2010-06-16 9:29 ` line-move-visual Tim X 0 siblings, 1 reply; 165+ messages in thread From: Uday S Reddy @ 2010-06-15 11:29 UTC (permalink / raw) To: help-gnu-emacs On 6/15/2010 10:20 AM, Tim X wrote: > I still don't understand the question you referred to when you wrote > > "When I asked "do you want C-n to move by logical line or visual line in > the logical line mode", the gallery has been silent." > > Perhaps I don't understand what you mean by logical line mode. My > interpretation was that logical line mode referred to what some would > call the 'traditional' default mode that emacs had until v23 i.e. C-n and Cp > moved to the next and previous lines where a line would be defined by > standard eol characters. By "logical line mode," I meant the state of Emacs whenever visual-line-mode is nil. When you fire up Emacs with 'emacs -Q', it is in this mode. This is not standard terminology. It is something I made up to describe the situation we expect to have when Emacs is not in visual-line-mode. By your terminology, "logical line mode" existed in Emacs 22, but it doesn't exist in Emacs 23. When you fire up 'emacs -Q' you get some kind of an "emacs default mode with a funny mixture of logical and visual lines". From this point of view, the problem is more simply stated: the Emacs default is not logical line mode any more. > So, I still don't understand your question and I suspect I'm not alone. > This could explain the lack of response to your question and provides an > alternative to your rather negative and somewhat arrogant assertion > regarding an 'ill informed gallery'. A failure to illicit a response to > a question can easily be due to the way it is presented and does not in > itself tell you anything about the audience. Sorry, arrogance was not my intent. The reason for calling the people that gave positive feedback "ill informed" is that either they don't realize that they can get the behavior they want by setting line-move-visual to t or they don't understand that things can break in unforeseen ways by changing the default behavior. I was myself "ill informed" in this sense until this thread started. So, if I happened to give positive feedback on this issue, it would have been worth nothing. > To again make my position clear. I believe that setting line-move-visual > to t by default was a mistake. I believe the introduction of the ability > to change the semantics of line movement is a good addition, despite some > of the negative consequences and the fact that I think there is still > some work to be done to handle things like macros in a reliable > consistent manner. This ability to change the movement semantics has > enabled improved support for a number of activities, many of which have > been mentioned elsewhere in this thread. I agree that its introduction > does come with some pain, but I think its worth it. From a theoretical > basis, I can see where some of the concerns are coming from, but I've > yet to hear of an actual example where the change has caused the > cataclysmic disasters that have been predicted. I think despite some > valid points, things have been over stated. I think we agree on all of this. However, I don't think I predicted "cataclysmic disasters". I only said that file corruption is possible. Whether it actually happens or not depends on how much code or macro collection is out there in circulation which uses `next-line'. As a developer, I avoid the possibility of file corruption at all cost. I don't expect myself to be proved or disproved about cataclysmic disasters. Perhaps my more important point is that, if we intend for Emacs to continue as a dependable system component (as opposed to a personal text editor), these kinds of incompatible changes should not be made. > Which brings me to my final issue and the one that actually dragged me > into this thread. The arrogance, derogatory comments about the emacs > maintainers, sweeping generalizations and assumptions regarding > everything from their personal motivations, experience, egos and even > age has been quite outrageous. Arrogant claims of teaching them lessons > and demands for more accountability etc have been over the top and all > of this due essentially to one poor decision to change the default > behavior. There has been no recognition for all the recent improvements > in font handling, support for GTK, dbus, etc, X window support > enhancements, emacsclient improvements, improved and extended support > for different character encodings, support for larger buffers and much > more. I'm quite amazed at the development and improvements we have been > seeing. Remember how slow it was to go from emacs 20 to 21? Remember the > constant frustrations of an emacs that frequently ran into limitations > that other systems didn't experience? I think the work that has been > done over the last few years has been quite remarkable. On this, we disagree. To set the record straight, neither I nor anybody else has used the phrase "teaching them a lesson" which has a very different meaning. I have talked about taking a lesson, which is something smart people do throughout their lives, by learning from experience and users' feedback. Nothing derogatory was intended here. Anybody who thinks that they don't need a lesson every now and then are probably arrogant themselves! I haven't made any comments on Mark Crispin's language or etiquette. Neither have I made such comments about anybody else. My feeling is that it is a waste of time to talk about etiquette on newsgroups. We are all adults and we are not going to change our behaviour patterns just because somebody commented on it in a newsgroup. It is much more productive to focus on the substance and the issues, and try to figure out what is being talked about rather than how it is talked about. If you want to acclaim the great progress being made in Emacs, please by all means start a thread and we will all join in. But you can't fault us for not doing it in this thread which has a particular purpose, to discuss line-move-visual. --- I wrote my last message to essentially sum up the discussion of this thread, which has been rather long by all standards. I don't intend to prolong it further unless anybody comes up with some reasons for why the current default setting was good idea. Cheers, Uday ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-15 11:29 ` line-move-visual Uday S Reddy @ 2010-06-16 9:29 ` Tim X 0 siblings, 0 replies; 165+ messages in thread From: Tim X @ 2010-06-16 9:29 UTC (permalink / raw) To: help-gnu-emacs Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> writes: > On 6/15/2010 10:20 AM, Tim X wrote: > >> I still don't understand the question you referred to when you wrote >> >> "When I asked "do you want C-n to move by logical line or visual line in >> the logical line mode", the gallery has been silent." >> >> Perhaps I don't understand what you mean by logical line mode. My >> interpretation was that logical line mode referred to what some would >> call the 'traditional' default mode that emacs had until v23 i.e. C-n and Cp >> moved to the next and previous lines where a line would be defined by >> standard eol characters. > > By "logical line mode," I meant the state of Emacs whenever visual-line-mode > is nil. When you fire up Emacs with 'emacs -Q', it is in this mode. This is > not standard terminology. It is something I made up to describe the situation > we expect to have when Emacs is not in visual-line-mode. > I think I understand what you mean now, but I still think your over complicating it somewhat. Forget about visual-line-mode. This is just confusing the situation. What you have is a logical line mode i.e. line-move-visual = nil and a visual line mode i.e. line-move-visual = t. The emacs mode called visual-line-mode is just the latter with a few enhancements, such as word wrap and the ability to have the previous 'state' restored when you turn it off. So, by default, emacs 23.1 starts in visual line mode. If you want it to start in logical line mode, you set line-move-visual to t and you have exactly the same behavior you had before. > By your terminology, "logical line mode" existed in Emacs 22, but it doesn't > exist in Emacs 23. No, it still exists, it just isn't the default. > When you fire up 'emacs -Q' you get some kind of an "emacs > default mode with a funny mixture of logical and visual lines". Where do you get the funny mix? Either line-move-visual is the default of t and you have movement by visual lines or it has been set to nil and you have the same logical line movement that you always had. > From this point of view, the problem is more simply stated: the Emacs > default is not logical line mode any more. Correct. Nobody has claimed otherwise. > > Perhaps my more important point is that, if we intend for Emacs to continue as > a dependable system component (as opposed to a personal text editor), these > kinds of incompatible changes should not be made. > If we had more than one contentious example, I might agree. However, the reality is that emacs has been improving and evolving considerably and remains incredibly stable. For the last 5 years or so, I've been running from the latest development sources and have yet to encounter anything other than minor trivial issues. Considering this has included quite substantial updates to core elements, such as GUI interface libraries, font rendering, character encoding etc. I think the maintainers have done an excellent job. Given that you agree the addition of the ability to move by visual lines is a good one and that possible issues exist, its worth noting that such issues would exist whether the change was made the default or not. Personally, I would have been more conservative and not made it the default initially. My preference would have been to make it an option and then, in a later release, if it turned out that having it as a default was justified, change it then. At the very least, this would somewhat rreduce possible negative impact as we would have understood the real impact and scope of issues better and maintainers would have had time to fix any issues (though there may be an arguement that developers wouldn't do anything until forced - I frequently see packages that still throw warnings for functions and variables that have been deprecated for years which never seem to get 'fixed' despite the release of new versions). However, that is all academic now. We have what we have and will have to wait and see to what extent it actually does cause all the issues that have been suggested. The bottom line is that there isn't a way to make this sort of development such that it is painless for everyone. Tim -- tcross (at) rapttech dot com dot au ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-13 10:22 ` line-move-visual Uday S Reddy 2010-06-13 10:51 ` line-move-visual David Kastrup 2010-06-14 0:46 ` line-move-visual Tim X @ 2010-06-14 4:48 ` Tim X [not found] ` <m2iq5nw4pj.fsf@gmail.com> 3 siblings, 0 replies; 165+ messages in thread From: Tim X @ 2010-06-14 4:48 UTC (permalink / raw) To: help-gnu-emacs Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> writes: > On 6/13/2010 2:41 AM, Tim X wrote: > > I am dying to figure out what application Mark Crispin is > putting Emacs to that makes it so hard for him to accommodate the > line-move-visual change. > > It seems, from a post I've just seen from Mark, that it isn't an application at all. What he has are some recipes/processes that staff follow using emacs. He has previously stated that asking them to set line=move-visual to nil was not acceptable as his users would be confused and that he has no access to the emacs software they are running. Therefore, it would be reasonable to assume that if they cannot add a simple line to set a variable and he does not have access to the machines, that the users are not installing any specialised packages or code and there is no elisp involved at all. His issue appears to be with how to update his processes/recipes in a clear manner so that they will still work regardless. This is a legitimate issue. I now think he has overstated the impact. Setting line movement to its old default is easily done via the options menu and doesn't require the user editing .emacs or even using M-x customize. It wouldn't be too difficult to add this to his recipes. (I do wonder how he deals with users who select other options, such as CUA mode, that are also likely to impact on his recipes). His point about setting visual line mode as the default being a poor decision is valid. Likewise, his concern that this is a sign of possible problems for his setup if more changes that affect basic commands occur in future versions is legitimate, though possibly over stated when based on a single contentious change (noting also that its not like a new major version of emacs comes out every other week. 4 major versions released in over 15 years!). However, discussion of such change is certainly beneficial, even if it only makes developers aware of the need to be conservative when proposing changes to interfaces or especially defaults. Unfortunately, over stating of the issue, derogatory assertions about the developers, baseless assumptions about their ages, motivation and expertise have tended to obscure the valid points he has raised. Instead of coming across well, much of it has come across as nothing more than a dummy spit. Tim -- tcross (at) rapttech dot com dot au ^ permalink raw reply [flat|nested] 165+ messages in thread
[parent not found: <m2iq5nw4pj.fsf@gmail.com>]
[parent not found: <hv2htd$4li$1@north.jnrs.ja.net>]
[parent not found: <m239wravxb.fsf@gmail.com>]
* Re: line-move-visual [not found] ` <m239wravxb.fsf@gmail.com> @ 2010-06-16 2:11 ` Joseph Brenner 2010-06-16 6:46 ` line-move-visual Helmut Eller 0 siblings, 1 reply; 165+ messages in thread From: Joseph Brenner @ 2010-06-16 2:11 UTC (permalink / raw) To: help-gnu-emacs Helmut Eller <eller.helmut@gmail.com> writes: > Uday S Reddy wore: >> Helmut Eller wrote: >>> If you or Mark Crispin are so dependent on Emacs why don't you have test >>> suites for your programs >> >> Why do you think Mark Crispin and I are the only ones "so dependent" >> on Emacs? > > I don't think that you are the only ones (and never said that). But it > seems to me that it's your own fault to use keyboard macros for > "mission-critical" stuff and not testing them. Right. So we hack our own test library, and we use it to determine that emacs 23 will break our code. We then put up a notice telling the end users that they shouldn't uprade their version of emacs. They do it anyway, and begin complaining, but everything's cool, because we can point at the notice we put up. Note that in this case, you'd have to have pretty good test coverage to have a hope of noticing this problem, because it's not the kind of breakage that anyone would've anticipated as being at all likely. ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-16 2:11 ` line-move-visual Joseph Brenner @ 2010-06-16 6:46 ` Helmut Eller 0 siblings, 0 replies; 165+ messages in thread From: Helmut Eller @ 2010-06-16 6:46 UTC (permalink / raw) To: help-gnu-emacs * Joseph Brenner [2010-06-16 04:11+0200] writes: >> I don't think that you are the only ones (and never said that). But it >> seems to me that it's your own fault to use keyboard macros for >> "mission-critical" stuff and not testing them. > > Right. So we hack our own test library, and we use it to determine that > emacs 23 will break our code. We then put up a notice telling the end > users that they shouldn't uprade their version of emacs. They do it > anyway, and begin complaining, but everything's cool, because we can > point at the notice we put up. Maybe we could fix our code and put up a version that works with Emacs23. Oh wait, that doesn't work because users can't be bothered to upgrade our code since it is oh so mission-critical. Yes you're right: it's better to not test anything and simply assume that Emacs never changes. Since Emacs is 20 years old it doesn't change anymore; we can just close our eyes and we don't need to see the reality. All our assumptions about Emacs are correct and our code is perfect. > Note that in this case, you'd have to have pretty good test coverage > to have a hope of noticing this problem, because it's not the kind of > breakage that anyone would've anticipated as being at all likely. A test with lines longer than screen width would notice it. Seems like a simple and common test to me. Helmut ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-12 20:09 ` line-move-visual Joseph Brenner 2010-06-13 1:41 ` line-move-visual Tim X @ 2010-06-13 10:36 ` David Kastrup 2010-06-16 2:19 ` line-move-visual Joseph Brenner 1 sibling, 1 reply; 165+ messages in thread From: David Kastrup @ 2010-06-13 10:36 UTC (permalink / raw) To: help-gnu-emacs Joseph Brenner <doom@kzsu.stanford.edu> writes: > Evans Winner <thorne@unm.edu> writes: > > But this isn't the solution to the problem at hand. > >> I have read a number of posts on the devel list discussing the >> question of how to communicate with Emacs users about things like >> proposed changes to defaults. > > The right answer is that you should not be changing the defaults. > > If we really can't convince the developers that they need to respect > backwards compatibility, an actual solution to the problem might > be something like creating a switch that needs to be flipped on to > get the new whizzy behavior, something like: > > (setq modernize-emacs t) > > You then recommend that the default ~/.emacs for *new* users should > include that line. That means that new users live in a separate universe where they can't expect older users to be able to help them with their setup and usage problems. Because the older users don't even have a clue about what new users might be working with. It also means that older users never will get to see newer user interface features, even if they might better fit their workflow. "In your face" is a strategy where people actually get to see things and make a conscious decision about keeping or leaving them. It is a matter of courtesy to make any feature work as well as possible before confronting users with it by default. Something like font-locking required a lot of work before Emacs developers felt it could be made the default (while it has been the default for much longer with XEmacs, with partly dire consequences because of less maturity). Emacs evolves, and its community evolves and grows. And there is something to be said for the community members to know what they are roughly talking about when having an exchange about Emacs. And that implies a choice between evolution or stagnation of the default behavior. Emacs should show the best and most consistent behavior out of the box, whether or not that implies change. And that's what the discussion, if it is to be taken seriously, is supposed to be about. My personal preference would be that when recording and replaying macros, the used functions for arrow keys should be logical rather than visual mode commands. The current state is not satisfactory with regard to macro recording. Which does not mean that I don't like it as a default behavior otherwise. -- David Kastrup ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-13 10:36 ` line-move-visual David Kastrup @ 2010-06-16 2:19 ` Joseph Brenner 0 siblings, 0 replies; 165+ messages in thread From: Joseph Brenner @ 2010-06-16 2:19 UTC (permalink / raw) To: help-gnu-emacs David Kastrup <dak@gnu.org> writes: > Joseph Brenner <doom@kzsu.stanford.edu> writes: >> If we really can't convince the developers that they need to respect >> backwards compatibility, an actual solution to the problem might >> be something like creating a switch that needs to be flipped on to >> get the new whizzy behavior, something like: >> >> (setq modernize-emacs t) >> >> You then recommend that the default ~/.emacs for *new* users should >> include that line. > > That means that new users live in a separate universe where they can't > expect older users to be able to help them with their setup and usage > problems. Because the older users don't even have a clue about what new > users might be working with. Yes, and if I'd thought about that issue at all, I might've said something like: Doing something like this would be far better than the current practices, though it's obviously not perfect. Problems include: o A third-party developer may be suprised by the need to ask users not to flip on "modernize-emacs", and may have to write code to shut it off and live with some user confusion when the "modernized" behavior goes away temporarily. o It's effectively a project fork that at the very least complicates documentation and testing. > "In your face" is a strategy where people actually get to see things > and make a conscious decision about keeping or leaving them. They can also make a conscious decision about dropping an unstable piece of software. ^ permalink raw reply [flat|nested] 165+ messages in thread
[parent not found: <huvsd5$8pm$1@north.jnrs.ja.net>]
* Re: line-move-visual [not found] ` <huvsd5$8pm$1@north.jnrs.ja.net> @ 2010-06-12 12:25 ` Tim X 2010-06-12 20:17 ` line-move-visual Joseph Brenner 0 siblings, 1 reply; 165+ messages in thread From: Tim X @ 2010-06-12 12:25 UTC (permalink / raw) To: help-gnu-emacs Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> writes: > On 6/12/2010 5:18 AM, Tim X wrote: > >> Your arguments all suggest an environment where interfaces never change. >> This just doesn't exist and never has. Frequently improvements and new >> functionality require changes to existing interfaces, both programming >> and user. > > That is not quite true. In the OS & network protocols world, things can never > change essentially. We still live with the possibility of 7bit mail transport > even though nobody knows for sure whether there are any 7bit mail transport > systems anywhere. New protocols are designed that work around the limitations > of the old protocols. It has taken Unix some 15 years to figure out how to > retrofit Unicode into its byte-oriented view of the world. Things get messy > but that is the price we pay for backward-compatibility. > I don't disagree, but the mere fact new protocols are developed to handle the new as well as theold is in itself a change in the interface. Citing an example that shows no interface change doesn't really counter the arguement, but citing one that has changed would seem to. > In the Emacs world, we don't need to go that far. But there is no reason why > we can't expect the stability of the basic editing operations. I agree it is important to keep stability in basic editing operations and I agree the choice to make visual line mode the default was probably a mistake. However, I disagree with the arguemment that all the stability has been lost. If the new feature could not be disabled, then I would agree. However, the fact you can revert back to the old 'stable' behavior with only a minimal configuration means you can have exactly the same behavior and stability as before. What is really at issue isn't the change as much as making the chang ethe default behavior. Tim -- tcross (at) rapttech dot com dot au ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-12 12:25 ` line-move-visual Tim X @ 2010-06-12 20:17 ` Joseph Brenner 0 siblings, 0 replies; 165+ messages in thread From: Joseph Brenner @ 2010-06-12 20:17 UTC (permalink / raw) To: help-gnu-emacs Tim X <timx@nospam.dev.null> writes: > Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> writes: >> Tim X wrote: >>> Your arguments all suggest an environment where interfaces never change. >>> This just doesn't exist and never has. Frequently improvements and new >>> functionality require changes to existing interfaces, both programming >>> and user. >> >> That is not quite true. In the OS & network protocols world, things can never >> change essentially. We still live with the possibility of 7bit mail transport >> even though nobody knows for sure whether there are any 7bit mail transport >> systems anywhere. New protocols are designed that work around the limitations >> of the old protocols. It has taken Unix some 15 years to figure out how to >> retrofit Unicode into its byte-oriented view of the world. Things get messy >> but that is the price we pay for backward-compatibility. > I don't disagree, but the mere fact new protocols are developed to > handle the new as well as theold is in itself a change in the interface. Now you're playing semantic games. The subject under discussion is a decision where the developers intentionally messed with experienced users on the theory that they can deal with the pain. That's the kind of change we're talking about. If someone working on "ls" made a change that broke dired, you might see the situation differently. > Citing an example that shows no interface change doesn't really counter > the arguement, but citing one that has changed would seem to. Yes, the switch to unicode and utf-8 was difficult to accomplish without any pain to existing users, because of the nature of utf-8. Even if this case, many developers worked hard at making things Just Work, and they *almost* succeeded. ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-10 16:57 ` line-move-visual Mark Crispin 2010-06-10 18:38 ` line-move-visual Uday S Reddy @ 2010-06-10 19:57 ` Stefan Monnier 2010-06-13 12:46 ` line-move-visual Uday S Reddy 1 sibling, 1 reply; 165+ messages in thread From: Stefan Monnier @ 2010-06-10 19:57 UTC (permalink / raw) To: help-gnu-emacs >> A third suggestion is that we should start thinking of Emacs as >> mission-critical software. > It amazes me that anyone would think otherwise. Based on the amount of bugs in Emacs, the wishy-washy semantics of most of its operations, the quick&dirty half-solutions seen in most of its packages, it amazes me that someone would consider Emacs as mission-critical ;-) Stefan "who never uses Emacs while root" ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-10 19:57 ` line-move-visual Stefan Monnier @ 2010-06-13 12:46 ` Uday S Reddy 0 siblings, 0 replies; 165+ messages in thread From: Uday S Reddy @ 2010-06-13 12:46 UTC (permalink / raw) To: help-gnu-emacs On 6/10/2010 8:57 PM, Stefan Monnier wrote: > > Based on the amount of bugs in Emacs, the wishy-washy semantics of most > of its operations, the quick&dirty half-solutions seen in most of its > packages, it amazes me that someone would consider Emacs as > mission-critical ;-) Mission-critical software isn't necessarily perfect software. What software is? Mission-critical software requires a clean architecture, attention to fundamental notions of reliability, a design that can isolate any potential problems and an ability to recover from them. Even though you seem to think the semantics of the Emacs operations is wishy-washy (and I have pointed out some of them to you myself), the Emacs manuals - both the user's manual and the programming manual - are of quite high-quality and do an excellent job of defining things. We can generally spot the portions that are wishy-washy or too complicated for comfort and stay away from them. The use of Lisp with type safety and memory safety means that even inexperienced programmers can usually deliver code of decent quality. The various fail-safe mechanisms, such as autosave, backups, movemail etc, help for failure recovery. The large, professional user base, along with its age, imply that most problems have been identified and fixed a long time ago. The small developer community might also mean that it grows at a manageable pace (even though that seems to be changing now). When I was trawling through the net, I found somebody say that nobody ever lost an email message in VM (the Emacs package for email that I currently maintain). When I enquired about it, it was pretty much true. There is only one known instance of mail folder corruption, which happened due to the unibyte-multibyte transition of Emacs around the same time that Kyle Jones was retiring from VM. So, the transition was apparently half-done and wasn't discovered until much later. In comparison, I have lost loads of emails in Microsoft tools, lost files or changes to files in the Office Suite, had files damaged by Sun-Microsoft file servers, and had damaging system crashes due to hardware/device driver faults. On the whole, Emacs has been among the most reliable of all the tools I use. And, I suspect that must be true for almost all of us here. So, please do own up to this proud heritage! > > Stefan "who never uses Emacs while root" I guess you will have to amplify this point for us to draw the right conclusions from it. Cheers, Uday ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-06 9:39 ` line-move-visual David Kastrup [not found] ` <hug5rv$6d2$1@north.jnrs.ja.net> 2010-06-07 8:39 ` line-move-visual Tim X @ 2010-06-09 21:38 ` Joseph Brenner [not found] ` <slrni10ga0.t64.Jim.Diamond@jdiamond-nb.acadiau.ca> 2 siblings, 1 reply; 165+ messages in thread From: Joseph Brenner @ 2010-06-09 21:38 UTC (permalink / raw) To: help-gnu-emacs David Kastrup <dak@gnu.org> writes: > Uday S Reddy <uDOTsDOTreddy@cs.bham.ac.uk> writes: > >> Coupled with these real technical issues, there are the attitudinal >> problems of holier-than-thou, smarter-than-thou and modern-than-thou >> and what have you. > > Everybody is free to join the discussions on the Emacs developer lists. > Those who choose not to help with the work don't get to criticize the > results. A common democratic principle. So... if I want to avoid breakage-on-upgrade on my system, I need to become a member of the development process of: emacs linux kernel ubuntu (and presumably debian) x windows Not to mention: apache postgresql perl mh-e mh ...and much more. If I thought everyone in the free and/or open world really believed this, I would've voted with my feet a long time ago. (Maybe you should stop pretending you're our spokesman, huh?) ^ permalink raw reply [flat|nested] 165+ messages in thread
[parent not found: <slrni10ga0.t64.Jim.Diamond@jdiamond-nb.acadiau.ca>]
* Re: line-move-visual [not found] ` <slrni10ga0.t64.Jim.Diamond@jdiamond-nb.acadiau.ca> @ 2010-06-10 16:15 ` Mark Crispin 0 siblings, 0 replies; 165+ messages in thread From: Mark Crispin @ 2010-06-10 16:15 UTC (permalink / raw) To: help-gnu-emacs On Wed, 9 Jun 2010, Jim Diamond posted: > David: the message (about fundamental features changing being a Bad > Thing) was delivered in a less than gentle way, I proved that it was necessary. His sort will stonewall - it's their nature - but now he has egg on his face. > but I think you should > re-consider the idea, as opposed to the way it was delivered. He won't. But perhaps he will think twice before making future pointless changes like this. > Further, your comment "Those who choose ... A common democratic > principle." is just plain wrong. But I assume you know that. He doesn't. You have to take him at his word. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-04 7:59 ` line-move-visual Uday S Reddy [not found] ` <87pr07qjio.fsf@thinkpad.tsdh.de> @ 2010-06-04 17:52 ` Mark Crispin 2010-06-04 18:28 ` line-move-visual David Kastrup 2010-06-04 21:16 ` line-move-visual Stefan Monnier 1 sibling, 2 replies; 165+ messages in thread From: Mark Crispin @ 2010-06-04 17:52 UTC (permalink / raw) To: help-gnu-emacs On Fri, 4 Jun 2010, Uday S Reddy posted: > Having used Emacs for some 30 years myself, I always expect a few surprises > with a new major version of Emacs. Why should users expect surprises? > It takes me a few months to read through > all the change logs and the new manual sections to become comfortable with > all the new and changed features. Why should users - who presumably have work to do - be obliged to do this? > Sometimes when there are significant new > features, the old version just stays, because several users are uncomfortable > with the new version. The good thing about free software is that you can do > that! Until there is some support issue with the old version, such as a major security bug, and the software developers refuse to fix it - "update that ancient version you stupid idiot." > Reading through the emacs-developers list yesterday, It's nice that you have time to do that. > I also discovered that > there is an Options -> Customize -> New Options menu I turned off that stupid menu years ago. I need every screen line. I want to use emacs, not MS Word. > As I said before, the line-move-visual setting has been a complex decision > for the developers. And they screwed it up. This is getting ridiculous. My .emacs file is getting bigger and bigger, not to do any customizations but rather [1] to restore behaviors that some arrogant and irresponsible software developer decided to change; and [2] so that emacs on the dozens of machines I routinely use works the same on each and every one of them for the very basic command set that I use. It does no good whatsoever to tell me that I should get used to the change. Other machines don't have that change. Some are still in emacs 18. Others are bleeding edge. I should not have to customize emacs so that CTRL/A, CTRL/E, CTRL/N, and CTRL/P continue to work the way they've done since the mid-1970s. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-04 17:52 ` line-move-visual Mark Crispin @ 2010-06-04 18:28 ` David Kastrup [not found] ` <alpine.OSX.2.00.1006041808540.77397@hsinghsing.panda.com> 2010-06-04 21:16 ` line-move-visual Stefan Monnier 1 sibling, 1 reply; 165+ messages in thread From: David Kastrup @ 2010-06-04 18:28 UTC (permalink / raw) To: help-gnu-emacs Mark Crispin <mrc@panda.com> writes: > On Fri, 4 Jun 2010, Uday S Reddy posted: >> Having used Emacs for some 30 years myself, I always expect a few >> surprises with a new major version of Emacs. > > Why should users expect surprises? > >> It takes me a few months to read through all the change logs and the >> new manual sections to become comfortable with all the new and >> changed features. > > Why should users - who presumably have work to do - be obliged to do > this? Why should they install newer versions if they don't want things to change? >> I also discovered that there is an Options -> Customize -> New >> Options menu > > I turned off that stupid menu years ago. I need every screen line. I > want to use emacs, not MS Word. Why don't you get and install a suitably old version and stay with it? > It does no good whatsoever to tell me that I should get used to the > change. Other machines don't have that change. Some are still in > emacs 18. Others are bleeding edge. Install Emacs 18 everywhere and you are finished. > I should not have to customize emacs so that CTRL/A, CTRL/E, CTRL/N, > and CTRL/P continue to work the way they've done since the mid-1970s. Install a version of Emacs from the mid-1970s, and you get the behavior of Emacs from the mid-1970s. What is so hard about that? -- David Kastrup ^ permalink raw reply [flat|nested] 165+ messages in thread
[parent not found: <alpine.OSX.2.00.1006041808540.77397@hsinghsing.panda.com>]
[parent not found: <878w6truxc.fsf@lola.goethe.zz>]
* Re: line-move-visual [not found] ` <878w6truxc.fsf@lola.goethe.zz> @ 2010-06-06 2:25 ` Mark Crispin [not found] ` <87typc9dt8.fsf@kzsu.stanford.edu> 1 sibling, 0 replies; 165+ messages in thread From: Mark Crispin @ 2010-06-06 2:25 UTC (permalink / raw) To: help-gnu-emacs On Sun, 6 Jun 2010, David Kastrup posted: > So you think that Emacs development should stop in order to save > helpless end users from having new versions installed to them? No. I think that developers have a responsibility not to make changes to fundamental functionality. > What makes you think that Emacs developers are responsible for end users > subjected to restrictive administrations? Any developer who does not feel responsible to the end users has no business being a developer. > To a degree where you think heaping abuse on them is the right answer > for your problems with authorities? They deserve it when they do something that is abusive to the end users. Hopefully they learn from the mistake and not repeat it. > What makes you think that Emacs developers are responsible for > maintaining the rug of end users? Any emacs developer who does not feel responsible for maintaining the rug of end users has no business being an emacs developer. The open source community spent a long time trying to obtain credibility in the face of PHBs who claim that open source is "unreliable hacker code." If it weren't for the intense efforts of the Ubuntus of the world to get stuff "ready for prime time", open source software would languish in obscurity. Developers who pull antics such as changes to fundamental functionality destroy this hard-won credibility. Don't kid yourself. The opponents of open source are pushing back. Part of the "embrace, extend, destroy" strategy of proprietary vendors is to attack open source as being "unreliable hacker code." I have, in my collection of papers, a remarkable document which basically argues that nobody should run open source software because only proprietary software (which is "written by professional programmers") is trustworthy. It's laughable, except when an open source developer does something irresponsible that make PHBs go "a-ha!" There needs to be some soul-searching. There are reasons why proprietary systems occupy the majority of end user platforms. Not all of those reasons are due to vendor FUD. Now, if it's a design goal that open source software be the exclusive tools of the elite, then perhaps it's alright to make unilateral changes to default functionality for everybody. But in that case, don't expect the "l33t" to be more than a very small community. Don't expect that your work will end up being particularly significant either. Being a developer requires humility. >>> Install a version of Emacs from the mid-1970s, and you get the >>> behavior of Emacs from the mid-1970s. What is so hard about that? >> Have you done it? > In the mid-70s? No. Perhaps you ought to be quiet when you don't have a clue. > That's the point of time _you_ mentioned. I referred to this incompatible change as being something that changed fundamental functionality that had been there since the 1970s. You were the one who went off snidely about "install a version of emacs from the mid-1970s". >> Do you have a clue as to what the task entails? > Yes. I doubt it. >> Do you know what you made a completely idiotic statement? > Well, _you_ were the one talking about the mid-70s. Perhaps you ought to be quiet when you don't have a clue. >> I can answer "yes" to all three questions. > Congratulations. Compiling and installing GNU Emacs before its > existence is indeed an impressive feat. I assure you that I compiled, installed, and used emacs in the mid-1970s. Too bad that you are so lacking in a clue that you do not know that GNU emacs was not the first emacs. Nor was it the second. Nor even the third. > You really don't want to start a dick size contest in these categories > with me. Sorry, I'm straight. Look for your boyfriends someplace else. > Oh, by the way: for somebody claiming to work with Emacs since the 70s, > it is a somewhat unimpressive track record for Emacs to not contain a > single code contribution by you. This, coming from the same gnu.org people who claim credit for the work of others ("call it GNU/Linux"!), and have promised (for 30 years!) but never deliver on their new wonderful operating system that will have all the features of ITS. Yawn. Maybe, just maybe, people have other projects than a text editor. Far more people use the work that I have done than have/will ever use emacs. A text editor is not an end unto inself. It is at best a means to an end. Very few people today use emacs for document preparation; that is not, nor has it ever been, its strength. Since you asked, the UI principle of functional symmetry in which C-<x> operates on a character and M-<x> operates on a word was mine. I had C-M-<x> operate on a sentence, but that was changed to S-expression early on when it turned out that nobody used the sentence operators and nobody defended those key bindings either. I did this in my proto-emacs macro library (which predated emacs by about 6 months) and convinced RMS (it didn't take much convincing) that this was the way to go. You can also thank me for things like file operators prompting for their value instead of putting you in a program minibuffer with a bunch of TECO (or LISP code) with the cursor at where you should type the file name. Once upon a time, most commands simply preloaded a minibuffer with the contents of the macro to do it. It didn't take much argument from me to convince RMS on that matter either. But I was the one who went and said that dumping the user in code in a minibuffer sucks. I wrote some code in the original PDP-10 version, but I have long since forgotten what it was and it doesn't matter anyway since that code is extinct for all practical purposes. emacs was the fusion of many people's ideas. I would not presume to claim that I made a major contribution; it wasn't. But it wasn't zero either. Probably those design elements would have happened anyway. But they hadn't happened until I talked RMS into them. Design elements live on. GNU emacs' advantage was that it was a functional superset (substantial) of the PDP-10 version yet required no retraining for users of the old version. More important, just about every program that calls itself emacs behaves in predictable ways on a certain basic set of command keys. All of a sudden, GNU emacs has broken this by default. It's as if someone were to decide that GCC should change "/" to get an APL-style reduce operator, since division is just multiplication by the inverse. And, when a user complains, the developer says "if you don't like the way the current version of GCC works then install an older version." > Do you really think you are in the best position to call the developers > names? When developers do something idiotic and irresponsible, it is perfectly proper to call them on it. If you are the irresponsible idiot that make this change, then you deserve it. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. ^ permalink raw reply [flat|nested] 165+ messages in thread
[parent not found: <87typc9dt8.fsf@kzsu.stanford.edu>]
[parent not found: <alpine.OSX.2.00.1006091815150.93771@hsinghsing.panda.com>]
* Re: line-move-visual [not found] ` <alpine.OSX.2.00.1006091815150.93771@hsinghsing.panda.com> @ 2010-06-10 7:12 ` David Kastrup 0 siblings, 0 replies; 165+ messages in thread From: David Kastrup @ 2010-06-10 7:12 UTC (permalink / raw) To: help-gnu-emacs Mark Crispin <mrc@panda.com> writes: > On Wed, 9 Jun 2010, Joseph Brenner posted: >> May I suggest that: >> (1) Backwards compatibility is important. >> (2) Gratuitious changes should be avoided. >> (3) Breakage on upgrade is Not Good. >> I can't believe we even need to argue about this. > > With arrogant system programmers, you do. If you like beating up strawmen. The actual question is what constitutes "gratuitious" and how to weigh different categories. That is decided in discussions on the developer lists which everybody can participate in. Spouting abuse in other lists, in contrast, is not going to cause a difference except to self-importancy. -- David Kastrup ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-04 17:52 ` line-move-visual Mark Crispin 2010-06-04 18:28 ` line-move-visual David Kastrup @ 2010-06-04 21:16 ` Stefan Monnier 2010-06-05 1:29 ` line-move-visual Mark Crispin 1 sibling, 1 reply; 165+ messages in thread From: Stefan Monnier @ 2010-06-04 21:16 UTC (permalink / raw) To: help-gnu-emacs >> Having used Emacs for some 30 years myself, I always expect a few >> surprises with a new major version of Emacs. > Why should users expect surprises? To spice things up, of course. >> I also discovered that there is an Options -> Customize -> New Options >> menu > I turned off that stupid menu years ago. I need every screen line. I want > to use emacs, not MS Word. C-mouse-3 shows you the menu, even when it's not displayed. >> As I said before, the line-move-visual setting has been a complex decision >> for the developers. > And they screwed it up. Yup, big time, Stefan ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual 2010-06-04 21:16 ` line-move-visual Stefan Monnier @ 2010-06-05 1:29 ` Mark Crispin 0 siblings, 0 replies; 165+ messages in thread From: Mark Crispin @ 2010-06-05 1:29 UTC (permalink / raw) To: help-gnu-emacs On Fri, 4 Jun 2010, Stefan Monnier posted: >> Why should users expect surprises? > To spice things up, of course. Young system programmers seem to do this a lot, before they acquire the judgement to know better. >>> As I said before, the line-move-visual setting has been a complex decision >>> for the developers. >> And they screwed it up. > Yup, big time, Indeed. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. ^ permalink raw reply [flat|nested] 165+ messages in thread
* Re: line-move-visual [not found] ` <alpine.OSX.2.00.1006031431510.77397@hsinghsing.panda.com> 2010-06-04 7:59 ` line-move-visual Uday S Reddy @ 2010-06-04 13:20 ` sable 1 sibling, 0 replies; 165+ messages in thread From: sable @ 2010-06-04 13:20 UTC (permalink / raw) To: help-gnu-emacs On Jun 3, 6:11 pm, Mark Crispin <m...@panda.com> wrote: > I don't care if M-X fart-noisily-with-spray changes its default scent from > skunk to lemon. LOL!!! ^ permalink raw reply [flat|nested] 165+ messages in thread
end of thread, other threads:[~2010-06-20 18:42 UTC | newest] Thread overview: 165+ 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 [not found] <alpine.OSX.2.00.1006031053170.77397@hsinghsing.panda.com> [not found] ` <hu925r$1b$1@north.jnrs.ja.net> [not found] ` <alpine.OSX.2.00.1006031431510.77397@hsinghsing.panda.com> 2010-06-04 7:59 ` line-move-visual Uday S Reddy [not found] ` <87pr07qjio.fsf@thinkpad.tsdh.de> 2010-06-04 11:24 ` line-move-visual Uday S Reddy 2010-06-04 12:49 ` line-move-visual Tassilo Horn 2010-06-09 19:51 ` line-move-visual Joseph Brenner 2010-06-09 20:22 ` line-move-visual Brendan Halpin 2010-06-10 1:23 ` line-move-visual Stefan Monnier [not found] ` <hualdf$eln$1@north.jnrs.ja.net> 2010-06-04 13:00 ` line-move-visual Tassilo Horn 2010-06-04 14:51 ` line-move-visual Stefan Monnier 2010-06-04 20:53 ` line-move-visual Tassilo Horn [not found] ` <871vcmhq79.fsf@wivenhoe.ul.ie> [not found] ` <hub2ss$is4$1@north.jnrs.ja.net> 2010-06-04 14:45 ` line-move-visual Brendan Halpin 2010-06-04 17:49 ` line-move-visual Xah Lee 2010-06-04 18:18 ` line-move-visual Mark Crispin 2010-06-04 19:19 ` line-move-visual Xah Lee [not found] ` <alpine.OSX.2.00.1006041829210.77397@hsinghsing.panda.com> [not found] ` <089883ee-0a63-4cb4-a0ec-d2fe4e71cc03@y18g2000prn.googlegroups.com> 2010-06-06 9:53 ` line-move-visual Uday S Reddy 2010-06-06 9:39 ` line-move-visual David Kastrup [not found] ` <hug5rv$6d2$1@north.jnrs.ja.net> 2010-06-06 15:21 ` line-move-visual Tassilo Horn 2010-06-07 8:19 ` line-move-visual Uday S Reddy [not found] ` <m2fx0z46wj.fsf@gmail.com> 2010-06-07 16:20 ` line-move-visual Stefan Monnier 2010-06-06 15:43 ` line-move-visual Alain Ketterlin 2010-06-07 21:30 ` line-move-visual Joost Kremers 2010-06-06 18:17 ` line-move-visual Mark Crispin [not found] ` <4C0C466E.3000803@thadlabs.com> 2010-06-07 2:53 ` line-move-visual Mark Crispin 2010-06-07 8:46 ` line-move-visual Tim X 2010-06-07 16:23 ` line-move-visual Stefan Monnier 2010-06-09 20:23 ` line-move-visual Joseph Brenner 2010-06-07 8:39 ` line-move-visual Tim X 2010-06-10 10:12 ` line-move-visual Uday S Reddy 2010-06-10 13:43 ` line-move-visual Stefan Monnier 2010-06-10 15:17 ` line-move-visual Uday S Reddy 2010-06-10 19:53 ` line-move-visual Stefan Monnier 2010-06-10 15:44 ` line-move-visual despen 2010-06-10 22:02 ` line-move-visual Tassilo Horn 2010-06-10 23:56 ` line-move-visual Uday S Reddy 2010-06-10 22:48 ` line-move-visual Evans Winner 2010-06-10 16:57 ` line-move-visual Mark Crispin 2010-06-10 18:38 ` line-move-visual Uday S Reddy 2010-06-11 23:56 ` line-move-visual Mark Crispin 2010-06-12 0:17 ` line-move-visual Wojciech Meyer 2010-06-13 17:23 ` line-move-visual Mark Crispin 2010-06-13 20:56 ` line-move-visual Alan Mackenzie 2010-06-14 0:42 ` line-move-visual Jim Diamond 2010-06-14 10:49 ` line-move-visual Uday S Reddy 2010-06-14 17:16 ` line-move-visual Alan Mackenzie 2010-06-14 17:34 ` line-move-visual Uday S Reddy 2010-06-15 9:26 ` line-move-visual Tim X 2010-06-15 13:49 ` line-move-visual Stefan Monnier [not found] ` <87sk4n3ocs.fsf@rapttech.com.au> 2010-06-16 14:43 ` line-move-visual Stefan Monnier [not found] ` <m2k4q18od5.fsf@softwarematters.org> [not found] ` <jwvaaqxbcca.fsf-monnier+gnu.emacs.help@gnu.org> 2010-06-15 6:54 ` line-move-visual Pascal J. Bourguignon 2010-06-15 8:42 ` line-move-visual Uday S Reddy 2010-06-15 9:30 ` line-move-visual David Kastrup 2010-06-15 9:38 ` line-move-visual Tim X 2010-06-15 13:45 ` line-move-visual Stefan Monnier 2010-06-15 13:57 ` line-move-visual David Kastrup [not found] ` <jwvbpbb6oyk.fsf-monnier+gnu.emacs.help@gnu.org> 2010-06-16 18:04 ` line-move-visual David Kastrup [not found] ` <hv8gvf$98o$1@north.jnrs.ja.net> [not found] ` <hv8iog$313e$1@colin2.muc.de> 2010-06-15 19:37 ` line-move-visual Leo 2010-06-15 21:04 ` line-move-visual Uday S Reddy 2010-06-16 15:33 ` line-move-visual Alan Mackenzie 2010-06-17 8:51 ` line-move-visual Uday S Reddy 2010-06-16 14:33 ` line-move-visual Stefan Monnier 2010-06-15 16:51 ` line-move-visual Alan Mackenzie 2010-06-16 12:43 ` line-move-visual David Kastrup 2010-06-15 19:17 ` line-move-visual Xah Lee [not found] ` <4C17FE36.30102@thadlabs.com> 2010-06-15 22:45 ` line-move-visual Xah Lee 2010-06-15 23:31 ` line-move-visual Thad Floryan 2010-06-16 3:30 ` line-move-visual Evans Winner 2010-06-16 16:14 ` line-move-visual Xah Lee 2010-06-16 23:23 ` line-move-visual Chris F.A. Johnson 2010-06-16 14:52 ` line-move-visual Stefan Monnier [not found] ` <87r5k6sqg2.fsf@unm.edu> 2010-06-17 2:25 ` line-move-visual Stefan Monnier 2010-06-17 3:51 ` line-move-visual Chris F.A. Johnson 2010-06-17 9:03 ` line-move-visual Uday S Reddy 2010-06-20 18:42 ` line-move-visual B. T. Raven 2010-06-20 17:08 ` line-move-visual B. T. Raven 2010-06-12 4:18 ` line-move-visual Tim X 2010-06-12 4:37 ` line-move-visual Evans Winner 2010-06-12 8:30 ` line-move-visual David Kastrup 2010-06-12 8:40 ` line-move-visual Evans Winner 2010-06-12 9:30 ` line-move-visual Uday S Reddy 2010-06-12 12:30 ` line-move-visual Tim X 2010-06-12 20:09 ` line-move-visual Joseph Brenner 2010-06-13 1:41 ` line-move-visual Tim X 2010-06-13 10:22 ` line-move-visual Uday S Reddy 2010-06-13 10:51 ` line-move-visual David Kastrup 2010-06-13 11:32 ` line-move-visual Uday S Reddy 2010-06-14 0:46 ` line-move-visual Tim X [not found] ` <hv4nkd$quq$1@north.jnrs.ja.net> 2010-06-15 9:20 ` line-move-visual Tim X 2010-06-15 11:29 ` line-move-visual Uday S Reddy 2010-06-16 9:29 ` line-move-visual Tim X 2010-06-14 4:48 ` line-move-visual Tim X [not found] ` <m2iq5nw4pj.fsf@gmail.com> [not found] ` <hv2htd$4li$1@north.jnrs.ja.net> [not found] ` <m239wravxb.fsf@gmail.com> 2010-06-16 2:11 ` line-move-visual Joseph Brenner 2010-06-16 6:46 ` line-move-visual Helmut Eller 2010-06-13 10:36 ` line-move-visual David Kastrup 2010-06-16 2:19 ` line-move-visual Joseph Brenner [not found] ` <huvsd5$8pm$1@north.jnrs.ja.net> 2010-06-12 12:25 ` line-move-visual Tim X 2010-06-12 20:17 ` line-move-visual Joseph Brenner 2010-06-10 19:57 ` line-move-visual Stefan Monnier 2010-06-13 12:46 ` line-move-visual Uday S Reddy 2010-06-09 21:38 ` line-move-visual Joseph Brenner [not found] ` <slrni10ga0.t64.Jim.Diamond@jdiamond-nb.acadiau.ca> 2010-06-10 16:15 ` line-move-visual Mark Crispin 2010-06-04 17:52 ` line-move-visual Mark Crispin 2010-06-04 18:28 ` line-move-visual David Kastrup [not found] ` <alpine.OSX.2.00.1006041808540.77397@hsinghsing.panda.com> [not found] ` <878w6truxc.fsf@lola.goethe.zz> 2010-06-06 2:25 ` line-move-visual Mark Crispin [not found] ` <87typc9dt8.fsf@kzsu.stanford.edu> [not found] ` <alpine.OSX.2.00.1006091815150.93771@hsinghsing.panda.com> 2010-06-10 7:12 ` line-move-visual David Kastrup 2010-06-04 21:16 ` line-move-visual Stefan Monnier 2010-06-05 1:29 ` line-move-visual Mark Crispin 2010-06-04 13:20 ` line-move-visual sable
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.