hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
>
> > - keeping "image and the code" in one place, along with the includes, bg
> > image(s) etc, would be ideal.  a project oriented approach.  and zip would be a
> > good format.
> >
> > - hate the idea/concept of "allow for editing, and re-save into the image file
> > wrapper".  if anything the other way round, keep everything plain human-readable
> > text and include image(s) and other binary content 'base64' encoded.
> >
> > anyway, thanks, have a clearer picture now of the "silly idea".
>
> I'm not sure I care too much exactly how it gets implemented.  I was under the
> impression that opening such an image file with a hex editor would result in the
> text part looking like --- plain text.  It's not like plain text is "special" -
> it all has to get displayed on the screen by something that interprets the ASCII
> values anyway.   At least that's the way it works in my head.

I suggested 'hexdump' because it is "safe", ie no stray control characters to
mess with yr terminal/console.  for comfortable viewing one could use
'png::getComments', or even simply:

  $ strings -n7 foo.png | less


> What about:
> http://textbundle.org/
> https://www.macsparky.com/blog/2014/11/the-textbundle-format/

see below.


> I posted about this idea a while back - there was some other file format that
> sort of acted like concatenated text files....   maybe it was a 'nix format...
> I can't remember.

unsure.  are you thinking of "literate programming"?  cf Knuth.


> > > It might also be possible to implement security by obscurity, to protect certain
> > > parts of code that an author might not want users casually messing with.  ...
> > also not keen on this.  if an author feels .. so strongly, well, then don't
> > publish.  simples.
>
> Right, but the idea is just to make the code available and usable, but not right
> there in the editor where it can easily be inadvertently corrupted.  I often
> write spreadsheets with "locked" cells - but the password is sitting right there
> in a documentation tab in case someone wants to edit it in the future.   But in
> daily use, they can't get messed up by accident, which is easy to do.

sure.  use a viewer like 'less' and only invoke the editor (by pressing 'v')
when intending to edit.  something like an .inc or other data one could make
read-only.


> I would like a project-oriented format/editor.  Open the project, and the main
> file is in the first tab (Maybe the second, if there's a documentation tab) and
> the includes and image files are available in other tabs.

though not using it at present, isn't that much like 'qtpovray's interface?


> OpenOffice allows use of hyperlinks in the spreadsheet, which I've used to
> navigate around a sheet or between tabs.  It would be cool to specify image
> filenames, and be able to click on those and get a preview, then "go back" and
> edit the SDL.  Working on some code and need to find out what some value an
> Lvalue has?   Click it and you jump back to the last #declare for that Lvalue.
>
> But I think just starting off with the basic bundle idea would solve a lot of
> organizational and archival issues.

yes.  think 'fossil'.  seriously.  as long as the project is a single directory
tree, that will address half of your needs.  (g)vim and a 'tags' file for
navigation will provide the other half.


> How do you keep the different text/SDL files separate, and maybe even package
> images for mapping together?   Isn't a zip a binary format?

and each fossil "repository" is a single file too, ie the same convenience
handling/backing up.


regards, jr.

Post a reply to this message