Unified file editing


#1

I’ve been toying around this this idea for a while and I’d love to implement it, but I know nothing about contributing to Atom, so I’d love some help building this.

Two things that bug be about code editing these days:

  1. switching between files
  2. file load order, module exports, globals

What if we can start writing code in one giant file, and denote different sections using anchors. All anchors with the same ending will be concatenated in order so you’ll end up with a program.js, program.css, and program.html files in a typical web application.

As you create a program, you can just start writing whatever you want. And rather than create a new file, you can just create another anchor tag describing what that sections is. Using these tags you can filter through these sections in different ways so you can have multiple perspectives on the code.

Suppose, I’m creating a new component. I may first write some markdown documentation. I may write some code on the server to handle this new component… Here’s the order of my anchors all within the same canonical file.

~home.docs.md
~home.server.js
~home.client.js
~home.html
~home.css
~user.html
~user.css
~user.client.js
~home.html
~home.css
~utils.docs.md
~utils.js
~home.client.js
~home.html
~home.css

Now, all the different sections will be concatenated in this order and thats your program. But while you’re coding, debugging, or trying to find you create a “new tab” based on querying these anchor tags, such as “home.js” which will take all files with “home” and “js” tags, concatenate them into a file in order, and then you can code within the sections right there. Another query might by “home.html | home.css” which will give you html interlaces with CSS based on the order from the cannonical file.

You can compile documentation by concatenating the results of queries such as “home.docs & utils.docs”. (& being concat, and | being interlace).

Anyways, I think this is pretty neat and not too complicated. You don’t have to switch files as much because you’ll be able to get everything you want right in from of your face by querying anchor tags. The load order is very explicit without the tedium of directory structure, file paths, load order, module exports, requiring modules, exposing variables, etc.

As far as an atom package,

  • there needs to be a meta-syntax highlighter that recognizes these anchor tags and highlights the section based on the file ending of the tag.
  • you need to be able to create a “new tab” using a “query”. When a section is edited and saved, the package must update the canonical file and any open files with that section.
  • the package must concatenate files (this is easy)

I’ve never build anything for Atom, and I don’t really know where to start (but I’m a coffeescript fan :slight_smile: ).

Thoughts?


#2

It’s an interesting idea, but I’m not sure whether scrolling through a giant file is any better than switching tabs…


#3

There would probably be commands to scroll/search through the “anchors”. I’m wondering though: won’t this end up being like using fuzzy file finder with the difference that everything is in one big file?


#4

Exactly what I wanted to say. Thanks for choosing better words :wink:


#5

Haha when I read “switching tabs” I immediately thought of using the mouse :stuck_out_tongue: but of course using fuzzy finder will also switch tabs


#6

So the point isn’t to scroll through a giant file. You start building in one file. You should be able to read this file from the top to the bottom and understand how everything works. But as the application gets bigger, you can filter these sections based on their tags. This will give you smaller pseudo-files which you can edit from, like “home.html” could be open in a new tab filtering all these tags and concatenating them. You can edit the sections directly in this tab, and it should be updating the canonical file behind the scenes.

Fuzzy finding will take you to each instance that tag is found, but you’ll end up jumping all over the page. My idea puts all the resulting sections right next to each other. You can make these tags a complex or specific as you want as well :smile:

Does that make more sense?


#7

Wouldn’t opening multiple tabs achieve the same goal with the plus of being able to split them?


#8

I also fail to see the advantage. Why is switching between tabs containing the files less annoying than switching between the tags in one big file? Is there any functional difference, from an editing point of view?


#9

This sounds a lot like Knuth’s Literate Programming. The benefit, I assume, would be that related things could be right next to each other on the screen, rather than having to hunt them down in some other file somewhere.


#10

Literate Programming mixes docs and code (literate coffeescript comes to mind), this idea is broader I think.


#11

I’m aware. The similarity is that Literate Programming (at least originally) encourages you to “tell a story”, in other words freely order the documentation and code in a way that is best to describe the system. While Literate Programming was about interleaving and reordering documentation and code, this is about interleaving and reordering different kinds of code.


#12

Well, it’s definitely one way to see it. Yet, just like I regard LP nice in theory but useless in practice, I still have a hard time trying to understand the exact problems it wants to solve…


#13

Ok. I think I’m having trouble explaining this with English. Maybe I just need to give you guys a simple example. Hang tight


#14

Alright. I created an example to show you guys. Use your imagination because this example is super simple – think of how this could be utilized in a much larger program with more anchor tags.

In the README.md, I explain how this is different from fuzzy searching the same large file, and jumping between tabs as we currently do.


#15

The idea is clear, and I think I understood it fully, but it still looks unnecessary to my eyes; I am probably not the best person for this kind of workflow. In particular, you seem to be stressing a lot on the fact that you see the file in a “chronological” order, the way the program flows. I see a major flaw in this reasoning: programs do not follow a linear flow. Linear flow might be expected within a single file, but multiple files are mostly interconnected.


#16

As programs become more complicated, they don’t follow a linear flow – that is correct. However, they do have a linear load order, so thats still relevant. In a big program, you’ll query these sections and work on smaller pieces at a time.


#17

Well, all I can say now is: do it! I’m sorry I can’t help you with it since I have no access to Atom till September, but I will give it a shot when I can.


#18

I’d be more than happy to put in all the leg work, but I have no idea how to build something for Atom! What I’d really like is if someone can spend 5 minutes to set up a boilerplate repo and tell me what needs to go where, and how to get started developing for Atom.

I need to:

  1. make a syntax highlighter that parses anchor tags piggybacks off other build in syntax highlighters for each section.
  2. a command to query query tags, open up a new tab with those sections, and update the sections in the canonical file as the file changes or is saved.

Or, is there some comprehensive documentation somewhere I can read through to get started myself?


#19

You can start with the Atom Flight Manual. It has sections on how to write a package and there is the API documentation that covers how to do many of the things you’re talking about.

On the other hand, there isn’t much information on how to write a language package. Most of it is picked up right now by looking at other packages.


#20

Ok. I finally got around to reading this stuff. Now a few questions to get me started in the right direction:

  1. Based on the atom markdown package, it looks like they hardcode every language they want to support.

Is it possible to parse the tag, and select whatever is the default syntax for that file ending? e.g. ~home.events.coffee would select whatever syntax matches the .coffee ending.

It looks like there isn’t much else I’d need to do here to make a syntax highlighter

  1. For filtering tags and editing, I want to do something similar to code folding – The sections I don’t want just disappear, and the sections remaining are directly editing the original file. I’m not sure how this works though – perhaps there is more code elsewhere that makes this all work:

https://github.com/atom/atom/blob/master/src/fold.coffee

Specifically, how do they reference a specific range of text in a larger document when displaying the truncated version of the document?

  1. Would it be possible to allow multiple tabs of the same file be opened with different tag filters?

Thanks for the help!