The :help command is buggy when invoked from within vimtutor and gvimtutor

[Georgiy Treyvus]

I've been using Vim for a few years now and hobbling around well enough
but ultimately decided I wanted to learn to use Vim more effectively.
Thus among other things I ran vimtutor again in hopes of absorbing stuff
that I didn't remember from the first time around. Ultimately as I
reached the end it suggested I run some :help commands and this is where
things went quite bad.

For example here is what happens when I ran ":help user-manual" from
within vimtutor:

E434: Can't find tag pattern
Press ENTER or type command to continue

After I pressed enter as it said something did open in the top pane but
it was complete garbage.

This same thing seems to occur when running gvimtutor as well.

This does not appear to happen when I use the usual commands of the form:
vim
gvim
vim file1 file2 ...
gvim file1 fil2 ...

Here is information about the version of vim that I am running:

[georgiy@PANTHER ~]$ vim --version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Aug 20 2015 10:38:14)
Included patches: 1-207, 209-801, 803-808, 810-827
Modified by <bugz...@redhat.com>
Compiled by <bugz...@redhat.com>
Huge version without GUI. Features included (+) or not (-):
+acl +farsi +mouse_netterm +syntax
+arabic +file_in_path +mouse_sgr +tag_binary
+autocmd +find_in_path -mouse_sysmouse +tag_old_static
-balloon_eval +float +mouse_urxvt -tag_any_white
-browse +folding +mouse_xterm -tcl
++builtin_terms -footer +multi_byte +terminfo
+byte_offset +fork() +multi_lang +termresponse
+cindent +gettext -mzscheme +textobjects
-clientserver -hangul_input +netbeans_intg +title
-clipboard +iconv +path_extra -toolbar
+cmdline_compl +insert_expand +perl +user_commands
+cmdline_hist +jumplist +persistent_undo +vertsplit
+cmdline_info +keymap +postscript +virtualedit
+comments +langmap +printer +visual
+conceal +libcall +profile +visualextra
+cryptv +linebreak +python/dyn +viminfo
+cscope +lispindent +python3/dyn +vreplace
+cursorbind +listcmds +quickfix +wildignore
+cursorshape +localmap +reltime +wildmenu
+dialog_con +lua/dyn +rightleft +windows
+diff +menu +ruby/dyn +writebackup
+digraphs +mksession +scrollbind -X11
-dnd +modify_fname +signs -xfontset
-ebcdic +mouse +smartindent -xim
+emacs_tags -mouseshape -sniff -xsmp
+eval +mouse_dec +startuptime -xterm_clipboard
+ex_extra +mouse_gpm +statusline -xterm_save
+extra_search -mouse_jsbterm -sun_workshop -xpm
system vimrc file: "/etc/vimrc"
user vimrc file: "$HOME/.vimrc"
2nd user vimrc file: "~/.vim/vimrc"
user exrc file: "$HOME/.exrc"
fall-back for $VIM: "/etc"
f-b for $VIMRUNTIME: "/usr/share/vim/vim74"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -g -pipe -Wall
-Werror=format-security -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1
Linking: gcc -L. -Wl,-z,relro -fstack-protector -rdynamic
-Wl,-export-dynamic -Wl,--enable-new-dtags -Wl,-z,relro
-L/usr/local/lib -Wl,--as-needed -o vim -lm -lnsl -lselinux
-lncurses -lacl -lattr -lgpm -ldl -Wl,--enable-new-dtags
-fstack-protector -L/usr/local/lib -L/usr/lib64/perl5/CORE -lperl
-lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
[georgiy@PANTHER ~]$

Here is information about the version of gvim I am running:

