search

ryanmcalister / unotes

Unotes Visual Studio Code Extension. A markdown WYSIWYG notes editor.
MIT License
173 stars 22 forks source link

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

Open kiyoka opened 1 year ago

kiyoka commented 1 year ago

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 1

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

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

This is clipboard data.

file:///c:/User/user1/sample/img/green1.png
ryan-mcalister commented 1 year ago

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

ryanmcalister commented 1 year ago

Thanks for the implementation plan. Looks good!

kiyoka commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.