X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=lfFCjvFyn4Ar+3YE+SfFi0IgfK9f6w0lYHMMPb53KQA=; b=I3TpOtM6auirkwvbDqIiS8PLvUJ2DtI17b21mMp2gP4ziuIyLKWQLlQVQhXyDzAiFK cFnwi0Y6pXCOuZmX2oe3w821NcMkamcLE+NMOSBe3e4SzGLKQFq9q7yXcIAotS1bxkLa 9AvI9e8fM7ifKKoGxJXbNKiXlg23eeRrSqpqeZgZ3F1JiaWQk1rC8UuXWwH3MCJktUtI qJPqY7P5iGyjlTRklPLIyfEhtL+WAuW1KfAtmHLsY+B3tZGuc1T11tpJcepgoFRv0MET /h+ZaHQgdgAYu0fwbc3JlCX0zkwyoY19QUmX7gcebRw98cAxUXlmGp4k80GbYxqUckFR b95Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=lfFCjvFyn4Ar+3YE+SfFi0IgfK9f6w0lYHMMPb53KQA=; b=PvK0NLn5ywtsJQD8Up/BrMZjmMFqW0tIrYGHWgcwYZxQONFsGWrka4Qwv6eJpZUFMT GB6CBCHIm08t0N2ui6H9U5p/Isms6wW2zVJ54LoB5ghG0oXibfpNyk2EmRDR27e39vj+ bNVmszPALP/88Mbr1ulmhO4P9UpJZ65EIkgGUrwqpBYwufheqvr1MJySQUE+PS29LWtA Xt+qWVBTad2UuNdnkTafEgtlSsu6f7QoTWExawaPEb/fPRuIWlx9OXs+uhq1buXIPtji hExB3kjIwQgCoYpsk27no3rIjzU81HVW9sBUawPBERDozKQvXk3yGXv77IQh/lxuike8 j5Cg== X-Gm-Message-State: AG10YOTqhlU9meAYTp9ILn4SGah5E4eCZPu6dmXVISSbMVH1rh2OOJXildU8vMchs6Lrrw== X-Received: by 10.25.37.2 with SMTP id l2mr962851lfl.160.1455831985960; Thu, 18 Feb 2016 13:46:25 -0800 (PST) Date: Thu, 18 Feb 2016 22:46:20 +0100 From: "Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com]" To: geda-user AT delorie DOT com Subject: Re: [geda-user] pcb import schematic crash, parantheses in netname Message-Id: <20160218224620.cdbb300b9a5be82b01976bed@gmail.com> In-Reply-To: References: <20160215215221 DOT fd472794e7b9446a243bfc40 AT gmail DOT com> <201602152055 DOT u1FKtM4K011038 AT envy DOT delorie DOT com> <20160215220938 DOT bbc7eaa59d827cd0b261ea97 AT gmail DOT com> <201602152135 DOT u1FLZrw9012774 AT envy DOT delorie DOT com> <7F210DE7-0A0B-42F9-ABBE-2C2768621186 AT noqsi DOT com> <20160216081722 DOT 1065cbed6653d3da4ffc7498 AT gmail DOT com> <201602160724 DOT u1G7Ox26001785 AT envy DOT delorie DOT com> <20160216085628 DOT b70143c330cd4da98a4603d3 AT gmail DOT com> <201602160805 DOT u1G85d8c003148 AT envy DOT delorie DOT com> <20160216092912 DOT 7f7439f703b49175a21dbb1b AT gmail DOT com> <201602161715 DOT u1GHFMBB028078 AT envy DOT delorie DOT com> <201602162032 DOT u1GKWL7Y005291 AT envy DOT delorie DOT com> X-Mailer: Sylpheed 3.5.0beta1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 > On Feb 18, 2016, at 12:59 PM, Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com] wrote: > > > On Tue, Feb 16, 2016 at 11:32 AM, DJ Delorie wrote: > >> > >>> The excuse is that doing that will lead to bugs. > >> > >> The context was "what should gnetlist allow?" The answer is: > >> everything it can. If the downstream tools have limits, let them > > > > I disagree. It doesn't add much to accept weird characters. UTF-8 is > > full of chars that *look* identical but compare non-equal, its nuts to > > send them to anything except a human reader if you can avoid it. > > It’s a UTF-8 world, we should be part of it. But you can’t even avoid the problem in ASCII. 0 and O. Or 1, I, l, and |. Yes and there is a label "Made in China" on the backside of almost every product on the desktop. > >> manage those limits themselves. Why should gnetlist, or even a > >> netlist backend, limit what *it* can handle, if it doesn't have to? > > > > Because you *know* it's gonna break downstream stuff, > > But you don’t know which characters break which downstream stuff. Should gnetlist restrict netnames to upper case for SPICE? If characters should be restricted gnetlist must know which characters to restrict. > > And that's the case here: the user doesn't know wtf is going on and > > that the problem is really upstream of gnetlist. It would be better > > to set up gnetlist st by default it pukes on weird stuff that's going > > to confuse downstream stuff. If user's want kanji let them set an > > option to get it. > > I completely disagree. The toolkit’s job is to enable the user to do what they need, not to get in their way. To restrict characters which happen to be ordinary character in a language is certainly not good at all. Noqsi is right the toolkit's job is to enable user to do what they need although the best would be to figure characters not possible to use. Nicklas Karlsson