A bird's eye stenogram should be primary means of consuming content with sections thumbnails next to. If something catches my attention, I should be allowed to click and watch only relevant part.

YT somehow goes into this direction, but we're not fully there yet.

Do you have other improvements ideas? What will happen to monetization if YT 2.0 will work this way? We'll we have ads in stenogram?

Comments URL: https://news.ycombinator.com/item?id=38288792

Points: 1

# Comments: 0

However, as a developer, I want to see something else:

1. Example projects created with this library. Challenges, solutions, pains, wins.

2. Video demonstrating how you created simple app with your lib. Reading docs is a too high bar in very crowded JS ecosystem. For example I want to see:

  - how tooling works, 
  - how debugging works, 
  - how build process works.
  - anything else this tool is strong with.

So here comes iPad Pro 12.9 - lightweight (maybe not that light including Magic Keyboard), but it's great to use in laptop way, on chair, in bed etc. Great to browse web, scroll through videos and write notes or emails. I liked this form factor so much that I started to figure out how to make it a coding machine. That's problematic of course, so I ended up buying paid terminal App in App Store to connect over ssh/mosh to some server/other machine and use terminal with tmux/nvim etc. Installed nerdfonds, started using TUIs and it was working pretty well. But, I hate terminals for long term real work. I want to use heavy UI debuggers, click around/browse, move etc, my work is not only inserting text. I considered buying Asus Zenbook s13 OLED and install Linux on it to have two devices to use depending on my mood and physical position I wanna have. But, first, Zenbook is on Intel/Ryzen which means heat and fan noise, two, there are high risks my linux setup will require tweaks and care which I'm not interested in.

In summary: I bought base MacBook Air 13 M2 and use it as couch/cafe machine as alternative to MPB 16. So I have 3 Apple devices. Which is... fine?

Other way is to run program in symbomlic interpreter and trace what it wants to read in any of the branches.

Of course I'm a chatbot, how dare you to think it was written by mere real person ;)

To the point: isn't modal editing overrated and actually universal? Pressing caps lock moves editor into "caps lock mode", shift/ctrl/alt/cmd lifts editor into shortcuts mode, pressing ModKey+F transitions into search mode etc. In Vim in normal mode I actually keep my left pinky on Ctrl (caps lock) key while with my index fingers I create chords with d/u/f/b to navigate. Pinky fatigue was meant to be a selling point of ergonomics of Vim motions, but it's actually not gone. Ergonomics can be even better realised with ergonomic keyboard, thumbs clusters and keyboard level programmable layers. I'm very comfortable in VSCode using Emacs keybingins plus my custom ones which allow me to not leave home row do to anything I need.

If it comes to smart selection inside word, paragraph, fn body etc - it's better handled by plugins like treesitter which actually understands AST without different ant algorithms crawling characters in unknown to me ways and trying to find edges.

One thing which you can argue is superior in modal editing is commands accumulation where you press 'd' and subsequent keystrokes build up a command waiting to be executed with a final key. This of course is powerful, but not discoverable and with no undo when you make a mistake. All accumulated keystrokes can't be reified (seen as an object) so they can't be further programmed. It's flat abstraction meant to be used in one certain way. Things which would be more interesting is search inside search on arbitrarly deep level with undo, backtracking, taking other branch with keeping previous branch etc. All this is more similar to Smalltalk actually.

Can anyone confirm or deny the modal editing had high meaning in early days of teletypes where it was easier to send single keys instead of chords?

Anyway, I have impression the (n)vim is great attention sink on which you can spend weeks/months/years and get amazing proficiency and reach some local maximum, but in general it's nothing different from what we had elready long time ago in 1976.

Yes, I know popular youtubers (especially THE most popular one) talking about vim and I've seen what they do with their fingers.

I'd like also to apologize for unorganized shape of this post, it's brain dump spanning different subjects. I also don't consider myself a power user of (n)vim at all.

Please don't try to bite me for criticism, I have intention to understand ideas underlying different editors and how to progress creating the next editor of course taking best features of all already existing ones. (n)vim is an amazing effort and made life of many people just better by not having to use popular editor of the year which can get destroyed by corporate incentives.

Comments URL: https://news.ycombinator.com/item?id=36431245

Points: 3

# Comments: 4

I'm interested in merging all known ideas (including Smalltalk IDEs) and moving forward.

Perhaps I have higher expectations which I didn't explain anywhere. Hard to tell full story in short text comment.

I'm not even trying to comment your guess about what "target" I am.

I know there are tools like GVim etc, but again, they are created with high engineering effort which for some people is simply pleasant to undertake.

Again, I'm not trying to defend or favor any system, I'm actually using at the same time VSCode (for best TS intellisense), WebStorm (for refactors), nvim (for quick browsing and small config file edits) and Emacs (for Magit). My computer is my tool, not single thing inside it.

Go to VSCode, put it into your `keybindings.json`:

    {
        "key": "ctrl+cmd+j",
        "command": "editor.action.smartSelect.expand"
    },
    {
        "key": "ctrl+cmd+k",
        "command": "editor.action.smartSelect.shrink"
    }

Ideas in VIM are still brilliant, the same goes for Emacs, but they both need to reincarnate in modern skin taking pixel perfect GUIs with proper animations to the extreme. In fully multithreaded and multiprocess environment.

I've been thinking about this problem a lot recently and feels like decentralized easy-to-clone system is needed. Everything what's been said about Reddit applies to HN as well.

Comments URL: https://news.ycombinator.com/item?id=36306981

Points: 3

# Comments: 5

  1) define somewhere in the repo that it's a "compound repo", a "workspace" etc - name is arbitrary, This is our repo "R",
  2) for certain paths in the repo, mark those paths as an aliases to other repos identified by a repository URL/path. These our "r" repos.
  3) for every git command executed inside repo "R", run appropriate commands in the background for each "r" repo only if repo "r" was affected by changes initiated in repo "R".
  4) If you made changes to repo "r" directly and then returned to "R", after "git pull" you should see nothing else than standard git diffs, conflicts etc. You should not run anything like "sync"/"refresh" etc. Only git pull/rebase/merge etc.
  5) Commit in repo "R" which is only responsible for bumping repos "r" should be handled by git submodule system transparently for the user of "R". I'm not a git expert to tell what kind of commit should be used here. Any ideas? You should commit seeing diffs of course, not some commits hashes.
  5) THAT'S IT.

Please help me find potential problems. thx!