[Hardhats] Vim tools for use with Mumps...
Sam Habiel
We are releasing a bunch of vim tools for Mumps. It's licensed under AGPL. I am not the author--Jim and David did all the work. Jim's have been around for some time now (syntax highlighting), David added ctags functionality and Global Dumps from vim. Yes there are bugs; but if you spend a lot of time in vim, you will fix those eventually, and hopefully send back the changes.
kdt...@gmail.com
I am just now getting around to trying this. I downloaded the file
and expanded. I can't find the .vimrc file that you refer to inside
the .tgz file. Am I missing something?
Thanks
Kevin
On Apr 27, 8:37 pm, Sam Habiel <sam.hab...@gmail.com> wrote:
> I better post this now; otherwise, I will just keep postponing this.
>
> We are releasing a bunch of vim tools for Mumps. It's licensed under AGPL. I am not the author--Jim and David did all the work. Jim's have been around for some time now (syntax highlighting), David added ctags functionality and Global Dumps from vim. Yes there are bugs; but if you spend a lot of time in vim, you will fix those eventually, and hopefully send back the changes.
>
>
>
> VIM Mumps Toolkit
>
> What is this?
> This kit provides:
> - Syntax Highlighting (automatic when you use supplied .vimrc)
> - ctags functionality (using traditional ctags keys CTRL-T and CTRL-])
> - Global dumps from within vim (using CTRL-K)
>
> Authors:
> -- Jim Self
> -- David Wicksell
>
> How to Install VIM Mumps toolkit by Sam Habiel
>
> 1. Put KBAWDUMP.m (from p directory) in your patches directory or (if you don't have one) in your regular routine directory.
> 2. Move the commands in the .vimrc to your .vimrc (in your home directory), or, if you wish, move the file whole, overwriting yours!
> 3. Move the commands in the .vim/ folder to your .vim folder (in your home directory), or alternately the whole files. Here they are:
>
> .vim/scripts.vim
> .vim/filetype.vim
>
> .vim/syntax:
> mumps.vim
>
> .vim/scripts:
> m-gdump.vim
> m-datetime.vim
> m-ctags.vim
>
> .vim/plugins:
>
> 4. If you wish to use ctags functionality, run m-ctags.sh with flag -w. Takes a long while to run. An example script run_m-ctags.sh is supplied for a cron job.
>
> Questions?
> comp.lang.mumps
>
> mumps_vim.tgz
> 17KViewDownload
>
> --http://groups.google.com/group/Hardhats
> To unsubscribe, send email to Hardhats+u...@googlegroups.com
--
http://groups.google.com/group/Hardhats
To unsubscribe, send email to Hardhats+u...@googlegroups.com
kdt...@gmail.com
The files were extracting, but they were hidden files, thus not
showing by default in by browser.
:-)
Kevin
r...@rcresearch.us
retired and is having a pretty good time from what I understand. He has
been to a number of VistA Community Meetings in the past and has put a lot
of work into the GUI development for VistA.
r...@rcresearch.us
and so these may be new developments that Jim Self is working with. Cool.
Sam, of course, is back from Jordan, and he is scheduled to return before
too long,( or not??). You can't tell the developers without a score card.
Way cool, either way. Way to go, guys.
I, Valdes
Astronaut. -- IV
On Apr 27, 7:37 pm, Sam Habiel <sam.hab...@gmail.com> wrote:
> I better post this now; otherwise, I will just keep postponing this.
>
> We are releasing a bunch of vim tools for Mumps. It's licensed under AGPL. I am not the author--Jim and David did all the work. Jim's have been around for some time now (syntax highlighting), David added ctags functionality and Global Dumps from vim. Yes there are bugs; but if you spend a lot of time in vim, you will fix those eventually, and hopefully send back the changes.
>
>
>
Sam Habiel
probably what you have.
Sam
Sam Habiel
Sam
kdt...@gmail.com
Kevin
On May 10, 4:08 pm, Sam Habiel <sam.hab...@gmail.com> wrote:
> This is new. Jim's syntax highlighting was around before, so that's
> probably what you have.
>
> Sam
>
Sam Habiel
The canonical definition of ctags is on their website: http://ctags.sourceforge.net/whatis.html
Sam
DL Wicksell
Sorry I am very negligent, not only in responding to forum threads, but even in reading them. :-)
I am the developer of all of these tools except for the syntax highlighting code ( mumps.vim ),
which was written by Jim Self. I have actually written my own version of mumps.vim, which also
includes syntax folding. What this means, is that it will automatically fold the code of a dotted DO
block. So if you have very long blocks of code, and you need to be able to see the code above and
below the block at the same time, you can fold it. You can control it at each block level, all at once,
or one at a time, and it recursively folds along dot depth. So you will get a fold within a fold, etc.
I'm not quite ready to roll a new release, but I will do so shortly, after I finish some other, more
pressing work. Also, Sam, I have fixed every bug that I've found, or that has been sent to me.
The version that you have is a couple of years old already. I have completely restructured the whole
code base around a typical vim plugin type build. So I have started creating vim documentation, which
can be used like the built-in docs, with :help, and I will be creating a tarball, and a vimball. I may even
take inspiration from Ignacio and create a .rpm, and a .deb.
In the meantime, I will attach some pictures of what the syntax folding looks like, to give you
guys an idea of what I'm talking about. Thanks guys, and feel free to ask me any questions, or
request any features. I can't guarantee that I will be able to get to them right away, but I will try my
best.
Also, Kevin, did Sam's explanation of ctags make sense to you? Maybe what I can do is create a
PDF tutorial to post here, where I explain how the tools work, and show examples of them in action.
--
David Wicksell
Vice President of Operations
Fourth Watch Sofware, LC
I, Valdes
> 123KViewDownload
>
> Syntax_folding_2.png
> 151KViewDownload
>
> Syntax_folding_3.png
> 154KViewDownload
>
> Syntax_folding_4.png
> 168KViewDownload
I, Valdes
DL Wicksell
Sam Habiel
One problem I have is that ctags is very time consuming for what it's
trying to do. For example, extracting 30000 routines from an RO file
into a routines folder takes much much less time than building the
ctags file. I think we can write our custom ctags program to generate
the tags file that will be much more efficient.
Sam
David Wicksell
Ok, I understand your point. Part of that is on me. Since ctags is so good at what
it does, and is the de facto standard for this type of work, I just used it. In order to
do so, I had to teach it how to create a tag file for GT.M. However, for me, this
worked fine, as I decided to make a global tag file, and just rebuild it once a day,
at midnight, when I'd never be using my computer. And yes, it does take about 3
hours to rebuild a tag file of 264,000+ tags, assembled from the 25,000+ routines
that make up VistA, EWD, and the like.
Now normally, ctags would recursively go through each directory, and would build
a tags file fairly quickly, but because of the way GT.M works, I had to have it go
through each file separately to build the tags file, and I just let it do it's thing
automatically, not worried about how long the tags file takes to complete. Since I
now have a user who thinks this is too long, I have several quick and easy solutions
to help you out, and have added a new option to mtags.sh that will build the global
tags file from start to finish in 1 hour, as opposed to a little over 3 hours. How is that
for a speed up, 3 times faster! Another thing that you can do, is create tags files in
each directory that has M routines, and those can be built faster, and have a global
tags file rebuilt once a week or something, if 1 hour is still too long in the middle of
the night.
Yes, of course we could write an M routine that could build a tags file in the right
format ourselves. But I'd rather work on other issues, since using the pre-existing
tool does work, and with minimum fuss. I could easily add some code to vim to
let you rebuild the tags for the routine you are currently editing, right from within the
editor, and have it fire every time you write to disk, if you like. That way, as long as
vim is the only editor you edit with, the 1 hour initial tag building time is the only time
you'll ever need it, as from then on out, the tag or tags files will be kept automatically
up-to-date. So your problem has a wealth of solutions.
Let me know if you need any help figuring out how to set it up to be much quicker.
If you do happen to want to write an M routine to build a tags file, let me know and I
can maybe bundle it with the tools, as an alternative approach. Or you can just wait
for my forthcoming release, that has lots of bug fixes, and improved functionality, and
will now include a way of building tags files quicker than before, automatically, with no
fuss to the end user.
%RI is mostly writing out the contents of each routine, with the minimal processing of
adding the headers and maybe stripping out the comments. Whereas ctags has to do
an extended regular expression search through every line of every routine, sort them,
and add meta data information, so that vim can do either an efficient binary search for
tags, resulting in immediate tag jumping, or as a fallback, a slower linear search. :-)
That's not to say or imply that an M routine couldn't do so quicker, just that there is
much more processing involved.
Thanks.
575-636-2229
David Wicksell
little processing, by comparison. :-)
Sam Habiel
The most important improvement is that gf now works across the board:
whether your routines are in the current path or not, and whether your
routines contain a % sign.
Find it here:
https://github.com/shabiel/vim-mumps-tools
Post Questions on comp.lang.mumps
Sam
David Wicksell
I'm almost finished with my newest release of these tools, called mtools. I will be releasing it as a mercurial repository on
bitbucket when I'm done. It includes much newer versions of all of the stuff that I wrote that you have released. So most of
that stuff is basically obsoleted. Since I have never actually released any of it publicly, I don't have to support any of it in
the form that you have released it. Next time I'd appreciate it if you consulted with me before releasing my unfinished project,
which I sent you for testing purposes only.
Sam Habiel
Your portion of the tools are exactly the same as the ones previously
released with your permission on April 27th 2010. I did not modify
them. Perform a diff to confirm that. If you want me to remove them
completely from my repo, I will do so.
Thanks,
Sam
David Wicksell
I appreciate that. I do not require that you remove them from your repository at this time. However,
as they are soon to be obsoleted, I may ask you to remove them when I release my latest
version, which should be today, or by next weekend. I hope. :-) I don't remember giving
permission for you to release them outside of hardhats, but maybe I did. I have improved
them a lot since then, and I don't want to have to support old, obsoleted versions. Thank you.
David Wicksell
And of course, the syntax file that you have was written by Jim Self, so you have to talk to him about
anything to do with that. I have created my own syntax file, which is different, only supports GT.M and
has additional functionality that Jim Self's doesn't. It was inspired by his work, and I credit him as such.
Sam Habiel
He will host it elsewhere: https://bitbucket.org/dlw/m-tools
Sam
Jignesh
On Nov 26, 2:42 pm, Sam Habiel <sam.hab...@gmail.com> wrote:
> Per David Wicksell's request, I have removed all his code from my repository.
>
> He will host it elsewhere:https://bitbucket.org/dlw/m-tools
>
> Sam
>
>
>
>
>
>
>
> On Sat, Nov 5, 2011 at 4:19 PM, David Wicksell <dlwicks...@gmail.com> wrote:
> > Sam,
>
> > And of course, the syntax file that you have was written by Jim Self, so
> > you have to talk to him about
> > anything to do with that. I have created my own syntax file, which is
> > different, only supports GT.M and
> > has additional functionality that Jim Self's doesn't. It was inspired by his
> > work, and I credit him as such.
>
> > On Sat, Nov 5, 2011 at 3:17 PM, David Wicksell <dlwicks...@gmail.com> wrote:
>
> >> Sam,
>
> >> I appreciate that. I do not require that you remove them from your
> >> repository at this time. However,
> >> as they are soon to be obsoleted, I may ask you to remove them when I
> >> release my latest
> >> version, which should be today, or by next weekend. I hope. :-) I don't
> >> remember giving
> >> permission for you to release them outside of hardhats, but maybe I did. I
> >> have improved
> >> them a lot since then, and I don't want to have to support old, obsoleted
> >> versions. Thank you.
>
> >> On Sat, Nov 5, 2011 at 3:07 PM, Sam Habiel <sam.hab...@gmail.com> wrote:
>
> >>> David,
>
> >>> Your portion of the tools are exactly the same as the ones previously
> >>> released with your permission on April 27th 2010. I did not modify
> >>> them. Perform a diff to confirm that. If you want me to remove them
> >>> completely from my repo, I will do so.
>
> >>> Thanks,
>
> >>> Sam
>
> >>> On Sat, Nov 5, 2011 at 3:43 PM, David Wicksell <dlwicks...@gmail.com>
> >>> wrote:
> >>> > Sam,
>
> >>> > I'm almost finished with my newest release of these tools, called
> >>> > mtools. I
> >>> > will be releasing it as a mercurial repository on
> >>> > bitbucket when I'm done. It includes much newer versions of all of the
> >>> > stuff
> >>> > that I wrote that you have released. So most of
> >>> > that stuff is basically obsoleted. Since I have never actually released
> >>> > any
> >>> > of it publicly, I don't have to support any of it in
> >>> > the form that you have released it. Next time I'd appreciate it if you
> >>> > consulted with me before releasing my unfinished project,
> >>> > which I sent you for testing purposes only.
>
> >>> > On Sat, Nov 5, 2011 at 1:08 PM, Sam Habiel <sam.hab...@gmail.com>
> >>> > wrote:
>
> >>> >> I updated the vim toolset for Mumps when editing routines for GT.M.
>
> >>> >> The most important improvement is that gf now works across the board:
> >>> >> whether your routines are in the current path or not, and whether your
> >>> >> routines contain a % sign.
>
> >>> >> Find it here:
> >>> >>https://github.com/shabiel/vim-mumps-tools
>
> >>> >> Post Questions on comp.lang.mumps
>
> >>> >> Sam
>
> >>> >> On Wed, May 18, 2011 at 2:28 PM, David Wicksell <dlwicks...@gmail.com>
> >>> >> wrote:
> >>> >> > Whoops, meant %RO, not %RI. I know you were talking about $RI, which
> >>> >> > also
> >>> >> > does
> >>> >> > little processing, by comparison. :-)
>
> >>> >> > On Wed, May 18, 2011 at 1:22 PM, David Wicksell
> >>> >> > <dlwicks...@gmail.com>
> >>> >> >> On Tue, May 17, 2011 at 2:10 AM, Sam Habiel <sam.hab...@gmail.com>
> >>> >> >> wrote:
>
> >>> >> >>> About time! I thought you would never do it.
>
> >>> >> >>> One problem I have is that ctags is very time consuming for what
> >>> >> >>> it's
> >>> >> >>> trying to do. For example, extracting 30000 routines from an RO
> >>> >> >>> file
> >>> >> >>> into a routines folder takes much much less time than building the
> >>> >> >>> ctags file. I think we can write our custom ctags program to
> >>> >> >>> generate
> >>> >> >>> the tags file that will be much more efficient.
>
> >>> >> >>> Sam
>
> >>> >> >>> On Thu, May 12, 2011 at 1:41 AM, DL Wicksell
> >>> >> >>> <dlwicks...@gmail.com>
> ...
>
> read more »
DL Wicksell
If you are talking about my m-tools package hosted on bitbucket, the
documentation says clearly that it was only created and tested for
GT.M running on Linux. There is no GT.M that runs
directly on a Mac. So the tools would be of limited use to you on a
Mac. As far as the installation goes, I have not tested that on a Mac,
because I don't have one. :-)
I have thought about getting one for testing, so maybe I'll do that
sometime, and then I can make sure that the installation scripts, etc.
will work there too. I hope this has cleared things up
for you.
> ...
>
> read more »
David Wicksell
I have a small announcement. I have changed the name of my M-tools
package of M/GT.M developer tools to Axiom. The URL has now changed to
https://bitbucket.org/dlw/axiom
If you go to the old URL, there will be a redirect link to the new
one. Nothing else has really changed with the package, though I have a
long list of features that
I will be adding in the coming months. :-)
This change was prompted by my recent discovery that Joel Ivey calls
his Eclipse plugin for MUMPS, M-Tools. https://github.com/OSEHR/M-Tools
I have known
about his plugin, though never used it, for several years. But I did
not know what its name was. And since he named his first, I feel
obligated to change mine, so there
is no confusion in the community.
Anyone who was previously following my M-tools package on
bitbucket.org, will need to go to my Axiom page and re-follow the
package, now that it is hosted in
a new repository.
Thank you.This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail (or the person responsible for delivering this document to the intended recipient), you are hereby notified that any dissemination, distribution, printing or coping of this e-mail, and any attachment thereto, is strictly prohibited. If you have received this e-mail in error, please respond to the individual sending the message, and permanently delete the original and any copy of any e-mail and printout thereof.
JohnLeo Zimmer
Not sent from anyone's Ipad
