@sand15 My suggestion entails having all your source in plaintext files. After that, their text would never get re-imported back into any worksheet format (whether Maple Notation or otherwise).
Suppose you have an entire module, M, whose source definition is in the text file srcM.mpl . In that case you could, in either the GUI or the commandline interface, "load" that module with the command,
Having loaded the module in any session, you could then call it's exports (or itself, it is is an appliable module. That would cover both the interactive application as well as any unit testing.
I don't understand how Shift-Enter issues would come into that.
If procedure in module M also call procedures from outside M (user-defined top-level procs, or exports of user-defined module N, say) then you would load both before executing. Eg.
Another way would be to use LibraryTools to save(lib) both M and N to the same .mla Library archive. A worksheet's Startup Code could contain either the simple read statements, or a statement that appends to libname (so as to pick up any .mla archive).
I usually have a very small text file (of Maple code) which:
1) sets the Maple include path
2) reads the module defn files (which may contain $include directives)
3) saves to .mla archive
And then I just need to augment libname to get the package into play. If it's very useful then I may even end up putting the .mla into a toolbox folder, so that libname is augmented automatically, upon normal launch of the GUI or commandline interfaces.
The key thing is that, once my source gets migrated to plaintext then it never gets put pack, literally as code, into any worksheet.
Having said all the above, I'm afraind that I don't understand your comment about WorksheetToMapleText and difficulties with references from within a module to other user-defined procedures. And I'm afraid that I also don't understand the comments about Shift-Enter, after using the menubar's File->Export as..., because the format to export to is plaintext (ie. .mpl or .txt, but certainly not some other .mw variant or anything with input prompts).
I forgot to mention it before but additional benefits of plaintext files are A) the stand-alone Maple language Syntax Checker mint can be used easily and to its full power, and B) plaintext files are extremely well protected against file-corruption when using mature editors such as vi, emacs, etc.
As far as Carl's comment goes, yes of course you don't necessarily have to split up module sources into seperate files for each procedure. If you do, then the $include directive (and includepath) is very handy. That's a matter of taste. I find that as my project gets large, and the revision histories get long, then it helps me to make sense of the revision diffs if I don't have to visually process too much at once. This aspect is colored by your choice of revision control tool, naturally.