Re: Odd behavior of "set border" and "splot"

Hans-Bernhard Bröker <HBB...@t-...> writes:

>> On the other hand, looking up the bits one by one is inconvenient.
>> It might be more user-friendly to add a keyword
>>      set border <bitmask> {{no} somethingdescriptive}
>
> I would tend to call them 'corner poles', as they're meant to appear be
> holding up the otherwise free-floating plotted surface at the corners, a
> bit like the tent poles.

Yeah, I like that name; was thinking something along the same lines,
actually.


> The syntax could be extended by a keyworded optional argument
>
> 	set border
> 	...
> 	{{cornerpoles | cp} {default | <corners>}}
>
> where the 'default' restores the current default: all four corner poles
> are drawn, if applicable.  The corresponding bit mask value <corners>
> would be 240, from 128+64+32+16.  I.e. for clarity it would use the same
> bit positions as in the existing <integer> parameter for the full
>
> Or 'cornerpoles' could become a new 'set' command of its own, or an
> optional argument to 'set surface', given as it only applies if 'set
> surface' is on.

I think it would be nice to manage two separate bit masks that use the
same bit meanings:

- the current "border" bitmask
- a new "cornerpoles" bitmask

I think this is what you're suggesting. If the "cornerpoles" bitmask
isn't managed with a new "set cornerpoles", but uses an extension to
"set border", what syntax are you proposing? How would you set a
"border" mask A and a "cornerpoles" mask B? Like this?

  set border A cp B

Or with two separate calls?

  set border A
  set border cp B

Not sure if one of these is what you had in mind. I think a separate
"set" would be clearer:

  set border A
  set cornerpoles B