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

[Hans-Bernhard B. <HBB...@t-...>]

Am 21.01.2020 um 05:43 schrieb Ethan A Merritt:

> I have no objection to adding a corresonding flag bit (for all of them) in the
> "set border" command or even four flag bits (matching the four vertical edges
> of the full graph box).
> But the flag bit[s] would have to default to "on" for backwards compatibility.

That, I'm afraid, largely precludes the addition of control bits into 
the exisiting bit mask --- the default of that, 31, is guaranteed to be 
assumed by tons of existing scripts out there.  So unless the 
to-be-added bits had inverse meaning, they can't be in that mask.

> 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.

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.