Search Ideas

There’s a bug where hovering over a link in the markdown preview removes the form and all typed text. Hovering over a link should have no effect on the form.

Since the diff processes the text as a single line, the hunk header is always going to say either @@ -0,0 +1 @@ (for the first version) or @@ -1 +1 @@ (for every subsequent version). Meaning the header provides no real information. So I might as well remove it.

Since the diff processes the text as a single line, the diff information is always going to say either @@ -0,0 +1 @@ (for the first version) or @@ -1 +1 @@ (for every subsequent version). Meaning it provides no real information. So I might as well remove that part.

There should be user profiles.

I also don't mind the bulk criticism.

Even if the person submitting a post doesn’t mind bulk criticism, others still have a harder time discerning which ideas in the post are true/salvageable and which should be discarded. Meaning error correction is harder.

It helps when critics quote which part they’re criticizing, like I’m doing above, but the responsibility still lies with the original poster.

I also don't mind the bulk criticism.

Even if the person submitting an idea doesn’t mind bulk criticism, others still have a harder time discerning which parts of the idea are true/salvageable and which should be discarded. Meaning error correction is harder.

It helps when critics quote which part they’re criticizing, like I’m doing above, but the responsibility still lies with the original poster.

Thanks for your contribution, Dirk.

Your post contains several ideas. In the future, you would benefit from submitting them separately so they have to be criticized separately. As it stands, a single criticism of your post will mark all of the ideas contained therein as problematic. I call this a ‘bulk criticism’, see #362.

To protect against bulk criticism, try to submit one idea per post.

Would you like to break your post up into several ideas before I offer criticism? They can still reference each other the same way I do above with idea #362 – if you type # followed by a number, it will turn into a link to the corresponding idea, much like GitHub does with issues.

In activity feed, behind timestamp (‘… hours ago’), link to corresponding discussion.

When a comment is a criticism on another criticism, the activity should say ‘So and so addressed criticism #…’

The activity feed just shows top-level criticisms as regular ideas. They should be shown as criticisms just like when they are child ideas.

Should probably show the explanation in a revision, when given. In the activity feed, that is.

Highlight current nav item.

The activity feed just shows top-level criticisms as regular ideas. They should be shown as criticisms such like when they are child ideas.

Should I give the icons in the activity feed colors?

Should probably show the explanation in a revision, when given.

When all I change during a revision is the criticism flag, the activity log just says ‘no changes’.

I think the thing I’m really fighting here is Rails being object-oriented. Which I can’t do anything about.

Not sure the Rails team realizes how much OOP reduces the extensibility of Rails.

Not as of #330, they couldn’t.

Hiccdown methods should live in their own, separate classes. How about they are called ‘displays’?

1
2
3
4
5

class ProductsDisplay
  def index vc, # …
    vc.some_helper_method
  end
end

Behind the scenes, the Hiccdown gem would need to make the instance variables available to the display class:

1
2
3
4
5
6
7
8

display = @display_module.new

view_context.instance_variables.each do |iv|
  display.instance_variable_set(
    iv,
    view_context.instance_variable_get(iv)
  )
end

Then:

1
2
3
4
5

class ProductsDisplay
  def index vc, # …
    vc.some_helper_method(@products)
  end
end

They are: vc.instance_variable_get(:@foo)

Hiccdown methods should live in their own, separate modules. How about they are called ‘displays’?

1
2
3
4
5

module ProductsDisplay
  def self.index vc, # …
    vc.some_helper_method
  end
end

A benefit of this approach is that, when people start a new Rails app, they may end up putting whatever they’d otherwise put in a helper in a display, since displays have the benefit of having unambiguously resolvable method names.

Tested, it works.

Test this!

Then how would you call index from a helper method?

Hiccdown methods should live in their own, separate modules. How about they are called ‘renderers’?

1
2
3
4
5

module ProductsRenderer
  def self.index vc, # …
    vc.some_helper_method
  end
end

A benefit of this approach is that, when people start a new Rails app, they may end up putting whatever they’d otherwise put in a helper in a renderer, since renderers have the benefit of having unambiguously resolvable method names.