unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* 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).