bug#5106: 23.1.50; global-visual-line-mode breaks find-file minibuffer usage

bug#5106: 23.1.50; global-visual-line-mode breaks find-file minibuffer usage

[Matthew Dempsky]

Normally pressing C-a while using find-file will place the point
immediately after the "Find file: " prompt, but after turning on
global-visual-line-mode, C-a will place the point at the start of the
minibuffer; i.e., before the "Find file: " prompt.


In GNU Emacs 23.1.50.1 (i386-apple-darwin9.8.0, NS apple-appkit-949.54)
 of 2009-12-02 on admins-macbook-pro-2.local
Windowing system distributor `Apple', version 10.3.949
configured using `configure  '--with-ns' '--without-x''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  global-visual-line-mode: t
  visual-line-mode: t
  transient-mark-mode: t

Recent input:
C-x C-f C-a C-g M-: ( g l o b a l - v i s u a l - l
i n e - m o d e SPC 1 ) <return> C-x C-f C-a C-g M-`
h s

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Quit
t
Quit

Load-path shadows:
None found.

Features:
(shadow mail-extr message ecomplete rfc822 mml mml-sec password-cache
mm-decode mm-bodies mm-encode mailcap mail-parse rfc2231 rfc2047 rfc2045
qp ietf-drums mailabbrev nnheader gnus-util netrc time-date mm-util
mail-prsvr gmm-utils wid-edit mailheader canlock sha1 hex-util hashcash
mail-utils emacsbug sendmail regexp-opt help-mode view tmm electric
tooltip ediff-hook vc-hooks lisp-float-type mwheel ns-win easymenu
tool-bar dnd fontset image fringe lisp-mode register page menu-bar
rfn-eshadow timer select scroll-bar mldrag mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev loaddefs button
minibuffer faces cus-face text-properties overlay md5 base64 format env
code-pages mule custom widget hashtable-print-readable backquote
make-network-process ns multi-tty emacs)

bug#5106: marked as done (23.1.50; global-visual-line-mode breaks find-file minibuffer usage)

[Emacs bug Tracking System]

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

Your message dated Sun, 06 Dec 2009 13:49:52 -0500
with message-id <87r5r80wfj.fsf@stupidchicken.com>
and subject line Re: 23.1.50; global-visual-line-mode breaks find-file minibuffer usage
has caused the Emacs bug report #5106,
regarding 23.1.50; global-visual-line-mode breaks find-file minibuffer usage
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com
immediately.)


-- 
5106: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=5106
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 4424 bytes --]

From: Matthew Dempsky <matthew@dempsky.org>
To: emacs-pretest-bug@gnu.org
Subject: 23.1.50; global-visual-line-mode breaks find-file minibuffer usage
Date: Wed, 2 Dec 2009 11:31:01 -0800
Message-ID: <d791b8790912021131p160c8d0bqf9c9e8567dc2a5b5@mail.gmail.com>

Normally pressing C-a while using find-file will place the point
immediately after the "Find file: " prompt, but after turning on
global-visual-line-mode, C-a will place the point at the start of the
minibuffer; i.e., before the "Find file: " prompt.


In GNU Emacs 23.1.50.1 (i386-apple-darwin9.8.0, NS apple-appkit-949.54)
 of 2009-12-02 on admins-macbook-pro-2.local
Windowing system distributor `Apple', version 10.3.949
configured using `configure  '--with-ns' '--without-x''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  global-visual-line-mode: t
  visual-line-mode: t
  transient-mark-mode: t

Recent input:
C-x C-f C-a C-g M-: ( g l o b a l - v i s u a l - l
i n e - m o d e SPC 1 ) <return> C-x C-f C-a C-g M-`
h s

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Quit
t
Quit

Load-path shadows:
None found.

Features:
(shadow mail-extr message ecomplete rfc822 mml mml-sec password-cache
mm-decode mm-bodies mm-encode mailcap mail-parse rfc2231 rfc2047 rfc2045
qp ietf-drums mailabbrev nnheader gnus-util netrc time-date mm-util
mail-prsvr gmm-utils wid-edit mailheader canlock sha1 hex-util hashcash
mail-utils emacsbug sendmail regexp-opt help-mode view tmm electric
tooltip ediff-hook vc-hooks lisp-float-type mwheel ns-win easymenu
tool-bar dnd fontset image fringe lisp-mode register page menu-bar
rfn-eshadow timer select scroll-bar mldrag mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev loaddefs button
minibuffer faces cus-face text-properties overlay md5 base64 format env
code-pages mule custom widget hashtable-print-readable backquote
make-network-process ns multi-tty emacs)


