Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

a prototype of a way to get multiple buffers #41

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

mikedeskevich
Copy link

This doesn't work since I'm not a JS developer and I don't know how to fire the right events. But using ctrl-1 through ctrl-9, you could switch buffers with no extra UI clutter.

This doesn't work since I'm not a JS developer and I don't know how to
fire the right events.  But using ctrl-1 through ctrl-9, you could
switch buffers with no extra UI clutter.
@heyman
Copy link
Owner

heyman commented Dec 23, 2023

I'm going to have to think about this.

It's not a big change UI wise. If I were to include this I would still want there to be some kind of reflection in the UI. But it could be enough with just an extra menu item plus some discreet visual representation that you only see when you have more than one buffer.

However, this is a big conceptual change. It also have non trivial implication on the code. E.g. right now the buffer is stored in buffer.txt, where should the different buffers be stored? buffer-i.txt? Should we then rename the default file to buffer-1.txt? What happens to buffer #4 when you delete buffer #3? Or maybe it's not possible to delete a buffer - you can only clear it? It also introduces the burden of maintaining this feature (for a single feature it might not be a lot, but tons of small single features add up)

@mikedeskevich
Copy link
Author

I did a terrible job of explaining my thought process - and I didn't help by giving you a working prototype.

One of the things that I thought that was brilliant in your code is that the location of the buffer was hidden to the user. It works as if it's in memory magically persisted. It's like the old swap files from back in the day. No one needs to know that the file exists or where it is.

So what I imagined was that from the perspective of the user the ctrl 1-9 would just "select a buffer". No one needs to know where that buffer is stored, it's just a different buffer.

To keep state management simple, changing the buffer would follow the same path as if you shut down the application (flush the dirty content to the existing buffer), change the buffer name, and open the application (attempt to open the file, if it's not there fill it with default content and create it).

For example, on a fresh install, I start Heynote, and it creates buffer-1.txt (or maybe just buffer.txt, it doesn't matter) with initial content. Now, I press ctrl-5. It now creates buffer-5.txt and fills it with initial content. It doesn't matter that buffers 2-4 don't exist (or really, all the buffers "exist" in the users mind, the backing store files don't exist until they're first used). If I press ctrl-1, it flushes the content to buffer-5.txt, switches the filename to buffer-1.txt, and reloads it as if it were on start up.

To answer some of your concerns:

  • On the UI you could just have an unobtrusive number in the status bar that just shows the buffer number that's active. But, yes keep it simple, I love the simplicity that's there right now.
  • you could keep the default first buffer as buffer.txt or name it buffer-1.txt. All you need is a map to 9 unique buffer names that are opaque to the user, those are just the backing store for the 9 buffers.
  • Can you delete a buffer? No, just like today, you can't delete buffer.txt (unless you go to the file system). You could clear it by selecting all and deleting. And then you'd just have an empty file on your filesystem.
  • What happens if to buffer 4 if buffer 3 is deleted (i.e. from the file system). Nothing. ctrl-4 will still open buffer 4. ctrl-3 will attempt to open buffer 3, if it's not there it will do the create-the-file-and-populate-with-initial-content path.

I totally understand maintenance burden and trying to keep things simple (that's the biggest fight I have in my day job). I hope that I gave you a path to a minimal set of extra code to maintain, but still gives a nice feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants