Is it obvious that string-match syntax matching is affected by the current buffer?

Is it obvious that string-match syntax matching is affected by the current buffer?

[Tom]

I did a word constituent match with string-match and a question
occured to me: what controls what is considered word constituent
in this case?

I checked info, but I saw no mention of this, so I did a test and
yes, the current syntax table affects string-match:

(let ((tab (make-syntax-table)))
  (modify-syntax-entry ?a " " tab)
  (with-syntax-table tab
    (string-match "\\s-" "a")))


Isn't a strange? E.g. I'm doing a string match in elisp, so I'm
not working with the current buffer, yet its active syntax table
affects the result of string-match. Seems to me these are
different domains and string-match should have its own
string-match-syntax-table or something, so there can be no
match side effects depending on the currently active buffer.

Do you think it's obvious for the elisp users that string-match
is affected by the current buffer? Maybe the documentation should
mention this. (Maybe it does, but I didn't see it.)

Re: Is it obvious that string-match syntax matching is affected by the current buffer?

[Andreas Röhler]

On 13.03.2016 17:31, Tom wrote:
> I did a word constituent match with string-match and a question
> occured to me: what controls what is considered word constituent
> in this case?
>
> I checked info, but I saw no mention of this, so I did a test and
> yes, the current syntax table affects string-match:
>
> (let ((tab (make-syntax-table)))
>    (modify-syntax-entry ?a " " tab)
>    (with-syntax-table tab
>      (string-match "\\s-" "a")))
>
>
> Isn't a strange? E.g. I'm doing a string match in elisp, so I'm
> not working with the current buffer, yet its active syntax table
> affects the result of string-match. Seems to me these are
> different domains and string-match should have its own
> string-match-syntax-table or something, so there can be no
> match side effects depending on the currently active buffer.
>
> Do you think it's obvious for the elisp users that string-match
> is affected by the current buffer? Maybe the documentation should
> mention this. (Maybe it does, but I didn't see it.)
>
>
>

string-match here is called from inside a let, so the settings there 
prevail.
Also from inside let: "with-syntax-table tab" - whilst"tab" is also 
let-bound.

Let protects against outer settings, so current-buffer or not seems not 
at stake.

Re: Is it obvious that string-match syntax matching is affected by the current buffer?

[Tom]

Andreas Röhler <andreas.roehler <at> easy-emacs.de> writes:
> 
> string-match here is called from inside a let, so the settings there 
> prevail.

Obviously, it was for my test only.

But that doesn't change my point that if there is no let then 
string-match uses the current buffer's syntax table which may
cause an unintended side effect, making the result of string-match
dependent on the current buffer.

Re: Is it obvious that string-match syntax matching is affected by the current buffer?

[Eli Zaretskii]

> From: Tom <adatgyujto@gmail.com>
> Date: Sun, 13 Mar 2016 16:56:23 +0000 (UTC)
> 
> But that doesn't change my point that if there is no let then 
> string-match uses the current buffer's syntax table which may
> cause an unintended side effect, making the result of string-match
> dependent on the current buffer.

Forget syntax tables: did you know that 'downcase' and
case-insensitive string match uses the current buffer's
case-conversion table?

IOW, the issue you raise is not the only place in Emacs where
buffer-local settings can change the results.  In many use cases,
using buffer-local settings is what the Lisp code wants; if not, it's
the responsibility of the caller to set up things differently.

Re: Is it obvious that string-match syntax matching is affected by the current buffer?

[Tom]

Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> Forget syntax tables: did you know that 'downcase' and
> case-insensitive string match uses the current buffer's
> case-conversion table?

Yes, those are examples of the same thing.

When I work with a string then I feel it should not be affected
by settings of the current buffer, because it's not buffer text
anymore, but a separate object.

But I understand the current behavior won't be changed, because
it could break existing code which relies on it, so it's up to
elisp developers to make sure the correct defaults are used when
calling the function.

Re: Is it obvious that string-match syntax matching is affected by the current buffer?

[Eli Zaretskii]

> From: Tom <adatgyujto@gmail.com>
> Date: Sun, 13 Mar 2016 19:19:09 +0000 (UTC)
> 
> When I work with a string then I feel it should not be affected
> by settings of the current buffer, because it's not buffer text
> anymore, but a separate object.

Yes.  But many times, the string is a substring created from (some
transformation of) the current buffer's text, in which case applying
the buffer's defaults to it yields the expected results.

Re: Is it obvious that string-match syntax matching is affected by the current buffer?

[Stefan Monnier]

> When I work with a string then I feel it should not be affected
> by settings of the current buffer, because it's not buffer text
> anymore, but a separate object.

I agree, yet at the same time this begs the question: which setting to
use, if not the current buffer's?

Using some global setting for them instead would be wrong just as often,
if not more.


        Stefan

RE: Is it obvious that string-match syntax matching is affected by the current buffer?

[Drew Adams]

> > When I work with a string then I feel it should not be affected
> > by settings of the current buffer, because it's not buffer text
> > anymore, but a separate object.
> 
> I agree, yet at the same time this begs the question: which setting to
> use, if not the current buffer's?
> 
> Using some global setting for them instead would be wrong just as often,
> if not more.

Probably it would help to mention such dependence on syntax
and case-conversion and tables in the doc string, explicitly
pointing out that this pertains also when the function is used
on a string instead of a buffer.