Loading ...
Sorry, an error occurred while loading the content.
 

Re: Weird problem with helpgrep

Expand Messages
  • DervishD
    Hi Bram :) ... I hadn t seen this from that point of view. For me they were documentation (as things you put under /usr/doc ) rather than help files (as
    Message 1 of 13 , Jan 30, 2007
      Hi Bram :)

      * Bram Moolenaar <Bram@...> dixit:
      > DervishD wrote:
      > > Given that "/usr/doc" or "/usr/share/doc" are pretty standard when
      > > it comes to install documentation, shouldn't "ex_helpgrep" use the
      > > directory from "helpfile" too, just like ":help" does?
      >
      > Vim documentation must be in the runtime directory. It doesn't make any
      > sense to put it below /usr/doc. These are help files, not generic
      > documentation files.

      I hadn't seen this from that point of view. For me they were
      documentation (as "things you put under /usr/doc") rather than help
      files (as "things you probably should place under /usr/lib").

      > Generally I find it quite strange to order application-specific files
      > by their type instead of by the application.

      But that's a very sensible thing to do. This way you can partition
      the hiearchy much more efficiently. For example, I have my /usr "zone"
      backup recorded on a DVD, and the rest of my system is on a CD and a USB
      pendrive. This way, if my hard disk decides to break, I can have my
      system up and running again in less than 10 minutes, booting from the
      CD, putting the read-write portion of my system in a ramdisk (under
      Linux, I mean) and mounting my backup DVD as /usr. By dividing by type
      and not by app, all read-only files are placed under the same mount
      point. Take a look at the FHS standard for a much deeper rationale
      (e.g., the division between /var and /usr, for example).

      I know, it is weird outside UNIX, and when I started to use Linux,
      almost a decade ago, I found it very strange and mind boggling, but in
      the end, that kind of filesystem structure has been a bless ;))

      > You scatter files all over the system and are left with files that you
      > don't know where to put (there is no /usr/syntax, /usr/indent or
      > /usr/vimplugins).

      Of course, those kind of files should go under /usr/lib/vim: they
      are static data needed for the program to run. If you modify them
      frequently (and you shouldn't, because you have all the "/after" dirs
      for modifying the vim runtime behaviour), you can place them under
      /etc/vim, for example. I have my own runtime under /etc/vim because I
      consider them configuration files and not exactly a runtime. Having the
      documentation under /etc/vim is weird in that case.

      But that's not the point. The point is that I may not want to use
      the default runtime. Then, where should I put the documentation for Vim?
      OK, they may count as help files, and so they should go under
      /usr/lib/vim/doc, no problem with that. But imagine I have a system
      which indexes ALL documentation in my system. Then I'll prefer to have
      all the documentation under /usr/doc.

      The point is: I should be able to put the application files,
      separated by type, where they fit under my hierarchy, always under
      common sense (for example, doesn't put help files under /var/lib/).
      Things like autoconf or mobs do these kind of duties (amongs others).

      And, BTW, I have my own vim runtime under /etc/vim, with no subdirs,
      it is very small (only handles the filetypes I use, and indentation,
      syntax and the like are fully adapted to my likings) and I have it
      mirrored on a SVN server so I can go back and forth between revisions of
      the files ;) It's weird, but I can do it because vim is flexible enough
      to allow it (except for helpgrep, but that can be fixed without touching
      the source code at all).

      > Anyway, using the directory from 'helpfile' for ":helpgrep" should indeed
      > be done. Otherwise it's not consistent with ":help".

      I think the same.

      > > I'm not familiar enough with the source to be able to add support
      > > for "helpfile" path to "ex_helpgrep" without resorting to a dirty
      > > hack, but I can try... "ex_helpgrep" looks like it is tailored to
      > > only process "runtimepath/doc" in the main loop, so any nonintrusive
      > > modification is almost impossible.
      >
      > I think that changing the source code would be the right thing to do.

      If you want, I can try to make the modification, but since I'm not
      familiar with the code, I cannot make promises about the code quality
      O:)

      Thanks for your answer :)

      Raúl Núñez de Arenas Coronado

      --
      Linux Registered User 88736 | http://www.dervishd.net
      It's my PC and I'll cry if I want to... RAmen!
    • Bram Moolenaar
      ... There is a big difference between placing files by their properties (e.g. being static or dynamic) or by their filetype. In my opinion all static files of
      Message 2 of 13 , Jan 30, 2007
        DervishD wrote:

        > > Generally I find it quite strange to order application-specific files
        > > by their type instead of by the application.
        >
        > But that's a very sensible thing to do. This way you can partition
        > the hiearchy much more efficiently. For example, I have my /usr "zone"
        > backup recorded on a DVD, and the rest of my system is on a CD and a USB
        > pendrive. This way, if my hard disk decides to break, I can have my
        > system up and running again in less than 10 minutes, booting from the
        > CD, putting the read-write portion of my system in a ramdisk (under
        > Linux, I mean) and mounting my backup DVD as /usr. By dividing by type
        > and not by app, all read-only files are placed under the same mount
        > point. Take a look at the FHS standard for a much deeper rationale
        > (e.g., the division between /var and /usr, for example).
        >
        > I know, it is weird outside UNIX, and when I started to use Linux,
        > almost a decade ago, I found it very strange and mind boggling, but in
        > the end, that kind of filesystem structure has been a bless ;))

        There is a big difference between placing files by their properties
        (e.g. being static or dynamic) or by their filetype. In my opinion all
        static files of a certain version of a certain program can be put
        together. Only a few things might need to be spread to other
        directories, using symlinks when possible (binary in /usr/local/bin,
        libs in /usr/local/lib, header files in /usr/local/include).
        Config file goes in /usr/local/etc, dynamic things below /var somewhere.
        I don't see a reason to move documentation files, unless they are in a
        standard format and will be found by generic tools. There is a standard
        place for man pages, of course (well, ignoring language and encoding,
        there doesn't seem to be a widely used standard for that).

        > > You scatter files all over the system and are left with files that you
        > > don't know where to put (there is no /usr/syntax, /usr/indent or
        > > /usr/vimplugins).
        >
        > Of course, those kind of files should go under /usr/lib/vim: they
        > are static data needed for the program to run. If you modify them
        > frequently (and you shouldn't, because you have all the "/after" dirs
        > for modifying the vim runtime behaviour), you can place them under
        > /etc/vim, for example. I have my own runtime under /etc/vim because I
        > consider them configuration files and not exactly a runtime. Having the
        > documentation under /etc/vim is weird in that case.

        /etc is really a bad place for these files. Only files that contain
        configuration options should go there. Some systems do have a
        /etc/vimrc, but having system-wide editor defaults is not good. All the
        default option values, as documented in the help file, might actually
        be overwritten with different defaults then.

        > But that's not the point. The point is that I may not want to use
        > the default runtime. Then, where should I put the documentation for Vim?
        > OK, they may count as help files, and so they should go under
        > /usr/lib/vim/doc, no problem with that. But imagine I have a system
        > which indexes ALL documentation in my system. Then I'll prefer to have
        > all the documentation under /usr/doc.

        You could put a copy of the Vim help there, if your indexing system can
        handle it (never seen that). I would not _move_ it there. Using
        symlinks would come in handy. Nevertheless, if somehow the format of
        the Vim runtime files change (e.g., help files are compresed), your
        system will fall down.

        > The point is: I should be able to put the application files,
        > separated by type, where they fit under my hierarchy, always under
        > common sense (for example, doesn't put help files under /var/lib/).
        > Things like autoconf or mobs do these kind of duties (amongs others).

        Autoconf only knows about generic things like man pages. You can't use
        that for Vim help files or other application-specific things.

        > And, BTW, I have my own vim runtime under /etc/vim, with no subdirs,
        > it is very small (only handles the filetypes I use, and indentation,
        > syntax and the like are fully adapted to my likings) and I have it
        > mirrored on a SVN server so I can go back and forth between revisions of
        > the files ;) It's weird, but I can do it because vim is flexible enough
        > to allow it (except for helpgrep, but that can be fixed without touching
        > the source code at all).

        It sounds very much like you actually have your personal things in
        system-wide directories.

        > > Anyway, using the directory from 'helpfile' for ":helpgrep" should indeed
        > > be done. Otherwise it's not consistent with ":help".
        >
        > I think the same.
        >
        > > > I'm not familiar enough with the source to be able to add support
        > > > for "helpfile" path to "ex_helpgrep" without resorting to a dirty
        > > > hack, but I can try... "ex_helpgrep" looks like it is tailored to
        > > > only process "runtimepath/doc" in the main loop, so any nonintrusive
        > > > modification is almost impossible.
        > >
        > > I think that changing the source code would be the right thing to do.
        >
        > If you want, I can try to make the modification, but since I'm not
        > familiar with the code, I cannot make promises about the code quality
        > O:)

        Give it a try. I probably won't have time for it soon.

        --
        hundred-and-one symptoms of being an internet addict:
        71. You wonder how people walk

        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
        /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
        \\\ download, build and distribute -- http://www.A-A-P.org ///
        \\\ help me help AIDS victims -- http://ICCF-Holland.org ///
      • DervishD
        Hi Bram :) ... Not really, frequently the filetype is a property (for example, libraries, binaries, etc.). ... Well, I know about a packaging system that
        Message 3 of 13 , Jan 31, 2007
          Hi Bram :)

          * Bram Moolenaar <Bram@...> dixit:
          > DervishD wrote:
          >
          > > > Generally I find it quite strange to order application-specific files
          > > > by their type instead of by the application.
          > >
          > > But that's a very sensible thing to do. This way you can partition
          > > the hiearchy much more efficiently. For example, I have my /usr "zone"
          > > backup recorded on a DVD, and the rest of my system is on a CD and a USB
          > > pendrive. This way, if my hard disk decides to break, I can have my
          > > system up and running again in less than 10 minutes, booting from the
          > > CD, putting the read-write portion of my system in a ramdisk (under
          > > Linux, I mean) and mounting my backup DVD as /usr. By dividing by type
          > > and not by app, all read-only files are placed under the same mount
          > > point. Take a look at the FHS standard for a much deeper rationale
          > > (e.g., the division between /var and /usr, for example).
          > >
          > > I know, it is weird outside UNIX, and when I started to use Linux,
          > > almost a decade ago, I found it very strange and mind boggling, but in
          > > the end, that kind of filesystem structure has been a bless ;))
          >
          > There is a big difference between placing files by their properties
          > (e.g. being static or dynamic) or by their filetype.

          Not really, frequently the "filetype" is a property (for example,
          libraries, binaries, etc.).

          > In my opinion all
          > static files of a certain version of a certain program can be put
          > together. Only a few things might need to be spread to other
          > directories, using symlinks when possible (binary in /usr/local/bin,
          > libs in /usr/local/lib, header files in /usr/local/include).

          Well, I know about a packaging system that does exactly that (I
          don't remember its name). The problem is that maintaining that lot of
          symlinks is a mess, usually. It's easier (and IMHO more convenient) to
          use the installation system of the package to put the files where they
          belong (again, IMHO) in the first place.

          > > Of course, those kind of files should go under /usr/lib/vim: they
          > > are static data needed for the program to run. If you modify them
          > > frequently (and you shouldn't, because you have all the "/after" dirs
          > > for modifying the vim runtime behaviour), you can place them under
          > > /etc/vim, for example. I have my own runtime under /etc/vim because I
          > > consider them configuration files and not exactly a runtime. Having the
          > > documentation under /etc/vim is weird in that case.
          >
          > /etc is really a bad place for these files. Only files that contain
          > configuration options should go there. Some systems do have a
          > /etc/vimrc, but having system-wide editor defaults is not good. All the
          > default option values, as documented in the help file, might actually
          > be overwritten with different defaults then.

          I understand your point: the machine users end up with a vim whose
          default behaviour is not that of the documentation.

          > > The point is: I should be able to put the application files,
          > > separated by type, where they fit under my hierarchy, always under
          > > common sense (for example, doesn't put help files under /var/lib/).
          > > Things like autoconf or mobs do these kind of duties (amongs others).
          >
          > Autoconf only knows about generic things like man pages. You can't use
          > that for Vim help files or other application-specific things.

          But currently, with Vim, you can't use it either to set the runtime
          (you must give "VIMRUNTIMEDIR" and "VIMRTLOC" to "make"), which should
          be considered to go in "datadir".

          > > And, BTW, I have my own vim runtime under /etc/vim, with no subdirs,
          > > it is very small (only handles the filetypes I use, and indentation,
          > > syntax and the like are fully adapted to my likings) and I have it
          > > mirrored on a SVN server so I can go back and forth between revisions of
          > > the files ;) It's weird, but I can do it because vim is flexible enough
          > > to allow it (except for helpgrep, but that can be fixed without touching
          > > the source code at all).
          >
          > It sounds very much like you actually have your personal things in
          > system-wide directories.

          Oh, not at all, it's only that all the users in my machine want more
          or less the same set of defaults, so for me it's easier to put them in
          the system wide vimrc instead of maintaining changes in every home
          directory.

          > > > Anyway, using the directory from 'helpfile' for ":helpgrep" should indeed
          > > > be done. Otherwise it's not consistent with ":help".
          > >
          > > I think the same.
          > >
          > > > > I'm not familiar enough with the source to be able to add support
          > > > > for "helpfile" path to "ex_helpgrep" without resorting to a dirty
          > > > > hack, but I can try... "ex_helpgrep" looks like it is tailored to
          > > > > only process "runtimepath/doc" in the main loop, so any nonintrusive
          > > > > modification is almost impossible.
          > > >
          > > > I think that changing the source code would be the right thing to do.
          > >
          > > If you want, I can try to make the modification, but since I'm not
          > > familiar with the code, I cannot make promises about the code quality
          > > O:)
          >
          > Give it a try. I probably won't have time for it soon.

          OK, I'll start working on it as soon as I can afford the time.

          Raúl Núñez de Arenas Coronado

          --
          Linux Registered User 88736 | http://www.dervishd.net
          It's my PC and I'll cry if I want to... RAmen!
        • François Pinard
          [DervishD] ... Hi, people. Just perusing email in ultra-fast mode :-). I did not read the previous exchanges, so I apologize if I m out of context. I used
          Message 4 of 13 , Jan 31, 2007
            [DervishD]
            > [Bram Moolenaar]

            >> Only a few things might need to be spread to other directories, using
            >> symlinks when possible (binary in /usr/local/bin, libs in
            >> /usr/local/lib, header files in /usr/local/include).

            >Well, I know about a packaging system that does exactly that (I don't
            >remember its name). The problem is that maintaining that lot of
            >symlinks is a mess, usually. It's easier (and IMHO more convenient) to
            >use the installation system of the package to put the files where they
            >belong (again, IMHO) in the first place.

            Hi, people. Just perusing email in ultra-fast mode :-). I did not read
            the previous exchanges, so I apologize if I'm out of context.

            I used two installation systems which were extremely fond on symbolic
            links: LUDE (from Université de Montréal) and Stow (from GNU). Both
            have been used in various places.

            LUDE was a bit gigantic for my own needs, I've never really been
            comfortable with it. Stow was OK and clean (not so messy). Even if
            I was careful to be stow-compatible for a few packages I maintained in
            another life, I nowadays prefer installations to be plain straight.

            --
            François Pinard http://pinard.progiciels-bpi.ca
          • DervishD
            Hi François :) ... [...] ... Stow!, that s the name I didn t remember :) Thanks for pointing! Raúl Núñez de Arenas Coronado -- Linux Registered User 88736
            Message 5 of 13 , Feb 1, 2007
              Hi François :)

              * François Pinard <pinard@...> dixit:
              > [DervishD]
              > >[Bram Moolenaar]
              > >>Only a few things might need to be spread to other directories, using
              > >>symlinks when possible (binary in /usr/local/bin, libs in
              > >>/usr/local/lib, header files in /usr/local/include).
              > >Well, I know about a packaging system that does exactly that (I don't
              > >remember its name).
              [...]
              > I used two installation systems which were extremely fond on symbolic
              > links: LUDE (from Université de Montréal) and Stow (from GNU). Both
              > have been used in various places.

              Stow!, that's the name I didn't remember :) Thanks for pointing!

              Raúl Núñez de Arenas Coronado

              --
              Linux Registered User 88736 | http://www.dervishd.net
              It's my PC and I'll cry if I want to... RAmen!
            Your message has been successfully submitted and would be delivered to recipients shortly.