I’m sorry if this is a dumb question (or even if is the right section), but i can’t highlight text while reading in preview mode.
When i use the == to highlight text, it only highlight it in edit mode, then when i switch to preview it only shows the “==” without highlighting anything. It shouldn’t do the opposite? Highlighting without showing the tags.
Maybe i’m doing something wrong?
Hi @pierxyz, I think your edite mode should look like ==highlighted text== and then it will show up in the prieview mode. At least it does in my text, on Windows 10.
Regards
Adrian
While I’m in preview mode, I want to highlight text without switching to markdown mode.
this feature request is similiar with this one, isn’t it?
I think some editing options should be left in preview mode.
Such as highlighting, bold, and italics.
This is very convenient when reading a formatted document to highlight some places in it.
I came here the exact same request because I often revisit notes to highlight or emphasis content as I’m reviewing. Currently I use two linked panes with one in preview and the other in edit. This works but having a more minimalist view to highlight would be nicer.
For my use-case, enabling the keyboard hotkeys in preview mode would be sufficient.
I agree it would be handy to be able to highlight from preview mode. Although I guess this would also be possible once there is a WYSIWYM-style editor (which I think is in the works). In which case, I would be ambivalent about getting this feature in the short term, if it simply delays work on a fully fledged WYSIWYM mode.
+1 - would love to be able to clip web articles in markdown mode into obsidian, then use preview mode on my tablet with my pen to both bold and highlight as part of progressive summarization.
I still think this would be useful, and the recent work on live preview might be a good time to do it?
A lot of Personal Knowledge Management classes stress the importance of engaging with highlights you make while reading, and set up pipelines from Kindle or Instapaper to Readwise to capture the highlights.
A similar experience to highlighting on kindle, in adobe acrobat, in instapaper, outside of edit mode in obsidian, would be very useful.
@thomasvs please don’t @ the devs. The request will be reviewed if it gets enough support. In any case, preview is a “read-only” mode. What you’re asking is editing the note (even if it’s just it’s format). It might be something that LP facilitates without any additional effort on the part of the devs.
Personally, I don’t think that the type of highlighting you would do on preview is an edit. Not part of preview either.
It ought to be a layer above preview. Anything else is a workaround.
From that point of view it ought probably to be a plugin request rather than a core request.
I think all this is in place in the WYSIWYG mode soon introduced.
Sorry for @ a dev. It’s not very obvious to me how to make requests for features being actively reworked - the few pages on Live Preview I could find do not allow any commenting.
On highlighting being editing, I don’t fully agree. When I highlight books on Kindle, I’m not editing the text, and I’m not changing the words. Same on Instapaper, in Adobe Acrobat, and any other app that lets you highlight text. I agree with Dor - highlighting and bolding is a layer between editing and previewing.
FWIW, I think the point is moot - what matters is the use case and the feature. I just started trying Live Preview, and it’s neither editing nor preview, so it’s clearly possible to do modes that are neither edit nor preview.
It’s both on one pane.
But taking edit to be write and prepare for publication, and preview to be publication, then highlighting is a layer on top of that. As it is in the kindle for example.
@Dor @thomasvs In this context, editing is making any modifications to the source (might be a bit technical and less philosophical). Highlighting and bolding is changing the source text by changing its formatting. You are adding symbols to the original text.
In any case, for what you mean, LP is probably the mode to use since what you want is a rendered view where you can add these formatting elements, regardless of whether we call that editing or not.
I understand completely that the technical implementation of bolding or highlighting changes the markdown. I am arguing from the use case perspective, not the implementation underneath, because the implementation is irrelevant to the use case. If the implementation was storing formatting in a separate database somehow, the use case would still work the same.
Live preview is an example of focusing on a use case regardless of the technical implication underneath.
Live preview, after trying it, is not a good substitution for a pure bolding/highlighting mode. A highlighting mode would only let you do highlight-related changes, not let you actually change the text at all (except maybe add footnotes, to emulate notes), and wouldn’t pop up the keyboard on mobile.
Bolding usually is, highlighting can be. But in most use cases highlighting is on top of the source not part of it. And, in fact, there is often a requirement not to change the source.
It’s like highlighting a PDF. And, as often pointed out, Preview is as close as many notes ever get to a PDF.
Exactly. Highlighting plugin with its own database storing the highlights. No reason it couldn’t do the same for PDFs, Docx, etc if they also present in the vault.
@thomasvs in my opinion this is then better as a plugin request. The technical aspect is important, we can’t ignore what this does to the source document. Perhaps you can request a plugin that does not insert the required syntax into your note and stores them some other way.
I agree that with the existence of Live Preview, and Mobile Toolbar or cMenu on desktop (both which can have a highlight command button), this “highlighting in preview” FR is already achieved on desktop environments (or iPad if connected to external keyboard).
But for this use case…
And my own, which is to do the same on my iPhone…
the FR is incomplete, for one main reason: the on-screen keyboard, which obscures half the screen if you try to select text for highlighting.
This would be resolved if someone can create a simple mobile-focused plugin to force-hide the on-screen keyboard (perhaps until a hovering pencil button is clicked), so that I can select text in Live Preview, then press the highlight toolbar button, all without the keyboard popping up.