I think the correct behavior for the weird example would be to ask if you want relative inclusions moved (in this case from test card foo to test card bar). Second best would be to change the {+John Abbe} to {test car bar+John Abbe}. Third best would be to not touch the inclusion syntax, but render test card foo+John Abbe as a card that doesn't exist (since it doesn't).

---

Here's the example john is talking about above:

Subtle rename error on relative inclusions. test card foo and test card bar exist. I created test card foo+John Abbe and relative-included it on test card foo. Then i renamed it to test card bar+John Abbe. Wagn still shows the inclusion syntax {+John Abbe} on test card foo, but renders it as test card bar+John Abbe.

 

I moved it out of example because it's a renaming / caching bug that's really outside of the core issue here. if it's not ticketed already it will be soon.

--Ethan McCutchen.....Wed Jul 16 11:10:49 -0700 2008

---

Something has changed so that the third best option is what is happening now.

  --John Abbe.....Wed Jul 23 00:21:13 -0700 2008

---

this was probably fixed by the 'expire old name from cache when renaming' fix. BUT it made me wonder if cascaded renames are handles properly-- looking into that.

  --Lewis Hoffman.....Thu Jul 24 17:32:58 -0700 2008

---

I don't think that's related to updating inclusions.

  --Ethan McCutchen.....Thu May 07 11:48:31 -0700 2009

---

When Wagn finds links/inclusions to rename it still labels the section listing them to "Links to Wiki on Wheels". We want "References to Wiki on Wheels", yes? Similarly, "Renaming will break links on the following cards unless they're updated:" -> "Renaming will break references on the following cards unless they're updated:"

  --John Abbe.....Tue May 19 18:03:16 -0700 2009

---

Does the renaming/caching bug you mentioned have a ticket yet, Ethan? Still getting third-best behavior; also got changed to . See http://dwagn.org/wagn/update_inclusions_when_renaming

  --John Abbe.....Tue May 19 18:39:50 -0700 2009

---

what you're calling third best is the most natural codewise. It would take a great deal more effort to change that by 1.0, so I think we should go forward with what we have and consider deeper patterns, prompting, etc later.

since relative inclusions are most often used in hard forms, I really don't know how option A or B would work.

If you want to make an Idea of the other options, though, that would be great.

  --Ethan McCutchen.....Wed May 20 09:54:51 -0700 2009

---

so to me the relative inclusions is a weird edge case (it behaves the same way with relative links, too, right?). Is it basically working well in the normal cases?

I fixed the Links -> references thing in the code.

  --Ethan McCutchen.....Wed May 20 10:01:14 -0700 2009

---

Cool!

The renaming problem is broader than i had noticed so far. See http://test.dwagn.org/wagn/relative_renaming for the aftermath of renaming "relative renaming+testing" to "renaming target+testing". Note that it offered to update "relative renaming" and "John Abbe" but updated neither (though it actually did edit the former to change the relative link & inclusion to be absolute). Is this the renaming/caching bug you mentioned, and does it have a ticket?

  --John Abbe.....Wed May 20 12:15:07 -0700 2009

---

 

John, are normal (non-relative) cases working?

 

OK, there are some challenges here:

 

1. relative inclusions are most often hard-formatted. We store references on these cards so they'll show up in related tabs and such, but that also means they will incorrectly show up on a rename list. For example, if User+*tform includes +image, and I change "John Abbe+image" to be "John Abbe's face", then there's no way to update his user card, but, as a reference it will show up on the list.

 

Here's my first fix. I changed "Renaming will break links and inclusions" to "Renaming could break links and inclusions". Which is more accurate anyway, thanks to plurals and such.

 

the same problem exists for all relative inclusions, though any that aren't soft formatted would at least be plausible to fix.

 

Here's what I would expect to happen by 1.0:

 

1. absolute inclusions and links (whether or not they are plus cards) get correctly renamed when card is renamed

2. relative inclusions and links don't change when the plus card referred to is renamed. If there's a reference to +B on A and I change A+B to C+D, then the +B should just stay +B. Note that this will mean it is listed in the references list as a possible target of updating but won't get updated.

3. however, relative inclusions and links are changed when the plus part in question is changed. This is the common case. Eg. A has a reference to +B. If I rename "B" to "E", then +B should be updated to "+E"

 

As far as I can tell, 1 is breaking on all plus cards, and 2 is breaking by leaving the (old) absolute name in place of the relative name. I don't know about case 3. Back to "in progress".

 

I don't see anything that looks like a caching bug any more.

 

  --Ethan McCutchen.....Wed May 20 14:45:02 -0700 2009

---

Non-relative cases seem to be working.

 

3 is having issues, e.g., try to change the name of http://test.dwagn.org/wagn/field and you get:

 

 

  --John Abbe.....Thu May 28 13:01:11 -0700 2009

---

Probably not directly related, but just in case, another renaming issue: renaming not updating and old names still working

  --John Abbe.....Thu May 28 13:03:48 -0700 2009

---

I have done a bunch of work on this but there's more complexity that needs handled, specifically behavior in regard to changing templates etc. should be in a branch on my local machine.

  --Lewis Hoffman.....Tue Jun 16 08:45:33 -0700 2009

---

man, it would be great if we could make sense of this ticket. It's very hard to see from browsing where things stand. My best guess is that we'll need a new ticket.

  --Ethan McCutchen.....Tue May 04 15:45:35 -0700 2010

---

I'm going to close this, since I have no idea what remains to be done. If there are still issues, let's make narrower tickets.

  --Ethan McCutchen.....Thu Jan 06 10:20:12 -0800 2011