Danger? Branch => its subbranches, each orphaned

[JeffreyBenjaminBrown]

I had two nodes open, one of them qq smsn (which had like 50 or 200 children, many of them not marked smsn internally), the other some new thing with little data. I had both buffers open. I never deleted the entire contents of qq smsn -- at least so I believe; it seems like a hard thing to do without noticing -- but somehow its content was swapped for that of the new tiny thing. The many subbranches of qq smsn are now orphaned. At one point there may have been a cycle involving both.

Finding them and putting them back will I think be easy using git.

I was bouncing between buffer-mode and smsn-mode. I have not so far thought of an interaction that would cause this effect.

[JeffreyBenjaminBrown]

It highlights the value of restating branch names in subbranches. Some titles only make sense in the context of a particular ancestry, unless one repeats the title down the depth of its branches.

[joshsh]

You can check your activity log to see when that atom was last updated. If you completely replace the contents of the buffer with some other legal tree, SmSn will apply that entire diff, which involves deleting all previous children of the atom.

[JeffreyBenjaminBrown]

Yes, it is as if the entire buffer were deleted and replaced with something much smaller.

It is related to another strange phenomenon that I somehow have not had the words to express until now: Sometimes the label of the buffer I am in changes when I update the screen (sometimes via forward-view). It's confusing; I'll close one thing, and repeatedly end up back in it anyway, and the name at the bottom of the screen is changing. If my memory is correct, reliably I can end the cycle by going to the buffer list and closing both of the cycling buffers.

[JeffreyBenjaminBrown]

Congratulations for your Uber-ascension!

…

On Sun, Apr 2, 2017 at 10:19 PM, Joshua Shinavier ***@***.***> wrote: You can check your activity log to see when that atom was last updated. If you completely replace the contents of the buffer with some other legal tree, SmSn will apply that entire diff, which involves deleting all previous children of the atom. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#42 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIfQT--t9vU0cGi3iO8yxatjgqEy1a4Mks5rsIFwgaJpZM4Mw97d> .

-- Jeff Brown | Jeffrey Benjamin Brown Website <https://msu.edu/~brown202/> | Facebook <https://www.facebook.com/mejeff.younotjeff> | LinkedIn <https://www.linkedin.com/in/jeffreybenjaminbrown>(spammy, so I often miss messages here) | Github <https://github.com/jeffreybenjaminbrown>

[joshsh]

Thanks! Do post here if you are able to provide steps to reproduce either of the issues you have mentioned.

[joshsh]

Do you have any more information on this/these issues?

[JeffreyBenjaminBrown]

I can reproduce it right now by doing this:

Open up a view of the children of this node:

  + :E6ES1d1SeTrkXP7X: the unreviewed portion of jeff's changes, april 4. HEY JOSH

Then delete the first three nodes, which are these:

  · :I3xJ2eOW8tvu2Xyq: go up         music
  · :I6FaXC9LEy7tfkup: eyes-closed visions
  + :I9AIMXyT1dIbqh7n: the nodes in some Josh commits

Then visit the top node, which is now this:

  + :IAPDHoznQunAO9gY: err

(It will look similar because their content is largely the same, so watch for the title bar to change to know that it loaded.) Now quit that view.

Supposedly now you have returned to "the unreviewed portion ...". However root-node is still equal to the ID of "err". Refresh the view, and you'll be back at "err". If you hadn't refreshed the view, but rather made some edits and then pushed the view, you would have replaced the contents of "err" with those of "the unreviewed portion ...". That is why those two nodes have (at least roughly; haven't checked exhaustively) the same content.

[joshsh]

I wish (?) I could reproduce this, but following your instructions to a tee, I end up back at E6ES1d1SeTrkXP7X, where I can update, or even add a note "foobar" under err and push.

[JeffreyBenjaminBrown]

Are you deleting the three nodes by highlighting from the start of the first until the start of the fourth, pressing delete, and pushing to graph?

[joshsh]

To a tee.

[JeffreyBenjaminBrown]

What's your version of Emacs?

[joshsh]

24.4 (on Mac OS X 10.9.5)

[JeffreyBenjaminBrown]

Hmm. I've got 24.5.1 (on Ubuntu 16.04.2).

[JeffreyBenjaminBrown]

I'm upgrading to 25.1 right now.

[joshsh]

I have just tried in Emacs 25.1-1, also on Mac OS X 10.9.5). Same result.

[joshsh]

I will try on Ubuntu later.

[JeffreyBenjaminBrown]

It said 25.1 but it gave me 26.0.50! It's markedly faster -- big pages like the one we are discussing load with much less delay now.

The bug is still there for me.

[JeffreyBenjaminBrown]

I just saw it happen with a non-smsn-mode buffer. From smsn-mode I opened ~/temp.txt, edited some text, then saved, and found myself back in the previous buffer. I did it twice, the second time to see if it was really happening.

Will try to repeat now. time elappses After closing the two buffers, couldn't repeat it; not sure exactly what I did.

[joshsh]

Since you say it happens outside of smsn-mode, I'm going to close this issue for now. It will still be here and can be re-opened if you find it is a smsn-mode issue, as opposed to an Emacs issue.

[JeffreyBenjaminBrown]

I'm puzzled that you say I say it happens outside of smsn-mode. I reread this thread and I see I mentioned buffer-list-mode. But I don't edit a buffer from buffer-list-mode; I just switch between them.

I think it might be a memory problem. I had cleared out the node "+ :E6ES1d1SeTrkXP7X: the unreviewed portion of jeff's changes, april 4. HEY JOSH" from around a thousand to only 150 children. I was unable to reproduce it that way, so then I duplicated its children a few times, to where it had 900. Then I was able to reproduce it. (I didn't use buffer-list-mode at all in the course of that.)

[joshsh]

OK, let's try to do some troubleshooting in real time.