bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Suggestion: check for \n, \t in regexp for query-replace-regexp


From: Kevin Rodgers
Subject: Re: Suggestion: check for \n, \t in regexp for query-replace-regexp
Date: Tue, 04 Dec 2001 11:16:11 -0700

David Kastrup wrote:
> 
> >>>>> "Michael" == Michael J Downes <address@hidden> writes:
> 
>  Michael> If we are on the same page, then when the user is prompted
>  Michael> for a regexp, 'x\\n' should be accepted and search for three
>  Michael> characters x \ n, 'xn' should be accepted and search for two
>  Michael> characters x n, but 'x\n' should probably always get a
>  Michael> warning because it does not do anything more useful than
>  Michael> 'xn' and is more cumbersome to enter, but most of all
>  Michael> because the user almost certainly was wishing to get a
>  Michael> newline character for the \n.

Actually, it might be helpful to warn about _any_ character following a
backslash that isn't special or one of the additional special constructs.
(I'm using the terminology of the Regexps/Syntax of Regular Expressions
node of the Emacs manual.)

For this, I think it'd be useful to define a read-regexp utility, and perhaps
define an `interactive' character code for it, that all commands like replace-
regexp could use.

>  Michael> Indeed it might be worth considering whether it should
>  Michael> simply be silently converted to a newline character, for the
>  Michael> sake of user friendliness---bearing in mind that I am only
>  Michael> talking about the case where the expression is entered
>  Michael> interactively in a user-level command---even though that
>  Michael> would not be strictly consistent with the advertised regexp
>  Michael> rules.
> 
> Not a good idea.  Second-guessing the user and accepting slightly
> illegal input is going to lead to problems later on.  For example, if
> the user decides to use the regexp he used interactively somewhere
> non-interactively, or not even in Emacs.

I agree completely.

-- 
Kevin Rodgers <address@hidden>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]