Yes, I would love a way to write a private function or method.  There are many tasks where I could use that.  I agree it's less straight forward than having a string of commands laid out in a file, but I think anyone who spends much time at this will find themself writing the same code in multiple contexts and wish there was a way to do it once and be done.  Also, presumably the software is attractive to people with some programming background.  And in that case not being able to write a subroutine, or just discovering that it's not possible, might be more confusing than learning how to do it in a new environment.

I noticed a quirk of the visual tools, that you may already be aware of, but it was difficult for me to make sense of.  I was working in a pattern with way too many points with similar names, many of which had already been moved or altered, but which still showed in multiple states in the plot.  I used the magnet visual tool, to rotate an edge, and the animation showed exactly what I wanted.  But when the code was inserted, the actual rotation was something completely different.  I finally realized that the point I was able to select on the screen was no longer in that position, and so the real rotation was about the new point of that name.  Of course, when I was selecting the point for the tool, I wasn't thinking about the fact that it no longer existed or that the name had been reused, so I was really lost trying to figure out why the results didn't agree.  

I see what you mean... try moving them may be?

perfect, thanks!

Magnet is a really useful function, I finally thought to check that it works with paths and not just lines (at first I didn't realize this and was creating short lines in the initial direction of the path just to use magnet).  You ought to add this to the function description.  And, also that it allows a negative sign in front of the path/line to reverse the orientation.  But with the visual tool, it's not possible to click an arbitrary path (only lines) and add use it, the name has to be typed in.  The animation in the visual tool is also very useful, both as a visualization, and I like to add some extra points temporarily to confirm the alignment, and then remove them before inserting the code, to keep from over crowding the drawing.

I think I've asked about this before but, I'm not sure I've gotten clarification.  There's a quirk when patterns are explicitly named and the same name is reused.   Instead of the pattern being replaced with the most recent instance, a union of both pattern is created.  E.g,

Is there a command like dash() to generate the dot-dash line style that the pleat function creates?  I have a pleat I'd like to draft by hand, and could use one more line style to distinguish the fold from other markings. 

I was thinking the same thing :) dotdash(), you think?

Sounds good to me.

Normally I don't do much converting between inches and centimeters, but I have been lately and I realize the cmtoin() function isn't sufficient for me because it rounds to 0.1 inch.  I can work around by just using a conversion factor (cm measurement)*(2.54).  And if I need to round I can use round().  Would it be possible for cmtoin() and intocm() to report at least 2 digits of accuracy?  I guess another option would be to have an optional second parameter that defaults to 1 and specifies the digits of accuracy, similar to the round() function.

Frankly, we added this function mainly to deal with the 'type' cases, and adding a parameter seems a bit too much. What we could do, is default intocm() to 1 decimal, and default cmtoin() to 2 digits. I guess this has to solve most of the cases.

I agree, a parameter would be awkward.  2 digits on cmtoin() would solve my issue.  I was using it with type() as a quick way to confirm a finished measurement on a pattern, but the rounding made me second guess things.  I hadn't noticed the rounding before.  Thanks.

Posted a ticket :)

Fixed, will be live with next release - Monday or Tuesday.

Released :)

Can you explain the difference between sz74, torso position, and sz82, neck depth?  The instruction for both says measure horizontally from the neck base (point Z) to the depth of the shoulder blade protrusion.  I'm thinking the smaller one, neck depth, is correct, and maybe the larger one is measured from the side neck base (point Y)?

Okay, I figured the first one out, sz82, should be measured from neck back horizontally to spine level, not shoulder blade.  It's redundant, sz82 = sz74 -  sz81

Next question.  

Okay, never mind again, measuring sz74 from side neck would put the curve of the back too far forward, so everything is perfect with that description.

Hello, sorry, I was away from the forum for a couple of days.

Yes, I did realize that some of the confusion with 74 and 82 is that they may be used for different size groups.  However if the description is correct and they are a duplication, then the calculation the program produces is incorrect, because in the sizes I've looked up, sz74 = sz82 + sz81, which is why I thought perhaps it's just a measurement to spine for convinience.

Yes, we shall edit that one, thanks!

Better late, than never, right?

Oh, thank you, I was going to ping you on that.  Also I noticed, that there's still an issue where if a pattern that contains a dotted line is transformed, the dotted line becomes solid.  Dashed lines stay dashed.  I just tried mirror() on a pattern, I'm not sure if other functions as well.  If I mirror a dotted line that's not in a pattern, it stays dotted.