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

The netrw plugin and patches

Expand Messages
  • Erik Warendorph
    Hi! I m sorry for cross-posting this one, but I wasn t really sure where it s supposed to go, since it s mostly about the netrw plugin, but also about patches
    Message 1 of 2 , Sep 2, 2002
    • 0 Attachment
      Hi!

      I'm sorry for cross-posting this one, but I wasn't really sure
      where it's supposed to go, since it's mostly about the netrw
      plugin, but also about patches in general...

      I had this idea of adding support for the rsync protocol to the
      netrw plugin. So I downloaded the latest sources, made sure
      that the newest version of netrw.vim was identical to the one
      in /usr/share/vim/vim61/plugin/netrw.vim on my machine and
      started... When I was finished implementing rsync (and some
      other stuff), I suddenly remembered about the patches... And
      of course there were two patches (6.1.064 and 6.1.117) for
      netrw.vim which I should have applied before starting. So that
      taught me a lesson!

      Well, before I start redoing everything against the patched
      version of netrw.vim, I thought I'd ask you all (especially you
      Chip, since you're the maintainer) if I should bother with
      these changes, so here's a list of what I did (and plan to
      redo):

      (1) Support for rsync: It is very similar to scp, so it wasn't
      actually much programming, more like "cut'n'paste"
      ("yank'n'put" :) from raf's scp code and then doing
      s/scp/rsync/ (more or less). I added this as netrw method
      6, but in patch 6.1.064 cadaver support now uses method 6,
      so I guess I should change it to method 7.

      (For those of you who haven't heard about rsync, it's
      similar to rcp and scp (it can be set up to use either rsh
      or ssh), but it only transfers the parts of the files that
      have changed, so it is much faster on big files with just a
      couple of changes in them.)

      (2) New global variable g:netrw_fixundo: The default is 0, to
      maintain backward compatibility. If this is set to a
      non-zero value, a rather inelegant hack is used to prevent
      the user from undoing back past the reading of the file to
      the empty buffer (so it behaves more like it does when
      editing local files). The code is put into the end of the
      NetGetFile function, here's the old code:

      " Delete last line when 0r used to read file and last line is empty
      if a:readcmd[0] == '0' && dodel && getline("$") == ""
      $d
      1
      endif

      and here's the new code:

      " Delete last line when 0r used to read file and last line is empty
      if a:readcmd[0] == '0' && dodel && getline("$") == ""
      $d
      1
      " inelegant hack to make sure we can't undo back to an empty file
      if g:netrw_fixundo != 0
      " save old undolevels and disable undo before fake modifying
      let s:save_ul = &ul
      set ul=-1
      " fake modify commands (use silent since it's just fake)
      silent norm O<Esc>
      silent norm dd
      silent norm uu
      " restore old undolevels
      let &ul = s:save_ul
      endif

      if someone know of a slightly less ugly way of "clearing"
      undo so you can't undo past a change, please share it!

      (3) New global variable g:netrw_silent: The default is 0, to
      maintain backward compatibility. If this is set to a
      non-zero value "silent" is put in front of all commands
      that echo stuff to the screen. The idea is to avoid having
      to press <Enter> when reading or writing.

      The problem with this is that I have to test for it for all
      commmands that might echo stuff to the screen, so a simple

      exe "'z+1,.!ftp -i -n"

      will be turned into

      if g:netrw_silent == 0
      exe "'z+1,.!ftp -i -n"
      else
      silent exe "'z+1,.!ftp -i -n"
      endif

      which makes the code much harder to read. But maybe there
      are other (more elegant) ways of accomplishing the same...?

      (4) New global variables g:netrw_*_cmd: These are used for the
      names of the external commands when reading and writing,
      instead of the hardcoded ones which are used now. Here
      they are with their default values:

      g:netrw_rcp_cmd = "rcp"
      g:netrw_ftp_cmd = "ftp"
      g:netrw_scp_cmd = "scp"
      g:netrw_http_cmd = "wget"
      g:netrw_rsync_cmd = "rsync -a"

      (I guess g:netrw_cadaver_cmd = "cadaver" should be added
      now). The point of having these in global variables for
      the user to change isn't really to use other commands than
      the default ones (since some of the code using them depends
      on the way they behave), although it can be used for this.
      The main benefit is that the user can add (and remove)
      command options, which, among other things, could make the
      output less or more verbose. Together with g:netrw_silent
      above this can be used to tune the output when reading and
      writing. For example, doing:

      :let g:netrw_silent = 1 | let g:netrw_scp_cmd = "scp -q"

      will make the reading and writing using scp behave quietely
      (similar to reading/writing local files). If you want
      (very) verbose reading and writing, you can do:

      :let g:netrw_silent = 0 | let g:netrw_scp_cmd = "scp -v"

      Alas, this doesn't work for ftp, since its verbose output
      will be put into the buffer along with the file content.
      But it might be useful to set/unset active/passive mode.
      And it could be used to set ssh protocol version and
      compression for scp and rsync. And probably other useful
      stuff...

      (5) Removal of explicit html filetype for http: In the code
      for http in the NetRead function, I don't think the line

      set ft=html

      is really necessary. If the URL contains an html file, the
      filetype will be set to html anyway, and for files of a
      different file type it will be wrong (my point here is that
      the file isn't necessarily html although the protocol is
      http).

      But this isn't totally true -- there are exceptions: If
      the URL ends in a directory, an index.html file (or
      similar) in that directory will be read without the
      filetype being set automagically to html afterwards (which
      it should be). Maybe there could be some nifty check for
      the last character in the URL being a slash? But this
      wouldn't catch URLs which actually "return" html code, but
      neither ends in ".html" or a slash. Maybe we could have
      another global variable (g:netrw_http_ft_html = 1) so the
      user could tune the behaviour...?

      Thoughts, comments, ideas, flames, and constructive and
      destructive criticism are welcome!

      I also have some general questions which I hope someone will
      take the time to answer:

      (6) Where should stuff like this be posted? To vim@...,
      vim-dev@..., or both?

      (7) Is it OK to just start messing around in plugins (and other
      files) that other people maintain and post a patch when
      finished, or should I first ask the maintainer? Or should
      I ask on the mailing list(s)? (What do you prefer, Chip?)

      (8) Do maintainers like to get patches or do they generally
      want suggestions and ideas, and then program it themselves?

      (9) From what I've seen of patches for Vim, all seem to use the
      context diff format ("diff -c"). Personally I prefer the
      unified diff format ("diff -u") (but I'm flexible -- I'm
      not trying to start a "diff format jihad" here... :). Is
      the context diff format a standard which are supposed to be
      used by everyone contributing to Vim?

      --
      Erik Warendorph (_) ___ __oO~
      <erik.warendorph@...> ~o O~ |\ /----)
      (._.)__| __\_/
      http://home.no.net/eware/ Cow ||"|| & _()_ Chicken
    • Bram Moolenaar
      Erik Warendorph wrote: I ll leave commenting on the netrw items to Charles. Most of it sounds useful to me, but we have to watch out for adding too many
      Message 2 of 2 , Sep 3, 2002
      • 0 Attachment
        Erik Warendorph wrote:

        I'll leave commenting on the netrw items to Charles. Most of it sounds
        useful to me, but we have to watch out for adding too many features in
        this plugin that is loaded by default.

        > (6) Where should stuff like this be posted? To vim@...,
        > vim-dev@..., or both?

        Since this is about making changes to Vim more than about normal use
        this should go to vim-dev.

        > (7) Is it OK to just start messing around in plugins (and other
        > files) that other people maintain and post a patch when
        > finished, or should I first ask the maintainer? Or should
        > I ask on the mailing list(s)? (What do you prefer, Chip?)

        There is nothing that stops you from messing around with the Vim
        scripts, except that you might have to redo your work when a new version
        is released.

        > (9) From what I've seen of patches for Vim, all seem to use the
        > context diff format ("diff -c"). Personally I prefer the
        > unified diff format ("diff -u") (but I'm flexible -- I'm
        > not trying to start a "diff format jihad" here... :). Is
        > the context diff format a standard which are supposed to be
        > used by everyone contributing to Vim?

        Not everybody has a patch program that understands unified diffs.

        --
        A poem: read aloud:

        <> !*''# Waka waka bang splat tick tick hash,
        ^"`$$- Caret quote back-tick dollar dollar dash,
        !*=@$_ Bang splat equal at dollar under-score,
        %*<> ~#4 Percent splat waka waka tilde number four,
        &[]../ Ampersand bracket bracket dot dot slash,
        |{,,SYSTEM HALTED Vertical-bar curly-bracket comma comma CRASH.

        Fred Bremmer and Steve Kroese (Calvin College & Seminary of Grand Rapids, MI.)

        /// Bram Moolenaar -- Bram@... -- http://www.moolenaar.net \\\
        /// Creator of Vim -- http://vim.sf.net -- ftp://ftp.vim.org/pub/vim \\\
        \\\ Project leader for A-A-P -- http://www.a-a-p.org ///
        \\\ Lord Of The Rings helps Uganda - http://iccf-holland.org/lotr.html ///
      Your message has been successfully submitted and would be delivered to recipients shortly.