X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.7+dev
X-Exmh-Isig-CompType: repl
X-Exmh-Isig-Folder: inbox
From: "karl AT aspodata DOT se [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] empty attributes
In-reply-to: <alpine.DEB.2.21.2109261600060.1280@nimbus>
References: <20210925133011 DOT D0B918587B70 AT turkos DOT aspodata DOT se> <alpine DOT DEB DOT 2 DOT 21 DOT 2109251919580 DOT 1189 AT nimbus> <20210925194712 DOT 152EA8587FD0 AT turkos DOT aspodata DOT se> <alpine DOT DEB DOT 2 DOT 21 DOT 2109261600060 DOT 1280 AT nimbus>
Comments: In-reply-to Roland Lutz <rlutz AT hedmen DOT org>
   message dated "Sun, 26 Sep 2021 16:12:13 +0200."
Mime-Version: 1.0
Content-Type: text/plain
Message-Id: <20210926174305.C8EAF8587FD8@turkos.aspodata.se>
Date: Sun, 26 Sep 2021 19:43:05 +0200 (CEST)
X-Virus-Scanned: ClamAV using ClamSMTP
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

Roland Lutz:
...
> I'm not terribly opposed to supporting empty (as opposed to, unset) 
> attributes, but having gEDA treat "refdes=" as an empty attribute would 
> introduce a semantic change as text objects in existing schematics may 
> then suddenly be interpreted as attributes.

$ grep -B1 'refdes=$' top.sch
T 17000 9439 5 10 1 0 0 3 1
refdes=
$

In lepton, an empty refdes, gives me an error:
ERROR: Throw to key `attribute-format' with args `("%parse-attrib" "~A is not a valid attribute: invalid string '~A'." (#<geda-object 0xcd3b40ab80> "refdes=") ())'.

 While gsch2pcb seem to treat it as nonexistant (or as text) and
 uses the default refdes. Using the default refdes is confusing,
 I tend to prefer to have an error message in this case,
 or rather to accept it as empty.
$ cat top.net 
U?/unnamed_net4 U?R2-2 U?R1-2 
unnamed_net2    U?R2-1 R3-1 
unnamed_net1    U?R1-1 R3-2 

 My guess is that, currently, for refdes specifically, none will use
T ... 1
refdes=
 intentionally, beceause if they do, the'll get the annoying U? refdes
 which they don't know where it come from since it isn't in the 
 schematics. So users are already burned on that thing.
 For other attributes not in the master list, don't they just behave as
 text in the schemtics so there wouldn't be a change there.
 Lepton seems to treat all sinle line things like "something=" as
 invalid attributes, so we can ask them how that has played out.

 I don't have a whole lot of sch file from others to check on, but
 my guess is that the current use is non-existant.

 It should be safe to allow attributes with empty value.

> I've long been in favor of making text and attributes different kinds of 
> objects, which would remove this ambiguity.  But that (like many other 
> potential improvements) would mean an incompatible file format change, 
> which I have so far tried to avoid.

Why don't we (geda lepton and other writing programs related to the 
file format) then sit down and do that.
The format as is isn't too bad, but there are corner cases that needs
to be resolved, like the case when we have multiple footprints files
with the same name.
 
> Allowing component objects to have an empty refdes would be another, 
> different change.  What would it mean for a component to have an empty 
> refdes?  If the empty string was treated like any other value, all such 
> components would be merged into one package.  Is this useful behavior?

Why not let the user decide, instead of having special cases and rules.

I believe it would be useful for designs with subsheets.
If someone wants to use it on regular symbols, it's their pain.

> I'm playing with the thought of allowing components to not have any 
> refdes= attribute at all in situations where this makes semantic sense, 
> e.g., with cascade simulation.  This is a somewhat different concept, 
> though, and may not play well together with hierarchy.

Not done that so I can't provide insights on thoose simulations.

Regards,
/Karl Hammar