A symbol with "/" in its name will be missing after schematic reload

[Thomas Figueroa]

Application: kicad
Version: (2017-11-14 revision ecbc441d6)-HI-DPI, release build
Libraries:
    wxWidgets 3.1.1
    libcurl/7.55.1-DEV OpenSSL/1.0.2l zlib/1.2.11 libssh2/1.8.0
Platform: Windows 10 (build 17035), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
    wxWidgets: 3.1.1 (wchar_t,wx containers)
    Boost: 1.65.1
    Curl: 7.55.1-DEV
    Compiler: Visual C++ 1911 without C++ ABI
Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=OFF
    KICAD_SCRIPTING_WXPYTHON=OFF
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_SPICE=OFF

Initial placement of a symbol with an "/" in its name will work, but upon close and reload of the schematic, the symbol will be missing as it can't resolve it.

[Wayne Stambaugh (stambaughw)]

Are these you libraries or the kicad libraries? If they are your libraries you are going to have manually fix them yourself. Library IDs cannot contain ':' or '/' characters or any other character that is not allow by the file system. If they are kicad libraries, I will have to file a bug report against the library repo. This restriction will become apparent in the new symbol library file format and will have the same limitation as the footprint library names. I could silently replace the illegal characters with underscores but then someone would file a bug report that the name of the symbol was changed unexpectedly. Maybe at some point in the future I will change this but not for the stable 5 release.

[Thomas Figueroa (tom-figueroa)]

They're mine, and it's no real trouble to fix them on my end. This report is merely to document what had occurred (it wasn't a problem prior to the symbol overhaul).

[Wayne Stambaugh (stambaughw)]

Since this is the expected behavior since the symbol library table changes I'm going to set the status to invalid.

[Chris Pavlina (pavlina-chris)]

I'm really disappointed we don't have a smoother way to handle this. Historically we have allowed forward slash in names, and there are several component vendors who use them in their part numbers. It's a shame we can't continue to allow them in names, but even if we don't I feel like we should adapt old libraries properly. You're right that we can't _silently_ change them but we should offer to do it for the user. Otherwise people are going to be surprised and not understand why their parts suddenly don't load when 5.0 is released.

[Wayne Stambaugh (stambaughw)]

It's not as if I didn't think about it. It's one of those damned if you
do, damned if you don't decisions. If I automatically replace illegal
characters, someone will file a bug report about symbol names not being
respected. If I don't replace the illegal characters, then you could
end up with broken symbol links. I'm fine with changing this if that
what most users prefer.

In the future, I would like to stop using the file name as the symbol
name. There already is support for names in the footprint library
format which would eliminate the file name character restriction. I
would also use some kind of escaping mechanism for the ':' and '\'
characters in the LIB_ID parser which would allow users to use any
character except for new lines for library item names.

On 11/16/2017 3:00 PM, Chris Pavlina wrote:
> I'm really disappointed we don't have a smoother way to handle this.
> Historically we have allowed forward slash in names, and there are
> several component vendors who use them in their part numbers. It's a
> shame we can't continue to allow them in names, but even if we don't I
> feel like we should adapt old libraries properly. You're right that we
> can't _silently_ change them but we should offer to do it for the user.
> Otherwise people are going to be surprised and not understand why their
> parts suddenly don't load when 5.0 is released.
>

[Chris Pavlina (pavlina-chris)]

> It's not as if I didn't think about it. It's one of those damned if you
> do, damned if you don't decisions. If I automatically replace illegal
> characters, someone will file a bug report about symbol names not being
> respected. If I don't replace the illegal characters, then you could
> end up with broken symbol links. I'm fine with changing this if that
> what most users prefer.

Sorry, that's a false dichotomy. The only choices are not "fix it silently in the background" and "do nothing". We already have a nice new dialog that handles remapping, it should do this interactively.

Look, I don't want to go on another big ranty UX crusade, especially when I haven't been active lately... but this is bad. Fixing the way this mangled one of my projects took way more "power user" kicad knowledge than we can realistically expect users to have.

[Hildo Guillardi Júnior (hildogjr)]

@Thomas
I have this problem in last KLC migration (and was no in the my personal, but in software library mainly with Microchip library. In GitHub we are working to not happiness again).

To fix do (propose):
1) Open the *.lib in a text editor and replace "/" to "_" in each name;
2) Open the schematics and do the same.

