Show number of selected nodes/vertices (this has already implemented for selected objects)

[matt.baker]

Why would this be useful? The below should sum it up.

Even in outline view with zoom at maximum you cant tell.

For objects it shows how many are selected, but not for vertices/nodes.

[matt.baker]

Also would be useful in the following case to show the number of lines/segments to determine if the path is closed as they both appear the same:

[Bri-Toon]

This is very well thought out, and I experience the same problem. The only thing I question is that more complex objects would have dozens of nodes. So, the person won't count to compare how many he or she sees over what is actually there. But I would be open to maybe a color indicator if there are nodes or vertices overlapping on the same path.

[matt.baker]

@Bri-Toon, that's a good point and the colour option also seems like a good addition.

This may also be of interest:

 

[JET_Affinity]

Coincident nodes is something to avoid in font glyphs. As I recall, Fontographer, since way back, displayed coincident sequential nodes (adjacent in the path winding order) with a dashed circle around them.

Auto-deletion or "merging" of coincident nodes is not necessarily a good idea, because you don't always want the same thing to happen in the results. Should the associated handles be retracted? Should just the two inboard handles be retracted? Should the resulting single node become a corner or a curve node? Or should the segment joining the two nodes simply be removed (i.e.; the path opened or cut between the two nodes)?

It can be simpler to just highlight the coincident nodes and let the user decide what to do with them. It's not uncommon for me, upon encountering coincident nodes, to select the frontmost one, use the arrow keys to nudge it, say, six increments in one direction, delete the joining segment, and nudge the moved node back.

Frankly, in general drawing practice, it's not that big a deal. One soon learns to sense when coincident nodes exist by the giveaway behaviors. But display of number of paths (open and closed) and count of nodes in the current selection should always be provided. So should path length. These are some of the reasons why I've always preferred programs with an "Inspector" based interface (as in FreeHand since around version 3) which tells you everything you need to know (and set) about the current selection in a tidy, concise palette, instead of having the  information scattered all across the interface.

JET