WIP: Add functionality to insert new block after the last block

[flolbr]

This adds a shortcut (Alt+Enter) to create a new block at the end of the buffer

[heyman]

Thanks!

There are now two PRs for creating new blocks at different locations in the buffer (this one and #34). I think it would be a good idea to have the following key bindings:

C-Enter: New block after current
Alt-Enter: New block before current

And adding Shift to those adds the block to either the beginning or the end of the whole buffer instead:

C-Shift-Enter: New block at the end of buffer
Alt-Shift-Enter: New block at the beginning of buffer

Currently, C-Shift-Enter is the keyboard shortcut for splitting the current block at the cursor position, so that would have to be rebound to C-Alt-Enter.

---

Would you be interested in creating the other key bindings as well (possibly merging #34 into this PR)?

Also, it should be fairly simple to create tests for this. Look at the existing tests for reference.

[flolbr]

I could absolutely merge both into this one, and try to write the tests as well.

The only thing I'm questioning, is whether the "simpler" shortcuts should be used to create at the beginning/end of the buffer, and the +Shift ones for before/after block. If feel that, for at least my use-case, they are more often used.

I'll prepare everything else while waiting for your opinion.

[heyman]

Cool!

I'm mainly using the one that creates a new block after the current one, so I'd like to keep the non-shift keybindings for those. Once proper keybinding support is implemented, users can change that themselves.

[heyman]

I added info to the Readme on how to run the tests: https://github.com/heyman/heynote?tab=readme-ov-file#run-tests

I found the test UI pretty nice because you'll get to see the actual Heynote UI that your're testing. However, I did find that there were some cases where the tests passed in the UI but not in the CLI runner (missing await IIRC), so make sure to run the tests in the CLI as well once they pass.

[fabjan]

Nice, and with tests to boot!

Since my PR is getting absorbed into this one I'll butt in with a short review even if nobody asked:

• The README is missing two of the new commands
• The README also has the wrong binding for "Split the current block at cursor position"
• initial-content.ts has the same two issues as the README has
• There are two console.log calls left in, maybe from debugging
• There is TODO left undone, about moving the cursor

Do with this info what you want, it's your PR!

[gerroon]

Does anyone know when this will be in?

[heyman]

Nice work @flolbr and @fabjan! I've fixed the visual bug, and updated the help text and Readme.

This should be good to merge now, yes?

[flolbr]

Not yet @heyman, I've made other changes and added more edge-case tests.
Thank you for fixing the visual bug. Have you checked if it also fixes this ?

[heyman]

Have you checked if it also fixes this ?

I've now pushed another fix for that.

[flolbr]

I think that's the one @heyman.

The main change of the last commits is writing a generator for the keybind helper, which gets fed to the initial content and the README. I guess it could also be used for a future docs tab in the settings.

[fabjan]

It all seems to be working great now as I test your branch with npm run dev 👍

The playwright tests however are not green when I run them on my Mac, because page.isMac is undefined som the Meta key is never used for the shortcuts. Looks like isMac is added by the HeynotePage helper class from testutils. If I wrap page from the test code in that the isMac check works and the tests are green for me:

    // create a new block
    let modKey = new HeynotePage(page).isMac ? "Meta" : "Control";
    await page.locator("body").press(key.replace("Mod", modKey));

[fabjan]

@heyman regarding the shortcuts, opt+shift is the default modifiers used by the Amethyst window manager. I ran into a collision already with opt+shift+F for format, in that case I just disabled the corresponding shortcut in Amethyst because I didn't use it. opt+shift+return however is the shortcut for making the focused window the main window in the layout, which I do all the time.

I don't know how common the window manager is and maybe you prefer to deal with issues from users later, should they arise, instad of trying to find a perfect shortcut. Anything will collide with something I guess.

[flolbr]

It all seems to be working great now as I test your branch with npm run dev 👍

The playwright tests however are not green when I run them on my Mac, because page.isMac is undefined som the Meta key is never used for the shortcuts. Looks like isMac is added by the HeynotePage helper class from testutils. If I wrap page from the test code in that the isMac check works and the tests are green for me:

    // create a new block
    let modKey = new HeynotePage(page).isMac ? "Meta" : "Control";
    await page.locator("body").press(key.replace("Mod", modKey));

Try to apply this patch and let me know if it works
isMac.patch

[fabjan]

Try to apply this patch and let me know if it works

Oh, that also works: the failing tests go green as the mod key gets set correctly 👍

It seems like at least "create block before first Markdown block" is flaky though, I saw it fail once but unfortunately didn't grab a screenshot. I'm wondering if the shared top level heynotePage can cause flakiness: https://playwright.dev/docs/browser-contexts and https://playwright.dev/docs/test-retries#reuse-single-page-between-tests but I cannot provoke the fail after many many retries now, so it may not be an issue.

[heyman]

I don't know how common the window manager is and maybe you prefer to deal with issues from users later, should they arise, instad of trying to find a perfect shortcut. Anything will collide with something I guess.

Yeah, I think the solution to this is to implement proper support for customizing key-bindings.

[heyman]

Is this ready to merge now @flolbr ?

[flolbr]

LGTM