maxigallery.txt - why is it so?

When I installed MaxiGallery v0.4.1, it was a bit tedious because I had to do several cut-n-pastes due to only being able to grab a few hundred lines at a time (limited scroll back on my window), and then I was concerned that i had missed a line or duplicated a line and so on.

At the time, I thought to myself - why is there not a little "read from file" button in the snippet manager that just allows you to import a file. I know that there are plans afoot for a full-scale resource installation thingy, but in the interim, a read-from-file would seem to be a simple but effective partial solution.

So then when I installed MaxiGallery v0.5, I decided to cut out all the comments from "maxigallery.txt" to make it easier... imagine my surprise when after doing that I ended up with JUST FOUR LINES of code..



So the 600+ line file boiled down to 4 lines...

I’m not sure what my point is here, other than to comment that this seems a bit odd... is there a good reason to incorporate 596 lines of what I guess is documentation inside the snippet?

Cheers

Gordon

Good question. I’m going to answer this generically, as I didn’t write MaxiGallery.

Firstly, some of the lines are version information and license information. Please remember to add them back in before you redistribute anything. These are important to the world but not to the app.

Secondly, I’ve never heard of limited scrollback before. I guess many people just expect Ctrl-A Ctrl-C Ctrl-V to work. Hence the MODx slogan "take ctrl". Frankly I recommend you investigate ways of improving your copy/paste situation. What system are you on?

Thirdly, usually a snippet has more code, but some of the bigger ones end up including the bulk of code from a separate PHP include. 0.4.1 was part include, part in-snippet. So the change in 0.5 to have less code in the snippet is itself saving you lots of copy/paste.

Fourthly, documentation within the snippet is a convention. It is natural to look at the code to see what it does and to see what variables it supports. Over time, these have been documented in snippet comments in addition to being figurable-outable. This particular one happens to just have a lot of documentation. Personally, I like it being there.

Fifthly, this is a beta and as such more likely to contain version change info, so that people can see what to test for.

Now, I don’t know whether the final version of 0.5 will have all this stuff - maybe it will just include a link to the wiki. Who knows?

Oh, if you have a syntax-colouring file reader, it is easier to see what lines are comments and can be omitted.

Ah.. thanks for the reply, it all makes more sense now..

Just to address your points

(1) Yes, I was not intending to redistribute anything, but certainly version information should be retained, and that was one aspect that I had not even thought about.

(2) Linux.. I have to convert the \r characters to \n first with a sort of modified dos2unix program (otherwise the LAST line of the snippet - usually the critical line return $output; - does not appear). The output of this program appears on my terminal window, after which I grab it with the mouse.. but my windows don’t allow unlimited scroll back (though probably I could change this if I worked out how). Ctrl-A Ctrl-C Ctrl-V doesn’t do anything.

(3) Nothing to say

(4) I like how it is done in eForm - an HTML doc with a reference to it in the actual snippet. But that is obviously a matter of taste..

Well, "vi" can syntax colour some things, like my C programs, but not it seems these snippets...

Cheers

Gordon

PS This was not a criticism, just curiosity..

VI will highlight php code, and do line numbers. I used it on my Mac for a couple of years.

http://www.vim.org/scripts/script.php?script_id=1120
http://www.mkssoftware.com/docs/man4/vi.4.asp
http://www.linux.ie/articles/tutorials/vi3.php

Instead of getting the output in your terminal window you could redirect it to a file and open that file in your favorite editor for decent copy-pasting abilities. Just add " > filename.txt" after the command you are executing and the output should go to a file named filename.txt (if the file existed it will be replaced !!!) instead of the terminal window.

Quote from: Mitch at Nov 24, 2006, 09:18 PM

Instead of getting the output in your terminal window you could redirect it to a file and open that file in your favorite editor for decent copy-pasting abilities. Just add " > filename.txt" after the command you are executing and the output should go to a file named filename.txt (if the file existed it will be replaced !!!) instead of the terminal window.

That only works if he is under a graphical desktop environment like Gnome, KDE, XFCE, etc...
I was under the impression he was doing this from a command line environment.

-sD-
Dr. Scotty Delicious, Scientist.

Hmm, I am pretty sure it is always possible to redirect the (standard) output of a commandline tool to a file with using " > filename.txt". I use it all the time at work when I have to use the Unix stations.