Feature Request: Ability to easily get the full path of the image

[kiyoka]

Unotes cannot easily get file paths to edit local images. It would be useful if the path could be gotten directly from the displayed image.

Current behavior (Unotes v1.4.3)

When I hover the mouse pointer over the displayed image, nothing happens.

Desired behavior (Implementation Plan)

1. Embed the image ". /img/green1.png" into the document

2. When the mouse pointer hovers over the image, a clipboard copy button appears.

3. You can get the full path of the image by button.

This is clipboard data.

file:///c:/User/user1/sample/img/green1.png

[ryan-mcalister]

I think this would be a great feature. Thanks for wanting to contribute to Unotes!

[ryanmcalister]

Thanks for the implementation plan. Looks good!

[kiyoka]

Thanks for the implementation plan. Looks good!

I'm trying to implement it. https://github.com/kiyoka/unotes/tree/fix_issue_134.tmp1

Unfortunately, I am stuck because of a bug in tui.editor 2.5. When I enclose img tags with div tag, the img nodes multiply when I switch between markdown mode and WYSIWYG mode. I need to fix the bug on the tui.editor side, so it will take a while.

[kiyoka]

I'm trying to implement it. https://github.com/kiyoka/unotes/tree/fix_issue_134.tmp1

Unfortunately, I am stuck because of a bug in tui.editor 2.5. When I enclose img tags with div tag, the img nodes multiply when I switch between markdown mode and WYSIWYG mode. I need to fix the bug on the tui.editor side, so it will take a while.

I tried enclosing img tags with div tags in tui.editor 3.2.x, I found no bugs of image multiplication in tui.editor 3.2.x. Therefore, I would like to bump up tui.editor version to the 3.2.x series before implementing this feature. https://github.com/kiyoka/tui.editor/tree/kiyoka/customhtmlrenderer-test

It was very difficult to build the tui.editor 2.x series and I gave up working with 2.x before fixing the 2.x bugs.

[ryanmcalister]

Updating to 3.x has been on the roadmap so I think if you are able to make it happen that would be great. I haven't had a chance to try 3.2 yet so I'm not sure how difficult that will be. It might take a bit of extra effort to get the theming to work but I'm not sure. Let me know if you run into difficulties...

[kiyoka]

OK. I will register an issue for upgrading to tui.editor 3.x as a Feature Request. Then I will actually work on it. I think this ticket should be done independently for tui.editor 3.x support.