* please make line-move-visual nil @ 2009-01-24 12:30 Alfred M. Szmidt 2009-05-13 13:35 ` garyo 2009-05-14 16:00 ` Shaun Johnson 0 siblings, 2 replies; 144+ messages in thread From: Alfred M. Szmidt @ 2009-01-24 12:30 UTC (permalink / raw) To: emacs-devel Please make line-move-visual nil, it is totally uninutive to have the point move to the same line, when you explicitly told it to move to the next line. It also breaks keyboard macros, since now you have no idea if you end up on a new line, or on the same line but at a different column. I know that it is pre-test time, but this behaviour is simply stupid and doesn't make any sense. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-01-24 12:30 please make line-move-visual nil Alfred M. Szmidt @ 2009-05-13 13:35 ` garyo 2009-05-13 23:59 ` Deniz Dogan 2009-05-14 17:14 ` Bob Nnamtrop 2009-05-14 16:00 ` Shaun Johnson 1 sibling, 2 replies; 144+ messages in thread From: garyo @ 2009-05-13 13:35 UTC (permalink / raw) To: Emacs-devel Alfred M. Szmidt wrote: > > Please make line-move-visual nil, it is totally uninutive to have the > point move to the same line, when you explicitly told it to move to > the next line. > I agree, this is very different behavior for such a core command! -- View this message in context: http://www.nabble.com/please-make-line-move-visual-nil-tp21640152p23521879.html Sent from the Emacs - Dev mailing list archive at Nabble.com. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-13 13:35 ` garyo @ 2009-05-13 23:59 ` Deniz Dogan 2009-05-14 0:06 ` garyo 2009-05-14 17:14 ` Bob Nnamtrop 1 sibling, 1 reply; 144+ messages in thread From: Deniz Dogan @ 2009-05-13 23:59 UTC (permalink / raw) To: garyo; +Cc: Emacs-devel 2009/5/13 garyo <garyo@genarts.com>: > > > > Alfred M. Szmidt wrote: >> >> Please make line-move-visual nil, it is totally uninutive to have the >> point move to the same line, when you explicitly told it to move to >> the next line. >> > > I agree, this is very different behavior for such a core command! I strongly disagree. I think this new behavior is way more intuitive to new Emacs users, who may not know how to set line-move-visual to non-nil themselves. It always bugged me when I started out using Emacs, coming from a Windows background, that it moved like it did. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-13 23:59 ` Deniz Dogan @ 2009-05-14 0:06 ` garyo 2009-05-14 8:51 ` Teemu Likonen 0 siblings, 1 reply; 144+ messages in thread From: garyo @ 2009-05-14 0:06 UTC (permalink / raw) To: Emacs-devel Deniz Dogan-3 wrote: > > 2009/5/13 garyo <garyo@genarts.com>: >> I agree, this is very different behavior for such a core command! > > I strongly disagree. I think this new behavior is way more intuitive > to new Emacs users > Good point, it's important to attract new users, but there are already so many ways Emacs differs from any other editor that I'm not sure it's worth breaking existing keyboard macros that have worked for years, not to mention forcing all the existing users to discover and change this setting. It really is a very core behavior, and it seems pretty late in the evolution of Emacs to change something like this. How about something like what C-x n n does? The first time you C-n down and end up on the same line, it could ask you if you want the "notepad" behavior or the "traditional" behavior? Then you could enable (permanently or not) or disable. Sure it would be a little odd, but we're already in uncharted territory it seems to me. -- View this message in context: http://www.nabble.com/please-make-line-move-visual-nil-tp21640152p23532135.html Sent from the Emacs - Dev mailing list archive at Nabble.com. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-14 0:06 ` garyo @ 2009-05-14 8:51 ` Teemu Likonen 2009-05-14 9:37 ` Antoine Levitt 2009-05-14 11:29 ` garyo 0 siblings, 2 replies; 144+ messages in thread From: Teemu Likonen @ 2009-05-14 8:51 UTC (permalink / raw) To: garyo; +Cc: Emacs-devel On 2009-05-13 17:06 (-0700), garyo wrote: > Good point, it's important to attract new users, but there are already > so many ways Emacs differs from any other editor that I'm not sure > it's worth breaking existing keyboard macros that have worked for > years [...] Hmm, does somebody really expect keyboard macros to work reliably over years? (Even if they may have worked in some cases.) Well, I have used Emacs less than year but I see macros more like temporary helpers. I'll have line-move-visual turned on from the day I upgrade to Emacs 23, regardless of the default. I think it's the normal behavior in text editors and pretty much in all text editing and thus it's sensible default. Long-timers with their years-old keyboard macros do know how to deal with Emacs configuration. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-14 8:51 ` Teemu Likonen @ 2009-05-14 9:37 ` Antoine Levitt 2009-05-15 3:21 ` Lennart Borgman 2009-05-14 11:29 ` garyo 1 sibling, 1 reply; 144+ messages in thread From: Antoine Levitt @ 2009-05-14 9:37 UTC (permalink / raw) To: Teemu Likonen; +Cc: garyo, Emacs-devel [-- Attachment #1: Type: text/plain, Size: 1248 bytes --] I think line-move-visual is great for common usage. It seems to me the problem of users with this new setting is mainly in keyboard macros. Why not disable line-move-visual when typing or replaying a keyboard macro, since in most case the user want the action to be independent of the line it is on ? Kind of a hack, but there's clearly two usages of the line move commands here. 2009/5/14 Teemu Likonen <tlikonen@iki.fi> > On 2009-05-13 17:06 (-0700), garyo wrote: > > > Good point, it's important to attract new users, but there are already > > so many ways Emacs differs from any other editor that I'm not sure > > it's worth breaking existing keyboard macros that have worked for > > years [...] > > Hmm, does somebody really expect keyboard macros to work reliably over > years? (Even if they may have worked in some cases.) Well, I have used > Emacs less than year but I see macros more like temporary helpers. > > I'll have line-move-visual turned on from the day I upgrade to Emacs 23, > regardless of the default. I think it's the normal behavior in text > editors and pretty much in all text editing and thus it's sensible > default. Long-timers with their years-old keyboard macros do know how to > deal with Emacs configuration. > > > [-- Attachment #2: Type: text/html, Size: 1621 bytes --] ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-14 9:37 ` Antoine Levitt @ 2009-05-15 3:21 ` Lennart Borgman 2009-05-15 4:22 ` Stephen J. Turnbull 0 siblings, 1 reply; 144+ messages in thread From: Lennart Borgman @ 2009-05-15 3:21 UTC (permalink / raw) To: Antoine Levitt; +Cc: Teemu Likonen, garyo, Emacs-devel On Thu, May 14, 2009 at 11:37 AM, Antoine Levitt <smeuuh@gmail.com> wrote: > I think line-move-visual is great for common usage. It seems to me the > problem of users with this new setting is mainly in keyboard macros. Why not > disable line-move-visual when typing or replaying a keyboard macro, since in > most case the user want the action to be independent of the line it is on ? > Kind of a hack, but there's clearly two usages of the line move commands > here. I have also suggested turning off line-move-visual when handling macros. I can't see any reason not to do that. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-15 3:21 ` Lennart Borgman @ 2009-05-15 4:22 ` Stephen J. Turnbull 2009-05-17 6:29 ` Alfred M. Szmidt 0 siblings, 1 reply; 144+ messages in thread From: Stephen J. Turnbull @ 2009-05-15 4:22 UTC (permalink / raw) To: Lennart Borgman; +Cc: Teemu Likonen, garyo, Antoine Levitt, Emacs-devel I think a better approach to context-dependent behavior would be buffer-local. Buffers where long lines are very common, and modes where newline is paragraph end, etc, should set line-move-visual on. Programming modes, table modes, etc should not. Lennart Borgman writes: > On Thu, May 14, 2009 at 11:37 AM, Antoine Levitt <smeuuh@gmail.com> wrote: > > I think line-move-visual is great for common usage. It seems to me the > > problem of users with this new setting is mainly in keyboard macros. Why not > > disable line-move-visual when typing or replaying a keyboard macro, since in > > most case the user want the action to be independent of the line it is on ? > > Kind of a hack, but there's clearly two usages of the line move commands > > here. > > I have also suggested turning off line-move-visual when handling > macros. I can't see any reason not to do that. The whole point of a macro is "what you did is what you get", but now people have to think about how behavior is going to change from when they just did to when they create the macro. That's going to reduce the utility of macros. One of the things that makes Emacs the great (and unusual) environment that it is is this *deliberate* blurring of the lines between UI and API, and between API and implementation. Because of the rigid nature of APIs, this necessarily causes a certain amount of rigidity in both UI and implementation. I don't think it's a good idea to draw a line between the UI and the API that way. Instead, say "I'm sorry, oldtimer, but this *is* a much better default behavior for most users most of the time, and if it bothers your ancient macros, switch it off." The rigidity is not a good thing, but please don't undermine the basic greatness of Emacs because you dislike it. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-15 4:22 ` Stephen J. Turnbull @ 2009-05-17 6:29 ` Alfred M. Szmidt 0 siblings, 0 replies; 144+ messages in thread From: Alfred M. Szmidt @ 2009-05-17 6:29 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: tlikonen, lennart.borgman, smeuuh, garyo, Emacs-devel I think a better approach to context-dependent behavior would be buffer-local. Buffers where long lines are very common, and modes where newline is paragraph end, etc, should set line-move-visual on. Programming modes, table modes, etc should not. I think this is a good suggestion. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-14 8:51 ` Teemu Likonen 2009-05-14 9:37 ` Antoine Levitt @ 2009-05-14 11:29 ` garyo 2009-05-14 15:37 ` Teemu Likonen 1 sibling, 1 reply; 144+ messages in thread From: garyo @ 2009-05-14 11:29 UTC (permalink / raw) To: Emacs-devel Teemu Likonen-2 wrote: > > Hmm, does somebody really expect keyboard macros to work reliably over > years? (Even if they may have worked in some cases.) Well, I have used > Emacs less than year but I see macros more like temporary helpers. > Well, I've been using Emacs since 1983 (about 25 years now), and C-n has never changed in all that time, and my ancient keyboard macros I've accumulated over the years still work :-). Another weirdness when this is turned on is what happens when you do C-u 25 C-n (go down 25 lines). This goes down a variable number of (real) lines now, depending on your emacs's screen width! A little odd, no? Maybe it's not, and I'm just old and stuck in my ways. -- View this message in context: http://www.nabble.com/please-make-line-move-visual-nil-tp21640152p23538683.html Sent from the Emacs - Dev mailing list archive at Nabble.com. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-14 11:29 ` garyo @ 2009-05-14 15:37 ` Teemu Likonen 2009-05-15 2:45 ` Alfred M. Szmidt 0 siblings, 1 reply; 144+ messages in thread From: Teemu Likonen @ 2009-05-14 15:37 UTC (permalink / raw) To: garyo; +Cc: Emacs-devel On 2009-05-14 04:29 (-0700), garyo wrote: > Another weirdness when this is turned on is what happens when you do > C-u 25 C-n (go down 25 lines). This goes down a variable number of > (real) lines now, depending on your emacs's screen width! A little > odd, no? Maybe it's not, and I'm just old and stuck in my ways. Obviously your logic is valid too. It's just that computer users tend to navigate visually on the screen-buffer. Machines, such as Emacs Lisp code, navigates on file-buffer (usually). ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-14 15:37 ` Teemu Likonen @ 2009-05-15 2:45 ` Alfred M. Szmidt 2009-05-15 14:31 ` Davis Herring 0 siblings, 1 reply; 144+ messages in thread From: Alfred M. Szmidt @ 2009-05-15 2:45 UTC (permalink / raw) To: Teemu Likonen; +Cc: garyo, Emacs-devel > Another weirdness when this is turned on is what happens when you > do C-u 25 C-n (go down 25 lines). This goes down a variable > number of (real) lines now, depending on your emacs's screen > width! A little odd, no? Maybe it's not, and I'm just old and > stuck in my ways. I find this odd as well. Obviously your logic is valid too. It's just that computer users tend to navigate visually on the screen-buffer. Machines, such as Emacs Lisp code, navigates on file-buffer (usually). There are alot of statements to the effect that new users will find line-move-visual more intuitive, and some new users have stated that they do find it more intuitive, likewise some old time users have stated the opposite. But has anyone actually done a poll on it or anything similar to that? I really think that this change should wait to after 23, and 23 should leave line-move-visual as nil. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-15 2:45 ` Alfred M. Szmidt @ 2009-05-15 14:31 ` Davis Herring 2009-05-17 6:29 ` Alfred M. Szmidt 0 siblings, 1 reply; 144+ messages in thread From: Davis Herring @ 2009-05-15 14:31 UTC (permalink / raw) To: ams; +Cc: Teemu Likonen, garyo, emacs-devel > > Another weirdness when this is turned on is what happens when you > > do C-u 25 C-n (go down 25 lines). This goes down a variable > > number of (real) lines now, depending on your emacs's screen > > width! A little odd, no? Maybe it's not, and I'm just old and > > stuck in my ways. > > I find this odd as well. > > Obviously your logic is valid too. It's just that computer users > tend to navigate visually on the screen-buffer. Machines, such as > Emacs Lisp code, navigates on file-buffer (usually). Perhaps this is too obvious to mention: why not make `next-line' treat `line-move-visual' as nil whenever it is given a prefix argument? It would not be difficult to decorate usage of C-n/C-p/<up>/<down> with C-1 in macros that already exist. (It would be tempting to have the prefix argument reverse the meaning of the variable rather than merely ignore it, but then macros written to use the character-based mode would change meaning when the variable changed.) Davis -- This product is sold by volume, not by mass. If it appears too dense or too sparse, it is because mass-energy conversion has occurred during shipping. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-15 14:31 ` Davis Herring @ 2009-05-17 6:29 ` Alfred M. Szmidt 2009-05-17 10:48 ` Eli Zaretskii 0 siblings, 1 reply; 144+ messages in thread From: Alfred M. Szmidt @ 2009-05-17 6:29 UTC (permalink / raw) To: herring; +Cc: tlikonen, garyo, emacs-devel > Obviously your logic is valid too. It's just that computer users > tend to navigate visually on the screen-buffer. Machines, such as > Emacs Lisp code, navigates on file-buffer (usually). Perhaps this is too obvious to mention: why not make `next-line' treat `line-move-visual' as nil whenever it is given a prefix argument? It would not be difficult to decorate usage of C-n/C-p/<up>/<down> with C-1 in macros that already exist. C-u C-n (and its variants) is a very useful movement command. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-17 6:29 ` Alfred M. Szmidt @ 2009-05-17 10:48 ` Eli Zaretskii 2009-05-17 20:28 ` Davis Herring 0 siblings, 1 reply; 144+ messages in thread From: Eli Zaretskii @ 2009-05-17 10:48 UTC (permalink / raw) To: ams; +Cc: tlikonen, garyo, emacs-devel > From: "Alfred M. Szmidt" <ams@gnu.org> > Date: Sun, 17 May 2009 02:29:38 -0400 > Cc: tlikonen@iki.fi, garyo@genarts.com, emacs-devel@gnu.org > Reply-To: ams@gnu.org > > Perhaps this is too obvious to mention: why not make `next-line' > treat `line-move-visual' as nil whenever it is given a prefix > argument? It would not be difficult to decorate usage of > C-n/C-p/<up>/<down> with C-1 in macros that already exist. > > C-u C-n (and its variants) is a very useful movement command. Indeed. I hope no one is seriously considering to interpret a numeric argument to these commands as anything other than the number of lines to move. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-17 10:48 ` Eli Zaretskii @ 2009-05-17 20:28 ` Davis Herring 2009-05-24 22:33 ` Drew Adams 0 siblings, 1 reply; 144+ messages in thread From: Davis Herring @ 2009-05-17 20:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ams, tlikonen, garyo, emacs-devel >> Perhaps this is too obvious to mention: why not make `next-line' >> treat `line-move-visual' as nil whenever it is given a prefix >> argument? It would not be difficult to decorate usage of >> C-n/C-p/<up>/<down> with C-1 in macros that already exist. >> >> C-u C-n (and its variants) is a very useful movement command. > > Indeed. I hope no one is seriously considering to interpret a numeric > argument to these commands as anything other than the number of lines > to move. I wasn't -- but I was suggesting that a numeric argument specify the number of lines and (if `line-move-visual is non-nil) change the meaning of the word "line" for the duration of the command. My thought is that visual movement, where it differs from logical, is likely to be over short distances and with quick bursts of n-n-n (with control held) or down-down-down rather than with numeric arguments. Maybe others disagree on the likely usage scenario. Davis -- This product is sold by volume, not by mass. If it appears too dense or too sparse, it is because mass-energy conversion has occurred during shipping. ^ permalink raw reply [flat|nested] 144+ messages in thread
* RE: please make line-move-visual nil 2009-05-17 20:28 ` Davis Herring @ 2009-05-24 22:33 ` Drew Adams 2009-05-24 23:18 ` Bastien ` (3 more replies) 0 siblings, 4 replies; 144+ messages in thread From: Drew Adams @ 2009-05-24 22:33 UTC (permalink / raw) To: emacs-devel I'm coming back to this thread because I just tried the new pretest (23.0.94.1), where the default value of `line-move-visual' is t. This is insane, IMO. The default value is t even in formatted modes such as Buffer Menu and Info. It is t even in code modes such as Emacs-Lisp. If you use `define-derived-mode' to define a new mode from scratch - a mode that has no parent mode, it has value t in that mode. It has value t everywhere, by default. This makes no sense. If you absolutely feel the need to make the default value be t for modes such as text-mode, which (you are convinced) are likely to benefit from it, then do so. But PLEASE leave the rest of Emacs alone, by default. This is a bad choice for Emacs - please reconsider this. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-24 22:33 ` Drew Adams @ 2009-05-24 23:18 ` Bastien 2009-05-24 23:18 ` Leo ` (2 subsequent siblings) 3 siblings, 0 replies; 144+ messages in thread From: Bastien @ 2009-05-24 23:18 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-devel "Drew Adams" <drew.adams@oracle.com> writes: > I'm coming back to this thread because I just tried the new pretest (23.0.94.1), > where the default value of `line-move-visual' is t. By the way, the function `line-move' (and friends) has no docstring. A docstring would help users better understand what this function does and how it is impacted by the default of `line-move-visual'. The better explanation I found is in the manual: "7.2 Changing the Location of Point", but I wonder who will go that far. -- Bastien ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-24 22:33 ` Drew Adams 2009-05-24 23:18 ` Bastien @ 2009-05-24 23:18 ` Leo 2009-05-24 23:50 ` Chong Yidong 2009-05-24 23:53 ` David Reitter 2009-05-25 2:02 ` Stefan Monnier 3 siblings, 1 reply; 144+ messages in thread From: Leo @ 2009-05-24 23:18 UTC (permalink / raw) To: emacs-devel On 2009-05-24 23:33 +0100, Drew Adams wrote: > I'm coming back to this thread because I just tried the new pretest (23.0.94.1), > where the default value of `line-move-visual' is t. > > This is insane, IMO. The default value is t even in formatted modes such as > Buffer Menu and Info. It is t even in code modes such as Emacs-Lisp. If you use > `define-derived-mode' to define a new mode from scratch - a mode that has no > parent mode, it has value t in that mode. It has value t everywhere, by default. > This makes no sense. > > If you absolutely feel the need to make the default value be t for modes such as > text-mode, which (you are convinced) are likely to benefit from it, then do so. > But PLEASE leave the rest of Emacs alone, by default. This is a bad choice for > Emacs - please reconsider this. I also think this is very bad design. Just imagine in vi, change hjkl to something different. If the purpose is to make new users feel at home, then we could create something like firstboot.el that runs in the first run. Most operating systems have this. Bye, -- .: Leo :. [ sdl.web AT gmail.com ] .: I use Emacs :. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-24 23:18 ` Leo @ 2009-05-24 23:50 ` Chong Yidong 2009-05-24 23:58 ` Lennart Borgman ` (2 more replies) 0 siblings, 3 replies; 144+ messages in thread From: Chong Yidong @ 2009-05-24 23:50 UTC (permalink / raw) To: Leo; +Cc: emacs-devel Leo <sdl.web@gmail.com> writes: > I also think this is very bad design. Just imagine in vi, change hjkl to > something different. During the course of Emacs development, the behavior of C-n and C-p have already evolved significantly, even before the line-move-visual change. For instance, they vscroll images and tall lines. The pros and cons of display line motion have been debated extensively, and I see no new points on either side of the debate. But since several people dislike the new behavior, I think it would be good to add an Options menu entry to disable it easily. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-24 23:50 ` Chong Yidong @ 2009-05-24 23:58 ` Lennart Borgman 2009-05-25 8:05 ` Miles Bader 2009-05-25 0:53 ` Drew Adams 2009-05-25 2:57 ` Eli Zaretskii 2 siblings, 1 reply; 144+ messages in thread From: Lennart Borgman @ 2009-05-24 23:58 UTC (permalink / raw) To: Chong Yidong; +Cc: Leo, emacs-devel On Mon, May 25, 2009 at 1:50 AM, Chong Yidong <cyd@stupidchicken.com> wrote: > Leo <sdl.web@gmail.com> writes: > >> I also think this is very bad design. Just imagine in vi, change hjkl to >> something different. > > During the course of Emacs development, the behavior of C-n and C-p have > already evolved significantly, even before the line-move-visual change. > For instance, they vscroll images and tall lines. > > The pros and cons of display line motion have been debated extensively, > and I see no new points on either side of the debate. But since several > people dislike the new behavior, I think it would be good to add an > Options menu entry to disable it easily. Since line-move-visual has been added partly for compatibility with editing in other environments (like for example in Firefox where I am writing this) and since in those environments this behaviour is bound to up/down arrows I think the options for customizing this should reflect that by distinguishing between C-n/C-p and up/down arrow keys. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-24 23:58 ` Lennart Borgman @ 2009-05-25 8:05 ` Miles Bader 0 siblings, 0 replies; 144+ messages in thread From: Miles Bader @ 2009-05-25 8:05 UTC (permalink / raw) To: Lennart Borgman; +Cc: Chong Yidong, Leo, emacs-devel Lennart Borgman <lennart.borgman@gmail.com> writes: > Since line-move-visual has been added partly for compatibility with > editing in other environments (like for example in Firefox where I am > writing this) and since in those environments this behaviour is bound > to up/down arrows I think the options for customizing this should > reflect that by distinguishing between C-n/C-p and up/down arrow keys. Please, no. That's even _more_ confusing... -Miles -- o The existentialist, not having a pillow, goes everywhere with the book by Sullivan, _I am going to spit on your graves_. ^ permalink raw reply [flat|nested] 144+ messages in thread
* RE: please make line-move-visual nil 2009-05-24 23:50 ` Chong Yidong 2009-05-24 23:58 ` Lennart Borgman @ 2009-05-25 0:53 ` Drew Adams 2009-05-25 1:03 ` Chong Yidong 2009-05-25 2:57 ` Eli Zaretskii 2 siblings, 1 reply; 144+ messages in thread From: Drew Adams @ 2009-05-25 0:53 UTC (permalink / raw) To: 'Chong Yidong', 'Leo'; +Cc: emacs-devel > During the course of Emacs development, the behavior of C-n > and C-p have already evolved significantly, even before the > line-move-visual change. For instance, they vscroll images > and tall lines. > > The pros and cons of display line motion have been debated > extensively, This is about the _default value_. You have changed the default value. > and I see no new points on either side of the debate. What's new is that you have changed the *default value*. > But since several people dislike the new behavior, I think it > would be good to add an Options menu entry to disable it easily. Sorry to say it this way, but that is a complete cop-out. This is about the DEFAULT VALUE. This is not about the ease of customizing. The default value should be nil. Except, if you insist, in specific buffers where (some) users might find it useful - for example, text-mode buffers. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-25 0:53 ` Drew Adams @ 2009-05-25 1:03 ` Chong Yidong 2009-05-25 1:59 ` Drew Adams 2009-05-25 2:32 ` Stephen J. Turnbull 0 siblings, 2 replies; 144+ messages in thread From: Chong Yidong @ 2009-05-25 1:03 UTC (permalink / raw) To: Drew Adams; +Cc: 'Leo', emacs-devel "Drew Adams" <drew.adams@oracle.com> writes: >> and I see no new points on either side of the debate. > > What's new is that you have changed the *default value*. This was done in July 2008, and there were fairly extensive discussions on this list then, and on several occasions afterwards. ^ permalink raw reply [flat|nested] 144+ messages in thread
* RE: please make line-move-visual nil 2009-05-25 1:03 ` Chong Yidong @ 2009-05-25 1:59 ` Drew Adams 2009-05-25 13:23 ` Stefan Monnier 2009-05-25 2:32 ` Stephen J. Turnbull 1 sibling, 1 reply; 144+ messages in thread From: Drew Adams @ 2009-05-25 1:59 UTC (permalink / raw) To: 'Chong Yidong'; +Cc: 'Leo', emacs-devel > >> I see no new points on either side of the debate. > > > > What's new is that you have changed the *default value*. > > This was done in July 2008 So what? We're talking about what is new for Emacs 23. Every change since Emacs 22 is new, regardless of how long ago it was first implemented. In this case, Emacs 23 has changed the default behavior from what it has always been. And this feature, and even this option, have been modified throughout the development period. The last change to this option was made just 4 weeks ago. Please don't try to paint this as some long-standing tradition or inscription in marble that it is too late to change. Emacs 23 has not even been released yet. Many of us have still not had the chance to exercise much of it. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-25 1:59 ` Drew Adams @ 2009-05-25 13:23 ` Stefan Monnier 2009-05-25 17:51 ` Drew Adams 0 siblings, 1 reply; 144+ messages in thread From: Stefan Monnier @ 2009-05-25 13:23 UTC (permalink / raw) To: Drew Adams; +Cc: 'Chong Yidong', 'Leo', emacs-devel >> >> I see no new points on either side of the debate. >> > What's new is that you have changed the *default value*. >> This was done in July 2008 > So what? We're talking about what is new for Emacs 23. See above: "I see no new points on either side of the debate". Stefan ^ permalink raw reply [flat|nested] 144+ messages in thread
* RE: please make line-move-visual nil 2009-05-25 13:23 ` Stefan Monnier @ 2009-05-25 17:51 ` Drew Adams 0 siblings, 0 replies; 144+ messages in thread From: Drew Adams @ 2009-05-25 17:51 UTC (permalink / raw) To: 'Stefan Monnier' Cc: 'Chong Yidong', 'Leo', emacs-devel > >> >> I see no new points on either side of the debate. > >> > What's new is that you have changed the *default value*. > >> This was done in July 2008 > > So what? We're talking about what is new for Emacs 23. > > See above: "I see no new points on either side of the debate". What about making the default value depend on the buffer type? The "debate" seems not to have been definitive. Either in terms of participation or in terms of ideas and arguments. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-25 1:03 ` Chong Yidong 2009-05-25 1:59 ` Drew Adams @ 2009-05-25 2:32 ` Stephen J. Turnbull 2009-05-25 3:01 ` Eli Zaretskii 1 sibling, 1 reply; 144+ messages in thread From: Stephen J. Turnbull @ 2009-05-25 2:32 UTC (permalink / raw) To: Chong Yidong; +Cc: 'Leo', Drew Adams, emacs-devel Chong Yidong writes: > This was done in July 2008, and there were fairly extensive discussions > on this list then, and on several occasions afterwards. Why have prereleases then, if it's "too late" for feedback from users who are not willing to bleed on the edge, and who don't necessarily read emacs-devel with their morning coffee? You should also consider that for this particular default, positive responses will come quickly from those who use long lines a lot, while they are unlikely to notice much aggravation in environments where visual motion is likely to be inappropriate, because those environment typically strongly discourage long lines anyway. Thus the complaints are likely to be relatively late and few---and for that very reason should be given more weight than the positive responses. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-25 2:32 ` Stephen J. Turnbull @ 2009-05-25 3:01 ` Eli Zaretskii 2009-05-25 4:16 ` Alfred M. Szmidt 2009-05-25 8:18 ` Drew Adams 0 siblings, 2 replies; 144+ messages in thread From: Eli Zaretskii @ 2009-05-25 3:01 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: emacs-devel > From: "Stephen J. Turnbull" <stephen@xemacs.org> > Date: Mon, 25 May 2009 11:32:49 +0900 > Cc: 'Leo' <sdl.web@gmail.com>, Drew Adams <drew.adams@oracle.com>, > emacs-devel@gnu.org > > Chong Yidong writes: > > > This was done in July 2008, and there were fairly extensive discussions > > on this list then, and on several occasions afterwards. > > Why have prereleases then, if it's "too late" for feedback from users > who are not willing to bleed on the edge, and who don't necessarily > read emacs-devel with their morning coffee? Pretest is not for changing the default behavior. They are for fixing bugs before the release. The time for users to voice their objections and requests for improvements is after Emacs is released. There's always the next release. > You should also consider that for this particular default, positive > responses will come quickly from those who use long lines a lot, while > they are unlikely to notice much aggravation in environments where > visual motion is likely to be inappropriate, because those environment > typically strongly discourage long lines anyway. Thus the complaints > are likely to be relatively late and few I don't know why you assume this: I happen to use longer-than-80-column lines quite a lot, and I'm quite sure it's not as rare as you seem to think. Not every text we see in Emacs is necessarily a well-formatted program source. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-25 3:01 ` Eli Zaretskii @ 2009-05-25 4:16 ` Alfred M. Szmidt 2009-05-25 8:34 ` Bastien ` (2 more replies) 2009-05-25 8:18 ` Drew Adams 1 sibling, 3 replies; 144+ messages in thread From: Alfred M. Szmidt @ 2009-05-25 4:16 UTC (permalink / raw) To: Eli Zaretskii; +Cc: stephen, emacs-devel Pretest is not for changing the default behavior. They are for fixing bugs before the release. And people have found that this is a bug, so they are voicing their objections again, since they were ignored last time. The time for users to voice their objections and requests for improvements is after Emacs is released. There's always the next release. The time is now, this is a regression in emacs, it is also not clear cut wherter people like it or not. It breaks several key features in emacs, like keyboard macros. It is a feature that should have been voted on before. Several people have suggested lots of good solutions, but people seem to have ignored them completely. Setting line-move-visual on a per-mode basis is a excellent middle ground that will make ALL parties happy. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-25 4:16 ` Alfred M. Szmidt @ 2009-05-25 8:34 ` Bastien 2009-05-25 20:21 ` Eli Zaretskii 2009-05-27 12:48 ` Andrew W. Nosenko 2 siblings, 0 replies; 144+ messages in thread From: Bastien @ 2009-05-25 8:34 UTC (permalink / raw) To: ams; +Cc: Eli Zaretskii, stephen, emacs-devel "Alfred M. Szmidt" <ams@gnu.org> writes: > It is a feature that should have been > voted on before. +1 -- Bastien ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-25 4:16 ` Alfred M. Szmidt 2009-05-25 8:34 ` Bastien @ 2009-05-25 20:21 ` Eli Zaretskii 2009-05-25 20:46 ` Drew Adams 2009-05-27 12:48 ` Andrew W. Nosenko 2 siblings, 1 reply; 144+ messages in thread From: Eli Zaretskii @ 2009-05-25 20:21 UTC (permalink / raw) To: ams; +Cc: stephen, emacs-devel > From: "Alfred M. Szmidt" <ams@gnu.org> > CC: stephen@xemacs.org, emacs-devel@gnu.org > Date: Mon, 25 May 2009 00:16:22 -0400 > > Pretest is not for changing the default behavior. They are for > fixing bugs before the release. > > And people have found that this is a bug, so they are voicing their > objections again, since they were ignored last time. A deliberate change in behavior is not a bug, as long as the only objection is "I don't like it". ^ permalink raw reply [flat|nested] 144+ messages in thread
* RE: please make line-move-visual nil 2009-05-25 20:21 ` Eli Zaretskii @ 2009-05-25 20:46 ` Drew Adams 0 siblings, 0 replies; 144+ messages in thread From: Drew Adams @ 2009-05-25 20:46 UTC (permalink / raw) To: 'Eli Zaretskii', ams; +Cc: stephen, emacs-devel > > Pretest is not for changing the default behavior. They are for > > fixing bugs before the release. > > > > And people have found that this is a bug, so they are voicing their > > objections again, since they were ignored last time. > > A deliberate change in behavior is not a bug, as long as the only > objection is "I don't like it". A deliberate change in behavior is not a good change, as long as the only reason supporting it is "I like it". Yes, let's get back to _reasons_ for the change in default behavior, _reasons_ against it, and perhaps discussion of alternatives, such as using different defaults for different kinds of buffers. Discussion of reasons is good. Proposals of alternatives and their discussion is good. We can note that (a) some people like the currently proposed change (yes, it is just a proposal - Emacs 23 has not yet been released) and (b) some people dislike it. Noting that is helpful, as a reminder that we are not quite there yet. But we need to move beyond just that notice. That notice shows only that we have a problem; it does not, in itself, point to a solution. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-25 4:16 ` Alfred M. Szmidt 2009-05-25 8:34 ` Bastien 2009-05-25 20:21 ` Eli Zaretskii @ 2009-05-27 12:48 ` Andrew W. Nosenko 2009-05-27 12:51 ` Andrew W. Nosenko 2009-05-31 11:45 ` Alfred M. Szmidt 2 siblings, 2 replies; 144+ messages in thread From: Andrew W. Nosenko @ 2009-05-27 12:48 UTC (permalink / raw) To: ams; +Cc: Eli Zaretskii, stephen, emacs-devel On Mon, May 25, 2009 at 7:16 AM, Alfred M. Szmidt <ams@gnu.org> wrote: > Setting line-move-visual on a > per-mode basis is a excellent middle ground that will make ALL parties > happy. Please NO!!!! First at all, after binding additional pair (M-down, M-up) to the "phisical" lines motion, In short: "magic" and unpredictable changing of behavior iis very inconeinient. At least I found it that. You can argue that it would not be "magic" or unpredictable, but indeed based on a mode or mode-deriviation. But could you predict (just as "stupid" user, not as mode's author), what deriviation tree has Occur mode, for example? Or Shell Output? (Ok, I know that Shell Command Output buffer has Fundamental mode, and what?) Even for C code it is very useful for me to have visual navigation. But I understand your point. Moreover, some time ago I also was very frustrated, because convinient way for "phisical" line navigation is no less. And solution is very simple: just give best from both worlds: above in this thread alredy mentioned that AquaEmacs has different bindings for C-n/C-p vs. down/up. I also just bound "phisical" line movements to the M-down and M-up in addition to the "visual" on down and up, and have now conventient and similar bindings to the both movement modes. Try it! Just don't throw away only because it is unusual for you. Try it first for some time (e.g. 1 week)! -- Andrew W. Nosenko <andrew.w.nosenko@gmail.com> ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-27 12:48 ` Andrew W. Nosenko @ 2009-05-27 12:51 ` Andrew W. Nosenko 2009-05-31 11:45 ` Alfred M. Szmidt 1 sibling, 0 replies; 144+ messages in thread From: Andrew W. Nosenko @ 2009-05-27 12:51 UTC (permalink / raw) To: ams; +Cc: Eli Zaretskii, stephen, emacs-devel On Wed, May 27, 2009 at 3:48 PM, Andrew W. Nosenko <andrew.w.nosenko@gmail.com> wrote: > On Mon, May 25, 2009 at 7:16 AM, Alfred M. Szmidt <ams@gnu.org> wrote: >> Setting line-move-visual on a >> per-mode basis is a excellent middle ground that will make ALL parties >> happy. > > Please NO!!!! > > > First at all, after binding additional pair (M-down, M-up) to the > "phisical" lines motion, Sorry. Paragraph above ("First at all...") is just artifact, forgorren to be deleted from the "draft". > > In short: "magic" and unpredictable changing of behavior iis very > inconeinient. At least I found it that. > > You can argue that it would not be "magic" or unpredictable, but > indeed based on a mode or mode-deriviation. But could you predict > (just as "stupid" user, not as mode's author), what deriviation tree > has Occur mode, for example? Or Shell Output? (Ok, I know that Shell > Command Output buffer has Fundamental mode, and what?) > > Even for C code it is very useful for me to have visual navigation. > > But I understand your point. Moreover, some time ago I also was very > frustrated, because convinient way for "phisical" line navigation is > no less. And solution is very simple: just give best from both > worlds: above in this thread alredy mentioned that AquaEmacs has > different bindings for C-n/C-p vs. down/up. I also just bound > "phisical" line movements to the M-down and M-up in addition to the > "visual" on down and up, and have now conventient and similar bindings > to the both movement modes. Try it! Just don't throw away only > because it is unusual for you. Try it first for some time (e.g. 1 > week)! > > -- > Andrew W. Nosenko <andrew.w.nosenko@gmail.com> > -- Andrew W. Nosenko <andrew.w.nosenko@gmail.com> ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-27 12:48 ` Andrew W. Nosenko 2009-05-27 12:51 ` Andrew W. Nosenko @ 2009-05-31 11:45 ` Alfred M. Szmidt 2009-05-31 12:08 ` Andreas Schwab ` (3 more replies) 1 sibling, 4 replies; 144+ messages in thread From: Alfred M. Szmidt @ 2009-05-31 11:45 UTC (permalink / raw) To: Andrew W. Nosenko; +Cc: eliz, stephen, emacs-devel You can argue that it would not be "magic" or unpredictable, but indeed based on a mode or mode-deriviation. But could you predict (just as "stupid" user, not as mode's author), what deriviation tree has Occur mode, for example? Or Shell Output? (Ok, I know that Shell Command Output buffer has Fundamental mode, and what?) Maybe you are right, all I would like to see is a compromise that the majority of people will agree to. The fact that Yidong, and Monnier simply disregard any discussion on the topic is frustrating, specially since people have voiced strong arguments for why the new behaviour is broken. Hand waving arguments are insulting to everyone on this list. This must be resolved before the release. But I understand your point. Moreover, some time ago I also was very frustrated, because convinient way for "phisical" line navigation is no less. And solution is very simple: just give best from both worlds: above in this thread alredy mentioned that AquaEmacs has different bindings for C-n/C-p vs. down/up. I also just bound "phisical" line movements to the M-down and M-up in addition to the "visual" on down and up, and have now conventient and similar bindings to the both movement modes. Maybe that is an idea, bind the line-move-visual behaviour to M-n/M-p or just the arrow keys (maybe someone suggested this already). What do people think? ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-31 11:45 ` Alfred M. Szmidt @ 2009-05-31 12:08 ` Andreas Schwab 2009-05-31 17:00 ` Miles Bader 2009-05-31 13:09 ` Deniz Dogan ` (2 subsequent siblings) 3 siblings, 1 reply; 144+ messages in thread From: Andreas Schwab @ 2009-05-31 12:08 UTC (permalink / raw) To: ams; +Cc: eliz, stephen, Andrew W. Nosenko, emacs-devel "Alfred M. Szmidt" <ams@gnu.org> writes: > Maybe that is an idea, bind the line-move-visual behaviour to M-n/M-p > or just the arrow keys (maybe someone suggested this already). What > do people think? The arrow keys should always behave the same as their C- counterparts. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-31 12:08 ` Andreas Schwab @ 2009-05-31 17:00 ` Miles Bader 2009-05-31 22:29 ` Bob Rogers 0 siblings, 1 reply; 144+ messages in thread From: Miles Bader @ 2009-05-31 17:00 UTC (permalink / raw) To: emacs-devel Andreas Schwab <schwab@linux-m68k.org> writes: >> Maybe that is an idea, bind the line-move-visual behaviour to M-n/M-p >> or just the arrow keys (maybe someone suggested this already). What >> do people think? > > The arrow keys should always behave the same as their C- counterparts. Yes. Making them different would make things _more_ confusing (and moreover, would discourage newbies from moving away from arrow keys -- suddenly they wouldn't be simply a different binding, but would be "the same thing except randomly different to stop a bunch of emacs old-timers from whining"). -Miles -- Logic, n. The art of thinking and reasoning in strict accordance with the limitations and incapacities of the human misunderstanding. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-31 17:00 ` Miles Bader @ 2009-05-31 22:29 ` Bob Rogers 2009-06-01 2:33 ` Miles Bader 0 siblings, 1 reply; 144+ messages in thread From: Bob Rogers @ 2009-05-31 22:29 UTC (permalink / raw) To: Miles Bader; +Cc: emacs-devel From: Miles Bader <miles@gnu.org> Date: Mon, 01 Jun 2009 02:00:46 +0900 Andreas Schwab <schwab@linux-m68k.org> writes: >> Maybe that is an idea, bind the line-move-visual behaviour to M-n/M-p >> or just the arrow keys (maybe someone suggested this already). What >> do people think? > > The arrow keys should always behave the same as their C- counterparts. Yes. Making them different would make things _more_ confusing (and moreover, would discourage newbies from moving away from arrow keys -- suddenly they wouldn't be simply a different binding, but would be "the same thing except randomly different to stop a bunch of emacs old-timers from whining"). -Miles Why do you suppose an Emacs newbie would expect the arrow keys to be the same as C-n/C-p? Personally, I would welcome binding visual movement to the arrow keys -- the arrows do *look* visual, especially compared to C-n/C-p. And it would make it much easier to switch between the two modes of movement if the visual/textual distinction was supported by distinct commands bound to distinct keys. -- Bob Rogers http://www.rgrjr.com/ ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-31 22:29 ` Bob Rogers @ 2009-06-01 2:33 ` Miles Bader 2009-06-01 9:22 ` Lennart Borgman 0 siblings, 1 reply; 144+ messages in thread From: Miles Bader @ 2009-06-01 2:33 UTC (permalink / raw) To: Bob Rogers; +Cc: emacs-devel Bob Rogers <rogers-emacs@rgrjr.dyndns.org> writes: > Why do you suppose an Emacs newbie would expect the arrow keys to be the > same as C-n/C-p? I don't think they'll "expect" that, I hope they'll learn from what we tell them, part of which is the traditional emacs key-bindings. That learning is what will be easier if emacs traditional key-bindings are simply different names for familiar concepts. > Personally, I would welcome binding visual movement to the arrow keys > -- the arrows do *look* visual, especially compared to C-n/C-p. And it > would make it much easier to switch between the two modes of movement if > the visual/textual distinction was supported by distinct commands bound > to distinct keys. Perhaps, but in this case it's harmful: whether one wants to use arrow keys or "emacsy" bindings tends to be dictated by the physical nature of the keyboard and one's task -- arrow keys are convenient because they're labelled, and a single keystroke, but they're inefficient and annoying if one is touch-typing (due to the very large hand movement required to use them), and lack integration with the general emacs key-binding scheme -- so it's very desirable to be able to switch between them. Having them be "similar but subtly different" horribly confuses an otherwise straight-forward association. -Miles -- [|nurgle|] ddt- demonic? so quake will have an evil kinda setting? one that will make every christian in the world foamm at the mouth? [iddt] nurg, that's the goal ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-06-01 2:33 ` Miles Bader @ 2009-06-01 9:22 ` Lennart Borgman 2009-06-01 9:54 ` Miles Bader 0 siblings, 1 reply; 144+ messages in thread From: Lennart Borgman @ 2009-06-01 9:22 UTC (permalink / raw) To: Miles Bader; +Cc: Bob Rogers, emacs-devel On Mon, Jun 1, 2009 at 4:33 AM, Miles Bader <miles@gnu.org> wrote: > Bob Rogers <rogers-emacs@rgrjr.dyndns.org> writes: >> Why do you suppose an Emacs newbie would expect the arrow keys to be the >> same as C-n/C-p? > Having them be "similar but subtly different" horribly confuses an > otherwise straight-forward association. I do not think that is true for something that you use as often as those keys. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-06-01 9:22 ` Lennart Borgman @ 2009-06-01 9:54 ` Miles Bader 2009-06-01 9:59 ` Lennart Borgman 0 siblings, 1 reply; 144+ messages in thread From: Miles Bader @ 2009-06-01 9:54 UTC (permalink / raw) To: Lennart Borgman; +Cc: Bob Rogers, emacs-devel Lennart Borgman <lennart.borgman@gmail.com> writes: >>> Why do you suppose an Emacs newbie would expect the arrow keys to be the >>> same as C-n/C-p? > >> Having them be "similar but subtly different" horribly confuses an >> otherwise straight-forward association. > > I do not think that is true for something that you use as often as those keys. I suppose an experienced user, like me, who uses both often[*], might be so accustomed to the differences that they would internalize them. Then they'd probably simply be _annoyed_ by the arbitrary differences, rather than confused by them. However my reply was talking about newbies. An emacs newbie, tentatively exploring the use of C-p/C-n instead of arrow-keys wouldn't have that experience. It seems pretty likely to me that they _would_ get confused (and annoyed of course) by such seemingly arbitrary differences and that this might discourage them. -Miles [*] I use arrow keys and C-n/C-p/etc pretty much interchangeably, depending on, for example, on whether I happen to be typing some text with both hands, or am browsing through a file while drinking coffee with the other hand.... -- Christian, n. One who follows the teachings of Christ so long as they are not inconsistent with a life of sin. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-06-01 9:54 ` Miles Bader @ 2009-06-01 9:59 ` Lennart Borgman 2009-06-05 22:13 ` Thien-Thi Nguyen 0 siblings, 1 reply; 144+ messages in thread From: Lennart Borgman @ 2009-06-01 9:59 UTC (permalink / raw) To: Miles Bader; +Cc: Bob Rogers, emacs-devel On Mon, Jun 1, 2009 at 11:54 AM, Miles Bader <miles@gnu.org> wrote: >>> Having them be "similar but subtly different" horribly confuses an >>> otherwise straight-forward association. >> >> I do not think that is true for something that you use as often as those keys. > > I suppose an experienced user, like me, who uses both often[*], might be > so accustomed to the differences that they would internalize them. Then > they'd probably simply be _annoyed_ by the arbitrary differences, rather > than confused by them. Is not what you feel here more of a choice? ;-) > However my reply was talking about newbies. An emacs newbie, > tentatively exploring the use of C-p/C-n instead of arrow-keys wouldn't > have that experience. It seems pretty likely to me that they _would_ > get confused (and annoyed of course) by such seemingly arbitrary > differences and that this might discourage them. Confusion is not generally annoying. It can also lead to curiosness. Otherwise people would not be playing games for example. (Did someone notice the n-back game?) ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-06-01 9:59 ` Lennart Borgman @ 2009-06-05 22:13 ` Thien-Thi Nguyen 0 siblings, 0 replies; 144+ messages in thread From: Thien-Thi Nguyen @ 2009-06-05 22:13 UTC (permalink / raw) To: emacs-devel () Lennart Borgman <lennart.borgman@gmail.com> () Mon, 1 Jun 2009 11:59:53 +0200 Confusion is not generally annoying. Sometimes people confound confusion and annoyance, and knowingly. One newbie's topiary maze is another's orange-tinged nightmare. Re this issue, i see the tutorial(s) strive to make the association between the arrow keys and C-n/C-p extremely simple (that is, w/o any "except in this situation..." subclauses). It would be a lot of work to change the tutorials. thi ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-31 11:45 ` Alfred M. Szmidt 2009-05-31 12:08 ` Andreas Schwab @ 2009-05-31 13:09 ` Deniz Dogan 2009-06-01 2:39 ` Miles Bader 2009-05-31 21:19 ` Chong Yidong 2009-06-01 13:29 ` Stefan Monnier 3 siblings, 1 reply; 144+ messages in thread From: Deniz Dogan @ 2009-05-31 13:09 UTC (permalink / raw) To: ams; +Cc: eliz, stephen, Andrew W. Nosenko, emacs-devel 2009/5/31 Alfred M. Szmidt <ams@gnu.org>: > Maybe that is an idea, bind the line-move-visual behaviour to M-n/M-p > or just the arrow keys (maybe someone suggested this already). What > do people think? I wouldn't be in favor of binding M-n and M-p by default as I have bound them to forward-paragraph and backward-paragraph, respectively, and I'm sure many other people have bound important stuff to those two combinations as well. Regarding the idea with the arrow keys, even though I think that ideally the arrow keys and their C- counterparts should behave the same at all times, it *is* a good suggestion, since newcomers often want to move by visual lines and use the arrow keys, while "old-timers" often want the opposite and often use C-n/C-p. -- Deniz Dogan ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-31 13:09 ` Deniz Dogan @ 2009-06-01 2:39 ` Miles Bader 0 siblings, 0 replies; 144+ messages in thread From: Miles Bader @ 2009-06-01 2:39 UTC (permalink / raw) To: Deniz Dogan; +Cc: ams, stephen, eliz, Andrew W. Nosenko, emacs-devel Deniz Dogan <deniz.a.m.dogan@gmail.com> writes: > I wouldn't be in favor of binding M-n and M-p by default as I have > bound them to forward-paragraph and backward-paragraph, respectively, > and I'm sure many other people have bound important stuff to those two > combinations as well. M-n/M-p are widely used in various modes, so it seems bad to given them global bindings with such a general meaning. > Regarding the idea with the arrow keys, even though I think that > ideally the arrow keys and their C- counterparts should behave the > same at all times, it *is* a good suggestion, since newcomers often > want to move by visual lines and use the arrow keys, while > "old-timers" often want the opposite and often use C-n/C-p. It's a bad suggestion (see my other responses on this thread for an explanation). -miles -- Liberty, n. One of imagination's most precious possessions. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-31 11:45 ` Alfred M. Szmidt 2009-05-31 12:08 ` Andreas Schwab 2009-05-31 13:09 ` Deniz Dogan @ 2009-05-31 21:19 ` Chong Yidong 2009-06-01 7:24 ` Mathias Megyei 2009-06-01 13:29 ` Stefan Monnier 3 siblings, 1 reply; 144+ messages in thread From: Chong Yidong @ 2009-05-31 21:19 UTC (permalink / raw) To: ams; +Cc: eliz, stephen, Andrew W. Nosenko, emacs-devel "Alfred M. Szmidt" <ams@gnu.org> writes: > Maybe you are right, all I would like to see is a compromise that the > majority of people will agree to. > > The fact that Yidong, and Monnier simply disregard any discussion on > the topic is frustrating, specially since people have voiced strong > arguments for why the new behaviour is broken. I've already made one suggestion: add a menu bar entry to make line-move-visual easier to turn on or off. Since there were objections to this, I haven't pursued it. There have been no other unproblematic suggestions AFAICT, so I think those who dislike the new behavior will, as Stefan said, simply have to set line-move-visual to nil and move on. > Maybe that is an idea, bind the line-move-visual behaviour to M-n/M-p > or just the arrow keys (maybe someone suggested this already). What > do people think? This is a bad idea, as pointed out by Andreas and Miles. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-31 21:19 ` Chong Yidong @ 2009-06-01 7:24 ` Mathias Megyei 0 siblings, 0 replies; 144+ messages in thread From: Mathias Megyei @ 2009-06-01 7:24 UTC (permalink / raw) To: Chong Yidong; +Cc: ams, stephen, eliz, Andrew W. Nosenko, emacs-devel On Sun, 2009-05-31 at 17:19 -0400, Chong Yidong wrote: > I've already made one suggestion: add a menu bar entry to make > line-move-visual easier to turn on or off. Since there were objections > to this, I haven't pursued it. There have been no other unproblematic > suggestions AFAICT, so I think those who dislike the new behavior will, > as Stefan said, simply have to set line-move-visual to nil and move on. What about adding a function 'toggle-visual-line-mode' to turn on/off visual line mode in the current buffer. At least for me it would be the best solution. Mathias ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-31 11:45 ` Alfred M. Szmidt ` (2 preceding siblings ...) 2009-05-31 21:19 ` Chong Yidong @ 2009-06-01 13:29 ` Stefan Monnier 2009-06-01 14:36 ` T.V. Raman 3 siblings, 1 reply; 144+ messages in thread From: Stefan Monnier @ 2009-06-01 13:29 UTC (permalink / raw) To: ams; +Cc: eliz, stephen, Andrew W. Nosenko, emacs-devel > This must be resolved before the release. > But I understand your point. Moreover, some time ago I also was > very frustrated, because convinient way for "phisical" line > navigation is no less. It is resolved: there is an easy and convenient way to get "physical line navigation", which is (setq line-move-visual nil). I do not think there is a real need to have both screen-line and logical-line movement available at the same time with convenient keys. Stefan ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-06-01 13:29 ` Stefan Monnier @ 2009-06-01 14:36 ` T.V. Raman 2009-06-01 16:20 ` Drew Adams 0 siblings, 1 reply; 144+ messages in thread From: T.V. Raman @ 2009-06-01 14:36 UTC (permalink / raw) To: Stefan Monnier, ams, eliz, stephen, Andrew W. Nosenko, emacs-devel But I'd still like to see the default behavior set so that visual line movement is not active. > This must be resolved before the release. > But I understand your point. Moreover, some time ago I also was > very frustrated, because convinient way for "phisical" line > navigation is no less. It is resolved: there is an easy and convenient way to get "physical line navigation", which is (setq line-move-visual nil). I do not think there is a real need to have both screen-line and logical-line movement available at the same time with convenient keys. Stefan -- On 6/1/09, Stefan Monnier <monnier@iro.umontreal.ca> wrote: >> This must be resolved before the release. > >> But I understand your point. Moreover, some time ago I also was >> very frustrated, because convinient way for "phisical" line >> navigation is no less. > > It is resolved: there is an easy and convenient way to get "physical > line navigation", which is (setq line-move-visual nil). > > I do not think there is a real need to have both screen-line and > logical-line movement available at the same time with convenient keys. > > > Stefan > > > ^ permalink raw reply [flat|nested] 144+ messages in thread
* RE: please make line-move-visual nil 2009-06-01 14:36 ` T.V. Raman @ 2009-06-01 16:20 ` Drew Adams 2009-06-01 17:56 ` Chong Yidong 2009-06-01 17:56 ` Chong Yidong 0 siblings, 2 replies; 144+ messages in thread From: Drew Adams @ 2009-06-01 16:20 UTC (permalink / raw) To: 'T.V. Raman', 'Stefan Monnier', ams, eliz, stephen, 'Andrew W. Nosenko' Please see bug report #3438. All of it is worth reading in this regard. Note in particular his request to have a buffer-local value for line-move-visual, and to have Dired use nil for this. (CCing the bug OP.) -- BTW, how's the user poll going? Where is it taking place? ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-06-01 16:20 ` Drew Adams @ 2009-06-01 17:56 ` Chong Yidong 2009-06-01 18:26 ` Drew Adams 2009-06-01 18:26 ` bug#3438: " Drew Adams 2009-06-01 17:56 ` Chong Yidong 1 sibling, 2 replies; 144+ messages in thread From: Chong Yidong @ 2009-06-01 17:56 UTC (permalink / raw) To: Drew Adams Cc: 3438, 'T.V. Raman', 'Andrew W. Nosenko', emacs-devel, 'ishikawa', ams, 'Stefan Monnier', stephen, eliz "Drew Adams" <drew.adams@oracle.com> writes: > Please see bug report #3438. All of it is worth reading in this regard. > > Note in particular his request to have a buffer-local value for > line-move-visual, and to have Dired use nil for this. >> In dired mode, when the cursor is near the beginning of a very long >> filename (as in near the "AaAaAa..." below , I can't move down to the >> next file by "n" or "cursor down" key anymore(!). In Dired, <up> and <down> call dired-previous-line and dired-next-line, which should not be affected by line-move-visual. I have not been able to reproduce the reported problem (i.e., getting point stuck in Dired). Maybe the reporter has some unusual customizations that are getting in the way. ^ permalink raw reply [flat|nested] 144+ messages in thread
* RE: please make line-move-visual nil 2009-06-01 17:56 ` Chong Yidong @ 2009-06-01 18:26 ` Drew Adams 2009-06-01 20:11 ` bug#3438: " Stefan Monnier ` (2 more replies) 2009-06-01 18:26 ` bug#3438: " Drew Adams 1 sibling, 3 replies; 144+ messages in thread From: Drew Adams @ 2009-06-01 18:26 UTC (permalink / raw) To: 'Chong Yidong' Cc: 3438, 'T.V. Raman', 'Andrew W. Nosenko', emacs-devel, 'ishikawa', ams, 'Stefan Monnier', stephen, eliz > > Please see bug report #3438. All of it is worth reading in > > this regard. Note in particular his request to have a > > buffer-local value for line-move-visual, and to have Dired > > use nil for this. > > >> In dired mode, when the cursor is near the beginning of a very long > >> filename (as in near the "AaAaAa..." below , I can't move > >> down to the next file by "n" or "cursor down" key anymore(!). > > In Dired, <up> and <down> call dired-previous-line and > dired-next-line, which should not be affected by line-move-visual. > I have not been able to reproduce the reported problem (i.e., > getting point stuck in Dired). Maybe the reporter has some unusual > customizations that are getting in the way. Ah, you're right. And I even remember that I started to mention Dired as an example of a formatted buffer in my original post in this thread, and removed it when I realized this was in fact the case (I used Info and Buffer List as examples). But I forgot about it when I saw the bug report. Thx. Dired is an exception in this regard among formatted buffers, so you are correct that Dired's bindings make it irrelevant for the immediate question. It does illustrate the general idea, however: line movement in formatted buffers is often different (should often be different) than it is in free-form text buffers. In Dired, it is particularly different, since we want point to stay on the file name - we constrain it to one column for vertical movement. IOW, Dired has its own buffer-local behavior for line movement, which is even more reflective of the buffer formatting than usual. If anything, this strengthens the argument for buffer-specific line movement, rather than weakening it. More typically (in formatted buffers), we want to reflect the use of newlines (they are positioned intentionally) and maintain the current column for line movement, but there is no single, privileged column (e.g. file name) that we want to constrain point to, as there is in Dired. Each formatted buffer could individually define its own line-movement commands, which amounts to just binding `line-move-visual' to nil around a call to `next-line'. But that would be a bit silly. Better to just let the variable be buffer-local. And provide nil as the default value for most formatted buffers. -- BTW, you didn't answer the questions about the poll. How's it coming along? Where is it? ^ permalink raw reply [flat|nested] 144+ messages in thread
* bug#3438: please make line-move-visual nil 2009-06-01 18:26 ` Drew Adams @ 2009-06-01 20:11 ` Stefan Monnier 2009-06-01 20:11 ` Stefan Monnier 2009-06-01 23:18 ` Drew Adams 2 siblings, 0 replies; 144+ messages in thread From: Stefan Monnier @ 2009-06-01 20:11 UTC (permalink / raw) To: Drew Adams Cc: 3438, 'T.V. Raman', 'Chong Yidong', emacs-devel, 'ishikawa', ams, stephen > More typically (in formatted buffers), we want to reflect the use of newlines > (they are positioned intentionally) and maintain the current column for line > movement, but there is no single, privileged column (e.g. file name) that we > want to constrain point to, as there is in Dired. I don't know if it's typical, but for most of those kinds of buffers you describe as "formatted", I think they should at least set truncate-lines. > Each formatted buffer could individually define its own line-movement > commands, which amounts to just binding `line-move-visual' to nil > around a call to `next-line'. But that would be a bit silly. > Better to just let the variable be buffer-local. And provide nil as > the default value for most formatted buffers. Any major mode is free to (set (make-local-variable 'line-move-visual) nil). As of now, I don't think any mode bothers to do that. > BTW, you didn't answer the questions about the poll. > How's it coming along? Where is it? I can't think of any poll which would bring any satisfactory answer to the discussion. Stefan ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-06-01 18:26 ` Drew Adams 2009-06-01 20:11 ` bug#3438: " Stefan Monnier @ 2009-06-01 20:11 ` Stefan Monnier 2009-06-01 21:00 ` bug#3438: " Drew Adams 2009-06-01 21:00 ` Drew Adams 2009-06-01 23:18 ` Drew Adams 2 siblings, 2 replies; 144+ messages in thread From: Stefan Monnier @ 2009-06-01 20:11 UTC (permalink / raw) To: Drew Adams Cc: 3438, 'T.V. Raman', 'Chong Yidong', 'Andrew W. Nosenko', emacs-devel, 'ishikawa', ams, stephen, eliz > More typically (in formatted buffers), we want to reflect the use of newlines > (they are positioned intentionally) and maintain the current column for line > movement, but there is no single, privileged column (e.g. file name) that we > want to constrain point to, as there is in Dired. I don't know if it's typical, but for most of those kinds of buffers you describe as "formatted", I think they should at least set truncate-lines. > Each formatted buffer could individually define its own line-movement > commands, which amounts to just binding `line-move-visual' to nil > around a call to `next-line'. But that would be a bit silly. > Better to just let the variable be buffer-local. And provide nil as > the default value for most formatted buffers. Any major mode is free to (set (make-local-variable 'line-move-visual) nil). As of now, I don't think any mode bothers to do that. > BTW, you didn't answer the questions about the poll. > How's it coming along? Where is it? I can't think of any poll which would bring any satisfactory answer to the discussion. Stefan ^ permalink raw reply [flat|nested] 144+ messages in thread
* bug#3438: please make line-move-visual nil 2009-06-01 20:11 ` Stefan Monnier @ 2009-06-01 21:00 ` Drew Adams 2009-06-01 21:00 ` Drew Adams 1 sibling, 0 replies; 144+ messages in thread From: Drew Adams @ 2009-06-01 21:00 UTC (permalink / raw) To: 'Stefan Monnier' Cc: 3438, 'T.V. Raman', 'Chong Yidong', emacs-devel, 'ishikawa', ams, stephen > > More typically (in formatted buffers), we want to reflect > > the use of newlines (they are positioned intentionally) > > and maintain the current column for line movement, but > > there is no single, privileged column (e.g. file name) > > that we want to constrain point to, as there is in Dired. > > I don't know if it's typical, but for most of those kinds of > buffers you describe as "formatted", I think they should at > least set truncate-lines. No reason given. Why? Why should Buffer List or Info or Man output or grep output or C code or Java code buffers have `truncate-lines' turned on? Because newlines are intentionally positioned in such modes, they should use `truncate-lines'? Why would that be? Is this a diversion to some other topic? What's the relation to the topic at hand, which is `line-move-visual'? > > Each formatted buffer could individually define its own > > line-movement commands, which amounts to just binding > > `line-move-visual' to nil around a call to `next-line'. > > But that would be a bit silly. Better to just let the > > variable be buffer-local. And provide nil as > > the default value for most formatted buffers. > > Any major mode is free to (set (make-local-variable > 'line-move-visual) nil). For those modes that come with Emacs, it is the Emacs code that would need to do that. It doesn't happen by spontaneous combustion. I proposed making the variable always buffer-local. If you don't want to do that, then yes, each mode for which nil is appropriate would need to do that. Or the opposite: Switch the default to nil, and let the (relatively fewer?) modes that use primarily free-form text do (set (make-local-variable 'line-move-visual) t). > As of now, I don't think any mode bothers to do that. Of course not. Nothing has been done yet about this issue. That's what the discussion is about: tailoring `line-move-visual' so that it DTRT. Which means turn itself off, by default, for non free-text modes, that is, code modes and modes with formatted text. IMHO. > > BTW, you didn't answer the questions about the poll. > > How's it coming along? Where is it? > > I can't think of any poll which would bring any satisfactory answer to > the discussion. "Let them eat cake!" (Or as the right-wing French government official said back in the day, speaking of the Nouvelle Caledonian independentistes, "Ever since we stopped listening to them, we don't hear anything from them anymore.") Poll, what poll? ^ permalink raw reply [flat|nested] 144+ messages in thread
* RE: please make line-move-visual nil 2009-06-01 20:11 ` Stefan Monnier 2009-06-01 21:00 ` bug#3438: " Drew Adams @ 2009-06-01 21:00 ` Drew Adams 2009-06-01 21:25 ` bug#3438: " Lennart Borgman ` (3 more replies) 1 sibling, 4 replies; 144+ messages in thread From: Drew Adams @ 2009-06-01 21:00 UTC (permalink / raw) To: 'Stefan Monnier' Cc: 3438, 'T.V. Raman', 'Chong Yidong', 'Andrew W. Nosenko', emacs-devel, 'ishikawa', ams, stephen, eliz > > More typically (in formatted buffers), we want to reflect > > the use of newlines (they are positioned intentionally) > > and maintain the current column for line movement, but > > there is no single, privileged column (e.g. file name) > > that we want to constrain point to, as there is in Dired. > > I don't know if it's typical, but for most of those kinds of > buffers you describe as "formatted", I think they should at > least set truncate-lines. No reason given. Why? Why should Buffer List or Info or Man output or grep output or C code or Java code buffers have `truncate-lines' turned on? Because newlines are intentionally positioned in such modes, they should use `truncate-lines'? Why would that be? Is this a diversion to some other topic? What's the relation to the topic at hand, which is `line-move-visual'? > > Each formatted buffer could individually define its own > > line-movement commands, which amounts to just binding > > `line-move-visual' to nil around a call to `next-line'. > > But that would be a bit silly. Better to just let the > > variable be buffer-local. And provide nil as > > the default value for most formatted buffers. > > Any major mode is free to (set (make-local-variable > 'line-move-visual) nil). For those modes that come with Emacs, it is the Emacs code that would need to do that. It doesn't happen by spontaneous combustion. I proposed making the variable always buffer-local. If you don't want to do that, then yes, each mode for which nil is appropriate would need to do that. Or the opposite: Switch the default to nil, and let the (relatively fewer?) modes that use primarily free-form text do (set (make-local-variable 'line-move-visual) t). > As of now, I don't think any mode bothers to do that. Of course not. Nothing has been done yet about this issue. That's what the discussion is about: tailoring `line-move-visual' so that it DTRT. Which means turn itself off, by default, for non free-text modes, that is, code modes and modes with formatted text. IMHO. > > BTW, you didn't answer the questions about the poll. > > How's it coming along? Where is it? > > I can't think of any poll which would bring any satisfactory answer to > the discussion. "Let them eat cake!" (Or as the right-wing French government official said back in the day, speaking of the Nouvelle Caledonian independentistes, "Ever since we stopped listening to them, we don't hear anything from them anymore.") Poll, what poll? ^ permalink raw reply [flat|nested] 144+ messages in thread
* bug#3438: please make line-move-visual nil 2009-06-01 21:00 ` Drew Adams @ 2009-06-01 21:25 ` Lennart Borgman 2009-06-01 21:25 ` Lennart Borgman ` (2 subsequent siblings) 3 siblings, 0 replies; 144+ messages in thread From: Lennart Borgman @ 2009-06-01 21:25 UTC (permalink / raw) To: Drew Adams Cc: 3438, T.V. Raman, Chong Yidong, emacs-devel, ishikawa, ams, stephen On Mon, Jun 1, 2009 at 11:00 PM, Drew Adams <drew.adams@oracle.com> wrote: > > I proposed making the variable always buffer-local. If you don't want to do > that, then yes, each mode for which nil is appropriate would need to do that. I think this is a global feature. Making it buffer local by default is probably not the best then. It would be on the same level as makeing the binding of C-n/C-p buffer local by default. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-06-01 21:00 ` Drew Adams 2009-06-01 21:25 ` bug#3438: " Lennart Borgman @ 2009-06-01 21:25 ` Lennart Borgman 2009-06-01 21:33 ` Drew Adams 2009-06-01 21:33 ` bug#3438: " Drew Adams 2009-06-01 22:33 ` Stefan Monnier 2009-06-01 22:33 ` Stefan Monnier 3 siblings, 2 replies; 144+ messages in thread From: Lennart Borgman @ 2009-06-01 21:25 UTC (permalink / raw) To: Drew Adams Cc: 3438, T.V. Raman, Chong Yidong, Andrew W. Nosenko, emacs-devel, ishikawa, ams, Stefan Monnier, stephen, eliz On Mon, Jun 1, 2009 at 11:00 PM, Drew Adams <drew.adams@oracle.com> wrote: > > I proposed making the variable always buffer-local. If you don't want to do > that, then yes, each mode for which nil is appropriate would need to do that. I think this is a global feature. Making it buffer local by default is probably not the best then. It would be on the same level as makeing the binding of C-n/C-p buffer local by default. ^ permalink raw reply [flat|nested] 144+ messages in thread
* RE: please make line-move-visual nil 2009-06-01 21:25 ` Lennart Borgman @ 2009-06-01 21:33 ` Drew Adams 2009-06-01 21:56 ` bug#3438: " Lennart Borgman 2009-06-01 21:56 ` Lennart Borgman 2009-06-01 21:33 ` bug#3438: " Drew Adams 1 sibling, 2 replies; 144+ messages in thread From: Drew Adams @ 2009-06-01 21:33 UTC (permalink / raw) To: 'Lennart Borgman' Cc: 3438, 'T.V. Raman', 'Chong Yidong', 'Andrew W. Nosenko', emacs-devel, 'ishikawa', ams, 'Stefan Monnier', stephen, eliz > > I proposed making the variable always buffer-local. If you > > don't want to do that, then yes, each mode for which nil > > is appropriate would need to do that. > > I think this is a global feature. Making it buffer local by default is > probably not the best then. Why? No reason given. But you say "then", as if being a global variable is a reason it shouldn't have a buffer-local value. > It would be on the same level as makeing > the binding of C-n/C-p buffer local by default. Since we have apparently replaced the classic behavior of `next-line', so it respects `line-move-visual', yes. (But I personally have no problem if we go back to the classic behavior, with normal line movement in all buffers.) If a non-nil value of `line-move-visual' is not appropriate for some (most?) buffers, but (some people think) it is appropriate for some other buffers, then that's the obvious conclusion: make it buffer-local. ^ permalink raw reply [flat|nested] 144+ messages in thread
* bug#3438: please make line-move-visual nil 2009-06-01 21:33 ` Drew Adams @ 2009-06-01 21:56 ` Lennart Borgman 2009-06-01 21:56 ` Lennart Borgman 1 sibling, 0 replies; 144+ messages in thread From: Lennart Borgman @ 2009-06-01 21:56 UTC (permalink / raw) To: Drew Adams Cc: 3438, T.V. Raman, Chong Yidong, emacs-devel, ishikawa, ams, stephen On Mon, Jun 1, 2009 at 11:33 PM, Drew Adams <drew.adams@oracle.com> wrote: >> > I proposed making the variable always buffer-local. If you >> > don't want to do that, then yes, each mode for which nil >> > is appropriate would need to do that. >> >> I think this is a global feature. Making it buffer local by default is >> probably not the best then. > > Why? No reason given. Yes, I think so. In the next sentence. It is a behaviour that is expected to be the same in most buffers for at least most new users. It is on the same level as a key binding. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-06-01 21:33 ` Drew Adams 2009-06-01 21:56 ` bug#3438: " Lennart Borgman @ 2009-06-01 21:56 ` Lennart Borgman 1 sibling, 0 replies; 144+ messages in thread From: Lennart Borgman @ 2009-06-01 21:56 UTC (permalink / raw) To: Drew Adams Cc: 3438, T.V. Raman, Chong Yidong, Andrew W. Nosenko, emacs-devel, ishikawa, ams, Stefan Monnier, stephen, eliz On Mon, Jun 1, 2009 at 11:33 PM, Drew Adams <drew.adams@oracle.com> wrote: >> > I proposed making the variable always buffer-local. If you >> > don't want to do that, then yes, each mode for which nil >> > is appropriate would need to do that. >> >> I think this is a global feature. Making it buffer local by default is >> probably not the best then. > > Why? No reason given. Yes, I think so. In the next sentence. It is a behaviour that is expected to be the same in most buffers for at least most new users. It is on the same level as a key binding. ^ permalink raw reply [flat|nested] 144+ messages in thread
* bug#3438: please make line-move-visual nil 2009-06-01 21:25 ` Lennart Borgman 2009-06-01 21:33 ` Drew Adams @ 2009-06-01 21:33 ` Drew Adams 1 sibling, 0 replies; 144+ messages in thread From: Drew Adams @ 2009-06-01 21:33 UTC (permalink / raw) To: 'Lennart Borgman' Cc: 3438, 'T.V. Raman', 'Chong Yidong', emacs-devel, 'ishikawa', ams, stephen > > I proposed making the variable always buffer-local. If you > > don't want to do that, then yes, each mode for which nil > > is appropriate would need to do that. > > I think this is a global feature. Making it buffer local by default is > probably not the best then. Why? No reason given. But you say "then", as if being a global variable is a reason it shouldn't have a buffer-local value. > It would be on the same level as makeing > the binding of C-n/C-p buffer local by default. Since we have apparently replaced the classic behavior of `next-line', so it respects `line-move-visual', yes. (But I personally have no problem if we go back to the classic behavior, with normal line movement in all buffers.) If a non-nil value of `line-move-visual' is not appropriate for some (most?) buffers, but (some people think) it is appropriate for some other buffers, then that's the obvious conclusion: make it buffer-local. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-06-01 21:00 ` Drew Adams 2009-06-01 21:25 ` bug#3438: " Lennart Borgman 2009-06-01 21:25 ` Lennart Borgman @ 2009-06-01 22:33 ` Stefan Monnier 2009-06-01 22:52 ` Drew Adams ` (3 more replies) 2009-06-01 22:33 ` Stefan Monnier 3 siblings, 4 replies; 144+ messages in thread From: Stefan Monnier @ 2009-06-01 22:33 UTC (permalink / raw) To: Drew Adams Cc: 3438, 'T.V. Raman', 'Chong Yidong', 'Andrew W. Nosenko', emacs-devel, 'ishikawa', ams, stephen, eliz >> I don't know if it's typical, but for most of those kinds of >> buffers you describe as "formatted", I think they should at >> least set truncate-lines. > No reason given. Why? > Why should Buffer List or Info or Man output or grep output or C code > or Java code buffers have `truncate-lines' turned on? Because newlines > are intentionally positioned in such modes, they should use > `truncate-lines'? Why would that be? Just goes to show that I misunderstood your notion of "formatted". I was thinking of buffers like pcl-cvs, VC, dired, buffer-list, ibuffer, ... Not info, not man, not Java, not C (not sure about grep, I like to set it in grep, but I'm not sure if it's a good idea in general). > Is this a diversion to some other topic? What's the relation to the > topic at hand, which is `line-move-visual'? When truncate-lines is non-nil, visual lines and logical lines coincide, so line-move-visual doesn't make much difference any more (other than for proportional text, that is). > I proposed making the variable always buffer-local. There would be no benefit to it: (set (make-local-variable <foo>) <bar>) is the standard way for major modes to set variables. Stefan ^ permalink raw reply [flat|nested] 144+ messages in thread
* RE: please make line-move-visual nil 2009-06-01 22:33 ` Stefan Monnier @ 2009-06-01 22:52 ` Drew Adams 2009-06-01 23:12 ` Lennart Borgman ` (3 more replies) 2009-06-01 22:52 ` Drew Adams ` (2 subsequent siblings) 3 siblings, 4 replies; 144+ messages in thread From: Drew Adams @ 2009-06-01 22:52 UTC (permalink / raw) To: 'Stefan Monnier' Cc: 3438, 'T.V. Raman', 'Chong Yidong', 'Andrew W. Nosenko', emacs-devel, 'ishikawa', ams, stephen, eliz > Just goes to show that I misunderstood your notion of "formatted". > I was thinking of buffers like pcl-cvs, VC, dired, buffer-list, > ibuffer, ... Not info, not man, not Java, not C (not sure about > grep, I like to set it in grep, but I'm not sure if it's a good > idea in general). I mentioned Info and Buffer List from the beginning. And I mentioned code buffers and buffers with tabular formatting as well. The distinction I made is between buffers that are mostly free-form text, where newlines are typically not intentionally positioned by the user or by Emacs, and the other buffers, where they are. Even for Buffer List, Dired, and the rest you mentioned, do you really "think they should at least set `truncate-lines'? Is that slated for Emacs 23.2? > > Is this a diversion to some other topic? What's the relation to the > > topic at hand, which is `line-move-visual'? > > When truncate-lines is non-nil, visual lines and logical > lines coincide, so line-move-visual doesn't make much > difference any more (other than for proportional text, that is). True, when the line is not wrapped in any way, there is no line-wrapping. Guess that's one way to skirt the issue. ;-) The relation to this issue is that with `truncate-lines' the issue is evacuated and the distinction no longer matters? "We're trying to decide whether to order fish or meat for the group." "Just don't eat, then it doesn't matter." > > I proposed making the variable always buffer-local. > > There would be no benefit to it: > (set (make-local-variable <foo>) <bar>) > is the standard way for major modes to set variables. I have no problem with _how_ the buffer-local value is set, as long as the default value set for buffers that are not mostly free-form text is nil. And I have no problem with it not being buffer-local at all, if the default value is nil. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-06-01 22:52 ` Drew Adams @ 2009-06-01 23:12 ` Lennart Borgman 2009-06-01 23:57 ` Drew Adams 2009-06-01 23:57 ` bug#3438: " Drew Adams 2009-06-01 23:12 ` Lennart Borgman ` (2 subsequent siblings) 3 siblings, 2 replies; 144+ messages in thread From: Lennart Borgman @ 2009-06-01 23:12 UTC (permalink / raw) To: Drew Adams Cc: 3438, T.V. Raman, Chong Yidong, Andrew W. Nosenko, emacs-devel, ishikawa, ams, Stefan Monnier, stephen, eliz On Tue, Jun 2, 2009 at 12:52 AM, Drew Adams <drew.adams@oracle.com> wrote: > > The distinction I made is between buffers that are mostly free-form text, where > newlines are typically not intentionally positioned by the user or by Emacs, and > the other buffers, where they are. Is not that a difficult distinction here? (In a word processor it would be different.) Exactly how do you do the distinction - as simple as possible, because if it is useful it must be easy to understand? One point I mentioned before is that code might look scrambled, but maybe that point could be cured some way? (If it really have to be cured ...) ^ permalink raw reply [flat|nested] 144+ messages in thread
* RE: please make line-move-visual nil 2009-06-01 23:12 ` Lennart Borgman @ 2009-06-01 23:57 ` Drew Adams 2009-06-01 23:57 ` bug#3438: " Drew Adams 1 sibling, 0 replies; 144+ messages in thread From: Drew Adams @ 2009-06-01 23:57 UTC (permalink / raw) To: 'Lennart Borgman' Cc: 3438, 'T.V. Raman', 'Chong Yidong', 'Andrew W. Nosenko', emacs-devel, 'ishikawa', ams, 'Stefan Monnier', stephen, eliz > > The distinction I made is between buffers that are mostly > > free-form text, where newlines are typically not > > intentionally positioned by the user or by Emacs, and > > the other buffers, where they are. > > Is not that a difficult distinction here? (In a word processor it > would be different.) Exactly how do you do the distinction - as simple > as possible, because if it is useful it must be easy to understand? > > One point I mentioned before is that code might look scrambled, but > maybe that point could be cured some way? (If it really have to be > cured ...) The exact decision for any given mode is not the issue. Please don't make the perfect into the enemy of the good. Adjustments can always be made later, based on user feedback wrt particular modes. The important thing is to decide that non-nil `line-move-visual' should be reserved, by default, for buffers that mostly have free-form text. That includes text-mode, mail message buffers, and the like. Don't search for the gray areas as a means to ignore or avoid a useful general distinction. Info is such a gray area. Should Info eventually become unformatted? Sure, maybe, because most of it is just text. Things can evolve. But today, Info's visual lines end with newlines. It has menus and headers that end in newlines. It has code samples. But yes, most of it is just text, for which line endings are, a priori, meaningless. I wouldn't argue much either way, for Info. Another gray area is *Help*, for similar reasons. But even if we disagree about how to treat Info or *Help* today, that's not the point. To "get" the distinction, look at the extremes, not the middle: Buffer List vs a text paragraph like this one. Think <pre> in HTML vs <p> (no, it's not exactly the same thing, but that might help you see the distinction). Is there a gradient from hot to cold? Of course. But not all meals are best hot, nor all best cold. You like to eat fried chicken cold, and I like it hot. So what? Does that mean we must pick one, hot or cold, to apply to all food? There's individual preference, sure, and users can define buffer-local variables as they see fit individually. But if we're serving meals for the group then we need to decide, based on some general rules of thumb. Salad is by default cold; soup is by default hot. ^ permalink raw reply [flat|nested] 144+ messages in thread
* bug#3438: please make line-move-visual nil 2009-06-01 23:12 ` Lennart Borgman 2009-06-01 23:57 ` Drew Adams @ 2009-06-01 23:57 ` Drew Adams 1 sibling, 0 replies; 144+ messages in thread From: Drew Adams @ 2009-06-01 23:57 UTC (permalink / raw) To: 'Lennart Borgman' Cc: 3438, 'T.V. Raman', 'Chong Yidong', emacs-devel, 'ishikawa', ams, stephen > > The distinction I made is between buffers that are mostly > > free-form text, where newlines are typically not > > intentionally positioned by the user or by Emacs, and > > the other buffers, where they are. > > Is not that a difficult distinction here? (In a word processor it > would be different.) Exactly how do you do the distinction - as simple > as possible, because if it is useful it must be easy to understand? > > One point I mentioned before is that code might look scrambled, but > maybe that point could be cured some way? (If it really have to be > cured ...) The exact decision for any given mode is not the issue. Please don't make the perfect into the enemy of the good. Adjustments can always be made later, based on user feedback wrt particular modes. The important thing is to decide that non-nil `line-move-visual' should be reserved, by default, for buffers that mostly have free-form text. That includes text-mode, mail message buffers, and the like. Don't search for the gray areas as a means to ignore or avoid a useful general distinction. Info is such a gray area. Should Info eventually become unformatted? Sure, maybe, because most of it is just text. Things can evolve. But today, Info's visual lines end with newlines. It has menus and headers that end in newlines. It has code samples. But yes, most of it is just text, for which line endings are, a priori, meaningless. I wouldn't argue much either way, for Info. Another gray area is *Help*, for similar reasons. But even if we disagree about how to treat Info or *Help* today, that's not the point. To "get" the distinction, look at the extremes, not the middle: Buffer List vs a text paragraph like this one. Think <pre> in HTML vs <p> (no, it's not exactly the same thing, but that might help you see the distinction). Is there a gradient from hot to cold? Of course. But not all meals are best hot, nor all best cold. You like to eat fried chicken cold, and I like it hot. So what? Does that mean we must pick one, hot or cold, to apply to all food? There's individual preference, sure, and users can define buffer-local variables as they see fit individually. But if we're serving meals for the group then we need to decide, based on some general rules of thumb. Salad is by default cold; soup is by default hot. ^ permalink raw reply [flat|nested] 144+ messages in thread
* bug#3438: please make line-move-visual nil 2009-06-01 22:52 ` Drew Adams 2009-06-01 23:12 ` Lennart Borgman @ 2009-06-01 23:12 ` Lennart Borgman 2009-06-01 23:13 ` Eli Zaretskii 2009-06-01 23:13 ` Eli Zaretskii 3 siblings, 0 replies; 144+ messages in thread From: Lennart Borgman @ 2009-06-01 23:12 UTC (permalink / raw) To: Drew Adams Cc: 3438, T.V. Raman, Chong Yidong, emacs-devel, ishikawa, ams, stephen On Tue, Jun 2, 2009 at 12:52 AM, Drew Adams <drew.adams@oracle.com> wrote: > > The distinction I made is between buffers that are mostly free-form text, where > newlines are typically not intentionally positioned by the user or by Emacs, and > the other buffers, where they are. Is not that a difficult distinction here? (In a word processor it would be different.) Exactly how do you do the distinction - as simple as possible, because if it is useful it must be easy to understand? One point I mentioned before is that code might look scrambled, but maybe that point could be cured some way? (If it really have to be cured ...) ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-06-01 22:52 ` Drew Adams 2009-06-01 23:12 ` Lennart Borgman 2009-06-01 23:12 ` Lennart Borgman @ 2009-06-01 23:13 ` Eli Zaretskii 2009-06-01 23:23 ` bug#3438: " Drew Adams 2009-06-01 23:23 ` Drew Adams 2009-06-01 23:13 ` Eli Zaretskii 3 siblings, 2 replies; 144+ messages in thread From: Eli Zaretskii @ 2009-06-01 23:13 UTC (permalink / raw) To: Drew Adams Cc: 3438, tv.raman.tv, cyd, andrew.w.nosenko, emacs-devel, chiaki.ishikawa, ams, monnier, stephen > From: "Drew Adams" <drew.adams@oracle.com> > Cc: "'Chong Yidong'" <cyd@stupidchicken.com>, > "'T.V. Raman'" <tv.raman.tv@gmail.com>, <ams@gnu.org>, <eliz@gnu.org>, > <stephen@xemacs.org>, > "'Andrew W. Nosenko'" <andrew.w.nosenko@gmail.com>, > <emacs-devel@gnu.org>, "'ishikawa'" <chiaki.ishikawa@ubin.jp>, > <3438@emacsbugs.donarmstrong.com> > Date: Mon, 1 Jun 2009 15:52:34 -0700 > > I mentioned Info and Buffer List from the beginning. And I mentioned code > buffers and buffers with tabular formatting as well. > > The distinction I made is between buffers that are mostly free-form text, where > newlines are typically not intentionally positioned by the user or by Emacs, and > the other buffers, where they are. Emacs does not reformat text in Info buffers, except for the header lines and the "bread-crumbs" lines. The rest is shown as produced by makeinfo from the Texinfo sources. ^ permalink raw reply [flat|nested] 144+ messages in thread
* bug#3438: please make line-move-visual nil 2009-06-01 23:13 ` Eli Zaretskii @ 2009-06-01 23:23 ` Drew Adams 2009-06-01 23:23 ` Drew Adams 1 sibling, 0 replies; 144+ messages in thread From: Drew Adams @ 2009-06-01 23:23 UTC (permalink / raw) To: 'Eli Zaretskii' Cc: 3438, tv.raman.tv, cyd, emacs-devel, chiaki.ishikawa, ams, stephen > Emacs does not reformat text in Info buffers, except for the header > lines and the "bread-crumbs" lines. The rest is shown as produced by > makeinfo from the Texinfo sources. Info presents the _user_ with buffers formatted that way. How Info does that - whether the info.el code does that or makeinfo does it or Texinfo does it or the input to Texinfo is preformatted that way - is irrelevant here. It's about the _user_. ^ permalink raw reply [flat|nested] 144+ messages in thread
* RE: please make line-move-visual nil 2009-06-01 23:13 ` Eli Zaretskii 2009-06-01 23:23 ` bug#3438: " Drew Adams @ 2009-06-01 23:23 ` Drew Adams 2009-06-02 15:59 ` Eli Zaretskii 2009-06-02 15:59 ` bug#3438: " Eli Zaretskii 1 sibling, 2 replies; 144+ messages in thread From: Drew Adams @ 2009-06-01 23:23 UTC (permalink / raw) To: 'Eli Zaretskii' Cc: 3438, tv.raman.tv, cyd, andrew.w.nosenko, emacs-devel, chiaki.ishikawa, ams, monnier, stephen > Emacs does not reformat text in Info buffers, except for the header > lines and the "bread-crumbs" lines. The rest is shown as produced by > makeinfo from the Texinfo sources. Info presents the _user_ with buffers formatted that way. How Info does that - whether the info.el code does that or makeinfo does it or Texinfo does it or the input to Texinfo is preformatted that way - is irrelevant here. It's about the _user_. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-06-01 23:23 ` Drew Adams @ 2009-06-02 15:59 ` Eli Zaretskii 2009-06-02 15:59 ` bug#3438: " Eli Zaretskii 1 sibling, 0 replies; 144+ messages in thread From: Eli Zaretskii @ 2009-06-02 15:59 UTC (permalink / raw) To: Drew Adams Cc: 3438, tv.raman.tv, cyd, andrew.w.nosenko, emacs-devel, chiaki.ishikawa, ams, monnier, stephen > From: "Drew Adams" <drew.adams@oracle.com> > Cc: <monnier@iro.umontreal.ca>, <cyd@stupidchicken.com>, > <tv.raman.tv@gmail.com>, <ams@gnu.org>, <stephen@xemacs.org>, > <andrew.w.nosenko@gmail.com>, <emacs-devel@gnu.org>, > <chiaki.ishikawa@ubin.jp>, <3438@emacsbugs.donarmstrong.com> > Date: Mon, 1 Jun 2009 16:23:50 -0700 > > > Emacs does not reformat text in Info buffers, except for the header > > lines and the "bread-crumbs" lines. The rest is shown as produced by > > makeinfo from the Texinfo sources. > > Info presents the _user_ with buffers formatted that way. No, it does not. It presents the text exactly as it is on disk, as if it were a simple text file (well, almost; see above). There's no formatting anywhere. We are probably miscommunicating, because I don't imagine you really believe that Info buffers are formatted in any way. They are free text. ^ permalink raw reply [flat|nested] 144+ messages in thread
* bug#3438: please make line-move-visual nil 2009-06-01 23:23 ` Drew Adams 2009-06-02 15:59 ` Eli Zaretskii @ 2009-06-02 15:59 ` Eli Zaretskii 1 sibling, 0 replies; 144+ messages in thread From: Eli Zaretskii @ 2009-06-02 15:59 UTC (permalink / raw) To: Drew Adams Cc: 3438, tv.raman.tv, cyd, emacs-devel, chiaki.ishikawa, ams, stephen > From: "Drew Adams" <drew.adams@oracle.com> > Cc: <monnier@iro.umontreal.ca>, <cyd@stupidchicken.com>, > <tv.raman.tv@gmail.com>, <ams@gnu.org>, <stephen@xemacs.org>, > <andrew.w.nosenko@gmail.com>, <emacs-devel@gnu.org>, > <chiaki.ishikawa@ubin.jp>, <3438@emacsbugs.donarmstrong.com> > Date: Mon, 1 Jun 2009 16:23:50 -0700 > > > Emacs does not reformat text in Info buffers, except for the header > > lines and the "bread-crumbs" lines. The rest is shown as produced by > > makeinfo from the Texinfo sources. > > Info presents the _user_ with buffers formatted that way. No, it does not. It presents the text exactly as it is on disk, as if it were a simple text file (well, almost; see above). There's no formatting anywhere. We are probably miscommunicating, because I don't imagine you really believe that Info buffers are formatted in any way. They are free text. ^ permalink raw reply [flat|nested] 144+ messages in thread
* bug#3438: please make line-move-visual nil 2009-06-01 22:52 ` Drew Adams ` (2 preceding siblings ...) 2009-06-01 23:13 ` Eli Zaretskii @ 2009-06-01 23:13 ` Eli Zaretskii 3 siblings, 0 replies; 144+ messages in thread From: Eli Zaretskii @ 2009-06-01 23:13 UTC (permalink / raw) To: Drew Adams Cc: 3438, tv.raman.tv, cyd, emacs-devel, chiaki.ishikawa, ams, stephen > From: "Drew Adams" <drew.adams@oracle.com> > Cc: "'Chong Yidong'" <cyd@stupidchicken.com>, > "'T.V. Raman'" <tv.raman.tv@gmail.com>, <ams@gnu.org>, <eliz@gnu.org>, > <stephen@xemacs.org>, > "'Andrew W. Nosenko'" <andrew.w.nosenko@gmail.com>, > <emacs-devel@gnu.org>, "'ishikawa'" <chiaki.ishikawa@ubin.jp>, > <3438@emacsbugs.donarmstrong.com> > Date: Mon, 1 Jun 2009 15:52:34 -0700 > > I mentioned Info and Buffer List from the beginning. And I mentioned code > buffers and buffers with tabular formatting as well. > > The distinction I made is between buffers that are mostly free-form text, where > newlines are typically not intentionally positioned by the user or by Emacs, and > the other buffers, where they are. Emacs does not reformat text in Info buffers, except for the header lines and the "bread-crumbs" lines. The rest is shown as produced by makeinfo from the Texinfo sources. ^ permalink raw reply [flat|nested] 144+ messages in thread
* bug#3438: please make line-move-visual nil 2009-06-01 22:33 ` Stefan Monnier 2009-06-01 22:52 ` Drew Adams @ 2009-06-01 22:52 ` Drew Adams 2009-06-12 17:16 ` Drew Adams 2009-06-12 17:16 ` Drew Adams 3 siblings, 0 replies; 144+ messages in thread From: Drew Adams @ 2009-06-01 22:52 UTC (permalink / raw) To: 'Stefan Monnier' Cc: 3438, 'T.V. Raman', 'Chong Yidong', emacs-devel, 'ishikawa', ams, stephen > Just goes to show that I misunderstood your notion of "formatted". > I was thinking of buffers like pcl-cvs, VC, dired, buffer-list, > ibuffer, ... Not info, not man, not Java, not C (not sure about > grep, I like to set it in grep, but I'm not sure if it's a good > idea in general). I mentioned Info and Buffer List from the beginning. And I mentioned code buffers and buffers with tabular formatting as well. The distinction I made is between buffers that are mostly free-form text, where newlines are typically not intentionally positioned by the user or by Emacs, and the other buffers, where they are. Even for Buffer List, Dired, and the rest you mentioned, do you really "think they should at least set `truncate-lines'? Is that slated for Emacs 23.2? > > Is this a diversion to some other topic? What's the relation to the > > topic at hand, which is `line-move-visual'? > > When truncate-lines is non-nil, visual lines and logical > lines coincide, so line-move-visual doesn't make much > difference any more (other than for proportional text, that is). True, when the line is not wrapped in any way, there is no line-wrapping. Guess that's one way to skirt the issue. ;-) The relation to this issue is that with `truncate-lines' the issue is evacuated and the distinction no longer matters? "We're trying to decide whether to order fish or meat for the group." "Just don't eat, then it doesn't matter." > > I proposed making the variable always buffer-local. > > There would be no benefit to it: > (set (make-local-variable <foo>) <bar>) > is the standard way for major modes to set variables. I have no problem with _how_ the buffer-local value is set, as long as the default value set for buffers that are not mostly free-form text is nil. And I have no problem with it not being buffer-local at all, if the default value is nil. ^ permalink raw reply [flat|nested] 144+ messages in thread
* RE: please make line-move-visual nil 2009-06-01 22:33 ` Stefan Monnier 2009-06-01 22:52 ` Drew Adams 2009-06-01 22:52 ` Drew Adams @ 2009-06-12 17:16 ` Drew Adams 2009-06-12 21:45 ` Stefan Monnier 2009-06-12 21:45 ` Stefan Monnier 2009-06-12 17:16 ` Drew Adams 3 siblings, 2 replies; 144+ messages in thread From: Drew Adams @ 2009-06-12 17:16 UTC (permalink / raw) To: emacs-devel; +Cc: 3438 > > I proposed making the variable always buffer-local. SM> There would be no benefit to it: SM> (set (make-local-variable <foo>) <bar>) SM> is the standard way for major modes to set variables. Irrelevant. This is not about how to set the variable, but whether the variable should always be buffer-local. `truncate-lines', `word-wrap', and similar variables are all always buffer-local. `line-move-visual' should be also, for the same reasons. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-06-12 17:16 ` Drew Adams @ 2009-06-12 21:45 ` Stefan Monnier 2009-06-13 0:19 ` Drew Adams 2009-06-13 0:19 ` bug#3438: " Drew Adams 2009-06-12 21:45 ` Stefan Monnier 1 sibling, 2 replies; 144+ messages in thread From: Stefan Monnier @ 2009-06-12 21:45 UTC (permalink / raw) To: Drew Adams; +Cc: 3438, emacs-devel > `truncate-lines', `word-wrap', and similar variables are all always > buffer-local. `truncate-lines' is always buffer-local. for historical reasons. `word-wrap' is buffer-local by mistake. Stefan ^ permalink raw reply [flat|nested] 144+ messages in thread
* RE: please make line-move-visual nil 2009-06-12 21:45 ` Stefan Monnier @ 2009-06-13 0:19 ` Drew Adams 2009-06-14 20:45 ` Stefan Monnier 2009-06-13 0:19 ` bug#3438: " Drew Adams 1 sibling, 1 reply; 144+ messages in thread From: Drew Adams @ 2009-06-13 0:19 UTC (permalink / raw) To: 'Stefan Monnier'; +Cc: 3438, emacs-devel > > > > I proposed making the variable always buffer-local. > > > > SM> There would be no benefit to it: > > SM> (set (make-local-variable <foo>) <bar>) > > SM> is the standard way for major modes to set variables. > > > > Irrelevant. This is not about how to set the variable, but > > whether the variable should always be buffer-local. > > > > `truncate-lines', `word-wrap', and similar variables are > > all always buffer-local. > > `truncate-lines' is always buffer-local. for historical reasons. > `word-wrap' is buffer-local by mistake. Why do you consider the latter a mistake? Is the former a mistake too, but won't be fixed? Why not, if it's misguided? And `goal-column', `fill-column, `fill-prefix', `left-margin', `comment-column', `tab-width', `require-final-newline'? Are they also mistakes? Put it another way: Which variables that have to do with wrapping, filling, truncating, target columns, and line/buffer endings are *NOT* always buffer-local? Which are not mistakes? And what's the _reason_ you call them mistakes? It's easy to dismiss - "historical", "mistake" - but why shouldn't they be always buffer-local? What are the criteria for your judgment? The only reason you gave was that major modes can make variables buffer local if they need to. That's doesn't speak to why they would or would not do that. And if that were the answer, then we would not have _any_ variables that are always buffer-local - we would just leave it up to major modes to make them buffer-local as needed. Why don't we expect `comment-column' (for instance) to simply be made buffer-local by each major mode that needs that? ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-06-13 0:19 ` Drew Adams @ 2009-06-14 20:45 ` Stefan Monnier 0 siblings, 0 replies; 144+ messages in thread From: Stefan Monnier @ 2009-06-14 20:45 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-devel > Why do you consider the latter a mistake? There are at least 3 kinds of variables: - global variables (which can be made buffer-local with make-local-variable) - automatically buffer-local vars (e.g. made with make-variable-buffer-local) - always buffer-local vars, e.g. default-directory (these can be tricky to distinguish from the previous kind). Normal variables (and the most flexible) are the first kind. The other kind should only ever be used when there's a really good reason for it. > And `goal-column', `fill-column, `fill-prefix', `left-margin', > `comment-column', `tab-width', `require-final-newline'? Are they > also mistakes? These are old, so they may have been mistakes, but since I wasn't there back then, I can only say that it's due to historical reasons. > Put it another way: Which variables that have to do with wrapping, filling, > truncating, target columns, and line/buffer endings are *NOT* always > buffer-local? Which are not mistakes? paragraph-start and friends? Buffer-localness has nothing to do with whether a variable is linked to filling or whatever other activity. Instead it has to do with how that variable is set, which kinds of values it holds, whether it is meaningful to talk about a "global" value for that variable, ... > And what's the _reason_ you call them mistakes? It's a lot easier to `make-local-variable' than to undo `make-variable-buffer-local'. Also make-variable-buffer-local can have tricky behaviors: e.g. if you `setq' a variable before loading the file that calls make-variable-buffer-local, it will be set globally, which would probably not be the intention. > "historical", "mistake" - but why shouldn't they be always buffer-local? What > are the criteria for your judgment? To me the main question is "why should the be automatically buffer-local when it's so easy to call make-local-variable?". > Why don't we expect `comment-column' (for instance) to > simply be made buffer-local by each major mode that needs that? I actually do expect just that. And in most cases, I expect major modes to not change comment-column (it usually reflects a user's preference, rather than the nature of the language handled by the major mode). Stefan ^ permalink raw reply [flat|nested] 144+ messages in thread
* bug#3438: please make line-move-visual nil 2009-06-12 21:45 ` Stefan Monnier 2009-06-13 0:19 ` Drew Adams @ 2009-06-13 0:19 ` Drew Adams 1 sibling, 0 replies; 144+ messages in thread From: Drew Adams @ 2009-06-13 0:19 UTC (permalink / raw) To: 'Stefan Monnier'; +Cc: 3438, emacs-devel > > > > I proposed making the variable always buffer-local. > > > > SM> There would be no benefit to it: > > SM> (set (make-local-variable <foo>) <bar>) > > SM> is the standard way for major modes to set variables. > > > > Irrelevant. This is not about how to set the variable, but > > whether the variable should always be buffer-local. > > > > `truncate-lines', `word-wrap', and similar variables are > > all always buffer-local. > > `truncate-lines' is always buffer-local. for historical reasons. > `word-wrap' is buffer-local by mistake. Why do you consider the latter a mistake? Is the former a mistake too, but won't be fixed? Why not, if it's misguided? And `goal-column', `fill-column, `fill-prefix', `left-margin', `comment-column', `tab-width', `require-final-newline'? Are they also mistakes? Put it another way: Which variables that have to do with wrapping, filling, truncating, target columns, and line/buffer endings are *NOT* always buffer-local? Which are not mistakes? And what's the _reason_ you call them mistakes? It's easy to dismiss - "historical", "mistake" - but why shouldn't they be always buffer-local? What are the criteria for your judgment? The only reason you gave was that major modes can make variables buffer local if they need to. That's doesn't speak to why they would or would not do that. And if that were the answer, then we would not have _any_ variables that are always buffer-local - we would just leave it up to major modes to make them buffer-local as needed. Why don't we expect `comment-column' (for instance) to simply be made buffer-local by each major mode that needs that? ^ permalink raw reply [flat|nested] 144+ messages in thread
* bug#3438: please make line-move-visual nil 2009-06-12 17:16 ` Drew Adams 2009-06-12 21:45 ` Stefan Monnier @ 2009-06-12 21:45 ` Stefan Monnier 1 sibling, 0 replies; 144+ messages in thread From: Stefan Monnier @ 2009-06-12 21:45 UTC (permalink / raw) To: Drew Adams; +Cc: 3438, emacs-devel > `truncate-lines', `word-wrap', and similar variables are all always > buffer-local. `truncate-lines' is always buffer-local. for historical reasons. `word-wrap' is buffer-local by mistake. Stefan ^ permalink raw reply [flat|nested] 144+ messages in thread
* bug#3438: please make line-move-visual nil 2009-06-01 22:33 ` Stefan Monnier ` (2 preceding siblings ...) 2009-06-12 17:16 ` Drew Adams @ 2009-06-12 17:16 ` Drew Adams 3 siblings, 0 replies; 144+ messages in thread From: Drew Adams @ 2009-06-12 17:16 UTC (permalink / raw) To: emacs-devel; +Cc: 3438 > > I proposed making the variable always buffer-local. SM> There would be no benefit to it: SM> (set (make-local-variable <foo>) <bar>) SM> is the standard way for major modes to set variables. Irrelevant. This is not about how to set the variable, but whether the variable should always be buffer-local. `truncate-lines', `word-wrap', and similar variables are all always buffer-local. `line-move-visual' should be also, for the same reasons. ^ permalink raw reply [flat|nested] 144+ messages in thread
* bug#3438: please make line-move-visual nil 2009-06-01 21:00 ` Drew Adams ` (2 preceding siblings ...) 2009-06-01 22:33 ` Stefan Monnier @ 2009-06-01 22:33 ` Stefan Monnier 3 siblings, 0 replies; 144+ messages in thread From: Stefan Monnier @ 2009-06-01 22:33 UTC (permalink / raw) To: Drew Adams Cc: 3438, 'T.V. Raman', 'Chong Yidong', emacs-devel, 'ishikawa', ams, stephen >> I don't know if it's typical, but for most of those kinds of >> buffers you describe as "formatted", I think they should at >> least set truncate-lines. > No reason given. Why? > Why should Buffer List or Info or Man output or grep output or C code > or Java code buffers have `truncate-lines' turned on? Because newlines > are intentionally positioned in such modes, they should use > `truncate-lines'? Why would that be? Just goes to show that I misunderstood your notion of "formatted". I was thinking of buffers like pcl-cvs, VC, dired, buffer-list, ibuffer, ... Not info, not man, not Java, not C (not sure about grep, I like to set it in grep, but I'm not sure if it's a good idea in general). > Is this a diversion to some other topic? What's the relation to the > topic at hand, which is `line-move-visual'? When truncate-lines is non-nil, visual lines and logical lines coincide, so line-move-visual doesn't make much difference any more (other than for proportional text, that is). > I proposed making the variable always buffer-local. There would be no benefit to it: (set (make-local-variable <foo>) <bar>) is the standard way for major modes to set variables. Stefan ^ permalink raw reply [flat|nested] 144+ messages in thread
* RE: please make line-move-visual nil 2009-06-01 18:26 ` Drew Adams 2009-06-01 20:11 ` bug#3438: " Stefan Monnier 2009-06-01 20:11 ` Stefan Monnier @ 2009-06-01 23:18 ` Drew Adams 2009-06-02 1:29 ` Stefan Monnier 2 siblings, 1 reply; 144+ messages in thread From: Drew Adams @ 2009-06-01 23:18 UTC (permalink / raw) To: 'Chong Yidong' Cc: 'T.V. Raman', 'Andrew W. Nosenko', emacs-devel, 'ishikawa', ams, 'Stefan Monnier', stephen, eliz > > In Dired, <up> and <down> call dired-previous-line and > > dired-next-line, which should not be affected by line-move-visual. Yes, but imagine if Dired _did_ use `next-line' for <down> or `n', so it was thus affected. Try it: M-x local-set-key n next-line. Narrow the Dired window so file names wrap. Try `n' with point at various horizontal positions. Do you really think `line-move-visual' is a good fit here? No? No, and the same is true for other buffers where newline chars and line length matter. In buffers where a line (line of code, line of Dired, etc.) is defined by ending in a newline, moving to the next line does not mean moving to the wrapped part of the same line. If `truncate-lines' is helpful in this respect (you don't even see the wrap), then so is nil `line-move-visual' (you don't move to the wrap, even if you see it). ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-06-01 23:18 ` Drew Adams @ 2009-06-02 1:29 ` Stefan Monnier 0 siblings, 0 replies; 144+ messages in thread From: Stefan Monnier @ 2009-06-02 1:29 UTC (permalink / raw) To: Drew Adams Cc: 'T.V. Raman', 'Chong Yidong', 'Andrew W. Nosenko', emacs-devel, 'ishikawa', ams, stephen, eliz > Try it: M-x local-set-key n next-line. Narrow the Dired window so file > names wrap. At this point I already notice that the wrapping makes the buffer unreadable/ugly, which is why the real answer is not to change line-move-visual but truncate-lines. > Do you really think `line-move-visual' is a good fit here? No worse than the other choice, actually. > No? No, and the same is true for other buffers where newline chars and > line length matter. That's your taste. Which is why you should set line-move-visual to nil. Stefan ^ permalink raw reply [flat|nested] 144+ messages in thread
* bug#3438: please make line-move-visual nil 2009-06-01 17:56 ` Chong Yidong 2009-06-01 18:26 ` Drew Adams @ 2009-06-01 18:26 ` Drew Adams 1 sibling, 0 replies; 144+ messages in thread From: Drew Adams @ 2009-06-01 18:26 UTC (permalink / raw) To: 'Chong Yidong' Cc: 3438, 'T.V. Raman', emacs-devel, 'ishikawa', ams, stephen > > Please see bug report #3438. All of it is worth reading in > > this regard. Note in particular his request to have a > > buffer-local value for line-move-visual, and to have Dired > > use nil for this. > > >> In dired mode, when the cursor is near the beginning of a very long > >> filename (as in near the "AaAaAa..." below , I can't move > >> down to the next file by "n" or "cursor down" key anymore(!). > > In Dired, <up> and <down> call dired-previous-line and > dired-next-line, which should not be affected by line-move-visual. > I have not been able to reproduce the reported problem (i.e., > getting point stuck in Dired). Maybe the reporter has some unusual > customizations that are getting in the way. Ah, you're right. And I even remember that I started to mention Dired as an example of a formatted buffer in my original post in this thread, and removed it when I realized this was in fact the case (I used Info and Buffer List as examples). But I forgot about it when I saw the bug report. Thx. Dired is an exception in this regard among formatted buffers, so you are correct that Dired's bindings make it irrelevant for the immediate question. It does illustrate the general idea, however: line movement in formatted buffers is often different (should often be different) than it is in free-form text buffers. In Dired, it is particularly different, since we want point to stay on the file name - we constrain it to one column for vertical movement. IOW, Dired has its own buffer-local behavior for line movement, which is even more reflective of the buffer formatting than usual. If anything, this strengthens the argument for buffer-specific line movement, rather than weakening it. More typically (in formatted buffers), we want to reflect the use of newlines (they are positioned intentionally) and maintain the current column for line movement, but there is no single, privileged column (e.g. file name) that we want to constrain point to, as there is in Dired. Each formatted buffer could individually define its own line-movement commands, which amounts to just binding `line-move-visual' to nil around a call to `next-line'. But that would be a bit silly. Better to just let the variable be buffer-local. And provide nil as the default value for most formatted buffers. -- BTW, you didn't answer the questions about the poll. How's it coming along? Where is it? ^ permalink raw reply [flat|nested] 144+ messages in thread
* bug#3438: please make line-move-visual nil 2009-06-01 16:20 ` Drew Adams 2009-06-01 17:56 ` Chong Yidong @ 2009-06-01 17:56 ` Chong Yidong 1 sibling, 0 replies; 144+ messages in thread From: Chong Yidong @ 2009-06-01 17:56 UTC (permalink / raw) To: Drew Adams Cc: 3438, 'T.V. Raman', emacs-devel, 'ishikawa', ams, stephen "Drew Adams" <drew.adams@oracle.com> writes: > Please see bug report #3438. All of it is worth reading in this regard. > > Note in particular his request to have a buffer-local value for > line-move-visual, and to have Dired use nil for this. >> In dired mode, when the cursor is near the beginning of a very long >> filename (as in near the "AaAaAa..." below , I can't move down to the >> next file by "n" or "cursor down" key anymore(!). In Dired, <up> and <down> call dired-previous-line and dired-next-line, which should not be affected by line-move-visual. I have not been able to reproduce the reported problem (i.e., getting point stuck in Dired). Maybe the reporter has some unusual customizations that are getting in the way. ^ permalink raw reply [flat|nested] 144+ messages in thread
* RE: please make line-move-visual nil 2009-05-25 3:01 ` Eli Zaretskii 2009-05-25 4:16 ` Alfred M. Szmidt @ 2009-05-25 8:18 ` Drew Adams 2009-05-25 20:46 ` Eli Zaretskii 1 sibling, 1 reply; 144+ messages in thread From: Drew Adams @ 2009-05-25 8:18 UTC (permalink / raw) To: 'Eli Zaretskii', 'Stephen J. Turnbull'; +Cc: emacs-devel > > > This was done in July 2008, and there were fairly > > > extensive discussions > > > on this list then, and on several occasions afterwards. > > > > Why have prereleases then, if it's "too late" for feedback > > from users who are not willing to bleed on the edge, and > > who don't necessarily read emacs-devel with their morning > > coffee? > > Pretest is not for changing the default behavior. They are for fixing > bugs before the release. The time for users to voice their objections > and requests for improvements is after Emacs is released. There's > always the next release. I see. So if you happen not to have dug deeply into each discussion thread before the prerelease, and spoken up about it, you're out of luck? Your voice doesn't count because it's too late? That's ridiculous. There has sometimes been a tendency to regard changes that have been made during Emacs 23 development as cast in bronze - even long, long before Emacs 23 is released. We hear arguments such as "that's been true since last July", as if that means it represents established practice from ancient history. Now we are in pretest, so this too-late!-already-cast-in-bronze argument is I suppose slightly stronger, but I still don't buy it. FWIW, here is what Richard replied to me after I complained to Chong Yidong in just such a situation, admittedly pre-pretest (2008-10-21, bug list, bug #1175), but pertinent anyway, I think: |DA. This is analogous to `find-file-noselect'. | `bookmark-jump-noselect' is an obvious choice for some | function to call, to obtain the bookmark buffer and | buffer position. Without actually displaying it - perhaps | because some other display mechanism is preferred or | perhaps because some other manipulation is to be performed. | |RMS. I agree with you. | |DA. Emacs 23 has not even been released, so please don't speak of | "changing" from the Emacs 23 behavior to what has always | been the behavior before. | |RMS. You are right here too. Compatibility with past Emacs releases | is more important, generally speaking, than avoiding changes in | the sources now. I am sure this function isn't used in very | many places in Emacs, so changing it back to be compatible won't | be a lot of work. No, the context wasn't exactly the same, but the spirit seems similar, to me. Emacs 23 has not been released, so new features are really just proposals still, no matter how long ago they were implemented. "Is this the default value we really want?" That's a fair question up until the release. And it's actually a fair question even after the release, IMO. Some of you complained that Richard took too long to put out a new release, because he insisted on bug fixes and documentation. I, for one, never had that complaint. Quite the contrary, in fact. For all your proclaimed haste, I don't see that we are better off. [One thing I do wish had happened: I wish that we had produced an Emacs 23 that had only the Unicode addition. Other changes could have come in another release after that. No one argued against adding Unicode - it is a super-important feature, and it should have been separated from all of the many behavioral changes that are now accompanying it. Just one (late) opinion.] > > You should also consider that for this particular default, > > positive esponses will come quickly from those who use long > > lines a lot, while they are unlikely to notice much > > aggravation in environments where visual motion is likely > > to be inappropriate, because those environment > > typically strongly discourage long lines anyway. Thus the > > complaints are likely to be relatively late and few > > I don't know why you assume this: I happen to use > longer-than-80-column lines quite a lot, and I'm quite sure > it's not as rare as you seem to think. Not every text we > see in Emacs is necessarily a well-formatted program source. Stephen's point is valid. And your response doesn't really respond to it. The point is that if you use Emacs with lines that are not long, and so do not wrap, then you will not necessarily notice much difference. That is my case, since I often have one buffer per frame, and I fit the frame to the buffer. With code etc., I rarely encounter any wrapped text, so I rarely notice visual-line movement. That doesn't mean that there is no reason to prefer newline-oriented line movement in those contexts. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-25 8:18 ` Drew Adams @ 2009-05-25 20:46 ` Eli Zaretskii 2009-05-25 21:06 ` Drew Adams 0 siblings, 1 reply; 144+ messages in thread From: Eli Zaretskii @ 2009-05-25 20:46 UTC (permalink / raw) To: Drew Adams; +Cc: stephen, emacs-devel > From: "Drew Adams" <drew.adams@oracle.com> > Cc: <emacs-devel@gnu.org> > Date: Mon, 25 May 2009 01:18:02 -0700 > > > Pretest is not for changing the default behavior. They are for fixing > > bugs before the release. The time for users to voice their objections > > and requests for improvements is after Emacs is released. There's > > always the next release. > > I see. So if you happen not to have dug deeply into each discussion thread > before the prerelease, and spoken up about it, you're out of luck? Your voice > doesn't count because it's too late? If you come too late in the pretest, yes. If we allow non-critical changes beyond certain point, we will either never make a release or release a buggy version (because each change might have, and usually has unintended consequences). > That's ridiculous. That's life. And just to keep this in perspective, we are talking about the default value of an easily customizable option. How critical could a default be, even if it turns out to be disliked by many? ^ permalink raw reply [flat|nested] 144+ messages in thread
* RE: please make line-move-visual nil 2009-05-25 20:46 ` Eli Zaretskii @ 2009-05-25 21:06 ` Drew Adams 2009-05-25 21:28 ` Eli Zaretskii 0 siblings, 1 reply; 144+ messages in thread From: Drew Adams @ 2009-05-25 21:06 UTC (permalink / raw) To: 'Eli Zaretskii'; +Cc: stephen, emacs-devel > If you come too late in the pretest, yes. Too late in which pretest? My guess is that you would have said the same thing for the first pretest, months ago. Emacs development can drag on for years, and it is a convenient excuse that has been used for a long time that "we are too close to the release" to discuss this or that change or new feature. > If we allow non-critical changes beyond certain point, we will > either never make a release or release a buggy version (because > each change might have, and usually has unintended consequences). Do you really think that restoring this to the previous default behavior would cause problems? If so, do you think we could not afford to take the time to fix those problems? Are you sure this isn't just an excuse to ignore the question? > > That's ridiculous. > > That's life. No, it's just one possible policy choice. Please don't confuse the laws of Nature with choices you have made. > And just to keep this in perspective, we are talking about the default > value of an easily customizable option. How critical could a default > be, even if it turns out to be disliked by many? Using "it's not critical" as the only reason to introduce a bad choice is lame. If you want a better perspective, that's the place from which to view this. How about some _reasons_ supporting this change (beyond "I like it")? ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-25 21:06 ` Drew Adams @ 2009-05-25 21:28 ` Eli Zaretskii 0 siblings, 0 replies; 144+ messages in thread From: Eli Zaretskii @ 2009-05-25 21:28 UTC (permalink / raw) To: Drew Adams; +Cc: stephen, emacs-devel > From: "Drew Adams" <drew.adams@oracle.com> > Cc: <stephen@xemacs.org>, <emacs-devel@gnu.org> > Date: Mon, 25 May 2009 14:06:18 -0700 > > > If you come too late in the pretest, yes. > > Too late in which pretest? Any pretest. Your question was general, so I gave a general answer. It started with an "if". Whether _now_ it's "too late" is not my call. > My guess is that you would have said the same thing for the first > pretest, months ago. So now you are inventing what I would have said, and then argue with your own inventions? Is that reasonable? or fair? > Using "it's not critical" as the only reason to introduce a bad choice is lame. That choice was already made, and the reasons back then were certainly not that it's not critical. We are now arguing about unmaking it, and it's in that context that I question the justification for such a reversal. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-24 23:50 ` Chong Yidong 2009-05-24 23:58 ` Lennart Borgman 2009-05-25 0:53 ` Drew Adams @ 2009-05-25 2:57 ` Eli Zaretskii 2009-05-25 8:10 ` Miles Bader 2009-05-26 3:48 ` Chong Yidong 2 siblings, 2 replies; 144+ messages in thread From: Eli Zaretskii @ 2009-05-25 2:57 UTC (permalink / raw) To: Chong Yidong; +Cc: emacs-devel > From: Chong Yidong <cyd@stupidchicken.com> > Date: Sun, 24 May 2009 19:50:24 -0400 > Cc: emacs-devel@gnu.org > > The pros and cons of display line motion have been debated extensively, > and I see no new points on either side of the debate. Well, just to add a data point: I'm a heavy Emacs user for the last 15 years, and I find this new behavior very useful in many situations. It took a bit to get accustomed to, but I find it so convenient I never even tried to customize it back to what it was before. > But since several people dislike the new behavior, I think it would > be good to add an Options menu entry to disable it easily. I think it's too late to add menu items at this time. It should be good enough to make its NEWS entry prominent and near the beginning, as much as possible under the usual structure of NEWS (first supported/deprecated targets, then build news, then the rest). ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-25 2:57 ` Eli Zaretskii @ 2009-05-25 8:10 ` Miles Bader 2009-05-26 3:48 ` Chong Yidong 1 sibling, 0 replies; 144+ messages in thread From: Miles Bader @ 2009-05-25 8:10 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Chong Yidong, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> The pros and cons of display line motion have been debated extensively, >> and I see no new points on either side of the debate. > > Well, just to add a data point: I'm a heavy Emacs user for the last 15 > years, and I find this new behavior very useful in many situations. > It took a bit to get accustomed to, but I find it so convenient I > never even tried to customize it back to what it was before. Me too. I think the current defaults are good. There simply is no setting that will be perfect in all situations, but the current (default) settings seem a reasonable compromise. -Miles -- Everywhere is walking distance if you have the time. -- Steven Wright ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-25 2:57 ` Eli Zaretskii 2009-05-25 8:10 ` Miles Bader @ 2009-05-26 3:48 ` Chong Yidong 1 sibling, 0 replies; 144+ messages in thread From: Chong Yidong @ 2009-05-26 3:48 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > I think it's too late to add menu items at this time. It should be > good enough to make its NEWS entry prominent and near the beginning, > as much as possible under the usual structure of NEWS (first > supported/deprecated targets, then build news, then the rest). It's the very first entry under Editing Changes. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-24 22:33 ` Drew Adams 2009-05-24 23:18 ` Bastien 2009-05-24 23:18 ` Leo @ 2009-05-24 23:53 ` David Reitter 2009-05-25 0:03 ` Lennart Borgman ` (2 more replies) 2009-05-25 2:02 ` Stefan Monnier 3 siblings, 3 replies; 144+ messages in thread From: David Reitter @ 2009-05-24 23:53 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 1354 bytes --] On May 24, 2009, at 6:33 PM, Drew Adams wrote: > If you absolutely feel the need to make the default value be t for > modes such as > text-mode, which (you are convinced) are likely to benefit from it, > then do so. > But PLEASE leave the rest of Emacs alone, by default. This is a bad > choice for > Emacs - please reconsider this. You didn't give any reason to support your view. I can see where you're coming from, though. I believe line-move-visual should be t because in this mode of operation, cursor movement commands correspond most closely to the visual representation of the buffer. Note that I have bound C-n/p to non-visual movement in Aquamacs, while arrow keys are visual. But of course I can see the argument to keep C- n/p and arrow keys bound to the same commands in Emacs, where a closer relationship between TTY and window system use is desired. Leo wrote: > If the purpose is to make new users feel at home, then we could create > something like firstboot.el that runs in the first run. Most operating > systems have this. ... and then Emacs would magically and surprisingly change its configuration after the first startup? Even more confusing. How about a newbie-mode, which can be en/disabled directly from the startup screen? Ps.: I think it's too late in the game for 23.1 for this sort of change. [-- Attachment #2: smime.p7s --] [-- Type: application/pkcs7-signature, Size: 2193 bytes --] ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-24 23:53 ` David Reitter @ 2009-05-25 0:03 ` Lennart Borgman 2009-05-25 0:52 ` Drew Adams 2009-05-25 2:26 ` Stephen J. Turnbull 2 siblings, 0 replies; 144+ messages in thread From: Lennart Borgman @ 2009-05-25 0:03 UTC (permalink / raw) To: David Reitter; +Cc: Drew Adams, emacs-devel On Mon, May 25, 2009 at 1:53 AM, David Reitter <david.reitter@gmail.com> wrote: >> If the purpose is to make new users feel at home, then we could create >> something like firstboot.el that runs in the first run. Most operating >> systems have this. > > > ... and then Emacs would magically and surprisingly change its configuration > after the first startup? > Even more confusing. > > How about a newbie-mode, which can be en/disabled directly from the startup > screen? > > Ps.: I think it's too late in the game for 23.1 for this sort of change. This has been proposed in several variants. I think the best would be an approach where key bindings (and maybe behaviour in some cases) could be switched to major platforms conformity by some command. (This could be implemented by options and functions turning on and saving them groupwise.) ^ permalink raw reply [flat|nested] 144+ messages in thread
* RE: please make line-move-visual nil 2009-05-24 23:53 ` David Reitter 2009-05-25 0:03 ` Lennart Borgman @ 2009-05-25 0:52 ` Drew Adams 2009-05-25 2:32 ` David Reitter 2009-05-25 2:26 ` Stephen J. Turnbull 2 siblings, 1 reply; 144+ messages in thread From: Drew Adams @ 2009-05-25 0:52 UTC (permalink / raw) To: 'David Reitter'; +Cc: emacs-devel > > If you absolutely feel the need to make the default value be t for > > modes such as text-mode, which (you are convinced) are likely to > > benefit from it, then do so. But PLEASE leave the rest of Emacs > > alone, by default. This is a bad choice for > > Emacs - please reconsider this. > > You didn't give any reason to support your view. I did too, though perhaps not explicitly enough. Most buffers in Emacs are code buffers or formatted text, with non-proportional fonts and hard-returns (newlines) as line separators. For _at least_ those contexts, we should keep the normal behavior. The traditional line movement fits well with lines as they are defined in those contexts. Lines defined by newlines fit well with newline-oriented movement. If a poll indicates that most people want to use the new behavior for buffers such as text-mode, then the default can be non-nil for such buffers. I don't have a problem with that. But my crystal ball says that those buffers are in the minority, in Emacs. And even if they were in the majority, it wouldn't make sense to impose non-nil for the other buffers, which have newline-delineated lines and provide a good fit for the traditional line movement. This is a widespread change, and it should not be. Impose the change, if you must impose it, on only text-oriented buffers - the kind of buffers for which you might use a proportional font, for instance. (Yes, the two things are different, but the use cases overlap considerably.) Use it for mail messages and text-mode. Do not use it, by default, for code and formatted buffers, whose content is split into newline-delineated lines by design. > I can see where you're coming from, though. Even though you didn't notice the reasons I gave? ;-) Good. Maybe you sense the reasons yourself? > I believe line-move-visual should be t because in this mode of > operation, cursor movement commands correspond most closely to the > visual representation of the buffer. Visual representation is not all that is important in a buffer. In code and formatted (e.g. tabular) text, the positions of hard newlines can make a difference. Look, GNU Emacs Dev itself demands that Emacs-Lisp code you submit not have lines longer than N columns. Why? Why do we format Info and *Help* and *Man* and *Dired* buffers? Shouldn't you be proposing that we do away with all that, and just have lines that are a zillion chars long? Let the display take care of it all, right? That's a different discussion, perhaps, but I sense that the door is being opened here... > Note that I have bound C-n/p to non-visual movement in Aquamacs, > while arrow keys are visual. Why would you even want non-visual movement? ;-) What's the use case/reason? Let me guess... code? formatted buffers? most Emacs buffers? > How about a newbie-mode, which can be en/disabled directly from the > startup screen? I don't think this is about newbies at all (except that some Emacs developers might be hoping that many newbies will be likely to use mainly Emacs for text, mail, etc.). I think it is about different line movements being appropriate for different kinds of "line". The solution, in terms of finding good default behavior, is to do this based on the buffer, that is, on its mode. Use newline-oriented line movement for buffers where "lines" are typically delineated by newlines. Use, if you like, visual-line-oriented movement for buffers where "lines" have no use for newlines. When I write a paragraph in this mail client (Outlook), there is no auto-fill or anything that chops the text by inserting newlines. Visual line movement might be appropriate here (and that's in fact the line movement I have). When you read this plain-text mail, it will have had newlines inserted (for better or, more likely, for worse), and newline-oriented line movement might be appropriate. If I instead sent the mail as HTML, then visual line movement might be appropriate. > Ps.: I think it's too late in the game for 23.1 for this sort > of change. Dunno if it's too late, but if time is really an argument here, then we can argue that this change of default came too late. But I think it doesn't really matter when we have the discussion. ;-) ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-25 0:52 ` Drew Adams @ 2009-05-25 2:32 ` David Reitter 2009-05-25 8:35 ` Drew Adams 0 siblings, 1 reply; 144+ messages in thread From: David Reitter @ 2009-05-25 2:32 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 2293 bytes --] On May 24, 2009, at 8:52 PM, Drew Adams wrote: > Most buffers in Emacs are code buffers or formatted text, with non- > proportional > fonts and hard-returns (newlines) as line separators. For _at least_ > those > contexts, we should keep the normal behavior. The traditional line > movement fits > well with lines as they are defined in those contexts. Lines defined > by newlines > fit well with newline-oriented movement. Much of my stuff is actually done in variable-width fonts (LaTeX editing, for instance). Using fixed-width fonts even for code is not a must - if it wasn't for weak indentation (tabs, etc.) and perhaps the clickability of narrow glyphs such as curly brackets, I would actually prefer a variable-width font for code as well. >> I can see where you're coming from, though. > > Even though you didn't notice the reasons I gave? ;-) Good. Maybe > you sense the > reasons yourself? I know fairly well by now how a lot of the developers (and certainly a share of the users) work. And as RMS pointed out in a related thread some time ago, much of the GNU tool set is based on line-by-line processing. >> Note that I have bound C-n/p to non-visual movement in Aquamacs, >> while arrow keys are visual. > > Why would you even want non-visual movement? ;-) What's the use case/ > reason? Let > me guess... code? formatted buffers? most Emacs buffers? Yes, code and formatted buffers. But even there I wouldn't want it all the time - just in some situations. Correspondence of the commands with what is most directly inferable from the observable state (i.e. visual interface!) is essential - more so than corresponding with some underlying format, i.e. the file format. > When I write a paragraph in this mail client (Outlook), there is no > auto-fill or > anything that chops the text by inserting newlines. Visual line > movement might > be appropriate here (and that's in fact the line movement I have). I believe that Auto-fill is a thing of the past. The new word-wrap is the way to go for non-code. Here's why: > When you read this plain-text mail, it will have had newlines > inserted (for > better or, more likely, for worse), For worse, because the text only occupies 50% of the window I use to display your message. [-- Attachment #2: smime.p7s --] [-- Type: application/pkcs7-signature, Size: 2193 bytes --] ^ permalink raw reply [flat|nested] 144+ messages in thread
* RE: please make line-move-visual nil 2009-05-25 2:32 ` David Reitter @ 2009-05-25 8:35 ` Drew Adams 0 siblings, 0 replies; 144+ messages in thread From: Drew Adams @ 2009-05-25 8:35 UTC (permalink / raw) To: 'David Reitter'; +Cc: emacs-devel > > Most buffers in Emacs are code buffers or formatted text, with non- > > proportional fonts and hard-returns (newlines) as line separators. > > For _at least_ those contexts, we should keep the normal behavior. > > The traditional line movement fits well with lines as they are > > defined in those contexts. Lines defined by newlines > > fit well with newline-oriented movement. > > Much of my stuff is actually done in variable-width fonts (LaTeX > editing, for instance). Sure, I can see that. Sometimes (or some parts of) LaTeX, HTML, and XML, depending on the code. Yes. (Troff, probably not. ;-)) > Using fixed-width fonts even for code is not a must No one said it is a must. This is about finding appropriate default values. It's not about forcing someone to use one or the other behavior. The point is that it makes sense for the defaults to be different, depending on the buffer type. Then users should be able to (easily) customize the values for different buffer types. > >> I can see where you're coming from, though. > > > > Even though you didn't notice the reasons I gave? ;-) Good. Maybe > > you sense the reasons yourself? > > I know fairly well by now how a lot of the developers (and > certainly a share of the users) work. And as RMS pointed out in a > related thread some time ago, much of the GNU tool set is based > on line-by-line processing. Yessir. > > Why would you even want non-visual movement? ;-) What's the > > use case/reason? Let me guess... code? formatted buffers? > > most Emacs buffers? > > Yes, code and formatted buffers. But even there I wouldn't want it > all the time - just in some situations. Precisely. It all depends. On the buffer type. On personal preference. On the moon, perhaps. Customization is there for personal preference, but it needs to be easily tweakable for different contexts, as you point out. One size here does not necessarily fit all contexts. The _default_ behaviors should at least be tailored to a reasonable consensus according to the buffer type. I suspect there might be consensus for a nil default for code buffers. But that doesn't that mean some people won't want non-nil there too, just as some people (as you suggested) might prefer proportional fonts for code too. > I believe that Auto-fill is a thing of the past. The new > word-wrap is the way to go for non-code. Here's why: > > > When you read this plain-text mail, it will have had newlines > > inserted (for better or, more likely, for worse), > > For worse, because the text only occupies 50% of the window I use to > display your message. Yes, for worse, I already agreed. But that's what happens with plain-text mail, isn't it? Many of us use HTML mail outside of mailing lists. But I can tell you that I sometimes wish I had a line-oriented mode for dealing more easily with blocks of code or tabular text in HTML emails. The most I can do using Outlook is switch to a fixed-width font. (Yes, I know, Emacs as mail client...) ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-24 23:53 ` David Reitter 2009-05-25 0:03 ` Lennart Borgman 2009-05-25 0:52 ` Drew Adams @ 2009-05-25 2:26 ` Stephen J. Turnbull 2 siblings, 0 replies; 144+ messages in thread From: Stephen J. Turnbull @ 2009-05-25 2:26 UTC (permalink / raw) To: David Reitter; +Cc: Drew Adams, emacs-devel David Reitter writes: > You didn't give any reason to support your view. Isn't that more contentious that you really mean? It's hard to express reasons for this kind of thing, and in any case, a change of defaults should shoulder the burden of explanation. It's better to be conservative with respect to defaults. > I believe line-move-visual should be t because in this mode of > operation, cursor movement commands correspond most closely to the > visual representation of the buffer. Are we not human? Can we not understand more abstractions than the two-dimensional image in front of our eyes? Maybe we should get rid of all cursor movement commands in favor of visually-oriented search? So unfortunately that explanation is so weak that it arrived in a heart-lung machine. Emacs has *many* modes, and they *interact*. A proper explanation would detail *for each and every* mode of Emacs why the default ought to be changed. For example in Python, assembler, picture, and FORTRAN modes, where columns are significant, that should be defaulted to nil. In most programmers' environments, long lines are relatively rare due to style guidelines, and indentation is on the contrary universal and significant. I would argue that in that general class of cases, cursor motion should be logical, not visual, by default. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-24 22:33 ` Drew Adams ` (2 preceding siblings ...) 2009-05-24 23:53 ` David Reitter @ 2009-05-25 2:02 ` Stefan Monnier 2009-05-25 4:16 ` Alfred M. Szmidt 2009-05-25 8:17 ` Drew Adams 3 siblings, 2 replies; 144+ messages in thread From: Stefan Monnier @ 2009-05-25 2:02 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-devel > I'm coming back to this thread because I just tried the new pretest > (23.0.94.1), where the default value of `line-move-visual' is t. > This is insane, IMO. The default value is t even in formatted modes > such as Buffer Menu and Info. It is t even in code modes such as > Emacs-Lisp. If you use `define-derived-mode' to define a new mode from > scratch - a mode that has no parent mode, it has value t in that > mode. It has value t everywhere, by default. This makes no sense. > If you absolutely feel the need to make the default value be t for > modes such as text-mode, which (you are convinced) are likely to > benefit from it, then do so. But PLEASE leave the rest of Emacs > alone, by default. This is a bad choice for Emacs - please > reconsider this. We've talked it over repeatedly. Add (setq line-move-visual nil) to your .emacs and live happily ever after. Stefan ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-25 2:02 ` Stefan Monnier @ 2009-05-25 4:16 ` Alfred M. Szmidt 2009-05-25 8:16 ` Miles Bader 2009-05-25 8:17 ` Drew Adams 1 sibling, 1 reply; 144+ messages in thread From: Alfred M. Szmidt @ 2009-05-25 4:16 UTC (permalink / raw) To: Stefan Monnier; +Cc: drew.adams, emacs-devel We've talked it over repeatedly. Add (setq line-move-visual nil) to your .emacs and live happily ever after. This is not a useful way to carry a conversation. People, lots of people, have complained about this behaviour, so it needs to be re-examined. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-25 4:16 ` Alfred M. Szmidt @ 2009-05-25 8:16 ` Miles Bader 2009-05-25 9:29 ` Ulrich Mueller 0 siblings, 1 reply; 144+ messages in thread From: Miles Bader @ 2009-05-25 8:16 UTC (permalink / raw) To: ams; +Cc: Stefan Monnier, drew.adams, emacs-devel "Alfred M. Szmidt" <ams@gnu.org> writes: > We've talked it over repeatedly. Add (setq line-move-visual nil) > to your .emacs and live happily ever after. > > This is not a useful way to carry a conversation. People, lots of > people, have complained about this behaviour, so it needs to be > re-examined. I don't really get the impression that "Lots of people" are complaining actually (seems more like a few people, at high volume). -Miles -- Monday, n. In Christian countries, the day after the baseball game. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-25 8:16 ` Miles Bader @ 2009-05-25 9:29 ` Ulrich Mueller 2009-05-25 10:16 ` Miles Bader ` (2 more replies) 0 siblings, 3 replies; 144+ messages in thread From: Ulrich Mueller @ 2009-05-25 9:29 UTC (permalink / raw) To: Miles Bader; +Cc: ams, Stefan Monnier, drew.adams, emacs-devel >>>>> On Mon, 25 May 2009, Miles Bader wrote: > "Alfred M. Szmidt" <ams@gnu.org> writes: >> This is not a useful way to carry a conversation. People, lots of >> people, have complained about this behaviour, so it needs to be >> re-examined. > I don't really get the impression that "Lots of people" are > complaining actually (seems more like a few people, at high volume). Add me to the list of people complaining, then. I think that it's counter-intuitive to move point horizontally when vertical movement was asked for. The default should be changed back to nil. Also, at former times the user community was asked before such UI changes were done (I remember polls about C-x 0, M-g, C-x C-w, and C-x C-q at least). Why isn't this done any more? Ulrich ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-25 9:29 ` Ulrich Mueller @ 2009-05-25 10:16 ` Miles Bader 2009-05-26 0:13 ` Richard M Stallman 2009-05-26 9:52 ` Alan Mackenzie 2 siblings, 0 replies; 144+ messages in thread From: Miles Bader @ 2009-05-25 10:16 UTC (permalink / raw) To: Ulrich Mueller; +Cc: ams, Stefan Monnier, drew.adams, emacs-devel Ulrich Mueller <ulm@gentoo.org> writes: > Also, at former times the user community was asked before such UI > changes were done (I remember polls about C-x 0, M-g, C-x C-w, and > C-x C-q at least). Why isn't this done any more? It would seem quite difficult to do a poll that actually yields results representative of the larger emacs user community (and a poll that _doesn't_ do that seems worse than useless). A well-supported educated guess may well be the better option. [Of course, this is the same reason that people just posting "me too!" in response to threads like this is pretty pointless...] -Miles -- "She looks like the wax version of herself." [Comment under a Paris Hilton fashion pic] ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-25 9:29 ` Ulrich Mueller 2009-05-25 10:16 ` Miles Bader @ 2009-05-26 0:13 ` Richard M Stallman 2009-05-28 10:38 ` David Kastrup 2009-05-26 9:52 ` Alan Mackenzie 2 siblings, 1 reply; 144+ messages in thread From: Richard M Stallman @ 2009-05-26 0:13 UTC (permalink / raw) To: Ulrich Mueller; +Cc: ams, emacs-devel, monnier, drew.adams, miles This is the sort of issue for which it is a good idea to poll the users -- not just this mailing list. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-26 0:13 ` Richard M Stallman @ 2009-05-28 10:38 ` David Kastrup 2009-05-28 11:23 ` Bastien ` (2 more replies) 0 siblings, 3 replies; 144+ messages in thread From: David Kastrup @ 2009-05-28 10:38 UTC (permalink / raw) To: emacs-devel Richard M Stallman <rms@gnu.org> writes: > This is the sort of issue for which it is a good idea to poll the > users -- not just this mailing list. Putting it in a pretest is polling the users. -- David Kastrup ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-28 10:38 ` David Kastrup @ 2009-05-28 11:23 ` Bastien 2009-05-28 13:38 ` Werner LEMBERG 2009-05-29 4:39 ` rms 2 siblings, 0 replies; 144+ messages in thread From: Bastien @ 2009-05-28 11:23 UTC (permalink / raw) To: David Kastrup; +Cc: emacs-devel David Kastrup <dak@gnu.org> writes: > Richard M Stallman <rms@gnu.org> writes: > >> This is the sort of issue for which it is a good idea to poll the >> users -- not just this mailing list. > > Putting it in a pretest is polling the users. Pulling is more about getting a clear yes/no answer on a specific question. Putting a feature in a pretest is more a way of opening the discussion about a feature, rather than closing it efficiently. -- Bastien ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-28 10:38 ` David Kastrup 2009-05-28 11:23 ` Bastien @ 2009-05-28 13:38 ` Werner LEMBERG 2009-05-29 4:39 ` rms 2 siblings, 0 replies; 144+ messages in thread From: Werner LEMBERG @ 2009-05-28 13:38 UTC (permalink / raw) To: dak; +Cc: emacs-devel >> This is the sort of issue for which it is a good idea to poll the >> users -- not just this mailing list. > > Putting it in a pretest is polling the users. But the implementers apparently don't consider this as such. Features in pretest appear to be cast in stone. Werner ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-28 10:38 ` David Kastrup 2009-05-28 11:23 ` Bastien 2009-05-28 13:38 ` Werner LEMBERG @ 2009-05-29 4:39 ` rms 2 siblings, 0 replies; 144+ messages in thread From: rms @ 2009-05-29 4:39 UTC (permalink / raw) To: David Kastrup; +Cc: emacs-devel Putting it in a pretest is polling the users. No, it isn't. Only a few of the users normally try a pretest. Polling the users means posting an announcement explicitly asking users to try the feature now, and say what they think _and why_. When possible, it is good to tell them a recipe to try the new behavior in the current released Emacs, so they can try it and respond without actually installing a pretest, ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-25 9:29 ` Ulrich Mueller 2009-05-25 10:16 ` Miles Bader 2009-05-26 0:13 ` Richard M Stallman @ 2009-05-26 9:52 ` Alan Mackenzie 2009-05-26 12:08 ` Lennart Borgman 2 siblings, 1 reply; 144+ messages in thread From: Alan Mackenzie @ 2009-05-26 9:52 UTC (permalink / raw) To: Ulrich Mueller; +Cc: ams, emacs-devel, Stefan Monnier, drew.adams, Miles Bader On Mon, May 25, 2009 at 11:29:48AM +0200, Ulrich Mueller wrote: > >>>>> On Mon, 25 May 2009, Miles Bader wrote: > > "Alfred M. Szmidt" <ams@gnu.org> writes: > >> This is not a useful way to carry a conversation. People, lots of > >> people, have complained about this behaviour, so it needs to be > >> re-examined. > > I don't really get the impression that "Lots of people" are > > complaining actually (seems more like a few people, at high volume). > Add me to the list of people complaining, then. I think that it's > counter-intuitive to move point horizontally when vertical movement was > asked for. The default should be changed back to nil. That's most people's reasoning, I think. Trouble is, they disagree about what "horizontal" and "vertical" mean; is it "horizontal" in a logical line, or "horizontal" in a visible line? Which comes back to the question "what do we mean by a line?". I don't do much with wide buffers - occasionally I read log files with long lines, occasionally I have to edit text in the paragraph-is-a-single-very-long-line style. For both of these scenarios, I prefer line-move-visual enabled, since I find the shock of C-n "jumping three lines" very disconcerting. But that's just my personal preference; I appreciate other people's arguments for leaving l-m-visual nil. The fact that somebody like Drew, who's normally so calm and collected, is so steadfastly opposed to the change is a strong argument in itself. I disagree with Eli that defaults are "only" defaults: they're the settings we impose on new users, and are critically important. If they're bad defaults, they could irritate and exasperate users for months or years before those users eventually change them. (C-n adding new lines onto the ends of files (which was the default in Emacs <= 20) springs to mind here). Add me to the list of people emphatically and loudly abstaining. It's important to get this right, though. > Also, at former times the user community was asked before such UI > changes were done (I remember polls about C-x 0, M-g, C-x C-w, and > C-x C-q at least). Why isn't this done any more? This practice was (tacitly) abandoned in spring 2008, when a much more massive change in Emacs's defaults was committed before discussions about it had really got underway. Stefan and Yidong did not require that change to be reverted during those discussions. > Ulrich -- Alan Mackenzie (Nürnberg). ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-26 9:52 ` Alan Mackenzie @ 2009-05-26 12:08 ` Lennart Borgman 2009-05-26 12:36 ` Rupert Swarbrick 2009-05-26 20:12 ` Alfred M. Szmidt 0 siblings, 2 replies; 144+ messages in thread From: Lennart Borgman @ 2009-05-26 12:08 UTC (permalink / raw) To: Alan Mackenzie Cc: Ulrich Mueller, emacs-devel, ams, Stefan Monnier, drew.adams, Miles Bader On Tue, May 26, 2009 at 11:52 AM, Alan Mackenzie <acm@muc.de> wrote: > > I disagree with Eli that defaults are "only" defaults: they're the > settings we impose on new users, and are critically important. If > they're bad defaults, they could irritate and exasperate users for months > or years before those users eventually change them. (C-n adding new > lines onto the ends of files (which was the default in Emacs <= 20) > springs to mind here). I guess new users will in most cases appreciate the change (since it makes Emacs behave more like other editing environments), but old timers will a bit more often dislike it. (This will of course make both polling and discussions like this difficult.) ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-26 12:08 ` Lennart Borgman @ 2009-05-26 12:36 ` Rupert Swarbrick 2009-05-26 20:12 ` Alfred M. Szmidt 1 sibling, 0 replies; 144+ messages in thread From: Rupert Swarbrick @ 2009-05-26 12:36 UTC (permalink / raw) To: emacs-devel [-- Attachment #1: Type: text/plain, Size: 2168 bytes --] Lennart Borgman <lennart.borgman@gmail.com> writes: > On Tue, May 26, 2009 at 11:52 AM, Alan Mackenzie <acm@muc.de> wrote: >> >> I disagree with Eli that defaults are "only" defaults: they're the >> settings we impose on new users, and are critically important. If >> they're bad defaults, they could irritate and exasperate users for >> months or years before those users eventually change them. (C-n >> adding new lines onto the ends of files (which was the default in >> Emacs <= 20) springs to mind here). > > I guess new users will in most cases appreciate the change (since it > makes Emacs behave more like other editing environments), but old > timers will a bit more often dislike it. I agree that this makes Emacs behave more like other editors. But I'm not sure it's something that new users will feel strongly about: How much is emacs _really_ "like other editing environments"? I mean, all the keyboard shortcuts are different. Killing and yanking is very different from Ctrl-C Ctrl-V. Using multiple buffers gets confusing very quickly if you're used to the Windows-style MDI etc. etc. etc. So my point is that making this (rather corner-case) behaviour more like gedit or notepad isn't necessarily a relevant goal: I don't believe that it makes much difference to new users, who are learning a significantly different approach to editing anyway [1]. Now, this post doesn't claim to have any bearing on any of the other arguments put forward in the discussion. My personal feeling is that Drew's suggestion of making a distinction between "programming" and "text" based on major-mode is very sensible. Hope this makes some sense, Rupert [1] Actually, I do have some data here: I'm a Uni student and my housemate started using Emacs at my suggestion a couple of months ago to run inferior octave processes. When I mentioned this thread to him this morning he grinned and said he'd come across the (old) behaviour, but decided that it made sense on balance. So far as I know, he didn't read any info files or help strings about it, so if it made sense without maybe it's not such a bad design! [-- Attachment #2: Type: application/pgp-signature, Size: 314 bytes --] ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-26 12:08 ` Lennart Borgman 2009-05-26 12:36 ` Rupert Swarbrick @ 2009-05-26 20:12 ` Alfred M. Szmidt 1 sibling, 0 replies; 144+ messages in thread From: Alfred M. Szmidt @ 2009-05-26 20:12 UTC (permalink / raw) To: Lennart Borgman; +Cc: ulm, emacs-devel, monnier, acm, drew.adams, miles [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset=utf-8, Size: 720 bytes --] > I disagree with Eli that defaults are "only" defaults: they're > the settings we impose on new users, and are critically > important. If they're bad defaults, they could irritate and > exasperate users for months or years before those users > eventually change them. (C-n adding new lines onto the ends of > files (which was the default in Emacs <= 20) springs to mind > here). I guess new users will in most cases appreciate the change (since it makes Emacs behave more like other editing environments), but old timers will a bit more often dislike it. Guessing is something everyone can do; instead a poll is a better measurement of what users, new and old will like or dislike. ^ permalink raw reply [flat|nested] 144+ messages in thread
* RE: please make line-move-visual nil 2009-05-25 2:02 ` Stefan Monnier 2009-05-25 4:16 ` Alfred M. Szmidt @ 2009-05-25 8:17 ` Drew Adams 2009-05-25 13:29 ` Stefan Monnier 1 sibling, 1 reply; 144+ messages in thread From: Drew Adams @ 2009-05-25 8:17 UTC (permalink / raw) To: 'Stefan Monnier'; +Cc: emacs-devel > > I'm coming back to this thread because I just tried the new pretest > > (23.0.94.1), where the default value of `line-move-visual' is t. > > > This is insane, IMO. The default value is t even in formatted modes > > such as Buffer Menu and Info. It is t even in code modes such as > > Emacs-Lisp. If you use `define-derived-mode' to define a > new mode from > > scratch - a mode that has no parent mode, it has value t in that > > mode. It has value t everywhere, by default. This makes no sense. > > > If you absolutely feel the need to make the default value be t for > > modes such as text-mode, which (you are convinced) are likely to > > benefit from it, then do so. But PLEASE leave the rest of Emacs > > alone, by default. This is a bad choice for Emacs - please > > reconsider this. > > We've talked it over repeatedly. Well, I haven't. This is the first I've spoken up on it. Call me a latecomer. Are you saying the party is over? Doesn't sound like it... > Add (setq line-move-visual nil) to > your .emacs and live happily ever after. Right. Same old same old... What is wrong with the proposal that the default be different, depending on the type of buffer? That seems quite sensible. We can argue over which buffer types should have a non-nil default, but at least making some such division makes sense. I personally would argue that only a minority of modes should have non-nil by default, but at least such a partition could be discussed. I would be perfectly happy with a non-nil default for text-mode and modes that inherit from it or are similar to it - mail composition buffers, for instance. And nil for the other modes - those that are for code or tabular or otherwise formatted text (in the sense of laid out, not in the sense of enriched text). That is a sensible default behavior, to me. I probably wouldn't even customize it, if the defaults were like that. I don't particularly _want_ a nil value everywhere. And I certainly don't want a non-nil value everywhere. Why not make this a little more flexible, and give it reasonable defaults based on the buffer type? ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-25 8:17 ` Drew Adams @ 2009-05-25 13:29 ` Stefan Monnier 2009-05-25 17:51 ` Drew Adams 0 siblings, 1 reply; 144+ messages in thread From: Stefan Monnier @ 2009-05-25 13:29 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-devel > What is wrong with the proposal that the default be different, > depending on the type of buffer? That seems quite sensible. "Two" things: 1 - it's far from clear which modes should use which default. 2 - there is very little evidence that someone might want different behavior in different buffers. 3 - Drew would come back screaming if (setq line-move-visual nil) only fixes that new brain-dead behavior in some modes but not all. -- Stefan ^ permalink raw reply [flat|nested] 144+ messages in thread
* RE: please make line-move-visual nil 2009-05-25 13:29 ` Stefan Monnier @ 2009-05-25 17:51 ` Drew Adams 2009-05-25 21:14 ` Stefan Monnier 0 siblings, 1 reply; 144+ messages in thread From: Drew Adams @ 2009-05-25 17:51 UTC (permalink / raw) To: 'Stefan Monnier'; +Cc: emacs-devel > > What is wrong with the proposal that the default be different, > > depending on the type of buffer? That seems quite sensible. > > "Two" things: > 1 - it's far from clear which modes should use which default. Whoa! If that's far from clear, then it's even farther from clear that _all_ modes should always have non-nil as the default. Talk about sophistry! > 2 - there is very little evidence that someone might want different > behavior in different buffers. Evidence: I'm someone who might want different behavior in different buffers. There is even less evidence that _everyone_ wants non-nil in _all_ buffers. This is about choosing reasonable _default_ behavior. > 3 - Drew would come back screaming if (setq line-move-visual nil) only > fixes that new brain-dead behavior in some modes but not all. It's irrelevant whether Drew comes back screaming. Forget the ad hominem appeals to the gallery and get back to reasoned argument. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-25 17:51 ` Drew Adams @ 2009-05-25 21:14 ` Stefan Monnier 2009-05-25 21:26 ` Lennart Borgman ` (2 more replies) 0 siblings, 3 replies; 144+ messages in thread From: Stefan Monnier @ 2009-05-25 21:14 UTC (permalink / raw) To: Drew Adams; +Cc: emacs-devel >> 1 - it's far from clear which modes should use which default. > Whoa! If that's far from clear, then it's even farther from clear that _all_ > modes should always have non-nil as the default. Talk about sophistry! I don't see why the two should be correlated, so I don't se the sophistry. AFAIK the choice bsically depends on the user's taste, similarly to the blinking cursor. Please give examples of modes where the choice is clear one way or the other (sufficiently so that it should override the user's default choice). We can then consider them. I still haven't seen any argument for any particular mode, so I think it is fair to say that it is unclear which modes should use which default. I've seen mention that text-mode should use a value of t, but haven't understood why that would be a better choice there than elsewhere. >> 2 - there is very little evidence that someone might want different >> behavior in different buffers. > Evidence: I'm someone who might want different behavior in different buffers. Which behavior where? > There is even less evidence that _everyone_ wants non-nil in _all_ buffers. Maybe if you explain the specific harm you see, we can start reasoning about where/when to use what. In my use, the new default saves me the trouble of having to worry about long wrapped lines, and that holds in all buffers. > This is about choosing reasonable _default_ behavior. Thank you for repeating the obvious. I think we are all painfully aware of this by now. >> 3 - Drew would come back screaming if (setq line-move-visual nil) only >> fixes that new brain-dead behavior in some modes but not all. > It's irrelevant whether Drew comes back screaming. Forget the ad > hominem appeals to the gallery and get back to reasoned argument. This was an attempt at humor rather than an ad-hominem. I'm sorry if you felt attacked/ridiculed/dimished, there was no such intention. The inflamed tone of this thread is one of the reasons why I think more than ever that this setting is only a question of personal taste. Stefan ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-25 21:14 ` Stefan Monnier @ 2009-05-25 21:26 ` Lennart Borgman 2009-05-26 6:56 ` Tassilo Horn 2009-05-26 19:17 ` Tobias C. Rittweiler 2 siblings, 0 replies; 144+ messages in thread From: Lennart Borgman @ 2009-05-25 21:26 UTC (permalink / raw) To: Stefan Monnier; +Cc: Drew Adams, emacs-devel On Mon, May 25, 2009 at 11:14 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote: > I've seen mention that text-mode > should use a value of t, but haven't understood why that would be > a better choice there than elsewhere. I think it might be that word-wrap is also turned on by visual-line-mode. That may perhaps give the impression that the code was badly formatted, but in my opinion the fringe wrap symbols makes it clear what is happening. >>> 2 - there is very little evidence that someone might want different >>> behavior in different buffers. > >> Evidence: I'm someone who might want different behavior in different buffers. > > Which behavior where? Maybe I should not say this because I like the way visual-line-mode works, but could not the concept of majo mode parents be used to get some structure out of this? ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-25 21:14 ` Stefan Monnier 2009-05-25 21:26 ` Lennart Borgman @ 2009-05-26 6:56 ` Tassilo Horn 2009-05-26 11:37 ` Deniz Dogan 2009-05-26 19:17 ` Tobias C. Rittweiler 2 siblings, 1 reply; 144+ messages in thread From: Tassilo Horn @ 2009-05-26 6:56 UTC (permalink / raw) To: Stefan Monnier; +Cc: Drew Adams, emacs-devel Stefan Monnier <monnier@IRO.UMontreal.CA> writes: Hi Stefan, > The inflamed tone of this thread is one of the reasons why I think > more than ever that this setting is only a question of personal taste. I'm one of those who like the new behavior, but I agree that one might run into troubles with keyboard macros. IMO that's the only point where the new behavior has some disadvantages which are not personal preferences. And I also agree that there are other features which may screw up macros as well and nobody objected to them; unfortunately I don't know which ones -- so at least they didn't bite me till now. Ok, so what I wanted to propose instead some special handling of line-move-visual in keyboard macros is the addition of two hook `before-kbd-macro-hook' and `after-kbd-macro-hook' which are run before and after the definition and execution of keyboard macros. Then users can decide the value of line-move-visual and others depending on the current buffer's mode or the lunar phase in macros, no matter the default or user-specified value. I think that's a reasonable solution, much better than any special hardcoding or workarounds like `M-x toggle-word-wrap' before each macro definition/execution. Bye, Tassilo ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-26 6:56 ` Tassilo Horn @ 2009-05-26 11:37 ` Deniz Dogan 2009-05-26 12:24 ` Lennart Borgman 2009-05-26 16:56 ` Stefan Monnier 0 siblings, 2 replies; 144+ messages in thread From: Deniz Dogan @ 2009-05-26 11:37 UTC (permalink / raw) To: Tassilo Horn; +Cc: Stefan Monnier, Drew Adams, emacs-devel 2009/5/26 Tassilo Horn <tassilo@member.fsf.org>: > Ok, so what I wanted to propose instead some special handling of > line-move-visual in keyboard macros is the addition of two hook > `before-kbd-macro-hook' and `after-kbd-macro-hook' which are run before > and after the definition and execution of keyboard macros. Then users > can decide the value of line-move-visual and others depending on the > current buffer's mode or the lunar phase in macros, no matter the > default or user-specified value. I completely support this and in my opinion it's not too late to add these hooks. -- Deniz Dogan ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-26 11:37 ` Deniz Dogan @ 2009-05-26 12:24 ` Lennart Borgman 2009-05-26 12:42 ` David Reitter ` (2 more replies) 2009-05-26 16:56 ` Stefan Monnier 1 sibling, 3 replies; 144+ messages in thread From: Lennart Borgman @ 2009-05-26 12:24 UTC (permalink / raw) To: Deniz Dogan; +Cc: Tassilo Horn, Stefan Monnier, Drew Adams, emacs-devel On Tue, May 26, 2009 at 1:37 PM, Deniz Dogan <deniz.a.m.dogan@gmail.com> wrote: > 2009/5/26 Tassilo Horn <tassilo@member.fsf.org>: >> Ok, so what I wanted to propose instead some special handling of >> line-move-visual in keyboard macros is the addition of two hook >> `before-kbd-macro-hook' and `after-kbd-macro-hook' which are run before >> and after the definition and execution of keyboard macros. Then users >> can decide the value of line-move-visual and others depending on the >> current buffer's mode or the lunar phase in macros, no matter the >> default or user-specified value. > > I completely support this and in my opinion it's not too late to add > these hooks. I am not sure this is a good idea. I believe it might be better to investigate more how certain features (like visual-line-move) should be handled under different circumstances. Such circumstances is (as is pointed out here) macros, but there are others two, like printing. And what about using the affected functions in functions that might do the editing in another window than the selected window? Even though I think like this I like visual-line-mode and think it should be on by default. But thinking over the questions above and documenting the behaviour is necessary in my opinion. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-26 12:24 ` Lennart Borgman @ 2009-05-26 12:42 ` David Reitter [not found] ` <m3hbz8c9qy.fsf@verona.se> 2009-05-26 12:42 ` joakim 2009-05-26 13:54 ` Jason Rumney 2 siblings, 1 reply; 144+ messages in thread From: David Reitter @ 2009-05-26 12:42 UTC (permalink / raw) To: Lennart Borgman Cc: Tassilo Horn, emacs-devel, Stefan Monnier, Drew Adams, Deniz Dogan [-- Attachment #1: Type: text/plain, Size: 812 bytes --] On May 26, 2009, at 8:24 AM, Lennart Borgman wrote: > I believe it might be better to investigate more how certain features > (like visual-line-move) should be handled under different > circumstances. Such circumstances is (as is pointed out here) macros, > but there are others two, like printing. And what about using the > affected functions in functions that might do the editing in another > window than the selected window? Rather than providing hooks so that the user can be trapped by the problem, diagnose it, find the hooks, and come up with the right lisp code (most users actually don't speak lisp) to fix it, why not turn off line-move-visual (and anything else of the "do what I mean" variety) during macro recording and playback? That would lead to consistent and predictable behavior. [-- Attachment #2: smime.p7s --] [-- Type: application/pkcs7-signature, Size: 2193 bytes --] ^ permalink raw reply [flat|nested] 144+ messages in thread
[parent not found: <m3hbz8c9qy.fsf@verona.se>]
* Re: please make line-move-visual nil [not found] ` <m3hbz8c9qy.fsf@verona.se> @ 2009-05-26 12:58 ` David Reitter 0 siblings, 0 replies; 144+ messages in thread From: David Reitter @ 2009-05-26 12:58 UTC (permalink / raw) To: joakim, Emacs-Devel devel [-- Attachment #1: Type: text/plain, Size: 721 bytes --] On May 26, 2009, at 8:46 AM, joakim@verona.se wrote: >> Rather than providing hooks so that the user can be trapped by the >> problem, diagnose it, find the hooks, and come up with the right lisp >> code (most users actually don't speak lisp) to fix it, why not turn >> off line-move-visual (and anything else of the "do what I mean" >> variety) during macro recording and playback? That would lead to >> consistent and predictable behavior. > > The mechanism for this could be in the form of a preloaded hook, > right? Yes, sounds like a good idea. That way it can be turned off / tinkered with. We should, however, take care to restore the previous value in case an error is signaled during Macro execution. [-- Attachment #2: smime.p7s --] [-- Type: application/pkcs7-signature, Size: 2193 bytes --] ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-26 12:24 ` Lennart Borgman 2009-05-26 12:42 ` David Reitter @ 2009-05-26 12:42 ` joakim 2009-05-26 13:54 ` Jason Rumney 2 siblings, 0 replies; 144+ messages in thread From: joakim @ 2009-05-26 12:42 UTC (permalink / raw) To: Lennart Borgman Cc: Tassilo Horn, emacs-devel, Stefan Monnier, Drew Adams, Deniz Dogan Lennart Borgman <lennart.borgman@gmail.com> writes: > On Tue, May 26, 2009 at 1:37 PM, Deniz Dogan <deniz.a.m.dogan@gmail.com> wrote: >> 2009/5/26 Tassilo Horn <tassilo@member.fsf.org>: >>> Ok, so what I wanted to propose instead some special handling of >>> line-move-visual in keyboard macros is the addition of two hook >>> `before-kbd-macro-hook' and `after-kbd-macro-hook' which are run before >>> and after the definition and execution of keyboard macros. Then users >>> can decide the value of line-move-visual and others depending on the >>> current buffer's mode or the lunar phase in macros, no matter the >>> default or user-specified value. >> >> I completely support this and in my opinion it's not too late to add >> these hooks. > > > I am not sure this is a good idea. > > I believe it might be better to investigate more how certain features > (like visual-line-move) should be handled under different > circumstances. Such circumstances is (as is pointed out here) macros, > but there are others two, like printing. And what about using the > affected functions in functions that might do the editing in another > window than the selected window? > > Even though I think like this I like visual-line-mode and think it > should be on by default. But thinking over the questions above and > documenting the behaviour is necessary in my opinion. I think this argument in fact supports the addition of hooks. Maybe you need to differentiate between recording hooks and execution hooks, but otherwise the idea seems good. It seems logical that youd want some generic mechanism to get Emacs into a state that is good for recording and executing macros. > > -- Joakim Verona ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-26 12:24 ` Lennart Borgman 2009-05-26 12:42 ` David Reitter 2009-05-26 12:42 ` joakim @ 2009-05-26 13:54 ` Jason Rumney 2009-05-26 20:21 ` Lennart Borgman 2 siblings, 1 reply; 144+ messages in thread From: Jason Rumney @ 2009-05-26 13:54 UTC (permalink / raw) To: Lennart Borgman Cc: Tassilo Horn, emacs-devel, Stefan Monnier, Drew Adams, Deniz Dogan Lennart Borgman wrote: > I believe it might be better to investigate more how certain features > (like visual-line-move) should be handled under different > circumstances. Such circumstances is (as is pointed out here) macros, > but there are others two, like printing. line-movement is not involved in printing. But any non-interactive use probably falls into the same category as macros. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-26 13:54 ` Jason Rumney @ 2009-05-26 20:21 ` Lennart Borgman 2009-05-27 2:50 ` Miles Bader 0 siblings, 1 reply; 144+ messages in thread From: Lennart Borgman @ 2009-05-26 20:21 UTC (permalink / raw) To: Jason Rumney Cc: Tassilo Horn, emacs-devel, Stefan Monnier, Drew Adams, Deniz Dogan On Tue, May 26, 2009 at 3:54 PM, Jason Rumney <jasonr@gnu.org> wrote: > Lennart Borgman wrote: >> >> I believe it might be better to investigate more how certain features >> (like visual-line-move) should be handled under different >> circumstances. Such circumstances is (as is pointed out here) macros, >> but there are others two, like printing. > > line-movement is not involved in printing. But any non-interactive use > probably falls into the same category as macros. Eh, yes, but printing is quite closely related here due to that visual-line-move turns on word-wrap. It would be nice to be able to get print to use that too. It is of course another problem. However I suspect that thinking about those problems together might create opportunities for better solutions (as you suggested). ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-26 20:21 ` Lennart Borgman @ 2009-05-27 2:50 ` Miles Bader 0 siblings, 0 replies; 144+ messages in thread From: Miles Bader @ 2009-05-27 2:50 UTC (permalink / raw) To: Lennart Borgman Cc: Deniz Dogan, Jason Rumney, Stefan Monnier, Tassilo Horn, emacs-devel, Drew Adams Lennart Borgman <lennart.borgman@gmail.com> writes: >> line-movement is not involved in printing. But any non-interactive use >> probably falls into the same category as macros. > > Eh, yes, but printing is quite closely related here due to that > visual-line-move turns on word-wrap. visual-line-mode does, but that's not what's being discussed... [What's being discussed is the default behavior of line-movement; the new default behavior is only controversial because it applies even when visual-line-mode is _not_ enabled...] -miles -- Un-American, adj. Wicked, intolerable, heathenish. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-26 11:37 ` Deniz Dogan 2009-05-26 12:24 ` Lennart Borgman @ 2009-05-26 16:56 ` Stefan Monnier 1 sibling, 0 replies; 144+ messages in thread From: Stefan Monnier @ 2009-05-26 16:56 UTC (permalink / raw) To: Deniz Dogan; +Cc: Tassilo Horn, Drew Adams, emacs-devel >> Ok, so what I wanted to propose instead some special handling of >> line-move-visual in keyboard macros is the addition of two hook >> `before-kbd-macro-hook' and `after-kbd-macro-hook' which are run before >> and after the definition and execution of keyboard macros. Then users >> can decide the value of line-move-visual and others depending on the >> current buffer's mode or the lunar phase in macros, no matter the >> default or user-specified value. > I completely support this and in my opinion it's not too late to add > these hooks. That can be done, yes. Stefan ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-25 21:14 ` Stefan Monnier 2009-05-25 21:26 ` Lennart Borgman 2009-05-26 6:56 ` Tassilo Horn @ 2009-05-26 19:17 ` Tobias C. Rittweiler 2 siblings, 0 replies; 144+ messages in thread From: Tobias C. Rittweiler @ 2009-05-26 19:17 UTC (permalink / raw) To: emacs-devel Stefan Monnier <monnier@IRO.UMontreal.CA> writes: > Please give examples of modes where the choice is clear one way or the > other (sufficiently so that it should override the user's default > choice). We can then consider them. I still haven't seen any argument > for any particular mode, so I think it is fair to say that it is unclear > which modes should use which default. I've seen mention that text-mode > should use a value of t, but haven't understood why that would be > a better choice there than elsewhere. I think it's problematic in buffers that are supposed to be analyzed mechanically by external programs. A couple of weeks ago there was a scenario where I could easily have been bitten by the bug: I was working on some code which reports error locations as a file position + an offset in lines. When debugging that code, I first went to the file position in the source file, and then used `C-u NN C-n' to see if everything's working out correctly. When the buffer happened to contain wrapped lines, I'd have got to the wrong line, making me think that the error reporting code was at fault. It would probably have taken a while before I'd have found out what's actually faulty. -T. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-13 13:35 ` garyo 2009-05-13 23:59 ` Deniz Dogan @ 2009-05-14 17:14 ` Bob Nnamtrop 1 sibling, 0 replies; 144+ messages in thread From: Bob Nnamtrop @ 2009-05-14 17:14 UTC (permalink / raw) To: Emacs-devel [-- Attachment #1: Type: text/plain, Size: 948 bytes --] I somehow missed this. I have no opinion on the default but I have noticed an inconsistency with this variable. In viper-mode, line-move-visual is respected by down/up arrows but not by j/k. I would think they should BOTH respect the variable. These call the functions previous-line/next-line and viper-previous-line/viper-next-line, respectively. It would seem the viper version need to be corrected. Bob On Wed, May 13, 2009 at 7:35 AM, garyo <garyo@genarts.com> wrote: > > > > Alfred M. Szmidt wrote: > > > > Please make line-move-visual nil, it is totally uninutive to have the > > point move to the same line, when you explicitly told it to move to > > the next line. > > > > I agree, this is very different behavior for such a core command! > > -- > View this message in context: > http://www.nabble.com/please-make-line-move-visual-nil-tp21640152p23521879.html > Sent from the Emacs - Dev mailing list archive at Nabble.com. > > > > [-- Attachment #2: Type: text/html, Size: 1427 bytes --] ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-01-24 12:30 please make line-move-visual nil Alfred M. Szmidt 2009-05-13 13:35 ` garyo @ 2009-05-14 16:00 ` Shaun Johnson 2009-05-14 16:20 ` David Reitter 1 sibling, 1 reply; 144+ messages in thread From: Shaun Johnson @ 2009-05-14 16:00 UTC (permalink / raw) Cc: emacs-devel Alfred M. Szmidt wrote: > Please make line-move-visual nil, it is totally uninutive to have the > point move to the same line, when you explicitly told it to move to > the next line. > > It also breaks keyboard macros, since now you have no idea if you end > up on a new line, or on the same line but at a different column. > > I know that it is pre-test time, but this behaviour is simply stupid > and doesn't make any sense. FWIW I completely agree, I find this behaviour bizarre in the extreme. I appreciate that others, coming from a different background, may find this behaviour intuitive but I don't see that as a reason to change such a core behaviour. Shaun Johnson. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-14 16:00 ` Shaun Johnson @ 2009-05-14 16:20 ` David Reitter 2009-05-14 18:17 ` Alan Mackenzie 0 siblings, 1 reply; 144+ messages in thread From: David Reitter @ 2009-05-14 16:20 UTC (permalink / raw) To: Emacs-Devel devel On May 14, 2009, at 9:00 AM, Shaun Johnson wrote: > Alfred M. Szmidt wrote: >> Please make line-move-visual nil, it is totally uninutive to have the >> point move to the same line, when you explicitly told it to move to >> the next line. > FWIW I completely agree, I find this behaviour bizarre in the extreme. > I appreciate that others, coming from a different background, may find > this behaviour intuitive but I don't see that as a reason to change > such > a core behaviour. For people seeking to understand the reasons behind this default choice at this late stage in the release process, it may be helpful to review the discussions here about the new word-wrap (soft wrapping) feature, where continued buffer lines comprise whole paragraphs in text rather than just the occasional over-long line in code. Also, consider the increased use of variable width fonts, which are standard for non-code text in modern operating environments. On a more general note, I wonder why experienced users occasional resist change in the UI in general (as it breaks things) rather than avoiding to upgrade. Perhaps, providing bug fixes for previous branches (e.g., Emacs 22) for a few years after the release of a new full version would mitigate these issues. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-14 16:20 ` David Reitter @ 2009-05-14 18:17 ` Alan Mackenzie 2009-05-15 5:32 ` David Reitter 2009-05-17 3:53 ` Stefan Monnier 0 siblings, 2 replies; 144+ messages in thread From: Alan Mackenzie @ 2009-05-14 18:17 UTC (permalink / raw) To: David Reitter; +Cc: Emacs-Devel devel On Thu, May 14, 2009 at 09:20:44AM -0700, David Reitter wrote: > On May 14, 2009, at 9:00 AM, Shaun Johnson wrote: > >Alfred M. Szmidt wrote: > >>Please make line-move-visual nil, it is totally uninutive to have the > >>point move to the same line, when you explicitly told it to move to > >>the next line. > >FWIW I completely agree, I find this behaviour bizarre in the extreme. > >I appreciate that others, coming from a different background, may find > >this behaviour intuitive but I don't see that as a reason to change > >such a core behaviour. > For people seeking to understand the reasons behind this default > choice at this late stage in the release process, it may be helpful to > review the discussions here about the new word-wrap (soft wrapping) > feature, where continued buffer lines comprise whole paragraphs in > text rather than just the occasional over-long line in code. Also, > consider the increased use of variable width fonts, which are standard > for non-code text in modern operating environments. I don't see anything bizarre and extreme about this change, but as a minor point I wish this change had been made by rebinding C-n to a [new?] command `next-visual-line'. It used to be that "line" meant the text between two \n's, and now its definition has become vague and mushy. I think I'm marginally in favour of C-n, C-p moving by screen lines, since the pain it causes old-timers (having to type C-n again) is less than the pain of navigating through buffers with long lines when C-n jumps over several screen lines. But yes, these new commands will cuase pain for people who use them in keyboard macros. These people will probably twig quite quickly what's amiss, and will be able to fix it at the cost of a throbbing headache. > On a more general note, I wonder why experienced users occasionally > resist change in the UI in general (as it breaks things) rather than > avoiding to upgrade. [linguistic point: "avoid" takes a noun or a gerund (which needn't be round), not an infinitive. You want "avoiding an upgrade" or "avoiding upgrading" here.] You're not trying to ignite another rambling heated debate about changing long standing features, are you? OK, thought not. Changing the UI makes the new version incompatible with the learning of the users of the old versions. Either they must relearn things, which is painful, or they must track down the options they need to unset to make it work how it used to, which is painful. This pain is a Bad Thing. Only if the new UI is stunningly good is the change justified. IMAO, the UI changes in Emacs 23 aren't justified. > Perhaps, providing bug fixes for previous branches (e.g., Emacs 22) for > a few years after the release of a new full version would mitigate > these issues. It's too much work at the moment. It might become feasible with bazaar. That's pure speculation by the way - I haven't tried bazaar out yet. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-14 18:17 ` Alan Mackenzie @ 2009-05-15 5:32 ` David Reitter 2009-05-15 7:18 ` Stephen J. Turnbull 2009-05-15 7:40 ` Stephen Berman 2009-05-17 3:53 ` Stefan Monnier 1 sibling, 2 replies; 144+ messages in thread From: David Reitter @ 2009-05-15 5:32 UTC (permalink / raw) To: Alan Mackenzie, Emacs-Devel devel [-- Attachment #1: Type: text/plain, Size: 1556 bytes --] On May 14, 2009, at 11:17 AM, Alan Mackenzie wrote: >> >> On a more general note, I wonder why experienced users occasionally >> resist change in the UI in general (as it breaks things) rather than >> avoiding to upgrade. > > [linguistic point: "avoid" takes a noun or a gerund (which needn't be > round), not an infinitive. You want "avoiding an upgrade" or > "avoiding > upgrading" here.] You are right. My heartfelt apologies. Language is to me what people (me excluded) speak, not what some book says. The avoid+infinitive construction doesn't get any traction in a Google search (using past tense), so I concede. > You're not trying to ignite another rambling heated debate about > changing > long standing features, are you? OK, thought not. God no, I am not. > Changing the UI makes the new version incompatible with the learning > of > the users of the old versions. Absolutely. But if people don't like change, then they shouldn't be forced to upgrade if we provided decent support for older versions. As you said, a new VCS will hopefully facilitate this. I use git and have evaluated Bazaar, and they both can cherry-pick bugfixes from the development branch and facilitate just that. One could really start with Emacs 22. Projects of the size/importance of Emacs should provide a roadmap with a promise to support certain releases for x many years. But even providing [important] bug fixes for the 22 series for a while should be considered. - David (who is actually a Diplom-Sprachwissenschaftler.) [-- Attachment #2: smime.p7s --] [-- Type: application/pkcs7-signature, Size: 2193 bytes --] ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-15 5:32 ` David Reitter @ 2009-05-15 7:18 ` Stephen J. Turnbull 2009-05-15 7:40 ` Stephen Berman 1 sibling, 0 replies; 144+ messages in thread From: Stephen J. Turnbull @ 2009-05-15 7:18 UTC (permalink / raw) To: David Reitter; +Cc: Alan Mackenzie, Emacs-Devel devel David Reitter writes: > Absolutely. But if people don't like change, then they shouldn't be > forced to upgrade if we provided decent support for older versions. Old versions of Emacs are not very buggy. Lack of support for old versions simply is not an issue. A recent survey of Emacsen conducted at a large 4-letter financial firm I am not at liberty to name showed over *30* different versions of Emacs/XEmacs in use, going back to Emacs 18.55. That in 220 responses. What people are upset about here is that upgrades that they really do want include backward incompatible changes that they dislike intensely and think are stupid. > As you said, a new VCS will hopefully facilitate this. I use git > and have evaluated Bazaar, and they both can cherry-pick bugfixes > from the development branch and facilitate just that. This is a really, really bad idea, unfortunately. This means doing all the design review and much of the quality assurance and some amount of the bug-fixing over again. People who want that are already doing it (a certain David Reitter who maintains Aquamacs comes to mind). But the people who are complaining about *defaults for options* (!!) are for sure not going to find that acceptable. What they want is the shiny new Emacs with the particolored new features, except the stupid ones. In theory that could be supported by "inverse cherry-picking" aka "spitting out the indigestible pits" (ie, reverting patches you don't like). But both cherry-picking and pit-spitting run into the problem that currently Emacs workflow does not require coherent changesets. There is no way to assure that *this* feature is associated with *exactly these* patches. Making that change to workflow is going to be very very hard, but without it the cherry-picking roll-yer-own Emacsen strategy is highly labor intensive. > Projects of the size/importance of Emacs should provide a roadmap with > a promise to support certain releases for x many years. Good luck with that. AFAIK "we support only the current version" is explicit policy. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-15 5:32 ` David Reitter 2009-05-15 7:18 ` Stephen J. Turnbull @ 2009-05-15 7:40 ` Stephen Berman 2009-05-15 7:58 ` Miles Bader 1 sibling, 1 reply; 144+ messages in thread From: Stephen Berman @ 2009-05-15 7:40 UTC (permalink / raw) To: emacs-devel On Thu, 14 May 2009 22:32:53 -0700 David Reitter <david.reitter@gmail.com> wrote: > On May 14, 2009, at 11:17 AM, Alan Mackenzie wrote: >>> >>> On a more general note, I wonder why experienced users occasionally >>> resist change in the UI in general (as it breaks things) rather than >>> avoiding to upgrade. >> >> [linguistic point: "avoid" takes a noun or a gerund (which needn't be >> round), not an infinitive. You want "avoiding an upgrade" or "avoiding >> upgrading" here.] > > You are right. My heartfelt apologies. Language is to me what people (me > excluded) speak, not what some book says. The avoid+infinitive construction > doesn't get any traction in a Google search (using past tense), so I concede. One not too rarely encountered (and to me fairly acceptable) avoid+infinitive construction is when `avoid' is passivized with an expletive subject: "It should be avoided to ...". FWIW Google (http://www.google.com/#hl=en&q="it+should+be+avoided+to"&btnG=Google+Search&aq=f&oq=undefined&fp=Frx3gI01710) shows "about 3,380" hits. Interestingly (and probably not insignificantly), the same search with the German Google (http://www.google.de/search?hl=de&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial&hs=cYC&q="it+should+be+avoided+to"&btnG=Suche&meta=&aq=f&oq=) shows "ungefähr 9.520" hits (for non-German readers: the point here is used like the comma in English). Steve Berman ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-15 7:40 ` Stephen Berman @ 2009-05-15 7:58 ` Miles Bader 2009-05-15 14:14 ` Drew Adams 2009-05-15 14:21 ` Stephen Berman 0 siblings, 2 replies; 144+ messages in thread From: Miles Bader @ 2009-05-15 7:58 UTC (permalink / raw) To: Stephen Berman; +Cc: emacs-devel Stephen Berman <stephen.berman@gmx.net> writes: > One not too rarely encountered (and to me fairly acceptable) > avoid+infinitive construction is when `avoid' is passivized with an > expletive subject: "It should be avoided to ...". FWIW Google To my ear, "avoid to" is clearly incorrect (and I think my ear is pretty good). There's _tons_ of bizarro grammar/misspellings/... on the net (googling as a means of checking spelling is risky because of that!). I suspect such usage is nowhere near the threshold where it's considered actually part of the language though.... -Miles -- A zen-buddhist walked into a pizza shop and said, "Make me one with everything." ^ permalink raw reply [flat|nested] 144+ messages in thread
* RE: please make line-move-visual nil 2009-05-15 7:58 ` Miles Bader @ 2009-05-15 14:14 ` Drew Adams 2009-05-15 14:21 ` Stephen Berman 1 sibling, 0 replies; 144+ messages in thread From: Drew Adams @ 2009-05-15 14:14 UTC (permalink / raw) To: 'Miles Bader', 'Stephen Berman'; +Cc: emacs-devel > One not too rarely encountered (and to me fairly acceptable) > avoid+infinitive construction is when `avoid' is passivized with an > expletive subject: "It should be avoided to ...". In what country is "avoid to" not too rarely encountered? ;-) One hears that kind of thing in continental Europe, from non-native English speakers. I always thought of it as a kind of faux ami: a direct (mis-)translation. The same thing happens with other verbs, besides "avoid". It's sometimes difficult for those for whom English is a second or third language to keep track of when the infinitive is called for. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-15 7:58 ` Miles Bader 2009-05-15 14:14 ` Drew Adams @ 2009-05-15 14:21 ` Stephen Berman 2009-05-15 14:27 ` Miles Bader 2009-05-16 6:13 ` Stephen J. Turnbull 1 sibling, 2 replies; 144+ messages in thread From: Stephen Berman @ 2009-05-15 14:21 UTC (permalink / raw) To: emacs-devel On Fri, 15 May 2009 16:58:02 +0900 Miles Bader <miles@gnu.org> wrote: > Stephen Berman <stephen.berman@gmx.net> writes: >> One not too rarely encountered (and to me fairly acceptable) >> avoid+infinitive construction is when `avoid' is passivized with an >> expletive subject: "It should be avoided to ...". FWIW Google > > To my ear, "avoid to" is clearly incorrect (and I think my ear is pretty > good). I agree with you (I'm a native speaker of American English) about "avoid to", i.e. in the active voice (and with an animate subject), but do you think the construction I referred to is just as "clearly incorrect" (I would rather say (un)acceptable)? I think there's a pretty clear difference in acceptability. There are at least a few other verbs that pattern with `avoid' in this respect. For example, these are all "clearly incorrect": (1) We avoided/recommended/suggested/discouraged to arrive early. in contrast to these, which are "correct" English: (2) We avoided/recommended/suggested/discouraged arriving early. When the main verb is passivized, an expletive subject is used, and the complements are reversed, I think there's a similar contrast. That is, the following are completely unacceptable[1]: (3) It should be avoided/ is highly recommended/ is strongly suggested/discouraged arriving early. while I think these sound more or less fine (`avoided' less than the others, but not completely bad, and clearly contrasting with (3)): (4) It should be avoided/ is highly recommended/ is strongly suggested/discouraged to arrive early. Do you find no acceptability contrast between (3) and (4)? Steve Berman Footnotes: [1] There is a marginal reading of (3) where the subject `it' refers to `arriving early' (it's marginal in (3) because as normally written it is set off by a comma). But on the reading I mean `it' is an expletive, non-referential. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-15 14:21 ` Stephen Berman @ 2009-05-15 14:27 ` Miles Bader 2009-05-16 6:13 ` Stephen J. Turnbull 1 sibling, 0 replies; 144+ messages in thread From: Miles Bader @ 2009-05-15 14:27 UTC (permalink / raw) To: emacs-devel Stephen Berman <stephen.berman@gmx.net> writes: >>> expletive subject: "It should be avoided to ...". FWIW Google >> >> To my ear, "avoid to" is clearly incorrect (and I think my ear is pretty >> good). > > I agree with you (I'm a native speaker of American English) about "avoid > to", i.e. in the active voice (and with an animate subject), but do you > think the construction I referred to is just as "clearly incorrect" Yes -Miles -- Patience, n. A minor form of despair, disguised as a virtue. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-15 14:21 ` Stephen Berman 2009-05-15 14:27 ` Miles Bader @ 2009-05-16 6:13 ` Stephen J. Turnbull 1 sibling, 0 replies; 144+ messages in thread From: Stephen J. Turnbull @ 2009-05-16 6:13 UTC (permalink / raw) To: Stephen Berman; +Cc: emacs-devel Stephen Berman writes: > (3) It should be avoided/ > (4) It should be avoided/ > Do you find no acceptability contrast between (3) and (4)? No. As they are identical, they are identically unacceptable. By that, I mean that in educating my daughter (who is a native Japanese speaker), I would *never* let that pass, not even in casual conversation. The only acceptable way to terminate those strings is with an immediate period, but then "it" cannot be an expletive. I agree that in terms of intelligibility it is somewhat better to follow an expletive "it" with the infinitive rather than the gerund. As a matter of style, of course that phrasing is abysmal. There is no need whatsoever for an expletive "it" to express that idea in English. ^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: please make line-move-visual nil 2009-05-14 18:17 ` Alan Mackenzie 2009-05-15 5:32 ` David Reitter @ 2009-05-17 3:53 ` Stefan Monnier 1 sibling, 0 replies; 144+ messages in thread From: Stefan Monnier @ 2009-05-17 3:53 UTC (permalink / raw) To: Alan Mackenzie; +Cc: David Reitter, Emacs-Devel devel > I don't see anything bizarre and extreme about this change, but as a > minor point I wish this change had been made by rebinding C-n to a [new?] > command `next-visual-line'. It used to be that "line" meant the text > between two \n's, and now its definition has become vague and mushy. There's already been such a distinction between next-line and forward-line. The "text between two \n" has always been associated with forward-line, whereas next-line was used for a mroe visually-oriented notion of line (e.g. it skips invisible text, even if it contains \n). For this reason, most (not all, of course) uses of next-line in Elisp is a bug. And for this reason as well, I don't think there's a strong motivation to introduce yet-another line-movement command. Stefan ^ permalink raw reply [flat|nested] 144+ messages in thread
end of thread, other threads:[~2009-06-14 20:45 UTC | newest] Thread overview: 144+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-01-24 12:30 please make line-move-visual nil Alfred M. Szmidt 2009-05-13 13:35 ` garyo 2009-05-13 23:59 ` Deniz Dogan 2009-05-14 0:06 ` garyo 2009-05-14 8:51 ` Teemu Likonen 2009-05-14 9:37 ` Antoine Levitt 2009-05-15 3:21 ` Lennart Borgman 2009-05-15 4:22 ` Stephen J. Turnbull 2009-05-17 6:29 ` Alfred M. Szmidt 2009-05-14 11:29 ` garyo 2009-05-14 15:37 ` Teemu Likonen 2009-05-15 2:45 ` Alfred M. Szmidt 2009-05-15 14:31 ` Davis Herring 2009-05-17 6:29 ` Alfred M. Szmidt 2009-05-17 10:48 ` Eli Zaretskii 2009-05-17 20:28 ` Davis Herring 2009-05-24 22:33 ` Drew Adams 2009-05-24 23:18 ` Bastien 2009-05-24 23:18 ` Leo 2009-05-24 23:50 ` Chong Yidong 2009-05-24 23:58 ` Lennart Borgman 2009-05-25 8:05 ` Miles Bader 2009-05-25 0:53 ` Drew Adams 2009-05-25 1:03 ` Chong Yidong 2009-05-25 1:59 ` Drew Adams 2009-05-25 13:23 ` Stefan Monnier 2009-05-25 17:51 ` Drew Adams 2009-05-25 2:32 ` Stephen J. Turnbull 2009-05-25 3:01 ` Eli Zaretskii 2009-05-25 4:16 ` Alfred M. Szmidt 2009-05-25 8:34 ` Bastien 2009-05-25 20:21 ` Eli Zaretskii 2009-05-25 20:46 ` Drew Adams 2009-05-27 12:48 ` Andrew W. Nosenko 2009-05-27 12:51 ` Andrew W. Nosenko 2009-05-31 11:45 ` Alfred M. Szmidt 2009-05-31 12:08 ` Andreas Schwab 2009-05-31 17:00 ` Miles Bader 2009-05-31 22:29 ` Bob Rogers 2009-06-01 2:33 ` Miles Bader 2009-06-01 9:22 ` Lennart Borgman 2009-06-01 9:54 ` Miles Bader 2009-06-01 9:59 ` Lennart Borgman 2009-06-05 22:13 ` Thien-Thi Nguyen 2009-05-31 13:09 ` Deniz Dogan 2009-06-01 2:39 ` Miles Bader 2009-05-31 21:19 ` Chong Yidong 2009-06-01 7:24 ` Mathias Megyei 2009-06-01 13:29 ` Stefan Monnier 2009-06-01 14:36 ` T.V. Raman 2009-06-01 16:20 ` Drew Adams 2009-06-01 17:56 ` Chong Yidong 2009-06-01 18:26 ` Drew Adams 2009-06-01 20:11 ` bug#3438: " Stefan Monnier 2009-06-01 20:11 ` Stefan Monnier 2009-06-01 21:00 ` bug#3438: " Drew Adams 2009-06-01 21:00 ` Drew Adams 2009-06-01 21:25 ` bug#3438: " Lennart Borgman 2009-06-01 21:25 ` Lennart Borgman 2009-06-01 21:33 ` Drew Adams 2009-06-01 21:56 ` bug#3438: " Lennart Borgman 2009-06-01 21:56 ` Lennart Borgman 2009-06-01 21:33 ` bug#3438: " Drew Adams 2009-06-01 22:33 ` Stefan Monnier 2009-06-01 22:52 ` Drew Adams 2009-06-01 23:12 ` Lennart Borgman 2009-06-01 23:57 ` Drew Adams 2009-06-01 23:57 ` bug#3438: " Drew Adams 2009-06-01 23:12 ` Lennart Borgman 2009-06-01 23:13 ` Eli Zaretskii 2009-06-01 23:23 ` bug#3438: " Drew Adams 2009-06-01 23:23 ` Drew Adams 2009-06-02 15:59 ` Eli Zaretskii 2009-06-02 15:59 ` bug#3438: " Eli Zaretskii 2009-06-01 23:13 ` Eli Zaretskii 2009-06-01 22:52 ` Drew Adams 2009-06-12 17:16 ` Drew Adams 2009-06-12 21:45 ` Stefan Monnier 2009-06-13 0:19 ` Drew Adams 2009-06-14 20:45 ` Stefan Monnier 2009-06-13 0:19 ` bug#3438: " Drew Adams 2009-06-12 21:45 ` Stefan Monnier 2009-06-12 17:16 ` Drew Adams 2009-06-01 22:33 ` Stefan Monnier 2009-06-01 23:18 ` Drew Adams 2009-06-02 1:29 ` Stefan Monnier 2009-06-01 18:26 ` bug#3438: " Drew Adams 2009-06-01 17:56 ` Chong Yidong 2009-05-25 8:18 ` Drew Adams 2009-05-25 20:46 ` Eli Zaretskii 2009-05-25 21:06 ` Drew Adams 2009-05-25 21:28 ` Eli Zaretskii 2009-05-25 2:57 ` Eli Zaretskii 2009-05-25 8:10 ` Miles Bader 2009-05-26 3:48 ` Chong Yidong 2009-05-24 23:53 ` David Reitter 2009-05-25 0:03 ` Lennart Borgman 2009-05-25 0:52 ` Drew Adams 2009-05-25 2:32 ` David Reitter 2009-05-25 8:35 ` Drew Adams 2009-05-25 2:26 ` Stephen J. Turnbull 2009-05-25 2:02 ` Stefan Monnier 2009-05-25 4:16 ` Alfred M. Szmidt 2009-05-25 8:16 ` Miles Bader 2009-05-25 9:29 ` Ulrich Mueller 2009-05-25 10:16 ` Miles Bader 2009-05-26 0:13 ` Richard M Stallman 2009-05-28 10:38 ` David Kastrup 2009-05-28 11:23 ` Bastien 2009-05-28 13:38 ` Werner LEMBERG 2009-05-29 4:39 ` rms 2009-05-26 9:52 ` Alan Mackenzie 2009-05-26 12:08 ` Lennart Borgman 2009-05-26 12:36 ` Rupert Swarbrick 2009-05-26 20:12 ` Alfred M. Szmidt 2009-05-25 8:17 ` Drew Adams 2009-05-25 13:29 ` Stefan Monnier 2009-05-25 17:51 ` Drew Adams 2009-05-25 21:14 ` Stefan Monnier 2009-05-25 21:26 ` Lennart Borgman 2009-05-26 6:56 ` Tassilo Horn 2009-05-26 11:37 ` Deniz Dogan 2009-05-26 12:24 ` Lennart Borgman 2009-05-26 12:42 ` David Reitter [not found] ` <m3hbz8c9qy.fsf@verona.se> 2009-05-26 12:58 ` David Reitter 2009-05-26 12:42 ` joakim 2009-05-26 13:54 ` Jason Rumney 2009-05-26 20:21 ` Lennart Borgman 2009-05-27 2:50 ` Miles Bader 2009-05-26 16:56 ` Stefan Monnier 2009-05-26 19:17 ` Tobias C. Rittweiler 2009-05-14 17:14 ` Bob Nnamtrop 2009-05-14 16:00 ` Shaun Johnson 2009-05-14 16:20 ` David Reitter 2009-05-14 18:17 ` Alan Mackenzie 2009-05-15 5:32 ` David Reitter 2009-05-15 7:18 ` Stephen J. Turnbull 2009-05-15 7:40 ` Stephen Berman 2009-05-15 7:58 ` Miles Bader 2009-05-15 14:14 ` Drew Adams 2009-05-15 14:21 ` Stephen Berman 2009-05-15 14:27 ` Miles Bader 2009-05-16 6:13 ` Stephen J. Turnbull 2009-05-17 3:53 ` Stefan Monnier
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.