* Re: Characterset for Abbrevation names limited
[not found] ` <E1I2ucR-00013Q-80@fencepost.gnu.org>
@ 2007-06-26 23:57 ` Glenn Morris
2007-06-27 2:19 ` Stefan Monnier
0 siblings, 1 reply; 4+ messages in thread
From: Glenn Morris @ 2007-06-26 23:57 UTC (permalink / raw)
To: Richard Stallman; +Cc: Emacs developers
Richard Stallman wrote (on Mon, 25 Jun 2007 at 15:53 -0400):
> > and/or include a similar comment into the function description.
> > Otherwise an uninformed user might use the unsupported characters like
> > [!"#%&/] and register the failure of the function and
> > interpret it as a bug.
>
> I suggest making that function give an error if the abbrev contains
> invalid characters.
>
> Would you like to do that?
I'm going on holiday for a couple of weeks, I can look at it when I
return. Someone else might wish to do it before then.
(This is about define-global-abbrev, continued from bug-gnu-emacs).
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Characterset for Abbrevation names limited
2007-06-26 23:57 ` Characterset for Abbrevation names limited Glenn Morris
@ 2007-06-27 2:19 ` Stefan Monnier
2007-06-27 2:56 ` Glenn Morris
2007-06-27 19:49 ` Richard Stallman
0 siblings, 2 replies; 4+ messages in thread
From: Stefan Monnier @ 2007-06-27 2:19 UTC (permalink / raw)
To: Glenn Morris; +Cc: Richard Stallman, Emacs developers
>> > and/or include a similar comment into the function description.
>> > Otherwise an uninformed user might use the unsupported characters like
>> > [!"#%&/] and register the failure of the function and
>> > interpret it as a bug.
>>
>> I suggest making that function give an error if the abbrev contains
>> invalid characters.
I can't recover the original email so I'm not sure what was suggested, but
if the suggestion is to make define-abbrev signal an error if the abbrev
uses chars that are not word constituents, this will be problematic because
the criterion depends on the syntax-table in use and that one may not be the
same during define-abbrev as during expand-abbrev (some code in Emacs even
uses pre-abbrev-expand-hook to change the syntax-table used during
expand-abbrev independently from the syntax-table used otherwise in the
buffer).
Stefan
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Characterset for Abbrevation names limited
2007-06-27 2:19 ` Stefan Monnier
@ 2007-06-27 2:56 ` Glenn Morris
2007-06-27 19:49 ` Richard Stallman
1 sibling, 0 replies; 4+ messages in thread
From: Glenn Morris @ 2007-06-27 2:56 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Richard Stallman, Emacs developers
Stefan Monnier wrote:
> I can't recover the original email so I'm not sure what was suggested,
The parent was off-list (for some reason...), but I quoted all of it.
The rest of the thread is in bug-gnu-emacs with the same subject.
> but if the suggestion is to make define-abbrev signal an error if
> the abbrev uses chars that are not word constituents, this will be
> problematic because the criterion depends on the syntax-table in use
> and that one may not be the same during define-abbrev as during
> expand-abbrev (some code in Emacs even uses pre-abbrev-expand-hook
> to change the syntax-table used during expand-abbrev independently
> from the syntax-table used otherwise in the buffer).
Yes, I did think about the define-abbrev case, and didn't see how one
could do much because of the reasons you cite. I think the suggestion
was perhaps just for define-global-abbrev, either to make it error or
warn if using a "non-standard-word-constituent" ([^a-zA-Z0-9] ?),
probably only when called interactively. As it stands you can define
"global" abbrevs that only work in some modes, which is a bit odd. But
I guess one could always construct a mode with a suitably bizarre
syntax that would still mess things up...
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Characterset for Abbrevation names limited
2007-06-27 2:19 ` Stefan Monnier
2007-06-27 2:56 ` Glenn Morris
@ 2007-06-27 19:49 ` Richard Stallman
1 sibling, 0 replies; 4+ messages in thread
From: Richard Stallman @ 2007-06-27 19:49 UTC (permalink / raw)
To: Stefan Monnier; +Cc: rgm, emacs-devel
I can't recover the original email so I'm not sure what was suggested, but
if the suggestion is to make define-abbrev signal an error if the abbrev
uses chars that are not word constituents, this will be problematic because
the criterion depends on the syntax-table in use and that one may not be the
same during define-abbrev as during expand-abbrev (some code in Emacs even
uses pre-abbrev-expand-hook to change the syntax-table used during
expand-abbrev independently from the syntax-table used otherwise in the
buffer).
We could leave define-abbrev alone and make the user level commands,
define-global-abbrev and define-mode-abbrev, do this check.
That way, ordinary users would be protected from the mistake,
and experts could still do whatever they wish.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2007-06-27 19:49 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <467A7A62.40202@gmx.de>
[not found] ` <tq7ipvg5j6.fsf@fencepost.gnu.org>
[not found] ` <467E88DA.8020906@gmx.de>
[not found] ` <18048.3335.394836.510128@fencepost.gnu.org>
[not found] ` <E1I2ucR-00013Q-80@fencepost.gnu.org>
2007-06-26 23:57 ` Characterset for Abbrevation names limited Glenn Morris
2007-06-27 2:19 ` Stefan Monnier
2007-06-27 2:56 ` Glenn Morris
2007-06-27 19:49 ` Richard Stallman
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).