[georgiy@PANTHER ~]$ gvim --version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Aug 20 2015 10:37:43)
Included patches: 1-207, 209-801, 803-808, 810-827
Modified by <bugz...@redhat.com>
Compiled by <bugz...@redhat.com>
Huge version with GTK2 GUI. Features included (+) or not (-):
+acl +farsi +mouse_netterm +syntax
+arabic +file_in_path +mouse_sgr +tag_binary
+autocmd +find_in_path -mouse_sysmouse +tag_old_static
+balloon_eval +float +mouse_urxvt -tag_any_white
+browse +folding +mouse_xterm -tcl
++builtin_terms -footer +multi_byte +terminfo
+byte_offset +fork() +multi_lang +termresponse
+cindent +gettext -mzscheme +textobjects
+clientserver -hangul_input +netbeans_intg +title
+clipboard +iconv +path_extra +toolbar
+cmdline_compl +insert_expand +perl +user_commands
+cmdline_hist +jumplist +persistent_undo +vertsplit
+cmdline_info +keymap +postscript +virtualedit
+comments +langmap +printer +visual
+conceal +libcall +profile +visualextra
+cryptv +linebreak +python/dyn +viminfo
+cscope +lispindent +python3/dyn +vreplace
+cursorbind +listcmds +quickfix +wildignore
+cursorshape +localmap +reltime +wildmenu
+dialog_con_gui +lua/dyn +rightleft +windows
+diff +menu +ruby/dyn +writebackup
+digraphs +mksession +scrollbind +X11
+dnd +modify_fname +signs -xfontset
-ebcdic +mouse +smartindent +xim
+emacs_tags +mouseshape -sniff +xsmp_interact
+eval +mouse_dec +startuptime +xterm_clipboard
+ex_extra +mouse_gpm +statusline -xterm_save
+extra_search -mouse_jsbterm -sun_workshop +xpm
system vimrc file: "/etc/vimrc"
user vimrc file: "$HOME/.vimrc"
2nd user vimrc file: "~/.vim/vimrc"
user exrc file: "$HOME/.exrc"
system gvimrc file: "/etc/gvimrc"
user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "~/.vim/gvimrc"
system menu file: "$VIMRUNTIME/menu.vim"
fall-back for $VIM: "/etc"
f-b for $VIMRUNTIME: "/usr/share/vim/vim74"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -pthread
-I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include
-I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo
-I/usr/include/pixman-1 -I/usr/include/libdrm
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16
-I/usr/include/pango-1.0 -I/usr/include/harfbuzz
-I/usr/include/pango-1.0 -I/usr/include/glib-2.0
-I/usr/lib64/glib-2.0/include -I/usr/include/freetype2
-I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/libpng16
-O2 -g -pipe -Wall -Werror=format-security -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
-m64 -mtune=generic -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64
-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: gcc -L. -Wl,-z,relro -fstack-protector -rdynamic
-Wl,-export-dynamic -Wl,--enable-new-dtags -Wl,-z,relro
-L/usr/local/lib -Wl,--as-needed -o vim -lgtk-x11-2.0 -lgdk-x11-2.0
-lpangocairo-1.0 -latk-1.0 -lcairo -lgdk_pixbuf-2.0 -lgio-2.0
-lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lfontconfig
-lfreetype -lSM -lICE -lXpm -lXt -lX11 -lSM -lICE -lm -lnsl -lselinux
-lncurses -lacl -lattr -lgpm -ldl -Wl,--enable-new-dtags
-fstack-protector -L/usr/local/lib -L/usr/lib64/perl5/CORE -lperl
-lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
[georgiy@PANTHER ~]$

This isn't a big deal for me personally but it probably won't leave
newer users trying to learn with a particularly good first impression.

[Christian Brabandt]

Hi Georgiy!

On Mi, 02 Sep 2015, Georgiy Treyvus wrote:

> I've been using Vim for a few years now and hobbling around well enough
> but ultimately decided I wanted to learn to use Vim more effectively.
> Thus among other things I ran vimtutor again in hopes of absorbing stuff
> that I didn't remember from the first time around. Ultimately as I
> reached the end it suggested I run some :help commands and this is where
> things went quite bad.
>
> For example here is what happens when I ran ":help user-manual" from
> within vimtutor:
>
> E434: Can't find tag pattern
> Press ENTER or type command to continue
>
> After I pressed enter as it said something did open in the top pane but
> it was complete garbage.
>
> This same thing seems to occur when running gvimtutor as well.

Hm, I can't replicate this behaviour.

Best,
Christian
--
Das Beste was das Christentum hervorgebracht hat sind seine Ketzer.
-- Ernst Bloch

[Georgiy Treyvus]

Christian,

Perhaps you tried reproducing this with a different version of Vim or
quite possibly I screwed something up on my end. Hopefully the attached
screenshots will help illuminate what's going on or at least to confirm
this bug. Is there perhaps other helpful diagnostic information I can
provide?

Regards,
Georgiy

[James McCoy]

On Wed, Sep 02, 2015 at 04:52:40PM -0400, Georgiy Treyvus wrote:
> Perhaps you tried reproducing this with a different version of Vim or
> quite possibly I screwed something up on my end. Hopefully the attached
> screenshots will help illuminate what's going on or at least to confirm
> this bug. Is there perhaps other helpful diagnostic information I can
> provide?

Looks like your system ships with gzipped help files. When you run
vimtutor, plugins aren't loaded. The gzip plugin is what normally
handles uncompressing the help files, but since it isn't loaded Vim just
opens the compressed file and can't find the tag to jump to.

Cheers,
--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <jame...@jamessan.com>

[Georgiy Treyvus]

On 09/02/2015 09:47 PM, James McCoy wrote:
> Looks like your system ships with gzipped help files. When you run
> vimtutor, plugins aren't loaded. The gzip plugin is what normally
> handles uncompressing the help files, but since it isn't loaded Vim just
> opens the compressed file and can't find the tag to jump to.

Though I now have an explanation of what's going on thanks to James I'm
somewhat confused as to how to proceed towards fixing it at this point.
The biggest question that now arises is whether the fix should be
applied upstream at Vim or more downstream with the Fedora packagers or
some combination of both.

I wonder if other systems also compress the Vim help files in this way
or if Fedora is the only distro that does that? Even in the latter case
I can totally understand why as human readable text is redundant and
there is plenty of hard disk space to be saved. After all just about
every distro compresses the man pages. Why shouldn't most distros do the
same for Vim's help files?

One possibility whether this is done upstream at Vim or downstream by
the Fedora packagers is to have various plugins loaded when vimtutor is
run which will therefore not trigger this bug. A big drawback of this
however is that there may be other plugins loaded which may drastically
alter the way vimtutor works and the whole (re)learning experience.

Another possibility is to take this up with the Fedora packagers and
have them rig vimtutor to load the gzip plugin so that the help commands
work exactly as expected. At least for Fedora users this would work
pretty well.

What I feel is probably the best option is to have this fixed upstream
at Vim though. I cant imagine it would be all that hard to modify
vimtutor to check on startup whether the help pages were compressed and
load the gzip plugin if needed. There are many distros out there and
odds are that Fedora isn't the first or last distro tempted to compress
help files that will make this mistake when packaging Vim. Thus to fix
this once and for all and prevent bug reports like this from being filed
again and again this is probably the best solution.

What are everyone's thoughts?

[Gary Johnson]

Here are the results of comparing the sizes of the Vim directories
installed as a package on my Fedora 14 system (Vim 7.3.315) with
those of my local build of Vim 7.4.838. Directory sizes were found
using 'du -hs'. The Fedora package doc files are gzipped; my doc
file are not compressed.

/usr/share/vim/vim73 22M
/usr/share/vim/vim73/doc 2.5M

/usr/local/share/vim/vim74 29M
/usr/local/share/vim/vim74/doc 6.0M

What this shows is that the Fedora packagers are saving no more that
3.5 MB of disc space by compressing the doc files. Given the size
of today's discs, it's ridiculous to spend any effort on compressing
these files or on working around problems from them being compressed.

Fedora should stop compressing these files.

Regards,
Gary

[Christian Brabandt]

Hi Georgiy!

On Fr, 04 Sep 2015, Georgiy Treyvus wrote:

> What are everyone's thoughts?

I would say, create a bug at the fedora project and discuss this issue
with them. I think, this is a purely packaging issue and my thought is,
the effort compressing the help files is not worth the effort,
considering todays disk sizes.

Best,
Christian
--
Ein Pedant ist ein Mensch, der geistig schlecht verdaut.
-- Jules Renard

[Georgiy Treyvus]

