Search Ideas

In Brave for iPad, the footer doesn’t extend all the way to the bottom of the page. As a result, in dark mode, there’s a black gap underneath the gray footer. I cannot reproduce the issue in Safari. The cause is unclear.

This UI bug essentially exacerbates a wider issue: that the footer color does not match the background color of the html element, which becomes apparent with scroll inertia on the bottom of the page.

I could prevent vertical overscroll.

In Brave for iPad, the footer doesn’t extend all the way to the bottom of the page. As a result, in dark mode, there’s a black bar underneath the gray footer. I cannot reproduce the issue in Safari. The cause is unclear.

This UI bug essentially exacerbates a wider issue: that the footer color does not match the background color of the html element, which becomes apparent with scroll inertia on the bottom of the page.

In Brave for iPad, the footer doesn’t extend all the way to the bottom of the page. As a result, in dark mode, there’s a black bar underneath the gray footer. I cannot reproduce the issue in Safari. The cause is unclear.

On iPad, the footer doesn’t extend all the way to the bottom of the page. As a result, in dark mode, there’s a black bar underneath the gray footer.

Right now, to get a good sense of an idea on Veritula, a user often has to study a branching discussion, which can take a lot of work depending on how the discussion played out.

While this is true for most existing discussions, it’s not a fundamental limitation of discussions in general. For example, ‘How Does Veritula Work?’ has several long-form posts without much discussion. It just depends on what kinds of posts people want to submit.

Didn’t you want competing articles on some topic? In which case the same criticism applies to articles as well, unless I’m missing something.

There could be a side pane that stays visible while scrolling content.

Search page is getting slower the more ideas there are in the db.

Autofocus should put the cursor at the end of an input, not the beginning.

I started a discussion earlier, and what I wrote in the “about” section of the discussion was not written well. I would like to revise it. Is this possible? If not, is there an intention to make this possible eventually?

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

Need email notifications.

If it’s mostly done, what’s missing?

Now that diffs are formatted, they don’t omit unchanged lines anymore.

There could be periodic reminders and a review board to make it easier.

This could inadvertently hide dormant but important ideas.

Proposed solution: edit a discussion to hide top-level ideas. That way, discussion owners can hide ideas they no longer deem relevant.

For example, completed tasks in discussions used as issue trackers, like this Meta thread, could be hidden so they don’t pollute the thread.

There could be a button for users to reveal hidden ideas so nothing is lost or hidden dishonestly. And direct links to hidden ideas would continue to work.

Old ideas can pollute discussions. Like in this meta thread.

I can still reproduce the issue by clicking on the button to collapse/expand an idea.

Feature idea: edit a discussion to hide top-level ideas. That way, discussion owners can hide ideas they no longer deem relevant.

For example, completed tasks in discussions used as issue trackers, like this Meta thread, could be hidden so they don’t pollute the thread.

There could be a button for users to reveal hidden ideas so nothing is lost or hidden dishonestly. And direct links to hidden ideas would continue to work.

Feature idea: edit a discussion to hide ideas. That way, discussion owners can hide ideas they no longer deem relevant. (For example, completed tasks in discussions used as issue trackers, like this Meta thread.) There could be a button for users to reveal hidden ideas so nothing is lost of hidden dishonestly.

I could override authenticate_user! in the DiscussionsController.

The thread suggests a workaround: use authenticated do … blocks in routes.rb instead of before_action :authenticate_user! in controllers.

It’s probably a good idea to do this anyway to avoid divulging the existence of routes that unauthenticated users don’t need to know exist. (They will get a 404 instead of a 401.)

The thread suggests solution: use authenticated do … blocks in routes.rb instead of before_action :authenticate_user! in controllers.

It’s probably a good idea to do this anyway to avoid divulging the existence of routes that unauthenticated users don’t need to know exist. (They will get a 404 instead of a 401.)