Mercurial version 1.9 Windows 7 With .hgrc "editor = vim", it is no longer possible to sensibly edit commit comments. When committing from the console, hg seems to open vim (the console icon changes from command prompt to vim), but the editor is not visible from the console, meaning that you have to edit the comment 'blind'. When editing is complete, the console reports "Vim: Warning: Output is not to a terminal" On hg version 1.7.5 it was possible to edit comments successfully using vim. A workaround is .hgrc "editor = gvim", but this opens vim in a new window, which is not quite as nice, as one is then in another window. Thanks.
Probably related to http://selenic.com/repo/hg/rev/bcc1a9fd0b8c # HG changeset patch # User Idan Kamara <idankk86@gmail.com> # Date 1308924277 -10800 # Branch stable # Node ID bcc1a9fd0b8c71267b793da7c1f056d94539a363 # Parent b39ed8c8e5e5c02ea8d38075cda32aac58d50cb2 ui: use ui out descriptor when calling util.system diff --git a/mercurial/ui.py b/mercurial/ui.py --- a/mercurial/ui.py +++ b/mercurial/ui.py @@ -629,7 +629,8 @@ util.system("%s \"%s\"" % (editor, name), environ={'HGUSER': user}, - onerr=util.Abort, errprefix=_("edit failed")) + onerr=util.Abort, errprefix=_("edit failed"), + out=self.fout) f = open(name) t = f.read()
Yeah, this and the filemerge issue is a manifestation of hitting the else in util.system: if out is None or out == sys.__stdout__: rc = subprocess.call(cmd, shell=True, close_fds=closefds, env=env, cwd=cwd) else: proc = subprocess.Popen(cmd, shell=True, close_fds=closefds, env=env, cwd=cwd, stdout=subprocess.PIPE, stderr=subprocess.STDOUT) for line in proc.stdout: out.write(line) proc.wait() rc = proc.returncode Which happens because we wrap sys.stdout in Windows: http://selenic.com/repo/hg/file/09c9c120a817/mercurial/windows.py#l65 So sys.stdout != sys__stdout__.
I think any of these should solve both issues: diff -r a56b3106345d mercurial/util.py --- a/mercurial/util.py Tue Jul 05 14:36:33 2011 +0300 +++ b/mercurial/util.py Thu Jul 07 14:51:17 2011 +0300 @@ -354,7 +354,7 @@ env = dict(os.environ) env.update((k, py2shell(v)) for k, v in environ.iteritems()) env['HG'] = hgexecutable() - if out is None or out == sys.__stdout__: + if out is None or out == sys.stdout: rc = subprocess.call(cmd, shell=True, close_fds=closefds, env=env, cwd=cwd) else: diff -r a56b3106345d mercurial/windows.py --- a/mercurial/windows.py Tue Jul 05 14:36:33 2011 +0300 +++ b/mercurial/windows.py Thu Jul 07 14:51:17 2011 +0300 @@ -62,7 +62,7 @@ self.close() raise IOError(errno.EPIPE, 'Broken pipe') -sys.stdout = winstdout(sys.stdout) +sys.__stdout__ = sys.stdout = winstdout(sys.stdout) def _is_win_9x(): '''return true if run on windows 95, 98 or me.'' but I don't know if this is the answer. Also I can't remember if there was any reason to compare to sys.__stdout__ in the first place instead of sys.stdout.
This is a 1.9 regression - setting priority to urgent
Indeed. Patches to the mailing list, please.
Fixed by http://selenic.com/repo/hg/rev/d2d592718e90 Idan Kamara <idankk86@gmail.com> win32: assign winstdout to sys.__stdout__ as well (issue2888) (please test the fix)
A quick compile and test shows that this resolves the issue for using windows console based editors to enter commit messages. I tested with emacs -nw and vim. I did not perform an additional regression testing for the issue.
Not resolved. If you use util.system() as opening editor for 'hg commit', you can do it correctly, But if it is used for extension, it will get failure. On windows, parameter 'out' of util.system() is asigned as instance of 'mercurial.windows.winstdout'. And sys.__stdout__ in util.py not asigned as winstdout. Thus, ui.edit() should pass 'out' as None! diff -r ef43610a4cce mercurial/ui.py --- a/mercurial/ui.py Sat Aug 20 21:47:10 2011 +0100 +++ b/mercurial/ui.py Tue Aug 23 20:28:08 2011 +0900 @@ -646,8 +646,7 @@ util.system("%s \"%s\"" % (editor, name), environ={'HGUSER': user}, - onerr=util.Abort, errprefix=_("edit failed"), - out=self.fout) + onerr=util.Abort, errprefix=_("edit failed")) f = open(name) t = f.read()
Not sure I'm getting the problem. > And sys.__stdout__ in util.py not asigned as winstdout. In 1.9.1 it is, see a few messages down: win32: assign winstdout to sys.__stdout__ as well > Thus, ui.edit() should pass 'out' as None! Setting out to None will break if self.fout != sys.stdout (which is the case for the command server).
@idank > win32: assign winstdout to sys.__stdout__ as well No, I add "print out" and "print sys.__stdout__" in above of util.py:413 . out: mercurial.windows.winstdout ... sys.__stdout__: open file 'stdout', mode 'w' at 0xb741d078 Then... > Setting out to None will break if self.fout != sys.stdout (which is the case for the command server). it don't pass "out == sys.__stdout__".
I don't have a Windows box at hand to test, but this doesn't make sense according to this: http://hg.intevation.org/mercurial/file/4a43e23b8c55/mercurial/windows.py#l65 Are you sure you're running 1.9.1?
> Are you sure you're running 1.9.1? Yes. sys.__stdout__ is wrapped with winstdout at the line you said. And the __stdout__ is passed to self.fout. However, I add "print out" and "print sys.__stdout__" at: http://hg.intevation.org/mercurial/file/4a43e23b8c55/mercurial/util.py#l357 then, out is typed as mercurial.windows.winstdout, and sys.__stdout__ is typed as "open file". Probably, "import windows as platform" is not loaded immediately. Now, I'm not in office so I don't have windows box. Then, I'm not sure, import windows import platform if "mercurial.windows" in sys.modules: imp.reload(sys.modules["mercurial.windows"]) This may fix it. (I say: I'm not sure)
Hmm, below's patch (I said) does not work correctly. Do you have any ideas?
Is this still broken?
> Is this still broken? Yes, problem does not fixed.
The simple case that started with the editing of commit messages with console based editors on Windows is fixed. However, according to the other user there is some sort of problem with extensions. I have not encountered the problem he explains. On Sep 12, 2011, at 6:17 PM, Matt Mackall <bugs@mercurial.selenic.com> wrote: > > Matt Mackall <mpm@selenic.com> added the comment: > > Is this still broken? > > ____________________________________________________ > Mercurial issue tracker <bugs@mercurial.selenic.com> > <http://mercurial.selenic.com/bts/issue2888> > ____________________________________________________
Alright, closing the bug described in the title. Mattn, please open a new bug for your issue including telling us how to reproduce it.
--- Bug imported by bugzilla@serpentine.com 2012-05-12 09:21 EDT --- This bug was previously known as _bug_ 2888 at http://mercurial.selenic.com/bts/issue2888