On 09/05/2015 03:56 PM, Gary Johnson wrote:
> Here are the results of comparing the sizes of the Vim directories
> installed as a package on my Fedora 14 system (Vim 7.3.315) with
> those of my local build of Vim 7.4.838. Directory sizes were found
> using 'du -hs'. The Fedora package doc files are gzipped; my doc
> file are not compressed.
>
> /usr/share/vim/vim73 22M
> /usr/share/vim/vim73/doc 2.5M
>
> /usr/local/share/vim/vim74 29M
> /usr/local/share/vim/vim74/doc 6.0M
>
> What this shows is that the Fedora packagers are saving no more that
> 3.5 MB of disc space by compressing the doc files. Given the size
> of today's discs, it's ridiculous to spend any effort on compressing
> these files or on working around problems from them being compressed.
>
> Fedora should stop compressing these files.
>
> Regards,
> Gary

Gary what your statistics show is that the total size of the
documentation files for Vim 7.4 exceeds that of Vim 7.3 by 3.5
megabytes. It does not show how much can be gained from the use of
compression.

Now while whatever gains can be made won't be astronomically huge they
will still be worth it. Now you and Christian do have a valid point
about the fact that today's disk sizes are quite large and the savings
aren't all that significant. In fact this is so much so that had we been
having this conversation just a few months ago I would have agreed a lot
more. However currently my disk is full almost to capacity in spite of
my best efforts to remove extra cruft and frankly any space savings I
could get right now would actually be quite appreciated.

Anyway a snippet of terminal output is worth a thousand words:

[georgiy@PANTHER ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 1.5G 0 1.5G 0% /dev
tmpfs 1.5G 84K 1.5G 1% /dev/shm
tmpfs 1.5G 1.1M 1.5G 1% /run
tmpfs 1.5G 0 1.5G 0%
/sys/fs/cgroup
/dev/mapper/logical_volumes-root_volume 20G 18G 738M 97% /
tmpfs 1.5G 44K 1.5G 1% /tmp
/dev/sda1 319M 163M 136M 55% /boot
/dev/mapper/logical_volumes-data_volume 207G 194G 2.2G 99%
/home/georgiy/Data
tmpfs 298M 4.0K 298M 1% /run/user/991
tmpfs 298M 24K 297M 1%
/run/user/1000
[georgiy@PANTHER ~]$

Having seen with your own eyes the stats for both my root and data
volumes need I say more?

Though I'm not exactly rich at the moment perhaps I may be able to
afford to upgrade to a bigger hard drive when I have no other choice.
However many others especially those users in poor/developing countries
wouldn't be able to afford this and that's even if they have access to
some old resource constrained computer at all. One of the key advantages
that make Linux and Vim are that they are much less bloated and much
more accessible to those without much in the way of resources.

As a side note in many ways I like Emacs a lot better than Vim. Though
this bit is purely subjective I find the keyboard shortcuts a lot more
comfortable. I also like the fact that I don't have to switch modes
every time I want to say delete a bunch of words and don't have to be
anywhere near as conscious of the editor mode I'm in. Emacs also gives
me less headaches when copying and pasting snippets of code. Why have I
been using Vim in spite of all that for all these years? Because the
rest of Emacs is so bloated and clunky. You don't want to become Emacs.
You don't want to wake up one day and realize that Vim has gone
(Windows) Vista.

Now I will be taking this up with the folks at Fedora. Ultimately though
the more I think about it the more I think this is best solved in Vim by
having vimtutor load the gzip plugin if necessary and encourage
compressing the help pages by default. Just about every distribution
compresses man pages and many other kinds of documentation (which across
thousands of packages saves quite some space) and hence packagers
wanting to compress Vim's help pages isn't all that outlandish and
unreasonable.

At the very least this issue should be documented in maybe the INSTALL
or README file or something of the source distribution. Fedora packagers
aren't the dumbest guys by any stretch of the imagination and that if
they made this mistake during packaging then odds are very good that
packagers from many other distros will as well resulting in more bug
reports like this from other people. Fixing this in Vim would kill many
birds with one stone. Perhaps I can even be of help implementing the
fix. Let me know how I can be of use.

Regards,
Georgiy

[Gary Johnson]

On 2015-09-11, Georgiy Treyvus wrote:
> On 09/05/2015 03:56 PM, Gary Johnson wrote:
> > Here are the results of comparing the sizes of the Vim directories
> > installed as a package on my Fedora 14 system (Vim 7.3.315) with
> > those of my local build of Vim 7.4.838. Directory sizes were found
> > using 'du -hs'. The Fedora package doc files are gzipped; my doc
> > file are not compressed.
> >
> > /usr/share/vim/vim73 22M
> > /usr/share/vim/vim73/doc 2.5M
> >
> > /usr/local/share/vim/vim74 29M
> > /usr/local/share/vim/vim74/doc 6.0M
> >
> > What this shows is that the Fedora packagers are saving no more that
> > 3.5 MB of disc space by compressing the doc files. Given the size
> > of today's discs, it's ridiculous to spend any effort on compressing
> > these files or on working around problems from them being compressed.
> >
> > Fedora should stop compressing these files.
> >
> > Regards,
> > Gary
>
> Gary what your statistics show is that the total size of the
> documentation files for Vim 7.4 exceeds that of Vim 7.3 by 3.5
> megabytes. It does not show how much can be gained from the use of
> compression.

You missed the sentence preceding the data. I was hoping to avoid a
full explanation and avoid gathering data beyond what I had handy.
The Fedora Vim 7.3 doc file are gzipped to a size of 2.5 MB. My Vim
7.4 doc files are not compressed and occupy 6.0 MB.

Now, we can safely assume that the size of Vim's documentation has
grown from 7.3 to 7.4. Therefore, if the disc space occupied by
compressed 7.3 files is 2.5 MB, the disc space occupied by
compressed 7.4 files must be greater than, or possibly equal to, 2.5
MB.

The amount of spaced saved by gzipping the 7.4 files is

space saved = uncompressed size - compressed size
<= 6.0 MB - 2.5 MB
<= 3.5 MB

It isn't an exact result, but it is a bound.

> Now while whatever gains can be made won't be astronomically huge they
> will still be worth it. Now you and Christian do have a valid point
> about the fact that today's disk sizes are quite large and the savings
> aren't all that significant. In fact this is so much so that had we been
> having this conversation just a few months ago I would have agreed a lot
> more. However currently my disk is full almost to capacity in spite of
> my best efforts to remove extra cruft and frankly any space savings I
> could get right now would actually be quite appreciated.

While I can appreciate the problem of running out of disc space, 3.5
MB is only 0.23 % of 1.5 GB. If that little bit is a problem, and
you are trying to squeeze extra space out of your file system 0.23 %
at a time, you are not spending your time wisely. That space is
likely going to disappear the next time you upgrade or install
another package.

Regards,
Gary

[James McCoy]

On Sun, Sep 13, 2015 at 06:16:22PM -0700, Gary Johnson wrote:
> While I can appreciate the problem of running out of disc space, 3.5
> MB is only 0.23 % of 1.5 GB. If that little bit is a problem, and
> you are trying to squeeze extra space out of your file system 0.23 %
> at a time, you are not spending your time wisely.

I have 2100 packages installed on my system. If all of them decided
3.5MB of savings wasn't worthwhile, that's over 7GB of extra data. In
isolation, 3.5MB isn't but in total it can be an appreciable difference.

That being said, we stopped compressing the help files in Debian's
packages back in 2004 since, at the time, :helpgrep didn't work with
compressed help files. I'm not sure whether that's still the case.

[Christian Brabandt]

On So, 13 Sep 2015, James McCoy wrote:

> On Sun, Sep 13, 2015 at 06:16:22PM -0700, Gary Johnson wrote:
> > While I can appreciate the problem of running out of disc space, 3.5
> > MB is only 0.23 % of 1.5 GB. If that little bit is a problem, and
> > you are trying to squeeze extra space out of your file system 0.23 %
> > at a time, you are not spending your time wisely.
>
> I have 2100 packages installed on my system. If all of them decided
> 3.5MB of savings wasn't worthwhile, that's over 7GB of extra data. In
> isolation, 3.5MB isn't but in total it can be an appreciable difference.
>
> That being said, we stopped compressing the help files in Debian's
> packages back in 2004 since, at the time, :helpgrep didn't work with
> compressed help files. I'm not sure whether that's still the case.

Looks like this is still an issue. Wondering how the fedora guys solved
that. Anyway here is a patch, that loads the gzip plugin when running
vimtutor.

Best,
Christian
--
Das Evangelium durch ein Wunder beweisen heißt etwas Widersinniges
durch etwas Naturwidriges zu beweisen.
-- Denis Diderot

[Bram Moolenaar]

Christian Brabandt wrote:

> On So, 13 Sep 2015, James McCoy wrote:
>
> > On Sun, Sep 13, 2015 at 06:16:22PM -0700, Gary Johnson wrote:
> > > While I can appreciate the problem of running out of disc space, 3.5
> > > MB is only 0.23 % of 1.5 GB. If that little bit is a problem, and
> > > you are trying to squeeze extra space out of your file system 0.23 %
> > > at a time, you are not spending your time wisely.
> >
> > I have 2100 packages installed on my system. If all of them decided
> > 3.5MB of savings wasn't worthwhile, that's over 7GB of extra data. In
> > isolation, 3.5MB isn't but in total it can be an appreciable difference.
> >
> > That being said, we stopped compressing the help files in Debian's
> > packages back in 2004 since, at the time, :helpgrep didn't work with
> > compressed help files. I'm not sure whether that's still the case.
>
> Looks like this is still an issue. Wondering how the fedora guys solved
> that. Anyway here is a patch, that loads the gzip plugin when running
> vimtutor.

Thanks. Can someone for who it didn't work before confirm that this
fixes the problem?


--
I have read and understood the above. X________________

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Georgiy Treyvus]

