M
Mark Volkmann
t $VIM)
The message above came from another thread.
After installing vim-ruby in this way, what is a good way to verify
that it worked?
The message above came from another thread.
After installing vim-ruby in this way, what is a good way to verify
that it worked?
N
Nikolai Weibull
t set $VIM)
Can you _please_ take vim-ruby related stuff to the vim-ruby
mailing-list (and perhaps RTFM before you ask any more questions)? I=E2=80=
=99m
getting really tired of seeing threads about Vim and Ruby on this
mailing-list (and I=E2=80=99m one of authors of vim-ruby). Thanks,
nikolai
--=20
Nikolai Weibull: now available free of charge at http://bitwi.se/!
Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}
Can you _please_ take vim-ruby related stuff to the vim-ruby
mailing-list (and perhaps RTFM before you ask any more questions)? I=E2=80=
=99m
getting really tired of seeing threads about Vim and Ruby on this
mailing-list (and I=E2=80=99m one of authors of vim-ruby). Thanks,
nikolai
--=20
Nikolai Weibull: now available free of charge at http://bitwi.se/!
Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}
M
Mark Volkmann
That's all you had to say.
(and perhaps RTFM before you ask any more questions)?
And now you've crossed the line.
I don't think I'm a person who repeated asks basic questions whose
answers are easy to find. I easily found information on how to install
vim-ruby, but not on how to verify that it worked. For example, if
I've got an older version installed already and I upgrade, how can I
determine whether I now have the new version correctly installed? I
don't believe that answer is easy to find.
N
Nikolai Weibull
Mark said:
What kind of an answer did you expect? If the gem installed without
warnings/errors, I=E2=80=99m betting that at least that part worked, righ=
t? And
the next step would be to run Vim and see that everything works as
expected, right? Not a lot to it.
A less smug response would be for me to tell you to start Vim and run
:scriptnames to see that the files are indeed loaded and from the place
you would expect.
And here=E2=80=99s the header of vim-ruby-install.rb:
# vim-ruby-install: install the Vim config files for Ruby editing
#
# * scope out the target directory and get user to confirm
# * if no directory found, ask user
# * allow user to force a search for a Windows gvim installation
# * find source files from gem or from top level directory
# * copy to target directory, taking account of
# * line endings (NL for Unix-ish; CRLF for Windows)
# * permissions (755 for directories; 644 for files)
If this header is correct, you were asked to confirm the
installation-path, so I=E2=80=99m betting that you=E2=80=99ll find the fi=
les there,
which probably means that Vim=E2=80=99ll too.
I guess what our documentation is lacking is a notification that you are
expected to be familiar with Unix directory structures, rubygems (if so
installed), and Vim before installing our packages,
nikolai
--=20
Nikolai Weibull: now available free of charge at http://bitwi.se/!
Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}
D
Doug Kearns
Well, just to annoy Nikolai, I'll respond here... ;-)
Just a quick pointer given the hour...
:help runtimepath
would be a good place to start as this is really just a generic Vim
question.
Feel free to post a message to vim-ruby-devel if you need extra help.
<snip>
Regards,
Doug
M
Mark Volkmann
Can someone point me to where I can go to subscribe to this? I found
http://rubyforge.org/mail/?group_id=3D16, but this looks like a list for
people developing vim-ruby instead of for users to ask questions. It
is described as "Development and project management of the vim-ruby
project".
M
Mark Volkmann
Never mind. I see in the reply from Doug that this is the list for me
to join. I think the description of it should be modified to indicate
that it's also a list for users of vim-ruby and not just developers.
to join. I think the description of it should be modified to indicate
that it's also a list for users of vim-ruby and not just developers.
G
Gavin Sinclair
I created that list and intended it to be for developers. User
questions are welcome on the list, but I reckon user questions (of the
vim-ruby stuff) are welcome on this list as well. I think it's
unreasonable to expect everyone to join a separate mailing list for
every package they use. Furthermore, Vim is a popular editor, so
discussing Ruby-related aspects of its use is likely to be of interest
to a lot of readers of this group.
And I don't echo the RTFM stuff, either. A question from a reasonable
person means something wasn't clear to a user that was clear to a
developer. The sensible resolution: developer thanks user and tries to
make the software clearer in what it's doing, or whatever. So thanks,
Mark.
Finally, Nikolai mentioned familiarity with Unix as a prerequisite for
using vim-ruby. I'm sure people who use Vim on Windows (like me) will
be a little surprised.
Regards,
Gavin
questions are welcome on the list, but I reckon user questions (of the
vim-ruby stuff) are welcome on this list as well. I think it's
unreasonable to expect everyone to join a separate mailing list for
every package they use. Furthermore, Vim is a popular editor, so
discussing Ruby-related aspects of its use is likely to be of interest
to a lot of readers of this group.
And I don't echo the RTFM stuff, either. A question from a reasonable
person means something wasn't clear to a user that was clear to a
developer. The sensible resolution: developer thanks user and tries to
make the software clearer in what it's doing, or whatever. So thanks,
Mark.
Finally, Nikolai mentioned familiarity with Unix as a prerequisite for
using vim-ruby. I'm sure people who use Vim on Windows (like me) will
be a little surprised.
Regards,
Gavin
N
Nikolai Weibull
Gavin said:
That assumes that every project maintainer/developer actually listens to
ruby-talk. A year ago I couldn=E2=80=99t, as it was being blocked by a
anti-spam service that shall remain nameless.
How was this clear to a developer? Dealing with Vim and its runtime
files isn=E2=80=99t the most easy task one can undertake. Understanding =
why
something doesn=E2=80=99t work for another user even less so. Fine, my R=
TFM
was perhaps uncalled for, but I do believe that the Vim documentation
mentions a lot of the stuff you need to know to get vim-ruby working and
the INSTALL, README, and vim-ruby-install.rb files mention the rest.
Apparently we must now also mention how to verify a successful
install...were does it end?
But fine, I=E2=80=99ll bow out of this one, as I=E2=80=99m not responsibl=
e for that part
of the project.
And by the way, I haven=E2=80=99t been paid a cent for any of my work, so=
excuse
me if I don=E2=80=99t feel that I have the energy to thank every user and=
answer
every question. The only thank you=E2=80=99s I=E2=80=99ve gotten were af=
ter I flew off
the handle last time and more or less demanded them [ruby-talk: 143461].
I realize that that=E2=80=99s the way open-source development works, but =
****,
it=E2=80=99s really quite ungrateful work as it is without having to deal=
with
people who sound as if they haven=E2=80=99t poked around a bit before ask=
ing
questions.
=E2=80=9CUnix directory structures=E2=80=9D was the actual quote. I beli=
eve the layout
is the same on Windows, substituting folder for directory (thanks Bill
for that one).
Something that should perhaps been taken off-list:
I guess my grief stems from an overall dislike for the over-inflated
importance of the vim-ruby project as a separate entity. As all (?) the
files are included in the Vim distribution anyway, why not just keep it
there? So far, this separation has made us miss an important release,
namely 6.3, that contained the old files instead. The 6.3 release will
finally be superseded by 6.4, but that=E2=80=99s been over a year of ques=
tions
regarding what files to use, how to install, and a general confusion
over what=E2=80=99s going on.
To me, _the sensible resolution_ would be to merge the vim-ruby project
with mainline Vim so that there won=E2=80=99t be any need for RTFMs from =
me or
=E2=80=9CHow do I install vim-ruby=E2=80=9D from users,
nikolai (25 years old and ready for anger management to save his
poor heart)
--=20
Nikolai Weibull: now available free of charge at http://bitwi.se/!
Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}
G
Gavin Sinclair
Nikolai said:
It [what happens during a vim-ruby install and how to verify it] is
clear to a devloper [me]. I see no harm in reviewing the vim-ruby
installer and adding some informative output (so long as I think it's
worthwhile; I ain't gonna accede to every single request).
Vim is a complex piece of software. It takes ages to know what's going
on with it all. It's reasonable to expect Vim newbies to be able to
use the vim-ruby stuff, which means they shouldn't be expected to read
every piece of Vim documentation.
There you go.
Mark never asked anyone to diagnose his problem, nor did he state he
had a problem. He just wanted to know, I gather, "what next?"
I have no problem with the project being merged if that's the sensible
thing to do. It wasn't the sensible thing to do when we started the
project, because there was no Vim release on the horizon. Such
releases are pretty rare, and the vim-ruby files were immature, so they
needed an independent release cycle. Whether that's the case any more,
I'm not the best person to judge.
Cheers,
Gavin
H
Hugh Sasse
---559023410-684387517-1129113626=:23927
Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-684387517-1129113626=:23927"
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
---559023410-684387517-1129113626=:23927
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
A definite pain, agreed, but there are other access methods.
If a developer/documenter didn't document it they must have thought it
sufficiently clear for the reasonable person.
this is why there are so many questions [and below]. I'm still not
clear what is really going on with Vim's startup, and I conclude
that it must be the simplest thing that actually works, but I'm
still baffled after reading the docs. There's so much of it.
Support never does (until the package dies). Murphy's law
originated with people's ability to misunderstand instructions,
IIRC.
I sympathise, and conclude that this is probably symptomatic of the
frustrations people are "expected" to have with computers: they get
used to complaining about things....
Agreed. I don't think anyone has found a solution for this.=20
Because Bram can't be expected to know every language intimately?
And for most vim users language-specific problems will look like
noise? Keeping it close to Ruby means that the problem domain is
well understood. As perfection is approached, so less modifications
need doing to the files, moving it over to the vim list looks
better. I'm fairly sure that the project was started to solve
things for frustrated rubyists who were not being served well by the
vim list. With vim subleties playing off against ruby subtleties,
the project will always feel alien wherever it lives.
This is why there is a flurry of vim noise now, so we can get this
right before 6.4 comes out. Of course, there'll be some more when
it does come out, but hopefully only for a short while.
I could do with that as well, I expect.
Thank you
Hugh
---559023410-684387517-1129113626=:23927--
---559023410-684387517-1129113626=:23927--
Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-684387517-1129113626=:23927"
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
---559023410-684387517-1129113626=:23927
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
A definite pain, agreed, but there are other access methods.
If a developer/documenter didn't document it they must have thought it
sufficiently clear for the reasonable person.
why
this is why there are so many questions [and below]. I'm still not
clear what is really going on with Vim's startup, and I conclude
that it must be the simplest thing that actually works, but I'm
still baffled after reading the docs. There's so much of it.
Support never does (until the package dies). Murphy's law
originated with people's ability to misunderstand instructions,
IIRC.
I sympathise, and conclude that this is probably symptomatic of the
frustrations people are "expected" to have with computers: they get
used to complaining about things....
Agreed. I don't think anyone has found a solution for this.=20
=E2=80=9CUnix directory structures=E2=80=9D was the actual quote. I beli= eve the layout
is the same on Windows, substituting folder for directory (thanks Bill
for that one).
Something that should perhaps been taken off-list:
I guess my grief stems from an overall dislike for the over-inflated
importance of the vim-ruby project as a separate entity. As all (?) the
files are included in the Vim distribution anyway, why not just keep it
there? So far, this separation has made us miss an important release,
Because Bram can't be expected to know every language intimately?
And for most vim users language-specific problems will look like
noise? Keeping it close to Ruby means that the problem domain is
well understood. As perfection is approached, so less modifications
need doing to the files, moving it over to the vim list looks
better. I'm fairly sure that the project was started to solve
things for frustrated rubyists who were not being served well by the
vim list. With vim subleties playing off against ruby subtleties,
the project will always feel alien wherever it lives.
This is why there is a flurry of vim noise now, so we can get this
right before 6.4 comes out. Of course, there'll be some more when
it does come out, but hopefully only for a short while.
I could do with that as well, I expect.
Thank you
Hugh
---559023410-684387517-1129113626=:23927--
---559023410-684387517-1129113626=:23927--
N
Nikolai Weibull
Gavin said:
And then what? At some point one has to sink or swim. If the installer
doesn=E2=80=99t complain, I bet that everything worked just fine. If not=
, then
we have a problem,
nikolai
--=20
Nikolai Weibull: now available free of charge at http://bitwi.se/!
Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}
N
Nikolai Weibull
Hugh said:
^^-- Why, oh, why?
So you mean that us developers should jump through hoops for our users?
Perhaps, but one can always improve. Perhaps the user that=E2=80=99s hav=
ing
difficulties can figure out what the problem is, write something up, and
send a patch?
Yes, it surely is. Too complicated in my opinion, but in many ways
better than the Emacs way (and that=E2=80=99s not a flame, OK?).
Support never does (until the package dies). Murphy's law originated
with people's ability to misunderstand instructions, IIRC.
Heh, how very true. I would probably sleep a lot better at night if I
wasn=E2=80=99t so hooked on computers...
That=E2=80=99s not what I=E2=80=99m saying. But there=E2=80=99s a CVS fo=
r Vim now, and we might
as well put most of our files in it immediately, instead of sidestepping
through another project.
I=E2=80=99m not sure I get you, but yeah, I suppose so.
And thank you for using our files,
nikolai
--=20
Nikolai Weibull: now available free of charge at http://bitwi.se/!
Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}
D
Doug Kearns
Sheesh, I'm really getting tired of these vim-ruby threads on
ruby-talk... ;-)
Well, that is currently an accurate assumption - Gavin, Tim, Hugh, you
and I are all here.
I certainly agree that it would be better for most of these exchanges to
occur on vim-ruby-devel as, I think, they currently do. The problem is a
lot of users seem to find it easier to tag a comment on the end of an
ANN message rather than post a bug report or a support request. I don't
think that's only a problem for our project.
=20
In the end it wasn't and I guessed incorrectly as to why Mark was even
asking. Don't forget many Vim users (not referencing Mark here) simply
use Vim with the basic editing commands and have very limited
understanding of its potential. It's actually one of the first pieces of
software I ever learned to use and I _still_ find the documentation
baffling at times. Not because it's incomplete, far from it, but because
you have to maintain so much context when reading it. See my last two
'lazy' messages to vim-dev. ;-)
*sob* ;-)
Agreed; but maybe some actual _users_ will chime in with some useful
remarks.
=20
No one has ever accused me of inflated self-importance before... ;-)
How is it any more separate than any of the thousand individually
maintained runtime files?
I don't understand this at all. How exactly are they not "there"? The
files in this project are currently 'maintained' in exactly the same
way as all runtime files with the one exception that they are released
together as a package for the end user's benefit. Every time they're
considered suitably improved they are released to users and a copy sent
to BM. That's how all runtime files are maintained.
Secondly, there has been some talk of including additions like your
'electric' functions which wouldn't, I imagine, be distributed with Vim.
That was simply due to a miscommunication rather than an inherent
problem with this supposed separation. BM gives very little warning of a
new release - ten days for 6.3. As I was probably doing the most work
prior to that release I could probably have been more helpful to Gavin
in organizing it but happened to be away. That said, I doubt we're the
first or last to miss a release. Do you remember the disastrous sh.vim
included a few releases ago? Poor Chip...
Right, but this is solved. Now we should only have to endure the same
annoying questions as all the other runtime file maintainers.
The distribution of these files between Vim releases is just plain
broken. I've spent more than a few minutes trying to track down updated
versions of yours after the 6.3 release. For example,
http://www.pcppopper.org/vim/ftplugin/pcp/zsh/ isn't providing me
with much joy right now. I'd find a Vim/Weibull project pretty handy, I
reckon. ;-)
=20
What should really happen is that all the latest runtime files should be
posted to www.vim.org, or similar, and stored there between releases
rather than being distributed across hundreds of websites. They're not
even added to Vim's CVS repository between releases!
Again, the only difference from the maintenance of the other runtime
files is that we distribute them together and with Gavin's nifty
installer. When he added it and the gem I'll confess that I considered
it overkill but there seems to be several hundred people using Gems to
install the runtime files every release which accounts for a little less
than half the downloads.
Heh, many of us were 25 and angry once... ;-)
Regards,
Doug
ruby-talk... ;-)
Well, that is currently an accurate assumption - Gavin, Tim, Hugh, you
and I are all here.
I certainly agree that it would be better for most of these exchanges to
occur on vim-ruby-devel as, I think, they currently do. The problem is a
lot of users seem to find it easier to tag a comment on the end of an
ANN message rather than post a bug report or a support request. I don't
think that's only a problem for our project.
=20
In the end it wasn't and I guessed incorrectly as to why Mark was even
asking. Don't forget many Vim users (not referencing Mark here) simply
use Vim with the basic editing commands and have very limited
understanding of its potential. It's actually one of the first pieces of
software I ever learned to use and I _still_ find the documentation
baffling at times. Not because it's incomplete, far from it, but because
you have to maintain so much context when reading it. See my last two
'lazy' messages to vim-dev. ;-)
*sob* ;-)
Agreed; but maybe some actual _users_ will chime in with some useful
remarks.
=20
No one has ever accused me of inflated self-importance before... ;-)
How is it any more separate than any of the thousand individually
maintained runtime files?
I don't understand this at all. How exactly are they not "there"? The
files in this project are currently 'maintained' in exactly the same
way as all runtime files with the one exception that they are released
together as a package for the end user's benefit. Every time they're
considered suitably improved they are released to users and a copy sent
to BM. That's how all runtime files are maintained.
Secondly, there has been some talk of including additions like your
'electric' functions which wouldn't, I imagine, be distributed with Vim.
That was simply due to a miscommunication rather than an inherent
problem with this supposed separation. BM gives very little warning of a
new release - ten days for 6.3. As I was probably doing the most work
prior to that release I could probably have been more helpful to Gavin
in organizing it but happened to be away. That said, I doubt we're the
first or last to miss a release. Do you remember the disastrous sh.vim
included a few releases ago? Poor Chip...
Right, but this is solved. Now we should only have to endure the same
annoying questions as all the other runtime file maintainers.
The distribution of these files between Vim releases is just plain
broken. I've spent more than a few minutes trying to track down updated
versions of yours after the 6.3 release. For example,
http://www.pcppopper.org/vim/ftplugin/pcp/zsh/ isn't providing me
with much joy right now. I'd find a Vim/Weibull project pretty handy, I
reckon. ;-)
=20
What should really happen is that all the latest runtime files should be
posted to www.vim.org, or similar, and stored there between releases
rather than being distributed across hundreds of websites. They're not
even added to Vim's CVS repository between releases!
Again, the only difference from the maintenance of the other runtime
files is that we distribute them together and with Gavin's nifty
installer. When he added it and the gem I'll confess that I considered
it overkill but there seems to be several hundred people using Gems to
install the runtime files every release which accounts for a little less
than half the downloads.
Heh, many of us were 25 and angry once... ;-)
Regards,
Doug
N
Nikolai Weibull
Doug said:
Sorry, ;-)
True. I guess since I managed I assume others will too. That=E2=80=99s
projection for you.
There=E2=80=99s always a first
.Well, that=E2=80=99s precisely it. I haven=E2=80=99t seen lengthy discus=
sions about
other runtime files on the Net as of yet, and few have their own
project pages. =20
Well, as I have been trying to get Bram to realize is that it would be
nice if everyone would just commit their files to a central repository
(the CVS) and then there wouldn=E2=80=99t be a need for separate projects=
and
the like. If users wanted new version they could just check it out from
there. Perhaps one could even implement a plugin for Vim that
downloaded and installed the newest versions of the runtime files every
so often or per user=E2=80=99s request. That would make for a central, s=
imple,
and above all standard way of dealing with updates to runtime files.
What we are doing with vim-ruby is definitely better than sticking a
URL: header in the .vim, but it=E2=80=99s not great (or we wouldn=E2=80=99=
t be having
this discussion).
Hm, true, that is a valid point. Some stuff is separate from the Vim
distribution. But this unclear separation of what vim-ruby is (as it
both releases with Vim and independently of it) makes for the confusion
that we see now, where people don=E2=80=99t really know what files they a=
re
using, what versions they have installed, and how to verify that they
have the latest versions. I guess this stems from the rather simplistic
design of the runtimepath in Vim. I=E2=80=99ve tried to get a patch in f=
or at
least allowing subdirectories in ~/.vim/plugin so that we could at least
pretend to have some kind of versioning and packaging system, but for
some inexplicable (to me) reason, people like Hari Krishna Dara opposed
it; which is weird, as he has pumped out so many plugins.
Yes, that wasn=E2=80=99t very nice. But then having a central repository=
would
ease this process.
Yes. That sucks. I=E2=80=99m sorry about that, but that=E2=80=99s just =
the problem.
URLs go dead. Having the files in a central repository is hopefully the
solution. Now I send my files to Bram immediately upon modification and
he applies them to CVS.
Hm, mine are in the Vim 7 CVS. Perhaps he doesn=E2=80=99t commit them to=
the
Vim 6 CVS any more.
Mm, don=E2=80=99t get me wrong. I like it that people are putting time i=
nto
getting nice ruby support for Vim, but I wonder if the current
distribution method is the best. But hey, if people are downloading, at
least that=E2=80=99s something. Now if we could only get them to file
bug-reports well ahead of the next release...
Hopefully I=E2=80=99ll be around to be able to say that I _once was_ angr=
y,
nikolai
--=20
Nikolai Weibull: now available free of charge at http://bitwi.se/!
Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}