Re: gEDA: Power nets (first RFC)

[David Cary <d.cary@ieee.org>]

>From: Andrew Dyer <adyer@enteract.com>
...
>I agree 100% adding spaces is just asking for trouble, especially when
>importing/exporting stuff to other formats.

There seems to be only 2 cases:
 * If we cannot handle spaces, we're going to have to mangle the names when
importing from  other formats that *can* handle spaces.
 * If we can handle spaces, we're going to have to mangle names when
exporting to other formats that *cannot* handle spaces.

Either way, we're going to have to mangle names. It seems much more elegant
to mangle them as late as possible, only on export.
...
>Maybe we could just define another unicode character set and use 16-bit
>chars everywhere ... :-)

That's what Java did :-).

>From: Roger Williams <roger@coelacanth.com>
...
>  >>  Should we allow spaces in net names?
...
>I prefer not.
>
>(It's like UNIX file names -- sure, I *can* use spaces in them, but it
>complicates everything so much that I refuse to do so.)

Huh ? Are you saying that UNIX would be "better" if it refused to create
files with spaces in them ?

I think it is best to give the user the flexibility to do anything he
wants. If you don't want any spaces in your drawings, well, no one is
forcing you to put them in. But you seem to be forcing everyone else to
take them out.

Yes, some other programs can't handle spaces in names. Some other programs
only allow a maximum of 8 character names, all in upper-case. Do we want to
mimic all these limitations of other programs, going for the least common
denominator ?

Your arguments are good reasons for not having spaces in names in the
standard libary of parts, and maybe even adding a DRC option to warn about
names that have spaces in them.

Is there a way to do a global search-and-replace, changing all "66MHz" to
"100MHz" in all net names ? It might be nice to allow people who are
annoyed by spaces to do a global search and replace for " " to "_".

"no spaces in net names" just seems like an unnecessary limitation, one
that is almost trivial to remove. Maybe I'm over-optimistic -- is it really
going to take tons of extra code to support this feature ? Then don't
bother.

--
David Cary "mailto:d.cary@ieee.org" "icbmto:N36 08.830' W97 03.443'"
  http://www.rdrop.com/~cary/
Future Tech, Unknowns, machine vision ><> <*> O-