On 09/14/2015 04:04 AM, Christian Brabandt wrote:
> On So, 13 Sep 2015, James McCoy wrote:
>
>> On Sun, Sep 13, 2015 at 06:16:22PM -0700, Gary Johnson wrote:
>>> While I can appreciate the problem of running out of disc space, 3.5
>>> MB is only 0.23 % of 1.5 GB. If that little bit is a problem, and
>>> you are trying to squeeze extra space out of your file system 0.23 %
>>> at a time, you are not spending your time wisely.
>>
>> I have 2100 packages installed on my system. If all of them decided
>> 3.5MB of savings wasn't worthwhile, that's over 7GB of extra data. In
>> isolation, 3.5MB isn't but in total it can be an appreciable difference.
>>
>> That being said, we stopped compressing the help files in Debian's
>> packages back in 2004 since, at the time, :helpgrep didn't work with
>> compressed help files. I'm not sure whether that's still the case.
>
> Looks like this is still an issue. Wondering how the fedora guys solved
> that. Anyway here is a patch, that loads the gzip plugin when running
> vimtutor.
>

Sorry for the late reply it's been a chaotic past few weeks for me.
Thank you so much for trying and quite probably succeeding at fixing this.

As far as how the folks at Fedora overcame the issue mentioned though I
feel like I'm missing some context with regards to fully understanding
it hopefully they'll be able to tell you soon enough. At around the time
I reported this here I filed
https://bugzilla.redhat.com/show_bug.cgi?id=1262182 there and pointed
them to this discussion. Hopefully when they see it your question will
be answered.

[Georgiy Treyvus]

On 09/14/2015 04:43 PM, Bram Moolenaar wrote:
>
> Christian Brabandt wrote:
>
>> On So, 13 Sep 2015, James McCoy wrote:
>>
>>> On Sun, Sep 13, 2015 at 06:16:22PM -0700, Gary Johnson wrote:
>>>> While I can appreciate the problem of running out of disc space, 3.5
>>>> MB is only 0.23 % of 1.5 GB. If that little bit is a problem, and
>>>> you are trying to squeeze extra space out of your file system 0.23 %
>>>> at a time, you are not spending your time wisely.
>>>
>>> I have 2100 packages installed on my system. If all of them decided
>>> 3.5MB of savings wasn't worthwhile, that's over 7GB of extra data. In
>>> isolation, 3.5MB isn't but in total it can be an appreciable difference.
>>>
>>> That being said, we stopped compressing the help files in Debian's
>>> packages back in 2004 since, at the time, :helpgrep didn't work with
>>> compressed help files. I'm not sure whether that's still the case.
>>
>> Looks like this is still an issue. Wondering how the fedora guys solved
>> that. Anyway here is a patch, that loads the gzip plugin when running
>> vimtutor.
>
> Thanks. Can someone for who it didn't work before confirm that this
> fixes the problem?
>

Bram are you referring to this bug or the other one involving :helpgrep?
I feel like I'm missing some context with regards to what's being
discussed here. Perhaps if I better understood this context I could be
of help testing that everything does indeed work as it should.

