annotate admin/notes/iftc @ 52846:2ff062ff0422

(Basic Windows): A window has fringe settings, display margins and scroll-bar settings. (Splitting Windows): Doc split-window return value. Clean up one-window-p. (Selecting Windows): Fix typo. (Cyclic Window Ordering): Explain frame as ALL-FRAMES in next-window. (Buffers and Windows): In set-window-buffer, explain effect on fringe settings and scroll bar settings. (Displaying Buffers): In pop-to-buffer, explain nil as buffer arg. (Choosing Window): Use defopt for pop-up-frame-function. For special-display-buffer-names, explain same-window and same-frame. Clarify window-dedicated-p return value. (Textual Scrolling): scroll-up and scroll-down can get an error. (Horizontal Scrolling): Clarify auto-hscroll-mode. Clarify set-window-hscroll. (Size of Window): Don't mention tool bar in window-height. (Coordinates and Windows): Explain what coordinates-in-window-p returns for fringes and display margins. (Window Configurations): Explain saving fringes, etc.

Iso-Functional Type Contour


This is a term coined to describe "column int->float" change approach, and can
be used whenever low-level types need to change (hopefully not often!) but the
meanings of the values (whose type has changed) do not.

The premise is that changing a low-level type potentially means lots of code
needs to be changed as well, and the question is how to do this incrementally,
which is the preferred way to change things.

Say LOW and HIGH are C functions:

  int LOW (void) { return 1; }
  void HIGH (void) { int value = LOW (); }

We want to convert LOW to return float, so we cast HIGH usage:

  float LOW (void) { return 1.0; }
  void HIGH (void) { int value = (int) LOW (); }  /* iftc */

The comment /* iftc */ is used to mark this type of casting to differentiate
it from other casting.  We commit the changes and can now go about modifying
LOW and HIGH separately.  When HIGH is ready to handle the type change, the
cast can be removed.

;;; arch-tag: 3309cc41-5d59-421b-b7be-c94b04083bb5