Suggestions for Enhancing Markdown Document Features

Here are two feature suggestions for Markdown documents in DTP.

  1. It would be helpful if a right-click on an image in the DTP Markdown viewer offered the option to “Show Image in Database.” Currently, when I want to make changes to an image while viewing a Markdown file in the DTP viewer (not the editor), I have to switch to the editor to find its location and then search for it in the database.

  2. Could you consider implementing a live preview with side-by-side scrolling for the editor and viewer in Markdown documents? Alternatively, it would be beneficial if clicking on a word, paragraph, or image in the Markdown viewer would cause the editor window to scroll to the corresponding position.

I appreciate that @cgrunenberg and @BLUEFROG are always attentive to feedback. I fully understand that not all suggestions can be implemented, and that the feature request list is extensive and must be carefully prioritized.

I can’t speak to what development may do but how’s this look…

imageLinks

I understand that the development team may not respond directly, so your input is valuable. I know there are no guarantees or public roadmaps, and that’s perfectly fine.

Your approach is intriguing—how did you achieve it? If I drag and drop an image into a markdown document, they are not clickable.

Discussing something internally. Thanks for your patience and understanding.

Thanks for the suggestion, the next maintenance release will support this.

1 Like

thanks so much, that’s great!

I assume the markdown linking between viewing and editor position is more tricky (see my first post)?

Somewhat related: in an HTML document in DT, you can highlight some text in rendered view, and DT will wrap it up with a span tag in the source. This feature is only available in the Preview view, not in the Side-by-side view. I don’t know the actual reason; My own thought is, if user actions in the rendered view are “synced” back to the source view, there could be issues concerning unsaved changes to the source.

That’s part of our to-do list already but not planned in the near future.

I fully understand and appreciate this. My second suggestion—allowing users to jump to the corresponding section in the editor or vice versa by clicking on a word—might be easier to implement than a real live scrolling mode. Nevertheless, it would be a good compromise. However, as I am not a developer, I will wait patiently.