The KLC (libraries definition) not allow ":" because will be used as library separator and neither "/".

[Hildo Guillardi Júnior (hildogjr)]

I reported this in the forum https://forum.kicad.info/t/important-symbol-library-table-merged-into-development-branch/8447/16

[KiCad Janitor (kicad-janitor)]

Fixed in revision b82bd8e0c58f1647f72e77b1d0762f1fe7669391
https://git.launchpad.net/kicad/patch/?id=b82bd8e0c58f1647f72e77b1d0762f1fe7669391

[Wayne Stambaugh (stambaughw)]

I pushed a fix for this issue. Symbols with names that have characters that would be illegal in a library ID name should now rescue and remap correctly. Please let me know if you have find any issues.

[Christoph Nieß (toffi-mixedstuff)]

Ran into that problem today with today's nightly build on OSX. The name gets remaped "behind the scenes", still displays with a '/' and the schematic breaks upon reopening.

Also, if the library can't handle those characters in a component name, it shouldn't be possible in the component editor to use them in names. That still is possible, so the problem could be considered a library editor bug.

Version Info:
Application: kicad
Version: (2017-12-16 revision 845ca5f)-master, release build
Libraries:
    wxWidgets 3.0.2
    libcurl/7.54.0 LibreSSL/2.0.20 zlib/1.2.11 nghttp2/1.24.0
Platform: Mac OS X (Darwin 17.3.0 x86_64), 64 bit, Little endian, wxMac
Build Info:
    wxWidgets: 3.0.2 (UTF-8,STL containers,compatible with 2.8)
    Boost: 1.61.0
    Curl: 7.43.0
    Compiler: Clang 7.3.0 with C++ ABI 1002

Build settings:
    USE_WX_GRAPHICS_CONTEXT=ON
    USE_WX_OVERLAY=ON
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_SPICE=ON

[Wayne Stambaugh (stambaughw)]

I'm pretty sure the reloading issue was fixed. The rescue dialog should
have flagged the bad part name and requested a rescue. If you ignored
this or have rescuing turned off, there is not much we can do about
that. That being said, I agree that you should not be able to place a
symbol with an invalid name in the first place. I will take a look at this.

On 12/17/2017 4:52 PM, Christoph Nieß wrote:
> Ran into that problem today with today's nightly build on OSX. The name
> gets remaped "behind the scenes", still displays with a '/' and the
> schematic breaks upon reopening.
>
> Also, if the library can't handle those characters in a component name,
> it shouldn't be possible in the component editor to use them in names.
> That still is possible, so the problem could be considered a library
> editor bug.
>
> Version Info:
> Application: kicad
> Version: (2017-12-16 revision 845ca5f)-master, release build
> Libraries:
> wxWidgets 3.0.2
> libcurl/7.54.0 LibreSSL/2.0.20 zlib/1.2.11 nghttp2/1.24.0
> Platform: Mac OS X (Darwin 17.3.0 x86_64), 64 bit, Little endian, wxMac
> Build Info:
> wxWidgets: 3.0.2 (UTF-8,STL containers,compatible with 2.8)
> Boost: 1.61.0
> Curl: 7.43.0
> Compiler: Clang 7.3.0 with C++ ABI 1002
>
> Build settings:
> USE_WX_GRAPHICS_CONTEXT=ON
> USE_WX_OVERLAY=ON
> KICAD_SCRIPTING=ON
> KICAD_SCRIPTING_MODULES=ON
> KICAD_SCRIPTING_WXPYTHON=ON
> KICAD_SCRIPTING_ACTION_MENU=ON
> BUILD_GITHUB_PLUGIN=ON
> KICAD_USE_OCE=ON
> KICAD_SPICE=ON
>
>
> ** Attachment added: "remapping.png"
> https://bugs.launchpad.net/kicad/+bug/1732236/+attachment/5023877/+files/remapping.png
>

[Christoph Nieß (toffi-mixedstuff)]

Just to clarify: I meant that you shouldn't be able to create a symbol with an invalid name in the first place. The editor doesn't even comment on the name, though.

Stopping them from being placed might be good, too.

[Maciej Suminski (orsonmmz)]

FYI, I added a rule to the symbol name validator to prevent the new illegal characters.