From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tim X Newsgroups: gmane.emacs.help Subject: Re: abbrevs, skeletons, and comments Date: Sun, 03 Jun 2007 20:32:52 +1000 Organization: Posted via Supernews, http://www.supernews.com Message-ID: <87odjxmip7.fsf@lion.rapttech.com.au> References: <1180794889.290796.147660@m36g2000hse.googlegroups.com> <87odjxvhyn.fsf@lion.rapttech.com.au> <1180845849.865552.185180@h2g2000hsg.googlegroups.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1180867240 6875 80.91.229.12 (3 Jun 2007 10:40:40 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 3 Jun 2007 10:40:40 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun Jun 03 12:40:39 2007 Return-path: Envelope-to: geh-help-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 1HunVj-0004ic-EA for geh-help-gnu-emacs@m.gmane.org; Sun, 03 Jun 2007 12:40:35 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HunVi-0005zc-Ue for geh-help-gnu-emacs@m.gmane.org; Sun, 03 Jun 2007 06:40:34 -0400 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!sn-xt-sjc-03!sn-xt-sjc-08!sn-post-sjc-02!sn-post-sjc-01!supernews.com!corp.supernews.com!not-for-mail Original-Newsgroups: gnu.emacs.help User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux) Cancel-Lock: sha1:0l6PsVgfTSkz6vLuCJiDEfP4i8I= Original-X-Complaints-To: abuse@supernews.com Original-Lines: 61 Original-Xref: shelby.stanford.edu gnu.emacs.help:149048 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:44636 Archived-At: nobrowser@gmail.com writes: > Tim X wrote: >> nobrowser@gmail.com writes: >> >> > In a module I'm writing, I'd like to bind abbrevs to code skeletons, >> > similar to what is done e.g. by sml-mode. But expanding the abbrevs >> > makes no sense when the point is inside a comment (or a string >> > literal). So I'd like to conditionally stop expansion. The main >> > opportunity for that seems to be pre-abbrev-expand-hook, but there are >> > only two ways it can stop an expansion: 1, throw an error, 2, change >> > the abbrev bindings (either by making changes in the current table or >> > by swapping in a whole new table). 1 is unacceptable - how many errors >> > before user gets mad and disables abbrevs altogether? 2, how to undo >> > the changes when the point leaves the comment or string? >> > >> >> maybe use an error handler that catches that specific error and ignores it? >> > > Well, there's no point where I get control, that's the problem. > Abbrev expansion can be triggered just by the user typing a space or > period, if they have Abbrev minor mode on. > > I see a way to do what I want. It involves hooking both pre-abbrev- > expand-hook and post-command-hook. I can restore the abbrev bindings > in the latter. But I am afraid what this could do to Emacs speed or > even stability. > > What I've decided on so far is I won't do anything by default (so > users who avoid Abbrev minor mode are not penalized) and have a > customize flag that turns on the above solution. > > Other suggestions still welcome. > OK, so if I understand, the problem with using the pre-abbrev-expand-hook is that once you use that hook to modify the table to prevent the expansion if this would occur inside a comment/string or whatever, you have no easy way of re-establishing that expansion, so text encountered later which is not in a comment/string won't be expanded as it should. How about changing perspective. Why not make a hook function that looks at the text that may be expanded/replaced and if it is text that should be expanded, make the appropriate entry into the abbrev table and if its not already there. If it is there, but he text sould not be expanded, then remove it. I think this would eliminate the problem of how to re=establish the corect expansion entry in the table after it has been removed/changed because the text being considered is either in a comment or a string. Another possibility is to use the abbrev hook function. This function runs after the abbrev has been done. I guess it would be possible to use it to 'undo' the expansion if the text is in a comment/string. Not very nice, but probably less impact than having something run via post-command-hook that would run more often. Tim -- tcross (at) rapttech dot com dot au