#M2S wish list
11 messages in this thread
<continuation>
to invoke the env seems to put the .lnk and exe files in M2Sprint when
compiling and linking. I'd really like and on-screen reminder as to
where my files will end up!
5. A split screen editor would be nice for the purposes of editting in the
code and being able to add the declarations as you use the identifiers.
6. Either in M2Prof or in a linker "map" file, provide information from
which one could determine any unused identifiers and thus remove them
(along with any unneeded data space). An additional help would be to
provide printable compiler xref files as well as link "map" files.
The above minor nits aside (I know, "real programmers don't use icons or
listings"), I am very impressed with the package, both software and
documentation.
wmc
P.S. one document comment… I thought HALT should have been documented
somewhere… did I miss it?
1) V1.1 provides complete control of where .lnk .sym .ref and executablkes go.
2) V1.1 has 3 different "Save Icons", one for the editor, the compiler and the
linker.
3) Setting the default tool for editor files to "M2Sprint:M2E" makes sense.
It's simpler and would probably end up working better than what I do now.
Although I think I'd set that for "M2Sprint:M2A" instead. No sense in loading
the editor from disk if it is already loaded in hot-key mode.
4) When clicking on a file from WB, the output of the environment will go to
the same drawer as the icon. When invoking with hot-keys, the output goes in
the current directory at the time the environment was started. In V1.1, you
have string gadgets that define the compiler "Input Drawer" and "Output Drawer"
and the same for the linker. If the string gadgets are empty, then the output
goes to the same location as currently (current dir).
5) Split screen editing is on my own wish list, although I don't know if there
will be enough time to work much on the editor for V2.0.
6) I'd also like to get some listings and xrefs. V2.0 will have an optimizing
compiler which will remove unused identifiers for you, so that will help. Hmm,
I guess it would be trivial to have the single-pass compiler report unused
identifiers though.
7) Yes, HALT should have been mentioned. V1.1 includes 3 totally new chapters
(compiler, linker and utilities) which replace some of the current chapters.
Hopefully this wil fill most of the holes in the documentation.
Martin,
WOW… Its almost like Christmas!! I'm almost .1 revs away form most of the
little nits I noticed on a great package being revised the way I'd like to see
em!!! NEAT!!
Gee… what am I gonna do for problems….
wmc
We aim to please… 🙂
You see, I'm a user of M2Sprint myself. The entire system is developed with
itself (it's actually quite interesting to compile the compiler with itself).
So being a user myself, I also encounter bugs or annoyances in the software.
But since I have the sources, I fix it 🙂 It turns out that many of the things
our users are reporting have already been improved.
Anyway, if you have other comments/bugs/suggestions, please send them along.
It's too late for V1.1 to add new features (I could manage to squeeze in a few
more bug fixes though), but I'm already working on future versions, so don't
hesitate.
Martin,
I'd like to add my appreciation for your quality product and excellent support.
I have a request for a future version of the M2E editor:
1. Allow macro bindings to the keypad keys. Many of us at work who have
Amigas use the MicroEmacs editor because we can set up the keypad to be very
similar to the VAX editor we use at work .
2. (Someone else has already mentioned this) Split-screen editing (again a la
MicroEmacs).
Thanks again for coming through with quality. Now if I could only find time to
produce some M2 software…
Gary
I'd like to support complete keyboard remapping in a future (V2.0?) version.
Lots of people want this feature. As for the split-screen editing, it would
indeed be a boost to productivity, I often have to open/position two windows on
my display to produce the same (or almost) effect. BTW, thanks for the nice
comments. Hearing stuff like that from our users is the most gratifying part of
the job!
I would prefer the default tool for editor files to be C:M2A. The whole point
in the HOT mode is to get the editor loaded and then keep the small activator
where you can get at it fast. In my case I keep M2A in RAD:C which is my C:.
(Actually its in RAD:Bin which i link to RAD:C with Bill Hawes Path device,
that way I know RAD:C has C-A programs ONLY, RAD:BIN has everybody else, and
they both look like C: !!)
I would like changeable editor configurations, Could you have M2(A|E) look in
the directory of the file being loaded for an M2.editconfig and use that for
that file. That way the default configuration for M2, my consulting reports,
and my son's grade school reports can all be different!
Similarly I would like options for loading different completion/case correction
files. I haven't used M2E for much REXX or any C programming yet but I know I
will need to. ( base development in M2, tools in M2 or Rexx, delivery to
customer in C …. )
Finally consider saving the configuration used to edit a document in the icon
file as Notepad does (this is one thing Notepad does right). That way
individual documents can be fully configured and you have an extremely flexible
editing system.
In the compiler, TDIs used to let one compile an implementation module all the
way to a stand alone executable. This was very convenient when knocking up
quick test drivers for a new module, just put them in the initialization code.
The new compiler doesn't support this.
its nice to use as it is, these things would make it very smooth.
Kevin
Great bunch of suggestions. I do have a problem with the default tool thing
though. I on't keep my M2A in C:, and I expect many folks have their stuff in
varying locations as well. I guess the best solution would be to have the
editor use a template icon in M2Data: just like the compiler and linker do.
Anyway, too late for V1.1, but I'll keep your stuff on the list for next
release.
BTW, it *is* possible to link an implementation as a stand-alone program. Just
specify the module name as Main Module name and link. It works well here in any
case. Let me know what problems you are having doing this.
Thanks, I'd only tried the implementation as stand-alone once, late at night so
I may have overlooked something, I'll try again.
On further thought about default tools I decided that I could live with I could
live with M2Sprint: by pulling some more trickery with PathMan.
I forgot to mention… You can easily have different variations of the various
config files. Simply create different M2Data directories, and do an ASSIGn to
the directory you are interested in before starting the environment.
I thought of that, I load M2E in my startup sequence. After that the only time
I even need the M2Sprint_Tools disk is to load Compiler/Linker (first time
used) or if I'm in the throes of debugging. I specifically don't want to keep
reloading the environment.
Kevin