Re: abstracting Lisp strings - macro name convention?

[Ken Raeburn <raeburn@raeburn.org>]

Richard Stallman <rms@gnu.org> writes:
> SMBP is too terse.  That won't be used so often
> that we cannot afford a longer and more meaningful name.

Okay, I'll use longer names.  Probably something like this set:

  STRING_DATA(obj)      /* produces a char* */
  STRING_REF(obj,index)
  STRING_SET(obj,index,newbyteval)
  STRING_INTERVALS(obj)
  STRING_SET_INTERVALS(obj,interval)
  STRING_NBYTES(obj)    /* STRING_BYTES exists, takes Lisp_String ptr */
  STRING_NCHARS(obj)
  STRING_MULTIBYTE(obj) /* already present */
  STRING_SET_UNIBYTE(obj) /* all uses of SET_STRING_BYTES are of the
                             form SET_STRING_BYTES(XSTRING(x),-1) */

And I'll remove or rename the macros operating on Lisp_String struct
pointers or with the terse names.

  STRING_SET_BYTES(ptr,-1) -> STRING_SET_UNIBYTE(obj)
  STRING_BYTES(ptr)        -> STRING_NBYTES(obj)
  XSTRING(obj)->foo        -> STRING_foo(obj),STRING_SET_foo(obj,...)
  SREF  -> STRING_REF
  SDATA -> STRING_DATA
  etc


With a pervasive change like this, do you really want separate
checkins for each file and detailed function-level change log and CVS
log entries for everything affected?  It's tedious, but doable; I'm
just unclear on how important you feel that level of detail is for
pervasive changes of such a simple nature.  Occasionally other changes
have been checked in with log entries like "all callers changed"; most
(but not all) of them are for static functions, so it's still
describing changes confined to the one file.

Ken