[IDEA] Show last modified date and tiddler size when tiddler already exists on import

[yaisog]

If one has multiple wikis and regularly copies some tiddlers from one to the other, it's hard to keep track of which is the newest version.
Import only notifies that a tiddler already exists.

Every file copy tool I know of will give the user some more information in that situation; at least the last modified date and object size, sometimes even a content comparison. That would be a good way to go for TW, too. I can imagine using a button pop-up or accordion thing to show this information only on demand and to not take up too much space in the UI. Personally, I'd be content with modified in a human-readably format and tiddler size in bytes (or maybe lines?).

This could also be useful in the upgrade UI where people often get confused by the various messages. A date comparison could go a long way to clear that confusion.

[pmario]

See the Import tiddler preview settings

[pmario]

I personally think there should be a "global setting", that defines the default, as shown above.

AND there should be some tabs if the preview is visible. IMO it would make it much faster to switch between the different preview states. Especially useful for long lists, where atm we need to go up -- change setting -- go down again

IMO you should rename the issue to Improve preview ....

[yaisog]

How did I never notice the import preview?!? (Well, maybe I did a long time ago, but forget about it again.)

This is way too hidden up there. From a UX perspective, where there is a conflict, my attention is focused on the conflict message. I need a visual hint there that gives me comparison options. The unfold icon to the left of the tiddler name that only becomes marginally useful when I change some other setting somewhere else is terrible! Like I said, I haven't used this in 10+ years of TW5 use with regular importing.

Taking a closer look at the existing functionality, I find it underwhelming, which probably explains why I forgot about it if I really did see it before.
In my wiki it looks a lot less colorful:

Especially the date formatting is not something I would call "human-readable". In a "diff" view I also do not want to see the fields that are the same.

What I am used to and what this should be (not necessarily look) like is how Windows does it:

xplorer² (my file manager) uses something similar, with a bit more convoluted UI:

This is also useful. It gives me the information I need to make a decision where I need it.
The yes, no, yes to all, etc. options are nice, but maybe not really necessary for TW. Although one could imagine such functionality for the checkboxes to the left of $:/Import.

I will leave the issue title as is, because I am not talking about the bunch of extra clicks needed to make this visible (after some deciphering).

[yaisog]

Here is a quick hack of $:/core/ui/ImportListing that makes the whole thing an order of magnitude more useful:

\define overWriteWarning()
\whitespace trim
<$list filter="[<currentTiddler>!has<suppressedField>]">
<$text text={{{[subfilter<payloadTitleFilter>!is[tiddler]then[]] ~[<lingo-base>addsuffix[Listing/Rename/OverwriteWarning]get[text]]}}}/><br>
<$log />
existing tiddler: <$view field="modified" tiddler=<<payloadTiddler>> format="date" template="DDth mmm YYYY 0hh:0mm:0ss" /><br>
incoming tiddler: <$view field="modified" tiddler=<<currentTiddler>> subtiddler=<<payloadTiddler>> format="date" template="DDth mmm YYYY 0hh:0mm:0ss" /><br>
</$list>
\end

It gives this:

Caveat emptor: I have no idea how the import mechanism really work. Like I wrote, this is a hack job. Maybe it breaks something, but I don't think so.

PS: There is no filter operator to access subtiddler content directly, right? For some hint like "(newer)" I'd like access to the raw field values in a filter...

[pmario]

In my wiki it looks a lot less colorful:

That's a problem of your wiki's palette ... If you have a closer look at the WIP palette-manager edition you'll be able to fix this problem very fast. If you search for: diff

[pmario]

... I find it underwhelming, which probably explains why I forgot about it if I really did see it before.

I do try to use "positive" language in issues even if I'm frustrated. For me as a core contributor reading terms like "underwhelming" doesn't trigger motivation to engage with the problem. ... I do like to read stories about challenges and examples how to "may be" solve them ...

So ... I do like the examples you posted ... especially the last one, which I think is relatively straight forward. ... The code for the $:/Import mechanism is one of the most complex in wikitext and in JS. ... So no promises here.

[yaisog]

For me as a core contributor reading terms like "underwhelming" doesn't trigger motivation to engage with the problem.

Sorry about that. I will try to be more constructive in the future.

[yaisog]

Hacking a bit further, I arrived at a solution that I personally find useful (enough):

The table header even summarizes nicely what I need to know at this time, because I don't want to compare numbers manually.

The table inside the import table maybe takes a little too much space? But I guess for a limited number of duplicates during import this would be OK. For non-duplicates it's not shown.

Here's the code for the modified overWriteWarning in $:/core/ui/ImportListing:

