[PATCH 1/2] Whitespace cleanups in randrproto.txt

[Gaetan Nadon]

On Sun, 2010-12-05 at 20:39 -0800, Keith Packard wrote:

> @@ -29,14 +29,14 @@ protocol described here, as it has been overtaken
> by events.
>  
>  These events include:
>        ► Modern toolkits (in this case, GTK+ 2.x) have progressed to
> the point
> -        of implementing migration between screens of arbitrary depths
> +       of implementing migration between screens of arbitrary depths
>        ► The continued advance of Moore's law has made limited amounts
> of VRAM
> -        less of an issue, reducing the pressure to implement depth
> switching
> +       less of an issue, reducing the pressure to implement depth
> switching
>         on laptops or desktop systems
>        ► The continued decline of legacy toolkits whose design would
> have
> -        required depth switching to support migration
> +       required depth switching to support migration
>        ► The lack of depth switching implementation experience in the
> -        intervening time, due to events beyond our control
> +       intervening time, due to events beyond our control
>  
>  Additionally, the requirement to support depth switching might
>  complicate other re-engineering of the device independent part of the
> @@ -138,7 +138,7 @@ Thomas Winischhofer for the hardware-accelerated
> SiS rotation implementation
>  Matthew Tippett and Kevin Martin for splitting outputs and CRTCs to
> more
>  fully expose what video hardware can do
>  
> -                              ❧❧❧❧❧❧❧❧❧❧❧
> +                             ❧❧❧❧❧❧❧❧❧❧❧
>  
>  2. Screen change model
>  
> @@ -182,7 +182,7 @@ pop-up menus and other pop up windows will
> position themselves correctly in
>  the face of screen configuration changes (the issue is ensuring that
> pop-ups
>  are visible on the reconfigured screen).
>  
> -                              ❧❧❧❧❧❧❧❧❧❧❧
> +                             ❧❧❧❧❧❧❧❧❧❧❧
>  
>  3. Data Types
>  
> @@ -190,7 +190,7 @@ The subpixel order is shared with the Render
> extension, and is documented
>  there. The only datatype defined is the screen size, defined in the
> normal
>  (0 degree) orientation.
>  
> -                              ❧❧❧❧❧❧❧❧❧❧❧
> +                             ❧❧❧❧❧❧❧❧❧❧❧
>  
>  4. Errors
>  
> @@ -203,7 +203,7 @@ CRTC
>  Mode
>         A value for a MODE argument does not name a defined MODE.
>  
> -                              ❧❧❧❧❧❧❧❧❧❧❧
> +                             ❧❧❧❧❧❧❧❧❧❧❧
>  
>  5. Protocol Types
>  
> @@ -266,11 +266,11 @@ CONNECTION { Connected, Disconnected,
> UnknownConnection }
>         connected to a monitor or other presentation device.
>  
>  SUBPIXELORDER { SubPixelUnknown                The subpixel order
> uses the Render
> -               SubPixelHorizontalRGB   extensions definitions; they
> are here
> -               SubPixelHorizontalBGR   only for convenience.
> -               SubPixelVerticalRGB
> -               SubPixelVerticalBGR
> -               SubPixelNone }
> +               SubPixelHorizontalRGB   extensions definitions; they
> are here
> +               SubPixelHorizontalBGR   only for convenience.
> +               SubPixelVerticalRGB
> +               SubPixelVerticalBGR
> +               SubPixelNone }
>  
>  SCREENSIZE { widthInPixels, heightInPixels: CARD16
>              widthInMillimeters, heightInMillimeters: CARD16 }
> @@ -292,15 +292,15 @@ MODEFLAG { HSyncPositive
>  
>  MODEINFO { id: MODE
>            name: STRING
> -           width, height: CARD16
> -           dotClock: CARD32
> -           hSyncStart, hSyncEnd, hTotal, hSkew: CARD16
> -           vSyncStart, vSyncEnd, vTotal: CARD16
> -           modeFlags: SETofMODEFLAG }
> +          width, height: CARD16
> +          dotClock: CARD32
> +          hSyncStart, hSyncEnd, hTotal, hSkew: CARD16
> +          vSyncStart, vSyncEnd, vTotal: CARD16
> +          modeFlags: SETofMODEFLAG }
>  
>  REFRESH { rates: LISTofCARD16 }
>  
> -                              ❧❧❧❧❧❧❧❧❧❧❧
> +                             ❧❧❧❧❧❧❧❧❧❧❧
>  
>  6. Extension Initialization
>  
> @@ -323,7 +323,7 @@ The name of this extension is "RANDR".
>         It is the clients responsibility to ensure that the server
>         supports a version which is compatible with its expectations.
>  
> -                              ❧❧❧❧❧❧❧❧❧❧❧
> +                             ❧❧❧❧❧❧❧❧❧❧❧
>  
>  7. Extension Requests
>  
> @@ -564,7 +564,7 @@ dynamic changes in the display environment.
>         name: STRING
>         connection: CONNECTION
>         subpixel-order: SUBPIXELORDER
> -        widthInMillimeters, heightInMillimeters: CARD32
> +       widthInMillimeters, heightInMillimeters: CARD32
>         crtcs: LISTofCRTC
>         clones: LISTofOUTPUT
>         modes: LISTofMODE
> 

Just to let you know that down to here, these changes are not related to
space/tab combos.
These changes replace 'space chars' with a 'tab char'. I don't know if
it is good or not,
or if it is intentional or not.

git diff reports only a few space/tab combo issues:

        randrproto.txt:622: space before tab in indent.
        +       output:OUTPUT
        randrproto.txt:624: space before tab in indent.
        +       atoms: LISTof ATOM
        randrproto.txt:636: space before tab in indent.
        +       pending: BOOL
        randrproto.txt:666: space before tab in indent.
        +       pending: BOOL
        randrproto.txt:683: space before tab in indent.
        +       output: OUTPUT
        randrproto.txt:720: space before tab in indent.
        +       output: OUTPUT
        randrproto.txt:731: space before tab in indent.
        +       output: OUTPUT
        randrproto.txt:782: space before tab in indent.
        +       window: WINDOW
        randrproto.txt:785: space before tab in indent.
        +       mode: MODE
        randrproto.txt:798: space before tab in indent.
        +       mode: MODE
        randrproto.txt:976: space before tab in indent.
        +       red: LISTofCARD16






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20101206/41a4754a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg-devel/attachments/20101206/41a4754a/attachment-0001.pgp>