I'm not sure if the issue being discussed is this one or the related one
involving the :helpgrep command. I'm not sure if the bug you folks are
talking about occurs on Debian or Fedora or both. Also with regards to
Christian's patch what version of Vim or what git revision of what
branch must I build and/or acquire to test/confirm that all is well?

I use Fedora and while it would be difficult for me to migrate to Debian
if this is a Debian related issue perhaps I may be able to still run the
tests from a Debian Live CD assuming they've gotten less buggy since
last I've seen them. Let me know if/how I can be of help to you.

[Christian Brabandt]

On Fr, 02 Okt 2015, Georgiy Treyvus wrote:

> Bram are you referring to this bug or the other one involving :helpgrep?
> I feel like I'm missing some context with regards to what's being
> discussed here. Perhaps if I better understood this context I could be
> of help testing that everything does indeed work as it should.

There are two questions that came up. First, does your helpgrep command
work? If so, I wonder how they did it, since apparently, the fedora
maintainer decided to compress the help files and the helpgrep command
is not prepared to handle that.

Second, your issue, which you originally reported. That the help command
did not work when running the tutor. I have provided a patch, that
should fix this issue. For testing, it should be sufficient, to just
change the vimtutor command and replace this line:

,----
| # Start vim without any .vimrc, set 'nocompatible'
| $VIM -f -u NONE -c "set nocp" $TUTORCOPY
`----

by this line:
# Start vim without any .vimrc, set 'nocompatible' and load the gzip Plugin
$VIM -f -u NONE -c "set nocp" -c 'ru plugin/gzip.vim' $TUTORCOPY

(so basically just add the -c parameter to the vim command)

Then run vimtutor and test the help command.


Best,
Christian
--
Ich beschäftige mich nicht mit dem, was getan worden ist. Mich
interessiert, was getan werden muß.
-- Marie Curie

[Bram Moolenaar]

Georgiy Treyvus wrote:

> On 09/14/2015 04:43 PM, Bram Moolenaar wrote:
> >
> > Christian Brabandt wrote:
> >
> >> On So, 13 Sep 2015, James McCoy wrote:
> >>
> >>> On Sun, Sep 13, 2015 at 06:16:22PM -0700, Gary Johnson wrote:
> >>>> While I can appreciate the problem of running out of disc space, 3.5
> >>>> MB is only 0.23 % of 1.5 GB. If that little bit is a problem, and
> >>>> you are trying to squeeze extra space out of your file system 0.23 %
> >>>> at a time, you are not spending your time wisely.
> >>>
> >>> I have 2100 packages installed on my system. If all of them decided
> >>> 3.5MB of savings wasn't worthwhile, that's over 7GB of extra data. In
> >>> isolation, 3.5MB isn't but in total it can be an appreciable difference.
> >>>
> >>> That being said, we stopped compressing the help files in Debian's
> >>> packages back in 2004 since, at the time, :helpgrep didn't work with
> >>> compressed help files. I'm not sure whether that's still the case.
> >>
> >> Looks like this is still an issue. Wondering how the fedora guys solved
> >> that. Anyway here is a patch, that loads the gzip plugin when running
> >> vimtutor.
> >
> > Thanks. Can someone for who it didn't work before confirm that this
> > fixes the problem?
> >
> Bram are you referring to this bug or the other one involving :helpgrep?
> I feel like I'm missing some context with regards to what's being
> discussed here. Perhaps if I better understood this context I could be
> of help testing that everything does indeed work as it should.

I was referring to the patch that Christian provided. Any remaining
problem after that?

> I'm not sure if the issue being discussed is this one or the related one
> involving the :helpgrep command. I'm not sure if the bug you folks are
> talking about occurs on Debian or Fedora or both. Also with regards to
> Christian's patch what version of Vim or what git revision of what
> branch must I build and/or acquire to test/confirm that all is well?

I can only fix the Vim distribution, not Debian or Fedora :-).

> I use Fedora and while it would be difficult for me to migrate to Debian
> if this is a Debian related issue perhaps I may be able to still run the
> tests from a Debian Live CD assuming they've gotten less buggy since
> last I've seen them. Let me know if/how I can be of help to you.

--
How To Keep A Healthy Level Of Insanity:
8. Don't use any punctuation marks.