magiblot / turbo

An experimental text editor based on Scintilla and Turbo Vision.
Other
442 stars 35 forks source link

Add support for opening current dir on start #59

Closed HelgeCPH closed 1 year ago

HelgeCPH commented 1 year ago

Hej,

First, I would like to say thank you for your modern port of Turbo Vision and especially for the turbo editor! I like the editor a lot and use it almost daily since I read about your Turbo Vision port on HackerNews some weeks ago.

As far as I understand, The turbo editor can take file paths as parameters on startup. These files are loaded then. I was missing that I could just start turbo with a pointer to the current directory, e.g., with turbo . or any other directory where then all files within this directory would be loaded.

The change in this PR implements that feature. Since I am not a C++ programmer, my change might be weird. Please let me know if I should change anything.

magiblot commented 1 year ago

Hi Helge! What operating system are you using?

HelgeCPH commented 1 year ago

I am on Linux (Ubuntu based).

$ lsb_release -a
No LSB modules are available.
Distributor ID: Pop
Description:    Pop!_OS 22.04 LTS
Release:    22.04
Codename:   jammy

But I can see that the build fails on Linux. That is weird, it builds for me :) Perhaps the reason is that I am using a newer GCC to build?

$ gcc --version
gcc (Ubuntu 11.2.0-19ubuntu1) 11.2.0
magiblot commented 1 year ago

First of all, thank you very much for your comment. I'm glad that you like Turbo. I wish to make it more enjoyable in the future although right now I am unable to spend a lot of time on it.

I wanted to know your operating system because, if you are on Linux, then it will likely be more convenient for you to do this from the command line.

Unlike popular GUI applications that show you a tree view of your current directory, Turbo only shows files that are currently open. In other words, Turbo has to open these files in order to show them in the tree view (see #52, #11).

And it is indeed difficult for Turbo to guess which files are relevant to the user and which files are not. Making Turbo open all the files in a directory tree may easily produce undesirable results such as opening binary files, hidden files, etc., which might lead to very long load times and high memory usage.

So, because I believe doing this in Turbo would be too complicated, I suggest you consider relying on the command line to achieve the same result (or even more sophisticated ones).

For example:

# Open all non-hidden files in CWD
turbo *
# Open all files in CWD and subdirectories
turbo `find . -type f`
# Open all .cc files in CWD and subdirectories
turbo `find . -type f -name '*.cc'`
# Open all files in CWD and subdirectories, excluding hidden files and directories
turbo `find . -not -path '*/.*' -type f`
# Open all files in CWD and subdirectories, excluding executables and hidden files and directories
turbo `find . -not -executable -not -path '*/.*' -type f`

If you find any of these commands to be very useful but unconvenient to type each time, you can just create an alias for it.

Hope this helps.

Cheers!

HelgeCPH commented 1 year ago

Ah, right. Then I understood correctly how turbo is opening files and that are specified via arguments and that they are always opened.

Currently, I am actually using an alias that provides me with the behavior (alias turboh="turbo {,**/}*") but I wanted the editor to support how I open directories with other GUI editors I use. Actually, I just wanted to see if I can make it work for me with hacking something in a C++ project :)

Perhaps my use case is different. I am often working on directories with a lot of text files, markdown, etc. and usually not many binary files. Some images and PDF files are around and I saw that they are loaded as binary files then.

I can also see what you mean by unintended effects like memory consumption. If I run turbo . in the root directory of this project, with all its dependencies and unfiltered hidden files from the Git database, then it consumes 1GB of memory...

That is, perhaps it is not a good idea to merge my PR into the project. But then I think it would be a good idea to mention some of the find expansions somewhere in the documentation (in the README?). perhaps I overlooked that information, but when using the editor first, I was wondering why turbo . does not work as I was expecting it to work. If you want to, I can add this information somewhere (but I am too sure where exactly it should go).

magiblot commented 1 year ago

Okay, adding this to the README is a good idea. Don't worry, I can take care of it.

HelgeCPH commented 1 year ago

Cool. Then I close this pull request.

magiblot commented 1 year ago

Fixed.

Also, if you were wondering why your changes failed to build on Linux, it's because we still support GCC 7, which doesn't provide the <filesystem> library.