Include some of note body in Note List

@anihm136 are you using the default filename to pull these chars? It seems like that’s the best option.

default filename currently just accepts katex etc. but it should probably be updated as well.

Images should not be displayed. Fancy formatting should not be displayed. Tables and such should not be displayed as tables. I would like to increase my recommendation of 80 characters to 120 - that’s about what Evernote pulls - about 2 lines worth in the note list column. Again ignoring line breaks in the note body for this function.

Ah,i had not thought of default name. I was pulling it from the database directly. Default name is a good option, I’ll try it out.

I’ll also increase characters to fill 2 lines at a medium width setting of the note list bar.

The issue with default title, I realised, is that it requires the entire note body to be loaded, which I’m trying to avoid. Instead, I’m using it as a kind of sanitizing function, and passing the characters that I’m requesting from the database to it to handle some of the special characters.

Would it make sense to use a regex-based replace logic for removing markdown elements from the preview?

I’ve also seen some existing packages for this, but I’m not sure if it makes sense to use them here. (remove-markdown and strip-markdown)

Notes can also include html so that would need to be handled. Obviously if you query only a part of the note body and then strip off most of it that will look a bit broken.

Some users for example put a block of css on top of their notes.

What if we select the first paragraph tag in the rendered HTML and used that as the preview content? That could be stored on the database and updated at some slower interval. It would accomodate for most of the issues, and we could take the preview from the rendered HTML for the viewer itself.

I’m having pretty good results with using the parsed markdown to get the preview text. What I’m doing is getting the text of the first rendered paragraph element and using that as a preview. Right now, I’m storing it as a new column in the notes table itself. That way, preview is not generated each time, only when the first paragraph changes. Duplicated notes are also handled this way.
@laurent do you think this is a feasible approach? Also, if it is, is storing the preview in the notes table the right way to do it?

What if we select the first paragraph tag in the rendered HTML and used that as the preview content?

That would make sense. But what abou cases where the first "paragraph" is just a few letters? For example, something like this:

Hello,

How have you been doing lately?

The preview should be "Hello, How have you been doing..." and not just "Hello,"

And I'm sure it can happen too that the first paragraph has no text at all, for example if it was HTML that's been stripped off by the sanitizer.

This is cache data, and we can't store this in the note table as that's going to be synced. For cache data, perhaps the best option is the KvStore service.

So would it make sense to extract text from paragraph elements only upto a certain number of characters (i.e, keep extracting from paragraphs until 80 characters are reached for instance)?
I will look into the KvStore service for caching and update on how it goes.

Latest update: I have it working using KvStore. The preview is taken as the first 100 characters from paragraph tags in the rendered markdown. This preview is updated in the background, and change is brought to the note list only when you switch to a different note (because you probably don’t use the preview for currently focused note anyway).

At this point, I’d appreciate someone review my changes to check that I’m doing things the right way. What’s the preferred way to do this? Do you want me to make a PR or is there another preferred method?

Making a PR is the preferred method. Looking forward to see what you’ve done!

I’m working on a markdown-it plugin to extract text from markdown. As the note preview feature would be one of its predominant uses as of now, I would like some feedback on how different types of elements should be handled when converting to text
For example, what I’m thinking right now is,

  1. Plain text : As is
  2. Links and images :
    • With description: Show only description text
    • Without description: Show link url
  3. Inline and fenced code: As is, with backticks to demarcate them
  4. Headings : Plain text
  5. Tables : ? (not sure what’s best here)
  6. Raw HTML : ?
  7. Charts and diagrams : ?
  8. Any other elements I’m missing?
1 Like

Just want to refresh this thread, since I have some free time now, I’ve been looking at how some apps (evernote, bear) handle their previews. With evernote, it seems to handle in the following way -

  1. For text, all formatting is removed (all whitespace compressed to a single space, list, bold/italics and code formatting removed)
  2. Tables are converted to plain text with whitespace
  3. Preview compressed to a character limit (I think 80 chars)
  4. If there are images, the first image is previewed on the right side of the note display

Considering that Joplin generally has support for more features/formats than this, I wanted some opinions on which of these features require previews, and which of them can be filtered out. For instance, can all html be filtered out, or are there cases where its preview is beneficial?
Another thing to discuss is the format of the previews. As noted earlier, evernote removes all formatting from the text for the previews. Bear, on the other hand, keeps all the markdown syntax as is in the preview. Which of these approaches seem better? Personally, I feel that keeping syntax is useful in some places (lists, headings etc.), while not so much in others (tables, bold/italics, code etc)

As you said, in some cases keeping the format would make sense but in other cases it would not. Also preventing XSS on cut HTML content can be tricky sometimes, so I’d think it’s best to avoid these issues altogether and display unformatted text.

There’s now a function markdownUtils.stripMarkdown() which could be used for this.

1 Like

Hi, I am new to Joplin and I was going to suggest a similar feature / theme where the note list view would contain additional info beyond the title. Is this still in the works or is it dead?

Just a bit about my particular use case, I am using joplin as a journal not dissimilar to Turtl, Day One, or Journey. In these apps, scanning, browsing the note list view is a huge part of the reflecting experience.

I don't think I am permitted to post screen shots of other apps so here's a wireframe that I mocked up.

note list

2 Likes

Is this still alive, being worked on? Is there a beta or something to look out?

2 Likes

anihm136, have you given up on this idea? It is the one thing I look for in every Joplin Summary and check the release notes for with every update. It is maybe the biggest thing keeping me from abandoning Evernote. In case you're wondering whether anybody cares any more. I do.

4 Likes

@anihm136 - are you willing to share the code for this? I need it in my life and am comfortable coding but would rather not do it from scratch!

1 Like

This feature is so important, please implement this function in the near future update!

2 Likes

+1 ... i currently consider Joplin over StandardNotes...but this current simple list kinda bugs me :confused:
Images are not important for me tho

1 Like