From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bob Nnamtrop Newsgroups: gmane.emacs.bugs Subject: bug#5805: 23.3 abbrev-insert needs a limited save-excursion Date: Thu, 7 Jul 2011 15:46:02 -0600 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1310075257 17130 80.91.229.12 (7 Jul 2011 21:47:37 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 7 Jul 2011 21:47:37 +0000 (UTC) Cc: 5805@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jul 07 23:47:33 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QewQ1-0005ht-Ch for geb-bug-gnu-emacs@m.gmane.org; Thu, 07 Jul 2011 23:47:33 +0200 Original-Received: from localhost ([::1]:52158 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QewQ0-0005kz-3x for geb-bug-gnu-emacs@m.gmane.org; Thu, 07 Jul 2011 17:47:32 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:55975) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QewPd-0005jh-Er for bug-gnu-emacs@gnu.org; Thu, 07 Jul 2011 17:47:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QewPb-0001CH-Lc for bug-gnu-emacs@gnu.org; Thu, 07 Jul 2011 17:47:09 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:49116) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QewPb-0001C7-HM for bug-gnu-emacs@gnu.org; Thu, 07 Jul 2011 17:47:07 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1QewPb-0004i7-0H; Thu, 07 Jul 2011 17:47:07 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Bob Nnamtrop Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 07 Jul 2011 21:47:06 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 5805 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 5805-submit@debbugs.gnu.org id=B5805.131007517217950 (code B ref 5805); Thu, 07 Jul 2011 21:47:06 +0000 Original-Received: (at 5805) by debbugs.gnu.org; 7 Jul 2011 21:46:12 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QewOg-0004fR-Ok for submit@debbugs.gnu.org; Thu, 07 Jul 2011 17:46:11 -0400 Original-Received: from mail-vw0-f44.google.com ([209.85.212.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QewOe-0004f9-CP for 5805@debbugs.gnu.org; Thu, 07 Jul 2011 17:46:09 -0400 Original-Received: by vws12 with SMTP id 12so1042928vws.3 for <5805@debbugs.gnu.org>; Thu, 07 Jul 2011 14:46:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=EcY1ix+DL5av49AFWmyz2Ij5LIRtH3xQuYSoXfPWQG8=; b=j9M0uFupsbP1z7dkVWj7erLDRRJhaMja3ietYO7f6+eAEkGP9FfI/C9fTUvv1VoUqZ Vv6l+yMdaa4Tf+2yWBH7O/BasByQxBoDgxWGE/DoWpwvem8A4Yb0Q2U0sEk1VOhUQNvX e/8MYPQ23FbclleKgTyHu/4vpv34PVE9g354A= Original-Received: by 10.52.108.231 with SMTP id hn7mr1816118vdb.283.1310075162341; Thu, 07 Jul 2011 14:46:02 -0700 (PDT) Original-Received: by 10.52.184.34 with HTTP; Thu, 7 Jul 2011 14:46:02 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Thu, 07 Jul 2011 17:47:07 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:48217 Archived-At: On Thu, Jul 7, 2011 at 2:59 PM, Stefan Monnier w= rote: > tags 5805 patch > thanks > >> I agree with the original poster that a save-excursion is needed in >> abbrev-expand and by making its scope limited (see below) it will not >> interfere with abbrevs that want to change point. The reason I find it >> annoying the way it is now is that some modes (e.g., idlwave) use >> abbrev's extensively to change keywords (e.g. capitalize them). These >> are defined without the leading "\". So if I am any number of lines >> with only whitespace below a keyword defined in this way (e.g. endfor) >> and run expand-abbrev then the point moves even if no visible change >> takes place. This is a VERY common occurrence for me since in viper >> mode changing from insert to vi mode runs expand-abbrev! Placing the >> save-excursion just around the part of abbrev-insert that actually >> expands the abbrev fixes this problem and does not limit abbrev's from >> moving the point (idlwave does this extensively as well and I've >> tested that it is not impacted). > > Hmm... sounds like an interesting solution. =A0I'll take a closer look an= d > get back to you. =A0Thank you. > >> Here is the diff against the >> abbrev.el in emacs 23.3 (note that whitespace not adjusted). > > Highly appreciated. > > > =A0 =A0 =A0 =A0Stefan > I've been thinking about this some more and while I think the save-excursion solution mentioned above is not a bad idea, perhaps fixing this at the heart of the problem would be better. The basic problem is that changing state from viper insert state to viper vi state causes abbrev's to be expanded if there is any amount of white space between the point and an abbrev. This differs from the rules of e.g. "space" causing an abbrev to be expanded. A space (or comma, ret, etc) will only cause an abbrev to expand if it is immediately after an abbrev. If changing state from viper insert to vi state followed the same rules then everything would work nicer. For example, what commonly happens to me is I type an abbrev (say \ef) then return. In idlwave mode this causes \ef to be expanded to endfor and the cursor blinks to the corresponding begin and back. Now if I type a return and a tab to indent and then exit viper insert state abbrev-expand is run again (since endfor is also an abbrev, for itself) and the cursor again blinks to the begin and the cursor is left on the endfor. The save-excursion fix only fixes where the cursor is left. The blinking still occurs. Thus it is only a partial fix. The rule should be "if a space (or any other non-word character) would not cause an abbrev to expand then exiting from viper insert state should not cause an abbrev to expand". And vise-versa. This would fix all the issues I have with abbrev. I've been trying to implement this today but without success. I know why changing viper state causes abbrev to run. There is a line (if abbrev-mode (expand-abbrev)) in viper-change-state-to-vi in viper-cmd.el which causes it. What I cannot figure out is what causes a normal space (or comma, ret, etc) to make an abbrev expand when one is directly after an abbrev (and when the point is one space past the abbrev another space does not cause an expansion, unlike the code above). Maybe you could give me a hint. Is there a "abbrev-pending" or something like that. Thanks, Bob