Hacker Newsnew | past | comments | ask | show | jobs | submit | rmsaksida's commentslogin


Unrelated - it looks like your blog's RSS feed isn't up to date. :-)


Thank you!


> I like how Google AI Studio allows one to delete sections and they are then no longer part of the context. Not possible in Claude, ChatGPT or Gemini, I think there one can only delete the last response.

I have the same peeve. My assumption is the ability to freely edit context is seen as not intuitive for most users - LLM products want to keep the illusion of a classic chat UI where that kind of editing doesn't make sense. I do wish ChatGPT & co had a pro or advanced mode that was more similar to Google AI Studio.


/compact does most of that, for me at least

/compact we will now work on x, discard y, keep z


the trouble with compact is that no one really knows how it works and what it does. hence, for me at least, there is just no way I would ever allow my context to get there. you should seriously reconsider ever using compact (I mean this literally) - the quality of CC at that point is order of magnitute significantly worse that you are doing yourself significant disservice


When you hit ^O after compact runs (or anytime), it tells you exactly what compact did, so it isn’t that mysterious


if you actually hit the compact (you should never be there no matter what but for the sake of argument) more often than not you'll see CC going off the rails immediately after compacting is done. it even doesn't know what it did let alone you :)


You mean you never stay in a CC session long enough to even see the auto compaction warning?



I've been using Valkey simply because after I updated to the latest Fedora version, it dropped redis and pointed me to Valkey instead. I assume as more distros do this and more people update their systems, the Valkey user base will grow. But perhaps with the AGPL redis that will no longer be the case.


Yeah Pix lets you choose limits. There's decent granularity for those, you can pick max $ per day, per transfer, per period, and per device. There's a caveat that when you increase a limit it takes a day or two to come into effect (basically to avoid people being forced to increase their limits by criminals).


It was a few months ago, but when X was banned in my country I tried Bluesky for a while. It took a lot of effort (adding blocklists, muting words and blocking individual accounts) to cleanse the timeline of k-pop and furry content. I am not interested in either type of content and didn't follow any such accounts, but still, the "Discover" feed kept showing that stuff to me. It was the strangest onboarding experience I've ever had in social media.


Life in that planet evolved to essentially hibernate during their long winter. Presumably the processes that resulted in the very earliest life forms happened countless times until some surfaced that had that feature.


Affinity is good but it's a shame they don't have a Linux version.



> All of the code is OOP-based, and they mount DOM nodes the old-school way (which is what React was supposed to solve..)

I don't know about VS Code, but I remember Atom was refactored to use manual DOM updates because the performance penalty of using React wasn't worth it.[1] By the way, isn't OOP by far the most popular paradigm for building desktop UIs? I imagine VS Code is a difficult codebase to work with that has a lot of intricate code (as is usually the case with large software projects), but that's a strange piece of criticism :-)

1. https://github.com/atom/atom/pull/5624


I have spent a great deal of time wading through the VS Code codebase and it takes OOP to the extreme. There are mile long inheritance chains, everything is a class, and it is a giant bowl of spaghetti. To some extent, I understand why they used that development approach. It doesn't use a UI framework, just DOM APIs, so classes make sense in lieu of components, but it's still bonkers.

> By the way, isn't OOP by far the most popular paradigm for building desktop UIs?

Yes, but I wish it wasn't. My day job is desktop development (with Electron), and I avoid OOP as much as I can and try to use a functional approach. After jumping all over the VS Code codebase to try to understand how some of this stuff works, and seeing how hard it is to navigate, I think heavy OOP is a bad idea.


Always interesting to hear such claims when graphic editors like Penpot, which have much tighter perf requirements than editors, are so fast while using React.


How do you implement a text editor?

I think a lot of people don't consider how complex text editors are and then there are the complexities of an IDE, or extensions, to be able to interact with it.

ropes? gap buffers? https://code.visualstudio.com/blogs/2018/03/23/text-buffer-r...

how vscode does it,

- https://code.visualstudio.com/blogs/2018/03/23/text-buffer-r...

- https://en.wikipedia.org/wiki/Piece_table


I'm not saying text editors are on the last place in terms of perf requirements.

I'm just saying, that general graphics editors is above that and do just fine with React.


I think at a time Vampire: The Masquerade was the most popular title in Brazil, but D&D eventually won.

Tormenta and Old Dragon are pretty popular as well.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: