Keeping Feature Requests Open Until Implemented


I noticed a feature request post, that I agree with, has been closed which means I cannot post an agreement or add my voice to the wish list.

Proposed solution

I would recommend that feature requests stay open until one of two things occurs.

  1. The feature is implemented.
  2. A firm refusal to implement the feature has been established for ‘reasons’.
1 Like

I agree with this. Absent of a clear roadmap about the longterm design goal of the product it’s pretty difficult to see if something more than little features will be added to the horizon. Even if things come a long way down the road i’d still know what gets into the plan and what is thrown out in order to either help prioritize important features or learn to keep my expectations down about things i’d want but that other products may offer.

feature request are open until implemented (or rejected). They are also closed when merged with other FRs.

What feature request? Most likely it was implemented, just not in the way you imagined, which means you should probably submit a new, specific FR for that.

The developers have published a roadmap and philosophy.

It was merged, just not with a relevant thread.

Its the word-wrapping of text in tables. The post I found had been merged with a post about a horizontal scroll bar. If I had looked harder I would have seen another ‘word-wrap in table’ post. So I guess we can close this one out since its inaccurate. Plus side, it points out the road map now.

1 Like

Line wrapping is disabled in tables because you quickly end up in a messy situation and you don’t know if you are current row or in another row.
You can enable it with some CSS too.

Yes, I’m guessing you found this one. Word wrap in markdown tables

Be sure to voice your support in there if you haven’t already.

Well the roadmap shows an empty list for long-term so if that’s really the case i feel sad for the product and for myself so I renew my request for a real roadmap ^^ as for the philosophy it talks about the current product but not about the direction it will aim to. For example “links as first class citizen” when all that means is you can link stuff and see the stuff linked is pretty shallow fur a first class citizen experience. They don’t have semantic, they don’t work in the yaml, they can’t be described, they can’t hold attributes, and the graph view shows links but beside looking beautiful is mostly read only visual but becomes cluttered, unorganized and messy very quickly. So i have to reiterate there is no roadmap or philosophy expressed about the future direction of the product

1 Like

I think it might be good to allow the user the option.

That said, is there a tutorial or guide for how to implement CSS in obsidian for such purposes?

There’s also nothing on the roadmap for adding support for tables in Live Preview…

  1. Please search for and support relevant FRs for the things you’re looking for, or post new ones if you can’t find something that matches. Specificity is key. Vague complaints like these are discouraging instead of helpful/productive.
  2. The long-term section of the roadmap is kind of barren at the moment because the short-term section is quite full. What do you want to see there, anyway? Again, see point 1.

The road map is not meant to be a complete list of all the things that may be implemented. There are about 3,000 feature requests here that are valid and may one day be implemented, even though they’re not on the roadmap. Development is a fuzzy process.

The roadmap should also not be taken for granted. Just because something is on a road map does not mean it will happen the way you expect, when you expect it. The easiest way to get burned by investing in an app is to do so because of some hope that it’ll be what you want in the future. That’s true of any software, not only Obsidian.


This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.