I see this doesn't use <textarea> or contenteditable, I'm curious how close can it get to native controls or can this replace them? Things like mouse selection and usual hot keys like Cmd+A and maybe other things.
> I see this doesn't use <textarea> or contenteditable
Technically, there is <textarea> but it's strictly for a more seamless interface with copy/paste. The web standard's clipboard API was not satisfactory.
> mouse selection
There was previously mouse selection but that was removed after I rewrote the selection logic. This will be re-introduced as an extension that be can opt into. It's relatively trivial for a mouse but will be harder to be robust with touch events.
One tricky bit will be the UX of scrolling and selecting at the same time, especially on mobile phones.
> usual hot keys like Cmd+A and maybe other things.
The general philosophy is to not assume any native controls, have zero default key handlers and have clients bring their own extension that adds this functionality. Cmd+a in particular would perhaps be something I can add directly in the default keyboard controller.
The underlying API is defining operations from two coordinates. From the current exposed API you can also get the last line, and from there get the last coordinate. This could be a new API I expose. With (0,0) and the last coordinate, the keyboard handler would just call that.
The one limitation is that we have to convert a bunch of lines of string into a giant string into the user's clipboard. This overload the browser's clipboard buffer once we get to a million lines of code.
I'm building a new Git hosting service focused on performance and great UX. It's another take on source code hosting and patch sharing, with some nice features like stacked diffs, automatically protected branches.
Currently just the cloud hosted version (https://gitncoffee.com), but plan to open-source most of it when it's more complete.
the engine cannot brake to a complete stop, so break pads are always in use. At low RPMs, the engine is going to stall (manual) or switch to neutral (automatic).
I actually prefer limited content width for prose content. Full width content on wide screens requires moving eyes all the way from one side to another for every line.
The real problem is that the browser won't let you control the width of a tab without resizing the browser window, which is a bit fiddly, exposes stuff behind the window, and makes you resize the window again and again when moving between tabs.
If you could easily shrink a tab, I would prefer websites to not limit text width. Since you can't, I sorta prefer them to do it, though it's much worse than the user controlling it in a nice per tab way
Right, if you have wide columns then you have to move eyes BOTH from left to right AND when you reach the end of the line you have to move them back to left AND down to next line. Whereas if the line is narrow enough to read without moving eyes horizontally you only need to move your eyes down after each line.
Right, there is a reason why print magazines use columns even for long multi-page articles. With long lines, readers tend to get lost when navigating from the end of one line to the start of the next line, and the reading experience suffers. You can help this somehow by increasing spacing between the lines, but the general recommendation is to have 45-75 characters per line.
This bookmarklet to shrink the width has been in my toolbox for a long time:
javascript:(function(){%20var%20myBody%20=%20document.getElementsByTagName('body')[0];%20var%20myBodyWidth%20=%20myBody.style.width;%20if%20(!myBodyWidth%20||%20myBodyWidth%20===%20'auto'%20||%20myBodyWidth%20===%20'inherit')%20{%20myBody.style.width%20=%20'1200px';%20myBody.style.marginLeft%20=%20'auto';%20myBody.style.marginRight%20=%20'auto';%20myBody.style.position%20=%20'relative';%20myBody.style.cssFloat%20=%20'none';%20}%20else%20{%20myBody.style.width%20=%20'auto';%20myBody.style.position%20=%20'static';%20}%20})();
I'm working on a new type of git forge[1], optimized for speed and work with patches.
It goes to extreme lengths to ensure great performance, i.e. rewritten most server-side parts of git from scratch, so there is no "exec"-ing git nor calls to libraries like libgit2. The frontend should also be very fast thanks for HTMX.
Gitpatch attempts to solve this. Supports versioned patches and patch stacks (aka stacked PRs). Also handles force-pushes in stacks correctly even without Change-IDs using heuristics based on title, author date etc. It should also be unusually fast. Disclosure: I'm the author.
I'm not convinced that review comments as commits make thing easier, but I think storing them in git in some way is a good idea (i.e. git annotations or in commit messages after merge etc)
> in that every software engineer now depends heavily on copilots
With many engineers using copilots and since LLMs output the most frequent patterns, it's possible that more and more software is going to look the same, which would further reinforce the same patterns.
For example, emdash thing, requires additional prompts and instructions to override it. Doing anything unusual would require more effort.
Gitpatch attempts to build a Git hosting with native support for patches and commit-based review system, where each commit is its own patch. It's also smart to handle force pushes and can update or reorder patches as needed.
I'll plug another option Gitpatch, however it's pretty early beta and not open-source yet, but most likely will be under AGPL at some point. It has built-in patch stacks (aka stacked PRs) and probably faster than any other Git host out there.
disclosure: I'm the author.
I see this doesn't use <textarea> or contenteditable, I'm curious how close can it get to native controls or can this replace them? Things like mouse selection and usual hot keys like Cmd+A and maybe other things.