[Top][All Lists]

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

Re: Buffer-local variables affect general-purpose functions

From: Eli Zaretskii
Subject: Re: Buffer-local variables affect general-purpose functions
Date: Thu, 27 Mar 2014 19:17:46 +0200

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden
> Date: Thu, 27 Mar 2014 10:17:23 -0400
> >   M-x find-file-literally RET some-file RET
> >   M-x set-variable RET case-fold-search RET t RET
> >   M-: (chars-equal ?à ?À) RET
> > This produces nil, although the characters should compare equal under
> > case-fold-search.  Why?  Because we are in a unibyte buffer, where
> > values between 128 and 255 are interpreted as eight-bit raw bytes, not
> > as Latin characters, and raw bytes don't have lower/upper-case pairs.
> I agree with Paul on this one: this should be fixed to disregard
> unibyte setting.  `char-equal' compares chars, not bytes (use `eq'
> for bytes).
> It's an old backward compatibility hack that should go.

Paul seemed to say something more broad: that _all_ behaviors specific
to unibyte buffers should go away.  Do you agree?

Anyway, what should replace those hacks?  Arbitrarily interpreting raw
bytes as Latin characters is not TRT, IMO.

Actually, in the above case, we could simply make char-equal disregard
case-fold-search in unibyte buffers -- that would give you and Paul
what you want, but also keep backward compatibility (except for ASCII

> > The question is: do we want to do something about that?
> Not sure.  It's hard to find all occurrences of this problem.
> And I don't think we can find a "general" solution: each case might be
> best solved in a different way.  Furthermore the right solution will
> sometimes (often?) be to throw away the current functionality and
> replace it with something different.

Maybe so, but something like

  (with-buffer-defaults BODY)

might be the solution, and should be easy enough to implement.  Or
maybe some other way of telling primitives: don't apply
buffer-specific behavior to this code.

>    % grep with-case-table **/*.el
>    emacs-lisp/lisp-mode.el:                       "eval-and-compile" 
> "eval-when-compile" "with-case-table"
>    leim/quail/sisheng.el:  (with-case-table (standard-case-table)
>    mail/smtpmail.el:                   (with-case-table ascii-case-table ;Why?
>    subr.el:(defmacro with-case-table (table &rest body)
> And the only uses of with-case-table are in lisp/leim/quail/sisheng.el
> (where it sets the standard case table, so it should have no effect) and
> in lisp/mail/smtpmail.el (where it uses ascii-case-table but should only
> apply it to ASCII text, so it could just as well use the standard case
> table).
> And then we can use the Unicode 'case tables' as recently discussed.
> Patch for that welcome on trunk.


reply via email to

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