all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Tim X <timx@nospam.dev.null>
To: help-gnu-emacs@gnu.org
Subject: Re: abbrevs, skeletons, and comments
Date: Sun, 03 Jun 2007 20:32:52 +1000	[thread overview]
Message-ID: <87odjxmip7.fsf@lion.rapttech.com.au> (raw)
In-Reply-To: 1180845849.865552.185180@h2g2000hsg.googlegroups.com

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

  reply	other threads:[~2007-06-03 10:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-02 14:34 abbrevs, skeletons, and comments nobrowser
2007-06-03  3:24 ` Tim X
2007-06-03  4:44   ` nobrowser
2007-06-03 10:32     ` Tim X [this message]
2007-06-03 13:31       ` nobrowser
2007-06-03 11:43     ` Andreas Roehler
2007-06-11  9:20 ` Johan Bockgård
2007-06-12 13:50 ` Stefan Monnier
2007-06-14 18:30   ` Johan Bockgård

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87odjxmip7.fsf@lion.rapttech.com.au \
    --to=timx@nospam.dev.null \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.