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] schematic attributes
In-reply-to: <63288ff-b013-eb67-cf40-56d6119e8cfa@grinsen-ohne-katze.de>
References: <20220821141622 DOT A5836824697A AT turkos DOT aspodata DOT se> <63288ff-b013-eb67-cf40-56d6119e8cfa AT grinsen-ohne-katze DOT de>
Comments: In-reply-to Roland Lutz <rlutz AT hedmen DOT org>
   message dated "Sun, 21 Aug 2022 22:50:49 +0200."
Mime-Version: 1.0
Content-Type: text/plain
Message-Id: <20220824165958.C92CB80724AC@turkos.aspodata.se>
Date: Wed, 24 Aug 2022 18:59:58 +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:
> On Sun, 21 Aug 2022, karl AT aspodata DOT se [via geda-user AT delorie DOT com] wrote:
...
> > As a user, I believe that it is important that the schematics I
> > make can be used in both programs.
> 
> gEDA/gaf is and will be fully downwards-compatible, so any schematic that 
> worked with an older version of gEDA/gaf will work with a newer version, 
> as well.

Backwards compatibility (i.e. old files still works) is a good thing.

> lepton-eda somewhat breaks that,

If so, I'd it would be good to fix that, in what way does
lepton break backwards compatibility ?

...
> > Is it time to make a clean break from the "old" attributes and
> > define a new set
> 
> Oh no, please don't!

The problem with the "old" set is that it is not well defined.
I don't say that we should remove the "old" set, I say we should
create something that is well defined. Also it shouldn't be
redundant like the pinseq, that could just be implicit.

...
> My preferred approach is to allow prefixing attributes with their 
> respective domains (pcb:footprint=, spice:device=, and so on) but 
> otherwise keep the existing semantics.

I'm fine with prefixing, but instead of
 spice:device=...
why not
 spice=xxxx
end let the xxxx's be a black box for everything except the spice
backend (btw. which spice) ? Or, using multiline

T ........ N
spice:
spice specific stuff

///

Btw, why do we have T ... N, when we have 
the
X ...
{
  X specific stuff
}

syntax ?

Regards,
/Karl Hammar