When a folder is moved from one tree location to another in a synchronised IMAP
account, the folder location (URL) is not updated in the QuickFolders Tab
pointing to the moved folder. 

Expected behavior (which works in POP mail) is that QuickFolders automatically
updates the Tab to point to the new location.

WORKAROUND

drag the email to another QuickFolder while holding SHIFT to force moving to
that location - this way QF will update the location correctly. Generally try
not to drag mails or folders INTO the folder tree, dragging to QuickFolders
Tabs (and their folder submenus) is generally faster and easier as it will
avoid vertical scroll-dragging which is tedious and error prone.

Here is a low level technical description of what the FolderListener
experiences when moving a folder within an (IMAP) folder tree:

1 - OnItemRemoved  (same event as when a folder is deleted)
    my code stores the old folder in a property "lastRemoved"
    it also checks a property "lastAdded" and, if this was different would
update referential integrity of any QuickFolders pointing to the "removed"
location. Obviously in the IMAP case the lastAdded is not currently set (set
before the removal) 
QuickFolders then _resets_ both lastAdded and lastRemoved properties as it
"assumes" that OnItemRemoved was the last one.

2 - OnItemAdded  (same event as when a folder is manually created in the tree)
    my code stores the foldeer in a property "lastAdded"; nothing else happens
here

3 - OnItemEvent the event "RenameCompleted" is fired:
    QuickFolders uses two properties:
  QuickFolders.FolderListener.newFolderName
  QuickFolders.FolderListener.oldFolderUri 
  - it would update the Quickfolders model (list of tabs) according to a
callBack function which is called when manually _renaming_ a folder (while
leaving it in place) and thus ensure refeerential integrity. Unfortunateley the
callback to set these properties was not triggered in this case.

I guess my best bet would be to add code for (3) to test whether I am in IMAP
and tryu to conserve / retrieve the old (deleted) folder URI to check whether
it leads to inconsistency. then compare the folder.prettyName (which should be
unchanged) with that of the old folder (most likely I will need to remember
that as well) - if it matches I can reassign the new folder URL to the
QuickFolders tab. At the end, delete any trace of old folder names from the
Listener properties.

I am currently experimenting with a fixed version. In theory it works well
(even when you rename a parent folder). The only major problem is that either
Thunderbird or Gmail arbiitrarily encode some parts of the folder URI for
subfolders, without any rhyme or reason. I have seen this happen to subfolders
of the special
 [Gmail] folder:

imap://thunderbirddaily%40gmail.com@imap.gmail.com/[Gmail]

I had a new folder called "Bug 26645" which had the folder URI
imap://thunderbirddaily%40gmail.com@imap.gmail.com/[Gmail]/Test/Bug 26646

- after renaming the folder a number of time (alternating the name between "Bug
26646" and "Bug_26646" the URI has changed:

imap://thunderbirddaily%40gmail.com@imap.gmail.com/%5BGmail%5D/Test/Bug%2026645

this makes it hard to match the URI path when checking for changes. I am also
using the "decodeURI()" function for matching paths, but when replacing the
path it will use the old "parent path" which may have the non-encoded parts in
it. So I need to make the algorithm more resilient against this problem.

The error console will display details during the renaming operation as long as
QF options > Advanced > debug is activated.

Created an attachment (id=8601) [details]
4.14 pre 12

Here is a test version

tested so far renaming / moving works, except in some instances (when inserting
a space in a file name) an encoded string may lead to a disconnect. Dealing
with this algorithmically is actually more difficult than I thought - I was
trying for a few hours already but it is tricky.

Note: all Asian locales are removed from this version because of a 1000kB limit
on the server

Closing bug for now (fixes where in 4.14 - released on 25/03/2019) - if new
referential problems caused by moving / deleting folders come to light I can
reopen it.

I tried to reproduce this problem, using the current release version of
QuickFolders. I did *not* manage to reproduce it.