From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: RJD <3246251196ryan@gmail.com> Newsgroups: gmane.emacs.help Subject: Re: bizare VC mode issue in emacs Date: Thu, 11 Dec 2014 16:12:02 +0000 (UTC) Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1418314380 18974 80.91.229.3 (11 Dec 2014 16:13:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 11 Dec 2014 16:13:00 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Dec 11 17:12:52 2014 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xz6MF-0005H5-Qn for geh-help-gnu-emacs@m.gmane.org; Thu, 11 Dec 2014 17:12:51 +0100 Original-Received: from localhost ([::1]:52286 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xz6MF-0006hg-Bd for geh-help-gnu-emacs@m.gmane.org; Thu, 11 Dec 2014 11:12:51 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33534) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xz6Lr-0006ZP-KB for help-gnu-emacs@gnu.org; Thu, 11 Dec 2014 11:12:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xz6Lk-0006dM-4L for help-gnu-emacs@gnu.org; Thu, 11 Dec 2014 11:12:27 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:49178) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xz6Lj-0006d7-Tm for help-gnu-emacs@gnu.org; Thu, 11 Dec 2014 11:12:20 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Xz6Lg-0004pq-Dl for help-gnu-emacs@gnu.org; Thu, 11 Dec 2014 17:12:16 +0100 Original-Received: from http-v.fe.bosch.de ([194.39.218.10]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 11 Dec 2014 17:12:16 +0100 Original-Received: from 3246251196ryan by http-v.fe.bosch.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 11 Dec 2014 17:12:16 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 73 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 194.39.218.10 (Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:101521 Archived-At: RJD <3246251196ryan gmail.com> writes: > > This seems to be the most bizarre anomaly I have ever encountered. Here is > the scenario: > > I am working. I make a change to a source file. I press `C-x v v` which > takes me to the *vc-log* buffer where I can enter a log message. In that > buffer I type something like this: > > TICKET: 123 > SUMMARY: implemented new function > REVIEWERS: richard.stallman > > And then I press `C-c C-c` which then goes ahead and commits the message. > Now, when I view the log message the whole thing truncates to ONLY the first > line. It is as if there was a cutoff point at the first newline character. I > have even went into the /lisp/vc-*.el file to do some debugging to print to > the *Message* buffer the value of `comment` - which itself tells me is the > whole thing, i.e.: > > TICKET: 123 > SUMMARY: implemented new function > REVIEWERS: richard.stallman > > But no matter what I do I only get the first line of the commit message. > > HOWEVER, on an alternate machine (that is, I use two machines at work and > used to work on this older machine I am about to talk of) if I use the EXACT > same version of emacs `(GNU Emacs 24.3.1 (i386-mingw-nt6.1.7601) > of 2013-03-17 on MARVIN)` I can check out the exact same repo in SVN, make > a change to the same file and do the process again. And - bang - it commits > and when I run an svn log --limit 1 - I get the entire commit message WITH > the newline characters. > > In order to iron out any possible variables, I have ran emacs -q on both the > machines. I have ran a diff on all el/elc files in /lisp/ in both emacs > installation directories. I have verified the versions of emacs with `C-h > C-a`. I have also ensured the the SVN binary produces the same result with > svn --version: sure enough, on both systems they are exactly the same version. > > Am I going mad? > > ** Windows 7 (unfortunately at work). The machine where I am only getting > one liners is a HP Z420, the other one is not. It is just a HP EliteDesk - > again, running the same operating system and same instruction-set processor etc. > > Bizarre issue solved: Yes, I was running two machines with exactly the same processor instruction set. The same version of emacs; non-different el and elc files. The same version of SVN! Everything. The only difference was this: On the machine which - yesterday (i.e. before this was solved) - produced multiple lines I had - on my $PATH - a location which pointed to a directory containing a windows shortcut named svn.exe; it pointed to the actual binary used. Now, on the machine which did not allow multi-line I did not have this location on my $PATH. Instead it just had the location of the directory containing the actual svn binary (though, this was also the case for the machine allowing multi-line, but because the directory containing the shortcut preceded the "actual" binary-directory, the shortcut gets accessed first; proved by using "which svn"). So, for some reason when using the svn binary directly I could not do multi-line. But, when using the shortcut which points to that binary anyway multi-line was not allowed. I just always treated windows shortcuts like symbolic links, but perhaps something else is going on here. Anyway, solved.