3 ms·

Storing text in a named file, folding a block of text within a file into a named "fold", and opening multiple views of the same file (with each view potentially

by nicklaf 12y ago

Storing text in a named file, folding a block of text within a file into a named "fold", and opening multiple views of the same file (with each view potentially being a different subset of that file), are all really just the same idea: that of a hierarchical filesystem. This could easily be achieved by writing a synthetic filesystem for Plan 9, and used with Acme. The only difference between the semantics in this kind of filesystem is that there are no directories. Rather than associating each file with a directory, we instead want to create the filesystem hierarchy directly out of named subsets of the files themselves. I might not have been completely clear about it toward the end, but my reply (currently a leaf) to my own thread on this page tries to describe how the mechanics for this might work.

jhallenworld 12y ago
Well it does not exactly match filesystem semantics- I mean a directory/file has both content and directory entries, and they are ordered. You would have to define what 'ls' does in this context. This made me wonder what code-browser did with xml files. It's nothing special, but it could have treated the elements as folds.
- nicklaf 12y ago
  Yes, good point about the differences in semantics with conventional filesystems. To the extent that they are similar, though, a synthetic filesystem could try to expose the folds as a Plan 9 filesystem interface. Plan 9 filesystems may or may not act like conventional filesystems, sometimes also require talking to a control file in some special-purpose protocol. Presumable, one could write a Plan 9 filesystem to handle folds in a way that a text editor can exploit (some small modifications to Acme, mostly related to mouse input--and a few rc scripts to talk to the filesystem--would probably be more than enough). But, by doing things the Plan 9 way, you get more flexibility and interoperability; for example, the ability to control folds (perhaps without even opening the text editor, although this raises the issue of how persistent folds should be) from the other scripts, or just to do things like access the contents of a fold with programs like cp, diff, ftp, etc. Good point as well about XML, a file format that is crying out to be treated along with the folds in a more unified way.
  - jhallenworld 12y ago
    Yeah, the OS should already treat any archive-type file as a filesystem automatically. So you can "cd" into a .zip, .tar or .ext4 file (no mount -o loop necessary). Applications have some support for this (MC and emacs in UNIX or Windows Explorer), but it should really be in the OS.
    - nicklaf 12y ago
      That would be very interesting indeed. Even Plan 9 requires you to mount tar files with a special command instead of simply typing "cd file.tar". The Plan 9 developers were conservative about preserving the semantics of commands like "cd", so that the system did not diverge too greatly from Unix. Instead, the equivalent of double-clicking on a file in Windows Explorer is handled by right clicking on a file in Acme. Acme sends the filename to something called the "Plumber", which then uses rules to decide what to do with the file: http://plan9.bell-labs.com/wiki/plan9/using_plumbing/ http://plan9.bell-labs.com/wiki/plan9/using_plumbing/

by nicklaf 12y ago

jhallenworld 12y ago

Well it does not exactly match filesystem semantics- I mean a directory/file has both content and directory entries, and they are ordered. You would have to define what 'ls' does in this context. This made me wonder what code-browser did with xml files. It's nothing special, but it could have treated the elements as folds.

nicklaf 12y ago
Yes, good point about the differences in semantics with conventional filesystems. To the extent that they are similar, though, a synthetic filesystem could try to expose the folds as a Plan 9 filesystem interface. Plan 9 filesystems may or may not act like conventional filesystems, sometimes also require talking to a control file in some special-purpose protocol. Presumable, one could write a Plan 9 filesystem to handle folds in a way that a text editor can exploit (some small modifications to Acme, mostly related to mouse input--and a few rc scripts to talk to the filesystem--would probably be more than enough). But, by doing things the Plan 9 way, you get more flexibility and interoperability; for example, the ability to control folds (perhaps without even opening the text editor, although this raises the issue of how persistent folds should be) from the other scripts, or just to do things like access the contents of a fold with programs like cp, diff, ftp, etc. Good point as well about XML, a file format that is crying out to be treated along with the folds in a more unified way.
- jhallenworld 12y ago
  Yeah, the OS should already treat any archive-type file as a filesystem automatically. So you can "cd" into a .zip, .tar or .ext4 file (no mount -o loop necessary). Applications have some support for this (MC and emacs in UNIX or Windows Explorer), but it should really be in the OS.
  - nicklaf 12y ago
    That would be very interesting indeed. Even Plan 9 requires you to mount tar files with a special command instead of simply typing "cd file.tar". The Plan 9 developers were conservative about preserving the semantics of commands like "cd", so that the system did not diverge too greatly from Unix. Instead, the equivalent of double-clicking on a file in Windows Explorer is handled by right clicking on a file in Acme. Acme sends the filename to something called the "Plumber", which then uses rules to decide what to do with the file: http://plan9.bell-labs.com/wiki/plan9/using_plumbing/ http://plan9.bell-labs.com/wiki/plan9/using_plumbing/