zim-wiki team mailing list archive

[Jaap Karssenberg <jaap.karssenberg@xxxxxxxxx>]

Beni Cherniavsky wrote:
... 8< ...
> Currently pyzim is close to the second and that's annoying - you have 
> to type the same thing twice to create a link!

Let me detail how it is intended to work in the current implementation: 
if the target and label already differ than the target will stay fixed 
while the text can be freely edited. However when both are the same they 
stay "linked" until the user eplicitly sets a different target.

The reasoning is that it would be very counter intuitive to see an URL, 
edit it, and find the target did not update. The same goes for page names.

The current dialog in pyzim allows you to specify both text an target, 
but this is not mandatory. If you enter the target, hit <Enter> twice 
(leaving the text empty) it will just use the target as the text. If you 
select text and open the dialog hitting <Enter> twice will turn it into 
a link.

I myself find that links become better behaved by treating them like 
objects that need to be edited with a dialog instead of a formatting 
style. But obviously there are corner cases.

The auto-linking of urls, camelcase, etc. should further reduce the 
numer of times that you actually need to use the dialog. Auto-linking 
behavior should be controllable from preferences because it can be very 
annoying when it gets things wrong. Also the undo action should properly 
undo autolinking as a separate editing step.

... 8< ...
> I'm not sure how all this should be blended, but here are some 
> tricks/ideas:
>
> * Show broken links in red: this makes it obvious when you are 
> breaking/retargetting links.

This is something I would really like - at least for internal links - an 
url checker is something else. I did not implement this in the perl 
version because of the cost of resolving links. In the python version we 
have the SQLLite driven index which make looking up page links much 
cheaper.

Should also set a style property for broken links in html export while 
we are at it.

> * Don't even show text field in Link dialog, only target.
>   This makes it clear that text is edited by directly editing the page.

Disadvantage is that when auto-formatting does not pick up the link you 
first type text, then go back select it and add the target. While now I 
hit the dialog, enter the target, hit Enter, and continue typing. Maybe 
very personal preference, but I don't like going back while typing in a 
flow.

> * Have checkbox or radiobox in Link dialog to toggle 1:1 mode (default 
> on).

How would that work ?? Once you have both a label and a target, how 
would you display it after switching back ? In general I would like to 
avoid switchable behavior for this.

> * Show the 2 link modes in different colors.  E.g. blue/red for 1:1 
> links, green for other links.

This could very well be done. Maybe keep the same color, but use e.g. a 
subtle underline to distinguish. Anyway the style would be controllable 
from the config file - so you cold make the colors more obvious if you 
want to.

> * While the editing cursor is on a link, it expands to also show the 
> target, e.g. [link|target].
>   When the cursor leaves the link, it collapses and you see just the 
> text in blue.

This is difficult to get right when it is inline in the textview. Also 
makes the page look "unstable" because text starts moving around when 
you move the cursor over the page.

Please note that the signals for mouse over are there already. Link 
target is displayed in the status bar on mouse over. Probably would more 
obvious when using tooltips for this. Should not be too hard to make.

> * While the editing cursor is on a link, a tooltip-like mini-dialog 
> hovers beneath it.
>   This is more discoverable and friendly, though less keyboard-friendly.
>   Gmail does this.

See above. At least statusbar display could be linked to cursor as well. 
Tooltip linked to cursor might be a bit annoying.

> * Consider Tomboy autolinking for creating links of the simple 1:1 kind?

You mean turning words that match page names into links ? This has been 
implemented in some zim version already as a hidden option, but never 
worked very well. Goes back to the same discussion about the cost of 
resolving a link. Can now be done much easier due to the new page index.

Would not use this myself, but I would welcome a patch for this as long 
as it is packaged as a plugin. Plugins can already hook into 
auto-formatting behavior, so while typing auto-linking can be done. And 
a plugin could check the page when loading.


Please let me know your thoughts on these topics, and where you see room 
for improvement.

Regards,

Jaap