\define overWriteWarning()
\define date-format() YYYY-0MM-0DD 0hh:0mm:0ss
<$list filter="[<currentTiddler>!has<suppressedField>]">
<$list filter="[subfilter<payloadTitleFilter>is[tiddler]]" variable="void">
<style>
.tc-import-table .mwi-import-comparison th {
	width: 50%;
}
</style>
<$text text={{{ [<lingo-base>addsuffix[Listing/Rename/OverwriteWarning]get[text]] }}}/>
<$set name="incomingDate" tiddler=<<currentTiddler>> subtiddler=<<payloadTiddler>> field="modified">
<$set name="incomingText" tiddler=<<currentTiddler>> subtiddler=<<payloadTiddler>> field="text">
<$let incomingLines={{{ [<incomingText>splitregexp[\n]count[]] }}}
	currentLines={{{ [<payloadTiddler>get[text]splitregexp[\n]count[]] }}}
	currentDate={{{ [<payloadTiddler>get[modified]] }}}
	incomingDescription={{{ [<incomingDate>compare:date:gt<currentDate>then[newer]] [<incomingLines>compare:number:gt<currentLines>then[larger]] +[!is[blank]join[, ]addprefix[(]addsuffix[)]] }}}
	currentDescription={{{ [<incomingDate>compare:date:lt<currentDate>then[newer]] [<incomingLines>compare:number:lt<currentLines>then[larger]] +[!is[blank]join[, ]addprefix[(]addsuffix[)]] }}}
	>

|tc-center mwi-import-comparison|k
|!existing <$text text=<<currentDescription>> />|!incoming <$text text=<<incomingDescription>> />|
| <$text text={{{ [<currentDate>format:date<date-format>] }}}/> | <$text text={{{ [<incomingDate>format:date<date-format>] }}}/> |
| <$text text=<<currentLines>> /> lines | <$text text=<<incomingLines>> /> lines |
</$let>
</$set>
</$set>
</$list>
</$list>
\end

The nice thing is that it looks like no code for the actual importing mechanism has to be touched. It is all just inside the warning message macro. I just needed to find out how subtiddlers were used in the import process.

Whoever wants to make a PR could use this as a starting point or inspiration, maybe. (I'm looking at you @pmario 😉)
I only put the CSS in there to have it all together in one place; that has to go into the stylesheet, of course.
There's probably a bunch of rules of core programming that this hack violates, and I guess all text has to be made language specific and new such tiddlers will have to be made. This is just meant as a demonstration of what I would find useful when importing...

Have a nice day
Yaisog

[pmario]

Hacking a bit further, I arrived at a solution that I personally find useful (enough):

That looks interesting. As you found out the $:/Import tiddler is like "virtual / temporary" plugin with some extra functions to toggle import state. ...

I'm not sure, how the message UI texts are created atm. ... I only know that it's an array with messages that is returned by the different import modules. So not sure atm if creating a table is easy or not.

Your code tweaks will definitely help if anyone will have a closer look. ... I did add the idea to my bundler issues, so I don't forget about it. ... wikilabs/plugins#136

[pmario]

date format will probably need a configuration somewhere. Don't know if it works for everyone hardcoded. ... But will be good enough for a POC (proof of concept)

\define date-format() YYYY-0MM-0DD 0hh:0mm:0ss

[AnthonyMuscio]

I tried both of the above replacement for $:/core/ui/ImportListing: on tiddlywiki.com and I get this;

• Sorry I do not know how to reduce the image size in GitHub

[yaisog]

Let me make a PR for this, so we get the vercel preview to play around with...

[AnthonyMuscio]

In a number of other places I have being discussing improving the differences methods available, one key reason is to support the import process.

I would like information visible for existing tiddlers at import without needing to select different previews etc... We should show a total for the number of fields changed, a summary of the fields that contain differences and the ability to exclude fields such as created and modified (from the differences check) since if only these change, its a trivial difference.

In a related way It would be good if incoming tiddlers could request expansion and rendering during import so the user gets to see pre-import notes, before importing. eg field display-on-import=yes then the Import process renders and displays that tiddlers body.

• This would allow help and even sophisticated pre-install checks to be designed, in to packages to import.

[yaisog]

Hi @AnthonyMuscio, you're talking about a much larger project. Some of these ideas are certainly useful, but would be significantly more work with a separate UI to configure all that. My approach was to be minimally invasive while providing the most relevant information during the import process. I think that something like your idea could supercede my rather small change, if someone is willing to work on that, be it in a plugin or as part of the core.

Also, I do think that the modified field is the most important in a comparison, though, since I usually want to import only newer tiddlers and not overwrite newer ones with older ones.

[AnthonyMuscio]

you're talking about a much larger project

• Actually its not large at all.

The differences component is in part addressed by the Levenshtein operator discussed here https://talk.tiddlywiki.org/t/what-if-we-would-implement-a-3-way-merge-system-into-tw/6248/11?u=tw_tones and the other modifications are in fact trivial given what I now understand about the Import process.

• But I am, fine with you keeping the scope small.
• I will propose these improvements when I get the opportunity.

However please consider introducing this new element via a tag driven solution so I and others can add additional information to each import pending tiddler.

• I can help with these code patterns if you want.

[yaisog]

I have closed the PR. I will support you should you make another one to implement your idea.