emacs-devel
[Top][All Lists]
Advanced

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

Re: abstracting Lisp strings - macro name convention?


From: Ken Raeburn
Subject: Re: abstracting Lisp strings - macro name convention?
Date: Tue, 02 Jul 2002 22:09:00 -0400
User-agent: Gnus/5.090005 (Oort Gnus v0.05) Emacs/21.1.50 (i686-pc-linux-gnu)

Richard Stallman <address@hidden> 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



reply via email to

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