Treeview not populating when loading a single file

Firstly this was a deliberate change to Atom introduced in version 1.36.0.

When only a file is specified, don’t open and index the parent directory.

So I realize I might be fighting an uphill battle on this one.

I use RenPy and it recommends and installs on request Atom as it’s preferred editor. However it uses version 1.34.0 of Atom. Since it installs the portable version, it is also not able to auto-update.

Obviously I wanted, if possible, to use the latest version of Atom. But when I tried using it (not portable), I found the TreeView (what I think of as the project view) was missing. When activating it manually, all the files that were previous shown as part of my project weren’t there. Plus next time I returned, the TreeView was closed again by default.

Thinking it was a configuration file issue (and before I understood the .atom folders location and use), I created a discussion thread on the RenPy support forums to ask if anyone could help. (Viewable: here)

In the meanwhile I tried to figure out things for myself. I ended up installing versions 1.41.0, 1.38.2, 1.36.1, 1.35.1 and 1.36.0.
Versions up to 1.35.1 worked how I was used to. 1.36.0 didn’t.
A quick look at the release notes and the cause was obvious (and linked above).

I guess what I’m asking, now I’ve gone through the background is there any way to override the current behavior for releases 1.36.0 onward?
Or would it be possible in a future release to make this “populate treeview for single files” configurable?

Failing that… is there a way of invoking Atom in such a way that a specified file is opened AND populate (and show) the treeview for that file’s parent directory… as was the behavior up to 1.35.1?

What RenPy does is it has a launcher which predefines a list of common files that the author will likely use. Clicking on files like script.rpy opens script.rpy, but also populates the treeview allowing the author to quickly navigate to other files that are part of the project. I can’t imagine that RenPy isn’t the only software tool that works this way.

I often just double-click on source files in the source folder too. There too, showing the rest of the project is really handy… or should I say the lack of it is really annoying.

Realistically Atom is a Swiss army knife when all I need is a hammer. Except someone removed the corkscrew and I miss it.

This is more of an answer to the question “how might I approach solving this problem” since I do not know RenPy. I can see what it does from here.

You have an old atom editor embedded in RenPy.

First experiment I would try would be to “fool” RenPy to access an external Atom editor instead of the embedded portable Atom editor.

Look for the RenPy installation of atom binary and create a symlink to the external Atom editor binary. That is, disable the binary and substitute a symlink which invokes the external Atom binary. Like an alias.

In ubuntu I run the command which atom to find the executable.

I have no idea if this works but I have used this hack to switch between versions of apps in a toolchain. If this “proxy” does work then of course you benefit from Atom upgrades and packages. There might be points in RenPy where the embedded old config files are accessed and the same symlink approach can be tried to bind to the external editor. If this idea fails then I would look at automation script (next chapter).

Cheers @d_l.
I already tried overriding the embedded version of Atom (1.34.0) with more recent versions. It works fine until 1.35.1… then with 1.36.0 there was a change to address performance issues at startup that borked things for me.

Seemingly I am not the first to notice this behavior.
I’m not really a modern developer. My background is mainframes. Effectively I’m a end-user these days… so I didn’t actually realize individual packages had their own support issues pages.

But I found this too:
# No Project Tree View When Opening a Single File #1313

I’ve raised it there now, since that seems to have been the place I should have mentioned it in the first place.
However, I’m still open to potential workarounds if anyone has any thoughts or comments here.

