Search Ideas

Another problem with the term ‘statement’ is that not every statement encodes knowledge. Only some statements do.

Recall Deutsch’s definitions of knowledge (paraphrasing from memory): information with causal power; information which, once instantiated, causes itself to remain instantiated.

The sentence ‘nice weather we’re having’ is a statement but doesn’t meet those definitions of knowledge.

Or the existing search page could be filtered by discussion. For example, I could link to that page with an additional query param discussion_id=1 or something like that.

Or each discussion could have a search/filter form to filter ideas not just by criticized or not but also content and potentially other attributes.

Feature to collapse all criticized ideas of a discussion? Useful for todo lists.

Feature to collapse all criticized ideas on a page? Useful for todo lists.

Fixed as of 76b7ab4.

Make sure cycling between a leaf revision with children and a leaf revision without children properly toggles the gutter.

Cycling through the revisions of a leaf reveals its gutter, which should be hidden since it’s a leaf.

Sometimes you just want to hide the comments without collapsing the parent idea.

Because that would mean hiding each comment individually if you ever do want to hide all comments of an idea.

Bulk

Because that would mean hiding each comment individually if you ever do want to hide all comments of an idea. And sometimes you just want to hide the comments without collapsing the parent idea.

Having features to both collapse an idea and hide all its comments seems like an opportunity for unification. Why not just go with collapsing and remove the ability to hide all comments?

Done as of fcf578c.

As noted in #1777, fetching the idea actually helps. Well worth the overhead.

This actually helps to prevent rendering links with IDs that don’t point to any existing idea.

Include (preview of) content in idea URLs: '/ideas/123-first-30-or-so-chars-of-idea-here'.

Wouldn’t even need friendly ID for that since the URL would contain the ID. Would only need to override to_param to concatenate the idea’s ID and content.

Seems like minor overhead. It’s not like there are tons of user-generated hashtags everywhere.

Fetching the idea is not necessary if the feature is backwards compatible. Can still just use /ideas/123.

Not if the feature is backwards compatible.

That would mean fetching an idea to compute the path for each hashtag. Overhead?

Facebook does it this way, too.

Reddit is a bit different because they have multiple subreddits/communities, but each community has top-level posts which people can then comment on. They have a completely separate page/UI for top-level posts. And then directly underneath a top-level post, there’s a textarea saying “Join the conversation”.

Could have backwards compatibility for the short version and continue using the hashtag in the UI. Best of both worlds?