When you create a new connection, doesn’t the program automatically assign a new net name to it?
My question then is, if you connect 2 nets, what name is assigned to the new merged net?
In a similar case, the Eagle CAD always raised a warning about what name to give to the new merged net?
There are rules that determine what the resulting net name will be. A label for example will take precedence over an automatic name.
But the program doesn’t necessarily have to consult the netlist to see if any connections were added, you don’t have to stipulate the mechanism. If it’s undesirable that the editor not create connections when symbols are moved around that’s a valid request. The problem is distinguishing between intended connection creation and not. Perhaps there should be two kinds of move.
Maybe these posts should be merged with all the previous discussions.
could you please provide a link to previous discussions?
Sorry I don’t have links so you’d have to search for them yourself, like me. Like hmk we have a sense of deja vu.
The general problem with this is that the computer can not know what individual people want. A software has to work in some way and sometimes its not the way you want and sometimes its what you wan’t. In addition some people are used to something else that may do something differently and have hard time starting to think in new ways.
So there are several ways one could deal with them but all of these have downsides:
-
It could be a user settable preference.
The problem with this approach is that it makes the software harder to learn. Since now not only do you need to know what setting is on when reading guides, tutorials and so on. And new users would still have this reaction that the software sucks as it does this that i don’t want. -
There could be 2 separate tools. One that does not attach the wires and one that does.
Problem with this is nearly the same as above but less of a problem for tutorials. -
One could just expect users to learn new workflows.
Again the reaction is mostly the same. -
One could come up with a new paradigm, that actually solves the problem. But one can not just suggest something that happens to work for you in this use case, it must make all users better of on the long run.
However, even this approach does not really solve the problem, because it does nothing to people who are like this is what I expect and this is how it should work.Example of this kind of thinking. Instead of making the pins part of the symbol make the pins, either areas or launch a dialog when you connect to the symbol. And the pin would appear where your connecting from. This way i could have free in order, symbols rotated at non 90 degree angles, because i do not rely on snap to connect.
But this would need the entire program to be rethought
That is a payne in the *** indeed. I believe it is/was a much needed function because of the default “stinkin’ N key”. The default N key is an even bigger payne in the ***
The stinkin' N key - #2 by paulvdh.
I have had only need for this function just because of the N key. Since I removed that shortcut I haven’t used this tool anymore.
If that shortkey never existed, it would be really hard to get things off grid in the first place.
So yeah. It sucks that accidently touching the N key can ultimately result in shorts as well…
I think that dragging a wire should not ever make a connection. If I need a connection, I can just make one…
Kind regards 
Bas
1 Like
Some people make a *&^%$#@! of things because of the n key, but it’s also common that beginners with KiCad set the grid to something random because they do not know about the “grid thing”.
I find it quite strange this has not been really fixed yet. Even something simple as never allowing a grid smaller then “50” for schematic symbols would fix it.
For example Once again: any way to disable "autoconnect"? and [Feature request] Schematic Editor: add option in preferences to disable autoconnect (#16834) · Issues · KiCad / KiCad Source Code / kicad · GitLab, but more aggressively Symbol editing and the netlist (maybe you want to read the last post of that first).
Thanks for the links.
Now I know that it’s called “autoconnect” feature.
I still haven’t found a single advantage from this feature.
Hope that someday it will be fixed, because I’m just afraid to touch the wires or move the symbols in the schematic editor now. 
Someone just called it that, it’s not a name of a feature AFAIK.
At severe danger of dredging up the many many discussions before, to be clear this is not something that will be “fixed”, because it is by design.
1 Like
It’s not a feature, it’s just the result of how the schematics editor works.
Kicad had no concept of schematic lines that overlap but do not connect to each other. As long as they connect coordinate wise, they just connect electrically.
Doing something else wouldn’t be like removing a feature, it would make things much more complex as Kicad would have to build an internal netlist or introduce a 3D stack of schematic items or something like that.
Feature: a distinctive attribute or aspect of something.
It’s not a feature, it’s just the result of how the schematics editor works.
That would be called a feature, not a deeply designed one necceserily, but feature nonetheless. Possibly should be called a emergent feature? Although this one is clearly working as designed.
As I mentioned way up the thread, I trained myself to use the G hotkey whenever I drag single or groups of symbols instead of “left mouse button hold down” so I can see if I’m going to get overlapping wires joining before I finalize the drag. This saves a lot of hassles.
but feature nonetheless.
It may as easily be considered a bug. I as programmer know that there is an extremely thin line between whether something is a bug or a feature. And this line may shift. At times I am not even sure if the thing I am looking at, is a bug or a feature. Just like these connection that KiCad may add autonomously. I think it is one dangerous hot potatoe bug. But I do can understand why some people consider it to be a feature.
At work we had a machine with a bug. It would stop sometimes for unknown reasons.
So we added a new feature, a general process timeout of 50s. The timeout occurs only if we are not logged in.
Now one year later, we are experimenting with an improved algorithm which works fine. Only the cycle time itself now is set at 60s which used to be 42s. Sometimes we forget to log in, we don’t always have to. Than we see that our future abruptly aborts the cycle after 50s. The randoms stops, the actual bug, was solved in the meantime but the timeout remained.
The feature which once ‘solved’ a bug has now become a bug itself 
Not really.
The procedure to use the machine is to log in first. Train yourself to log in first 
I assume that Kicad keeps a database of schematic coordinates and a corresponding net name.
If I am wrong please correct me.
Using x,y with x-vertical and y-horizontal, then the coordinate data (8,1,VDD) and (8,9,VDD) would cause Kicad to draw a vertical line from 1 to 9 and label it VDD.
If a small (7,4,RST) to (7,5,RST) zig-zag is dragged from the 7-vertical to the 8-vertical and dropped there creating the new (8,4,RST) to (8,5,RST) coordinates, then now Kicad makes a decision to rename one of the nets to the other net name and place connection dots at the (8,4) and (8,5) coordinates.
So don’t do that, leave all four coordinates in the database.
Thereon out Kicad could display the (8,4,RST) to (8,5,RST) line segment in RED to let the user know that there are two overlapping nets that occupy the 8-vertical.
Right-clicking any RED line segment could produce a selection list to allow the user to grab ahold of one of the contentious nets to move it again to eliminate the contention, or not.
If not, the schematic may become unintelligible when printed but, the database could still be followed correctly when it comes time to create a PCB net list.
It would remain the user’s responsibility to remove all of the REDness from the schematic.
All for now
I don’t think it does, and if it does, it will be only as a temporary cache to allow faster rendering and not as a replacement of a netlist or something.
In the schematic file, wires are stored as a list of coordinates with an UUID.
https://dev-docs.kicad.org/en/file-formats/sexpr-schematic/index.html#_wire_and_bus_section
Labels are also stored as coordinates with an UUID and some other attributes:
https://dev-docs.kicad.org/en/file-formats/sexpr-schematic/index.html#_local_label_section
And in the end it just uses matching / overlapping coordinates to figure out which section of wire gets which net name. I guess that the presentation in memory is somewhat similar to what is in the file, but if you want to go that deep, the source code is also freely available on gitlab. One of the strong points of Open Source software 