I did find there that you can invoke Atom specifying both the folder and the single filename.
(atom {folder} {folder{filename}).
That actually works how I had intended. But tends to leave the treeview hanging around even after the file has been closed. Not worthless, but it feels a bit untidy.

However that does nothing to fix those occasions where I double-click on source file to work on it… and it’s associated project as a whole.

Seemingly right now, it’s working as intended and was implemented to address some performance concerns. I guess all I’m asking is could it be optional? Could I (and other people like me) people have the old workflow back in full knowledge that there will be a performance hit?

Are you in Windows?
In my Ubuntu setup I can launch into Atom tree-view from an external file manager (Krusader in Ubuntu, possibly Total Commander in your case) and I envisage that this might work for you. It is a matter of researching how to make apps work in a chain through CLI. I recently wrote a post on this approach.

This RenPy tutorial discusses other editors such as Sublime, Jedit, Atom.

This post was flagged by the community and is temporarily hidden.

This post was flagged by the community and is temporarily hidden.

Did you know there is a script file ( or init.js) for Atom that you can code with customization? You can even have some custom key mapping of you choose.

The API for the init script file is here:

This idea comes without digging deep into solving the issue; without attempting to find the correct engineering solution. A script can handle adding to tree when a single file is opened and remove from tree when closing. Or you can opt to trigger by a shortcut key.

Additionally or as substitute, consider a OS batch/shell script. Typically the script should extract the path information from the file handed to it and call Atom in the appropriate way through shell commands.

A typical user would not even notice the difference, provided that the OS opens Atom via the shell script when selecting a file. I imagine constructing a bat file under Windows will do the job nicely using the format you mention: (atom {folder} {folder{filename}).

One problem with the bat file - the project tree will not ‘close’ when the file close. Coding init would be needed there.

This post was flagged by the community and is temporarily hidden.

Cheers @snoop .
That’s sounding like a workaround that should work for me.

I’m not sure my coding is really up to implementing it (Unless Atom is using COBOL on the backend :blush:). But it definitely sounds like something I need to be looking at and you’ve given me a starting point.

Hell, I didn’t even have a GitHub account until a few hours ago. Maybe I’m evolving :):crazy_face:

This post was flagged by the community and is temporarily hidden.


Reverse the ageing process.
Learn new things!
But be warned - best to be bald or hair loss may occur when hands pull them out.

buzz-buzz … Having a Github account is not essential.

What I liked about Win7 the most is the ‘hidden secret’: the ability to code voice commands. Natively. No web link needed. Though now I also have forgotten the how. :cry:

See if coding a bat file is possible for an option. Some targeted web searches should push you into realization if it is something you look forward to win.

Final idea follows.

apm install project-viewer

Restart Atom

Topbar > Packages > Project Viewer > Open editor

Define path to your file

Files can be in Groups (e.g. Novels)

In project-viewer right panel launch any selected (RenPy) project file(s) in tree-view

This post was flagged by the community and is temporarily hidden.

@snoop I felt I had to create a GitHub account to comment on an issue ticket raised earlier this year about exactly the same thing.

Ughhh… I was on GitHub… I think I need to go lie down.

@Woetoo: I have been warned to not go off topic, so no socializing just facts.

Place this into the file:

atom.packages.onDidActivateInitialPackages ->
  return unless (atom.project.getPaths().length < 1)
  return unless path = atom.workspace.getActiveTextEditor().getPath()

Find the file here.

This will add the path to the tree-view when you open Atom by double-clicking the code file.

Footnote to someone following this topic where our off-topic messages were already deleted… the topic-starter has Windows 7.

1 Like

@Woetoo: Here is part 2.

atom.workspace.observeActiveTextEditor (editor) ->
  if editor?
    editor.onDidDestroy ->
      return if (atom.workspace.getTextEditors().length > 0)
      paths = atom.project.getPaths()
      return if (paths.length < 1)
      for path in paths

Feel welcome to add this code to what you already have in

1 Like

Thanks again @snoop

I actually realized yesterday that leaving the TreeView outstanding when the last file was closed was something that Atom has always done, even in versions 1.35.1 and earlier. I saw an issue with something that always previously worked that way.

In tracing what happens with TreeView… I started to see it sat there, even when the last file was closed (and when a new session of Atom was started).
The reality was that when I was using Atom “normally”… at least normally for me… I would never close that final file, nor open Atom itself without also opening one file from one of my projects.

Which is not to say that I won’t be using your updated init script. Thank you so much for putting the time into figuring it out.

(and yeah… I got my warning too. In hindsight, I can see their point).

I hope to interest you in an upgrade to the script offering.

The below code replaces what came before:

    - Add project folder: new file open and project tree is unpopulated.
    - Remove all project folders: last file closed and user give permission.
atom.workspace.observeActiveTextEditor (editor) ->
  if editor?
    # Legal object .. New project opened.
    if (atom.project.getPaths().length < 1) # ....unpopulated project tree
      path = editor.getPath() # ..................get file path.
      atom.project.addPath(path) # ...............populate project tree
    editor.onDidDestroy ->
      # Trigger when editor is closed
      if (atom.workspace.getTextEditors().length < 1) # ....last editor closed?
        paths = atom.project.getPaths()
        return if (paths.length < 1) # .....................project tree still populated?
        note = atom.notifications.addWarning( # ............user decides action
          "CLOSE ALL PROJECTS?",
          dismissable: true,
          buttons: [
            { # clear all folders from project tree then close notification
              text: "YES"
              onDidClick: ->
                for path in paths
            { # only close notification
              text: "NO"
              onDidClick: ->
      editor = undefined # remove object

The code is documented for your convenience. It offers the following attributes:

  • The project tree is populated whenever you open a file and the project tree is unpopulated.
    From where the file opened from is now not important.
  • The project tree will be cleared when the last file is closed.
    But this time the user is asked if it should do so or not.
    Sometime you’d like the tree to stay as-is.

Consider what you want to do with this setting:

Yours are on the default YES.

1 Like