bug#6028: 24.0.50; HELLO wants "C-x v v"

bug#6028: 24.0.50; HELLO wants "C-x v v"

[Eli Zaretskii]

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug.  If you can, give
a recipe starting from `emacs -Q':

Inside an Emacs bzr branch:

 emacs -Q
 C-h H
 C-x C-q

The last command causes Emacs to display the following bogus message:

  File is under version-control; use C-x v v to check in/out

The buffer becomes writable, nonetheless, as expected.

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
d:/gnu/bzr/emacs/trunk/etc/DEBUG.


In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
 of 2010-04-24 on HOME-C4E4A596F7
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4)'

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: ENU
  value of $XMODIFIERS: nil
  locale-coding-system: cp1255
  default enable-multibyte-characters: t

Major mode: Fundamental

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

Recent input:
C-h H C-x C-q M-x r e p o r t - e m a <tab> <retur
n>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Loading vc-bzr...done
View mode: type C-h for help, h for commands, q to quit.
File is under version-control; use C-x v v to check in/out

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr message rfc822 mml easymenu mml-sec
mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mailabbrev mail-utils gmm-utils mailheader
emacsbug thai-util thai-word mule-util lao-util regexp-opt vc-bzr sha1
hex-util view tooltip ediff-hook vc-hooks lisp-float-type mwheel dos-w32
disp-table ls-lisp w32-win w32-vars 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 button minibuffer faces cus-face files text-properties overlay
md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process multi-tty emacs)

bug#6028: 24.0.50; HELLO wants "C-x v v"

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

> This bug report will be sent to the Free Software Foundation,
> not to your local site managers!
> Please write in English if possible, because the Emacs maintainers
> usually do not have translators to read other languages for them.
>
> Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
> and to the gnu.emacs.bug news group.
>
> Please describe exactly what actions triggered the bug
> and the precise symptoms of the bug.  If you can, give
> a recipe starting from `emacs -Q':
>
> Inside an Emacs bzr branch:
>
>  emacs -Q
>  C-h H
>  C-x C-q
>
> The last command causes Emacs to display the following bogus message:
>
>   File is under version-control; use C-x v v to check in/out
>
> The buffer becomes writable, nonetheless, as expected.

If this is in an uninstalled tree, then C-h H opens the HELLO file that is managed by bzr.
The message that you see is what VC says when you try to make writable a file managed by VC.
Is that the issue here?
 

bug#6028: 24.0.50; HELLO wants "C-x v v"

[Eli Zaretskii]

> Cc: 6028@debbugs.gnu.org
> From: Dan Nicolaescu <dann@gnu.org>
> Date: Sat, 24 Apr 2010 15:32:58 -0400
> 
> If this is in an uninstalled tree, then C-h H opens the HELLO file that is managed by bzr.

Yes.

> The message that you see is what VC says when you try to make writable a file managed by VC.
> Is that the issue here?

The issue here is that the message is bogus.  The VCS that is used
does not require "C-x v v" to make the file writable, because the file
is already writable under bzr.  The _buffer_ is made read-only by
"C-h H", but the file is not.  Perhaps VC sees that the file is under
VCS control and the buffer is read-only, and erroneously deduces that
the VC backend is some VCS of the locking variety.  But that is false.

I think VC should not display this message if the backend is not a
locking VCS.

bug#6028: 24.0.50; HELLO wants "C-x v v"

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: 6028@debbugs.gnu.org
>> From: Dan Nicolaescu <dann@gnu.org>
>> Date: Sat, 24 Apr 2010 15:32:58 -0400
>> 
>> If this is in an uninstalled tree, then C-h H opens the HELLO file that is managed by bzr.
>
> Yes.
>
>> The message that you see is what VC says when you try to make writable a file managed by VC.
>> Is that the issue here?
>
> The issue here is that the message is bogus.  The VCS that is used
> does not require "C-x v v" to make the file writable, because the file
> is already writable under bzr.  The _buffer_ is made read-only by
> "C-h H", but the file is not.  Perhaps VC sees that the file is under
> VCS control and the buffer is read-only, and erroneously deduces that
> the VC backend is some VCS of the locking variety.  But that is false.
>
> I think VC should not display this message if the backend is not a
> locking VCS.

FWIW I agree.  I think this was discussed on the list a few times, but
I don't remember the conclusion....

But please retitle this bug to be more descriptive of the actual problem.

bug#6028: 24.0.50; HELLO wants "C-x v v"

[Stefan Monnier]

>> I think VC should not display this message if the backend is not a
>> locking VCS.
> FWIW I agree.  I think this was discussed on the list a few times, but
> I don't remember the conclusion....

Yes.  Especially since this message was there to help the transition
away from C-x C-q to C-x v v for vc-next-action.

Since this change was made for Emacs-22, I think we can simply drop this
message altogether for Emacs-24.


        Stefan

bug#6028: 24.0.50; HELLO wants "C-x v v"

[Eli Zaretskii]

> Cc: 6028@debbugs.gnu.org
> From: Dan Nicolaescu <dann@gnu.org>
> Date: Sat, 24 Apr 2010 23:05:17 -0400
> 
> But please retitle this bug to be more descriptive of the actual problem.

Retitled as:

   VC assumes files of read-only buffers are locked by a VCS

OK?

bug#6028: 24.0.50; HELLO wants "C-x v v"

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> I think VC should not display this message if the backend is not a
>>> locking VCS.
>> FWIW I agree.  I think this was discussed on the list a few times, but
>> I don't remember the conclusion....
>
> Yes.  Especially since this message was there to help the transition
> away from C-x C-q to C-x v v for vc-next-action.
>
> Since this change was made for Emacs-22, I think we can simply drop this
> message altogether for Emacs-24.

IMHO the message still makes sense for RCS (and similar systems) where
editing files requires an explicit checkout operation.

bug#6028: 24.0.50; HELLO wants "C-x v v"

[Eli Zaretskii]

> From: Dan Nicolaescu <dann@gnu.org>
> Date: Sun, 25 Apr 2010 15:20:52 -0400
> Cc: 6028@debbugs.gnu.org
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> >>> I think VC should not display this message if the backend is not a
> >>> locking VCS.
> >> FWIW I agree.  I think this was discussed on the list a few times, but
> >> I don't remember the conclusion....
> >
> > Yes.  Especially since this message was there to help the transition
> > away from C-x C-q to C-x v v for vc-next-action.
> >
> > Since this change was made for Emacs-22, I think we can simply drop this
> > message altogether for Emacs-24.
> 
> IMHO the message still makes sense for RCS (and similar systems) where
> editing files requires an explicit checkout operation.

Agreed.

bug#6028: 24.0.50; HELLO wants "C-x v v"

[Stefan Monnier]

> IMHO the message still makes sense for RCS (and similar systems) where
> editing files requires an explicit checkout operation.

If someone wants to write a patch that preserves the message for locking
VCSes, I'll be happy to integrate it,


        Stefan

bug#6028: 24.0.50; HELLO wants "C-x v v"

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Inside an Emacs bzr branch:
>
>  emacs -Q
>  C-h H
>  C-x C-q
>
> The last command causes Emacs to display the following bogus message:
>
>   File is under version-control; use C-x v v to check in/out
>
> The buffer becomes writable, nonetheless, as expected.

This bug seems to have disappeared now (because of the change I did last
week to `C-x C-q'?), so I'm closing this bug.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/