Received: (at 1948-quiet) by debbugs.gnu.org; 15 Jan 2010 19:37:03 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 15 14:37:02 2010 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1NVryf-0007hr-Mh for submit <at> debbugs.gnu.org; Fri, 15 Jan 2010 14:37:01 -0500 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from <rgm <at> gnu.org>) id 1NVryH-0007hK-A3 for 1948-quiet <at> debbugs.gnu.org; Fri, 15 Jan 2010 14:36:37 -0500 Received: from rgm by fencepost.gnu.org with local (Exim 4.69) (envelope-from <rgm <at> gnu.org>) id 1NVryD-0001RC-3Z for 1948-quiet <at> debbugs.gnu.org; Fri, 15 Jan 2010 14:36:33 -0500 From: Stephen Berman <Stephen.Berman <at> gmx.net> To: 1948-quiet <at> debbugs.gnu.org Subject: dabbrev-eliminate-newlines Date: Fri, 09 May 2008 14:01:53 +0200 Lines: 26 X-From-Line: emacs-devel-bounces+rgm=gnu.org <at> gnu.org Fri May 9 08:02:54 2008 Received: from mx10.gnu.org ([199.232.76.166]:45198) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from <emacs-devel-bounces+rgm=gnu.org <at> gnu.org>) id 1JuRJO-00018r-Kj for rgm <at> gnu.org; Fri, 09 May 2008 08:02:54 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from <emacs-devel-bounces+rgm=gnu.org <at> gnu.org>) id 1JuRK4-0004hR-2x for rgm <at> gnu.org; Fri, 09 May 2008 08:03:39 -0400 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on monty-python X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS, SPF_PASS,TRACKER_ID,UNPARSEABLE_RELAY autolearn=no version=3.1.0 Received: from lists.gnu.org ([199.232.76.165]:37976) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from <emacs-devel-bounces+rgm=gnu.org <at> gnu.org>) id 1JuRK3-0004h5-6t for rgm <at> gnu.org; Fri, 09 May 2008 08:03:35 -0400 Received: from localhost ([127.0.0.1]:49268 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JuRK2-0005SZ-TX for rgm <at> gnu.org; Fri, 09 May 2008 08:03:34 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JuRIl-0004q4-9d for emacs-devel <at> gnu.org; Fri, 09 May 2008 08:02:15 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JuRIh-0004kh-AI for emacs-devel <at> gnu.org; Fri, 09 May 2008 08:02:12 -0400 Received: from [199.232.76.173] (port=53978 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JuRIg-0004jq-N2 for emacs-devel <at> gnu.org; Fri, 09 May 2008 08:02:10 -0400 Received: from main.gmane.org ([80.91.229.2]:40017 helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from <ged-emacs-devel <at> m.gmane.org>) id 1JuRIg-0004Nt-7c for emacs-devel <at> gnu.org; Fri, 09 May 2008 08:02:10 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JuRIY-0007jH-SY for emacs-devel <at> gnu.org; Fri, 09 May 2008 12:02:02 +0000 Received: from i5387d8f6.versanet.de ([83.135.216.246]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <emacs-devel <at> gnu.org>; Fri, 09 May 2008 12:02:02 +0000 Received: from Stephen.Berman by i5387d8f6.versanet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <emacs-devel <at> gnu.org>; Fri, 09 May 2008 12:02:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ X-Debbugs-No-Ack: yes X-Complaints-To: usenet <at> ger.gmane.org X-Gmane-NNTP-Posting-Host: i5387d8f6.versanet.de X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel <at> gnu.org X-Mailman-Version: 2.1.5 Precedence: list X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) Message-ID: <e4fx679n3z.fsf <at> fencepost.gnu.org> User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -4.6 (----) X-Debbugs-Envelope-To: 1948-quiet X-Mailman-Approved-At: Fri, 15 Jan 2010 14:37:01 -0500 X-BeenThere: debbugs-submit <at> debbugs.gnu.org List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Sender: debbugs-submit-bounces <at> debbugs.gnu.org Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org X-Spam-Score: -4.6 (----) [ resent from http://lists.gnu.org/archive/html/emacs-devel/2008-05/msg00619.html ] If you have a buffer with this text: ------8<------ First. Second. ------>8------ and later in the buffer type `M-/ SPC M-/', Emacs (started with -Q) inserts this: ------8<------ First. Second ------>8------ It was only by stepping through Dabbrev expansion with Edebug that I learned that this behavior is due to dabbrev-eliminate-newlines, in particular that it is t by default. Before that I wasn't even aware of this variable. I think at the very least dabbrev-eliminate-newlines should be documented in (emacs)Dabbrev Customization, and its doc string should reflect the above behavior (currently it reads "*Non-nil means dabbrev should not insert newlines. Instead it converts them to spaces."). It might also be a good idea to go a step further and separate the handling of newlines and spaces, letting them be independently customizable. Steve Berman
Received: (at 1948) by emacsbugs.donarmstrong.com; 19 Jan 2009 14:54:30 +0000 From cyd <at> stupidchicken.com Mon Jan 19 06:54:30 2009 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: * X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=1.0 required=4.0 tests=GMAIL autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 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 <at> emacsbugs.donarmstrong.com>; Mon, 19 Jan 2009 06:54:28 -0800 Received: by cyd.mit.edu (Postfix, from userid 1000) id C23BE57E18A; Mon, 19 Jan 2009 09:54:48 -0500 (EST) From: Chong Yidong <cyd <at> stupidchicken.com> To: Lars Lindberg <Lars.Lindberg <at> sypro.cap.se> Cc: 1948 <at> debbugs.gnu.org, Peter Tury <tury.peter <at> gmail.com> Subject: Re: confusion and bug in dabbrev.el Date: Mon, 19 Jan 2009 09:54:48 -0500 Message-ID: <871vuzpcqv.fsf <at> cyd.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi Lars, could you take a look at this bug report for dabbrev? Thanks. Peter Tury <tury.peter <at> gmail.com> 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)
Chong Yidong <cyd <at> stupidchicken.com>:Emacs Bugs <bug-gnu-emacs <at> gnu.org>.
Full text available.bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>:bug#1948; Package emacs.
Full text available.
Received: (at submit) by emacsbugs.donarmstrong.com; 18 Jan 2009 19:38:54 +0000
From tury.peter <at> gmail.com Sun Jan 18 11:38:54 2009
X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02
(2008-06-10) on rzlab.ucr.edu
X-Spam-Level:
X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available.
hammytokens:Tokens not available.
X-Spam-Status: No, score=0.0 required=4.0 tests=none autolearn=ham
version=3.2.5-bugs.debian.org_2005_01_02
Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10])
by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n0IJcofv022837
for <submit <at> emacsbugs.donarmstrong.com>; Sun, 18 Jan 2009 11:38:52 -0800
Received: from mail.gnu.org ([199.232.76.166]:47988 helo=mx10.gnu.org)
by fencepost.gnu.org with esmtp (Exim 4.67)
(envelope-from <tury.peter <at> gmail.com>)
id 1LOdSV-00067F-SG
for emacs-pretest-bug <at> gnu.org; Sun, 18 Jan 2009 14:37:23 -0500
Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60)
(envelope-from <tury.peter <at> gmail.com>)
id 1LOdTt-0006xZ-EQ
for emacs-pretest-bug <at> gnu.org; Sun, 18 Jan 2009 14:38:50 -0500
Received: from mail-bw0-f17.google.com ([209.85.218.17]:58263)
by monty-python.gnu.org with esmtp (Exim 4.60)
(envelope-from <tury.peter <at> gmail.com>)
id 1LOdTs-0006xN-RT
for emacs-pretest-bug <at> gnu.org; Sun, 18 Jan 2009 14:38:49 -0500
Received: by bwz10 with SMTP id 10so145665bwz.18
for <emacs-pretest-bug <at> gnu.org>; Sun, 18 Jan 2009 11:38:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=domainkey-signature:mime-version:received:date:message-id:subject
:from:to:content-type:content-transfer-encoding;
bh=tnzVpj/Uz59Sg1Nwk1pKLZYPS4etkbnVEAMkP8PbIN8=;
b=UH5QRrzahc4XRGyqh3QPqr5E6UCkMGPtozu0P+ayEJwlcGcXntS8lJCsVufnYyoJZO
tpjY9zSFu84p6NBUyww/fcB2bFNAMbzXOTr8ZXuu0SDEqc3dl/JVjk/nVUvtfUtLIVwQ
TVSLbCFA6moLEJkwDBA7aBucNja4w7l2UNGtI=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=gamma;
h=mime-version:date:message-id:subject:from:to:content-type
:content-transfer-encoding;
b=L8ImhbE+pw/WcrQeMLjcQvzw/xrw4TSuSKnHJmF24YnoL9+TZ6S6H3PfnSHup4+XQT
3fbFoDP0BIwzKaZiAFyyUsDBwAvs5GssFXnO9pwschePEwY1ap0Ycs+sM5JmWl4RAi3i
rS6cgCtPXuxbbUDawQz8doLeTE1g+D8zCmo3A=
MIME-Version: 1.0
Received: by 10.103.106.1 with SMTP id i1mr170895mum.47.1232307473849; Sun, 18
Jan 2009 11:37:53 -0800 (PST)
Date: Sun, 18 Jan 2009 20:37:53 +0100
Message-ID: <b5accf970901181137g45f24159pa31b6b0b7a8c0fec <at> mail.gmail.com>
Subject: confusion and bug in dabbrev.el
From: Peter Tury <tury.peter <at> gmail.com>
To: emacs-pretest-bug <at> gnu.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2)
Hi,
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)
Could you please fix these bugs in dabbrev.el.
Thanks,
P
Peter Tury <tury.peter <at> gmail.com>:Emacs Bugs <bug-gnu-emacs <at> gnu.org>.
Full text available.bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>:bug#1948; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.