I guess one of the benefits of HN using such simplistic styling is that its easy to make a TUI that basically resembles the site 100%. This looks awesome!
Hi everyone, this is my second "Show HN" submission posted in Hacker News. The first one was https://github.com/aome510/hackernews-TUI. I received a lot of good feedbacks and suggestions from the community back then. For the second one, I also look forward to hearing the community's opinions.
A bit background on the project: I started `hackernews-tui` and after that `spotify-player` (both are terminal application) because I want to learn Rust and build applications with Rust which I'm able to use daily.
`spotify-player` is a terminal application that can be used as either a remote player to control another Spotify client or a local player with an integrated Spotify client. So if you already know spotify-tui[1] or ncspot[2], `spotify-player` is kinda a simplified combination of both =).
Downvoters on HN are not required to explain why they downvote. That would just lead to massive numbers of low-quality "explanations" and tons more flamewars.
Downvoters on HN are not required to explain why they downvote
Maybe by this point this belongs in the document that talks about voting meta, given that it's one of the most persistent and common voting meta comments.
If your affirmation is true, why many of HN users (me included) get [dupe] at first place? In general, Is not the HN intention to decrease number of duplicates? If not so then HN should provide a solution for prevent this, such prevention that is not happening today. Example search input.
Sorry but I'm seeing big contradictions in the so called rules.
Just one example:
> If a story has not had significant attention in the last year or so, a small number of reposts is ok. Otherwise we bury reposts as duplicates.
> "in the last year or so"
Not in the same month or even after some hours later.
> "a small number of reposts is ok"
Well, HN what to prevent duplications or not ?
> Dupes are not against the rules. You're likely getting downvoted by people aware of that.
With that premise in mind, let's continue making duplicate content. right?
So don't misunderstand me, since my intention here is just to put in evidence the same recurrent problem to improve HN. For instance I have also faced the same problem in the past so there is nothing agains rules or things like that, but instead is more a improvement for HN.
The reason because I'm interested on this is because I feel part of the community and this is a concern for me (I suppose for others too). Otherwise I could take the easy and dirty way to just say nothing and ignore the problem.
The issue with duplicates isn't reposts of articles as such, it's not wanting significant duplicate discussions. We allow reposts as a way of mitigating the randomness of /newest. But once a story has gotten significant attention, we bury reposts as duplicates. (But after a year or so, enough time has gone by that a repost is ok again.)
In the current case, the previous submission didn't get much attention, so we didn't count this one as a dupe. In the case of your post https://news.ycombinator.com/item?id=26812145, the previous submission of the story did get a big discussion, so we marked the repost as a dupe. There's no contradiction.
Does that make sense? If not, take a look at some of the previous explanations. If you still have questions after that, let us know.
> > If a story has not had significant attention in the last year or so, a small number of reposts is ok. Otherwise we bury reposts as duplicates.
> > "in the last year or so"
> Not in the same month or even after some hours later.
A year is the expiration date on reposts of items that _have_ had significant discussion. Items which did not have significant discussion, and also did not have a large quantity of reposts already are exempt. In some cases the mods have reached out to submitters and suggested they repost items which the mods felt were interesting but did not catch on.
Unfortunately this is not clarifying my concerns about duplications in this particular case. I understand about the year of expiration and moderators can reach out submitters but for me is not clear what `significant discussion` means as well as `moderators could suggest submitters repost items which the mods felt were interesting but did not catch on`.
Essentially I still don't understand why some get label as duplicated and some others not.
Anyway, Unfortunately https://news.ycombinator.com/newsfaq.html is not clear at all for me and I think HN needs to make it more obvious to help members to understand without doubts or contradictions, which was the case for me.
So I will contact HN soon in order to request an account deletion.
Thanks for try to explain me about it.
PD. Sorry for the deviation of these comments from the main topic here.
But I think my concern is already expressed on previous comments.
> something that cuts out all layout, formatting and images and shows me the raw article text in a fixed with font.
FYI, I have implemented a reader view for `hackernews_tui v0.6.0` [0] which seems to satisfy most of the conditions above. Judging from my experience, this reader view works quite well and can cover many use cases.
Really hope to see Emacs get more attention after `native-comp` branch merged to master.
Recently, I have switched to Emacs full-time (first spacemacs[0], now doom[1]). So far, it has been a great experience. Spacemacs is a bit slow but with doom and `native-comp`, I rarely encounter any performance issues.
I love Doom but it needs more documentation and more developers/maintainers. If your Elisp is good and you use Doom I would strongly recommend contributing to the code. Even if your Elisp is not good, you can totally contribute towards documentation.
I just played around with newspaper3k today, and it works really well out of the box.
I plan to add support for article view reader mode with newspaper3k integration. My current approach is to create a child process with `std::Process:Command` then run a python script. Doesn't seem to be the best approach, but I guess it's the easiest one.
> 1. collapsable threads, ideally with three different shortcuts: (i) collapse daughters of current comment, (ii) collapse mother of current comment - this is very useful when on the Nth comment far away below the mother comment, so no need to scroll up, but can continue reading the sister of mother's comment, (iii) collapse entire thread.
Please correct me if I misunderstand your request. I guess what you want is navigating between sibling comments right? It seems that most of the use cases you mention above can be done with a combination of `l` (move to the next sibling) and `h` (move the previous sibling) commands.
> 2. A story view for the /active section. I think there is no official API for it, but I find it to be the most useful entrypoint into HN at the beginning of the day, to catch up.
I don't really get this feature. Can you elaborate more?
> 3. Semi-offtopic dreamland: a version adapted to (a terminal in) the remarkable and related tablets :)
Yeah, I also would love to achieve this, but supporting tablets seems to be quite painful experience :<.
> I guess what you want is navigating between sibling comments right?
It's actually more than that: when there are lots of sub-comments, it helps to see the immediate "mother" of the comment node you're reading. Imagine a comment that has two replies, and the first reply has dozens and dozens of sub-replies and sub-sub-replies, which typically veer into all sorts of adjacent issues. By the time I'm done with the 1st reply and its dozens and dozens of sub-replies, it is often unclear what the initial comment (or even topic) was. It is then very helpful to be able to glance back up to the initial comment across the now-collapsed first reply and its dozens and dozens of sub-replies, before reading reply #2. Simply navigating to reply #2 doesn't give you that.
> don't really get this feature. Can you elaborate more?
I mean this page of the HN site: https://news.ycombinator.com/active . It has the currently actively discussed stories, and is a great way to catch up after not reading HN for a day or two. A kind of intermediate step between best ( https://news.ycombinator.com/best ) and the homepage.
[Edit: the 'active' page apparently has an RSS feed here, in case you would be inclined to add it: https://hnrss.org/active ]
> It's actually more than that: when there are lots of sub-comments, it helps to see the immediate "mother" of the comment node you're reading. Imagine a comment that has two replies, and the first reply has dozens and dozens of sub-replies and sub-sub-replies, which typically veer into all sorts of adjacent issues. By the time I'm done with the 1st reply and its dozens and dozens of sub-replies, it is often unclear what the initial comment (or even topic) was. It is then very helpful to be able to glance back up to the initial comment across the now-collapsed first reply and its dozens and dozens of sub-replies, before reading reply #2. Simply navigating to reply #2 doesn't give you that.
I think I get what you mean. Instead of adding 3 different collapse commands, WDYT about adding one command to collapse the current comment and one command to move up to the parent comment?
> I mean this page of the HN site: https://news.ycombinator.com/active . It has the currently actively discussed stories, and is a great way to catch up after not reading HN for a day or two. A kind of intermediate step between best ( https://news.ycombinator.com/best ) and the homepage.
Interesting, I don't know `/best` and `/active` exist. `/best` seems to be a list of stories (up to past 4 days) sorted by `points`.
`/active`, on the other hand, and `/news` as well are quite weird. I don't really know the algorithm behind the order of sorting submissions in those.
In the meantime, I guess open the `Story View - All stories` with `sort_by=popularity` and `time_range=past 24 hours` might do the job.
Edit: it seems to work now.