From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.bugs Subject: bug#1948: confusion and bug in dabbrev.el Date: Mon, 19 Jan 2009 09:54:48 -0500 Message-ID: <871vuzpcqv.fsf@cyd.mit.edu> Reply-To: Chong Yidong , 1948@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1232377850 5463 80.91.229.12 (19 Jan 2009 15:10:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 19 Jan 2009 15:10:50 +0000 (UTC) Cc: 1948@emacsbugs.donarmstrong.com, Peter Tury To: Lars Lindberg Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jan 19 16:12:02 2009 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1LOvn6-0004pI-ET for geb-bug-gnu-emacs@m.gmane.org; Mon, 19 Jan 2009 16:11:53 +0100 Original-Received: from localhost ([127.0.0.1]:59013 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LOvlp-0005Bz-B9 for geb-bug-gnu-emacs@m.gmane.org; Mon, 19 Jan 2009 10:10:33 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LOvhW-0003EY-Op for bug-gnu-emacs@gnu.org; Mon, 19 Jan 2009 10:06:06 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LOvhV-0003DR-UC for bug-gnu-emacs@gnu.org; Mon, 19 Jan 2009 10:06:06 -0500 Original-Received: from [199.232.76.173] (port=33498 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LOvhV-0003DB-OP for bug-gnu-emacs@gnu.org; Mon, 19 Jan 2009 10:06:05 -0500 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:44702) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LOvhV-0001x6-5k for bug-gnu-emacs@gnu.org; Mon, 19 Jan 2009 10:06:05 -0500 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0JF3RO0024863; Mon, 19 Jan 2009 07:03:27 -0800 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id n0JF04Sh023796; Mon, 19 Jan 2009 07:00:04 -0800 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: Chong Yidong Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Mon, 19 Jan 2009 15:00:03 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 1948 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 1948-submit@emacsbugs.donarmstrong.com id=B1948.123237687022321 (code B ref 1948); Mon, 19 Jan 2009 15:00:03 +0000 Original-Received: (at 1948) by emacsbugs.donarmstrong.com; 19 Jan 2009 14:54:30 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from cyd.mit.edu (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0JEsRRw022315 for <1948@emacsbugs.donarmstrong.com>; Mon, 19 Jan 2009 06:54:28 -0800 Original-Received: by cyd.mit.edu (Postfix, from userid 1000) id C23BE57E18A; Mon, 19 Jan 2009 09:54:48 -0500 (EST) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Resent-Date: Mon, 19 Jan 2009 10:06:06 -0500 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:24280 Archived-At: Hi Lars, could you take a look at this bug report for dabbrev? Thanks. Peter Tury wrote: > 1) in `dabbrev--substitute-expansion' (in dabbrev.el), `t' value of > variable `dabbrev-eliminate-newlines' causes elimination of spaces > (and tabs) as well. Thus its name and its functionality are not really > compatible. In the best case it should have a better name > (`dabbrev-eliminate-whitespace'??), but as a minimum, its > documentation should be improved and mention elimination of tabs and > spaces as well, I think. > Moreover, contrary to its documentation again, it doesn't "converts > them [=newlines] to spaces": instead it just removes them. So its > documentation should be fixed here as well in my opinion. > 2) However, the more serious problem is that it "forgets" such > eliminations when it searches for `old' expansion in case of repeated > calls of `dabbrev-expand' (i.e. when the check "(eq last-command > this-command)" in this function results t) what results in weird text > in some cases. To check this: > * customize `dabbrev-abbrev-char-regexp' to be a period (.) Thus > dabbrev-expand will replace whole lines. > * type these two lines into a buffer (with double spaces between the > words!): > one tt > one ww > * then type "on" in the next line and call `dabbrev-expand' two times. > Your buffer should look like this at the end: > one tt > one ww > one tt > But instead you will get this: > one tt > one tt > one ww > What seems to be a complete mess. > As I see the key here is the search for `old' at the end of > `dabbrev--substitute-expansion' (`old' is the first parameter of this > function). If I replace the following original code: > " (if old > (save-excursion > (search-backward old))" > to be > " (if old > ;; Convert whitespace to single spaces. > (progn > (if dabbrev-eliminate-newlines > (let ((pos > (if (equal abbrev " ") 0 (length abbrev)))) > ;; If ABBREV is real, search after the end of it. > ;; If ABBREV is space and we are copying > successive words, > ;; search starting at the front. > (while (string-match "[\n \t]+" > old pos) > (setq pos (1+ > (match-beginning 0))) > (setq old > (replace-match > " " nil > nil > old))))) > (save-excursion > (search-backward > old)))" > my test (above) works well. Here I simply copy-pasted (...) original > whitespace-elimination code from few lines above, so this is clearly > not a nice solution: it just shows a way of fixing the broken > functionality. > (I "reported" this problem in gnu.emacs.help with the subject "strange > dabbrev for whole lines and double spaces in cvs Emacs 23" on > Jan.8.2009)