Just wanted to mention that I thought I saw that the edit-object-text-after-moving behavior just got removed.

Also this might be a GitHub or dev list topic but imo the main process shouldn't have anything to do with anything from the gui, including object/line geometry. The only thing it should be concerned with is audio and message processing, and the bare minimum info necessary to accomplish that.
So the main process would get info on which connections are made or removed, and what order the inlets and outlets are in but that would be it.

@seb-harmonik.ar Yeah, I noticed this too. Miller reverted it for some reason. I have pinged him on Github to ask for the reason. It seems like a settled issue, but sometimes we need his perspective as well...

@danomatika I remember someone giving some reason for reverting but still feels like a strange decision imo.
Maybe there should be some option/preference..
edit: ah, I see in the thread you make the same suggestion..

@danomatika said:

@seb-harmonik.ar Yeah, I noticed this too. Miller reverted it for some reason. I have pinged him on Github to ask for the reason.

From the comment in the source code, it seems that some users frequently do:

1. Ctrl-D to duplicate an object.
2. Mouse move.
3. Retype immediately into the object box.

... which, with the "no-edit" change, requires an extra click.

(My suspicion here is that "some users" = only Miller Puckette, but anyway.)

In github, I had commented two months ago that this really should be a user preference.

Now, granted... unpaid open source project, volunteer development, a couple of months inactivity on a non-critical issue is not at all surprising. So I wouldn't read anything into non-response.

It may be helpful for other forum users to comment on the github issue. Where it stands now, in github, is that there's MSP's view (which looks to me like "I want mouse-move-edit, and it's my project"), one grumpy user (myself) strongly opposing it, and a couple of votes in favor of a user preference. Because it takes developer time to add a user preference, it may require input from more users -- currently there's not enough demand for them to take the time, but if 20 users ask for the same change, then that's different.

hjh

@ddw_music said:

In github, I had commented two months ago that this really should be a user preference.

Actually it looks not crazy-difficult to implement that myself. I can't prioritize that project so it might take a little while, but I think I see the main code bits to take as models.

hjh

@ddw_music I might take a look at this and add the preference to pd-next too, if it isn't accepted. after all it's just an aesthetic/editing thing that doesn't affect the objects or patch format at all..
I think another option would be to have a keybinding to edit currently selected object(s?), since the users who want to edit object text after ctl-d need to use the keyboard at that point anyways