[-- Attachment #3: Type: message/rfc822, Size: 1863 bytes --]

From: Chong Yidong <cyd@stupidchicken.com>
To: Matthew Dempsky <matthew@dempsky.org>
Cc: 5106-done@emacsbugs.donarmstrong.com
Subject: Re: 23.1.50; global-visual-line-mode breaks find-file minibuffer usage
Date: Sun, 06 Dec 2009 13:49:52 -0500
Message-ID: <87r5r80wfj.fsf@stupidchicken.com>

> Normally pressing C-a while using find-file will place the point
> immediately after the "Find file: " prompt, but after turning on
> global-visual-line-mode, C-a will place the point at the start of the
> minibuffer; i.e., before the "Find file: " prompt.

I guess beginning-of-visual-line should constrain to field boundaries,
like move-beginning-of-line.  I've checked in a fix.  Thanks.

bug#5106: 23.1.50; global-visual-line-mode breaks find-file minibuffer usage

[Matthew Dempsky]

On Sun, Dec 6, 2009 at 10:49 AM, Chong Yidong <cyd@stupidchicken.com> wrote:
> I guess beginning-of-visual-line should constrain to field boundaries,
> like move-beginning-of-line.  I've checked in a fix.  Thanks.

I can confirm C-a is fixed, but I just noticed C-b still moves past
field boundaries too.

bug#5106: 23.1.50; global-visual-line-mode breaks find-file minibuffer usage

[Matthew Dempsky]

On Mon, Dec 7, 2009 at 1:50 PM, Matthew Dempsky <matthew@dempsky.org> wrote:
> I can confirm C-a is fixed, but I just noticed C-b still moves past
> field boundaries too.

Actually, this happens regardless of whether visual-line-mode is in
use, though I believe C-b used to stop at the prompt.  Maybe this was
an intentional change?  (If so, I wouldn't say I'm opposed; just
making sure it's not an inadvertent regression.)

bug#5106: 23.1.50; global-visual-line-mode breaks find-file minibuffer usage

[Stefan Monnier]

>> I can confirm C-a is fixed, but I just noticed C-b still moves past
>> field boundaries too.

> Actually, this happens regardless of whether visual-line-mode is in
> use, though I believe C-b used to stop at the prompt.  Maybe this was
> an intentional change?  (If so, I wouldn't say I'm opposed; just
> making sure it's not an inadvertent regression.)

C-b and C-f have always ignored field boundaries, AFAIK.


        Stefan

bug#5106: 23.1.50; global-visual-line-mode breaks find-file minibuffer usage

[Lennart Borgman]

On Tue, Dec 8, 2009 at 3:35 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>> I can confirm C-a is fixed, but I just noticed C-b still moves past
>>> field boundaries too.
>
>> Actually, this happens regardless of whether visual-line-mode is in
>> use, though I believe C-b used to stop at the prompt.  Maybe this was
>> an intentional change?  (If so, I wouldn't say I'm opposed; just
>> making sure it's not an inadvertent regression.)
>
> C-b and C-f have always ignored field boundaries, AFAIK.


Are they just disobeying, or?

bug#5106: 23.1.50; global-visual-line-mode breaks find-file minibuffer usage

[Matthew Dempsky]

On Mon, Dec 7, 2009 at 6:35 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> C-b and C-f have always ignored field boundaries, AFAIK.

Ah, that's possible.  I mistakenly assumed Aquamacs's behavior
regarding this was the default in GNU Emacs too, but I see now that
part of aquamacs.el is:

  (setq minibuffer-prompt-properties
	(plist-put minibuffer-prompt-properties
		   'point-entered 'minibuffer-avoid-prompt))

Sorry for the bad assumption.

bug#5106: 23.1.50; global-visual-line-mode breaks find-file

[Stefan Monnier]

>>>> I can confirm C-a is fixed, but I just noticed C-b still moves past
>>>> field boundaries too.
>>> Actually, this happens regardless of whether visual-line-mode is in
>>> use, though I believe C-b used to stop at the prompt.  Maybe this was
>>> an intentional change?  (If so, I wouldn't say I'm opposed; just
>>> making sure it's not an inadvertent regression.)
>> C-b and C-f have always ignored field boundaries, AFAIK.

> Are they just disobeying, or?

No, it's just that without it, it can become too difficult to escape
the field.


        Stefan