http://permalink.gmane.org/gmane.editors.vim.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.editors.vim.devel/34601 <pre>Hello email bounced. &lt;ds26&lt; at &gt;gte.com&gt;: Sorry,_I_wasn't_able_to_establish_an_SMTP_connection._(#4.4.1)/I'm_not_going_to_try_again;_this_message_has_been_in_the_queue_too_long./ </pre> Thilo Six 2012-05-22T18:00:14 http://permalink.gmane.org/gmane.editors.vim.devel/34600 <pre>There must be some assumptions here Or I am missing some context It seems to me that the below example p:8 can only work if you know your path name only consists of one-node ??? What happens if your path name is "c:\lets have some fun\with silly mickey-soft windows" -----Original Message----- From: vim_dev&lt; at &gt;googlegroups.com [mailto:vim_dev&lt; at &gt;googlegroups.com] On Behalf Of John Beckett Sent: Monday, May 21, 2012 8:24 PM To: vim_dev&lt; at &gt;googlegroups.com Subject: RE: home_replace() does not work with short path name on windows. mattn wrote: If there is a problem, please spell it out as the above is correct. That's why I said *if* :p always produced the expanded long name, then :p:8 would be all that was needed to produce the equivalent short name. If :p produced the expanded long path, would there be a need for any further changes? Why? John -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http:/</pre> Bovy, Stephen 2012-05-22T16:02:39 http://permalink.gmane.org/gmane.editors.vim.devel/34599 <pre>Bram, I noticed the GTK build of gvim does not make use of the browsefilter variables. So I threw some code at that problem ;) Find the patch attached. regards, Christian </pre> Christian Brabandt 2012-05-22T13:54:21 http://permalink.gmane.org/gmane.editors.vim.devel/34598 <pre>Hello everybody This is a very small patch. The preprocessor directive is not nested. It distracted me a little. Greetings Elias </pre> Elias Diem 2012-05-22T09:06:05 http://permalink.gmane.org/gmane.editors.vim.devel/34597 <pre> I don't know how many bugs about short name in vim. I found a bug about home_replace() in the first, In next, I found fnamemodify(). home_replace() is used in :scriptnames, or fnamemodify(x, ':~') or etc. Or do you mean "You should change subject of this thread" ? We need long path, not short name. In some times, file name has an important thing about `What is this`. Short name break them. For example, :let filename = s:get_vimrc_filename_from_somewhere() :if filename =~ '[/\][._]vimrc$' " is .vimrc or _vimrc ? : call s:do_something_about_vimrc() :endif If `s:get_vimrc_filename_from_somewhere` return short path name(for example output from external program), We can't expand long path. Please try following. :let shortname = fnamemodify('~/.vimrc', ':p:8') :echo shortname c:/docume~1/mattn/VIMRC~1 :echo fnamemodify(shortname, ':p') c:/docume~1/mattn/VIMRC~1 Then, the code above don't pass into doing `s:do_something_about_vimrc`. And also, we can't know .vimrc become 'vimrc~1' or 'vimrc~2' or others </pre> mattn 2012-05-22T04:40:00 http://permalink.gmane.org/gmane.editors.vim.devel/34596 <pre> If there is a problem, please spell it out as the above is correct. That's why I said *if* :p always produced the expanded long name, then :p:8 would be all that was needed to produce the equivalent short name. If :p produced the expanded long path, would there be a need for any further changes? Why? John </pre> John Beckett 2012-05-22T03:23:49 http://permalink.gmane.org/gmane.editors.vim.devel/34595 <pre> No. :echo fnamemodify('C:\Program Files', ':8:p') C:\PROGRA~1 What we want is full long path. Currentl, :p don't return long full long path. Do you prefer :9 or :) ? </pre> mattn 2012-05-22T01:44:17 http://permalink.gmane.org/gmane.editors.vim.devel/34594 <pre> Is that needed? If :p (on Windows) always produced the expanded long name, then :p:8 could be used if someone wanted the short full path. I can't see a reason someone would need an 8.3 name expanded to anything other than its full long path (with :p), or its full short path (with :p:8). At any rate, :f does not sound a good mnemonic for "short". John </pre> John Beckett 2012-05-21T22:54:04 http://permalink.gmane.org/gmane.editors.vim.devel/34593 <pre>Hello Bram, Excerpt from Bram Moolenaar: </pre> Thilo Six 2012-05-21T19:26:55 http://permalink.gmane.org/gmane.editors.vim.devel/34592 <pre> Thilo Six wrote: I would propose to make changes like this after a version control system has been setup for runtime file maintainers. That way it's easier to track changes and the reason why they were made. I would expect a change to the file with a comment that mentions that the email bounced. I don't want to do these commits for every little change, it takes too much of my time. I don't know what the overhead is for these commits. If not too much I could pull the changes into the release version, instead of applying the diff and making a commit for lots of changes at once. Note that it's still possible that some email bounces once but works the next day. </pre> Bram Moolenaar 2012-05-21T19:07:28 http://permalink.gmane.org/gmane.editors.vim.devel/34591 <pre> Yeah, but Google Code only has a few allowed licenses. Vim License is not one of them. Bram has dual-licensed Vim under GPL v2 and Vim License to allow putting it on Google Code. </pre> Ben Fritz 2012-05-21T18:43:10 http://permalink.gmane.org/gmane.editors.vim.devel/34590 <pre>Hello John, Excerpt from John Beckett: I am all with you here. I just want to add a note. see below. runtimefiles are all (or better they all should be) licensed under Vim licences. This is important to note. Uniform licening in all runtimefiles and make sure they all stay at this level is one of the todos that our team should take care of. Their are some more "standardizations" that i would like us to work on. </pre> Thilo Six 2012-05-21T17:59:47 http://permalink.gmane.org/gmane.editors.vim.devel/34589 <pre>Hello Charles, Excerpt from Charles Campbell: </pre> Thilo Six 2012-05-21T17:49:29 http://permalink.gmane.org/gmane.editors.vim.devel/34588 <pre>Hello Ben and John, Excerpt from Ben Fritz: </pre> Thilo Six 2012-05-21T17:30:29 http://permalink.gmane.org/gmane.editors.vim.devel/34587 <pre>In my experience, its often _not_ straightforward (although, admittedly, sometimes it is). Also, I've received several patches that fixed an issue, but would have introduced other problems. Of course, with languages' syntax files that are mostly just keyword lists would be straightforward to upgrade (if the upgrade only needed more keywords, that is). Regards, Chip Campbell </pre> Charles Campbell 2012-05-21T16:49:26 http://permalink.gmane.org/gmane.editors.vim.devel/34586 <pre>&lt;snip&gt; &lt;snip&gt; Perhaps there could be an automated annual email such as: ------------------------------- Hello! Thank you for your maintaining of &lt;runtimefile.vim&gt;. The Vim community greatly appreciates your work. This is an automated annual request: are you still willing to be a maintainer? Regards, The Vim Community ------------------------------- Actually, I'd prefer it if I only received one such emails for all the runtime files I maintain, so idealy that &lt;runtimefile.vim&gt; would be changed to &lt;runtimefile.vim&gt; &lt;runtimefile.vim&gt; ... so I only needed to reply once. Regards, Chip Campbell </pre> Charles Campbell 2012-05-21T16:40:43 http://permalink.gmane.org/gmane.editors.vim.devel/34585 <pre>Hello Gary, Excerpt from Gary Johnson: </pre> Thilo Six 2012-05-21T16:34:29 http://permalink.gmane.org/gmane.editors.vim.devel/34584 <pre>Hello Bram, Excerpt from Bram Moolenaar: </pre> Thilo Six 2012-05-21T16:32:30 http://permalink.gmane.org/gmane.editors.vim.devel/34583 <pre> Yes, I think this would be a good thing to put in the file header. And sections of a file with special considerations, like the auto-generated section of the Vim syntax file, could have a prominent comment nearby alerting any potential contributors. I think level 3 has two major differences from level 4: 1. the official maintainer would be the "default" person to make changes from suggestions on the list, bugfixes, etc. 2. the official maintainer would be a "file guru" as you say, at least until the team maintainers gain the needed knowledge, which might take years if it ever happens. Many runtime files change quite infrequently. Agreed. I think level (1) is the only level appropriate for including only a personal address in the file. Level (2) could probably list the vim_dev list as primary contact, and the maintainer as a secondary if at all (in case the maintainer wants to be CC'd on emails to the list). Level (3) or (4) should probably just list vim_dev. I think when we get this underway </pre> Ben Fritz 2012-05-21T15:17:11 http://permalink.gmane.org/gmane.editors.vim.devel/34582 <pre> I thought about this too. I think we may need a new thread to discuss this at some point...but of course Bram gets the final say since he's the one pulling changes. What files go in the repository are in large part determined by how Bram wants to pull changes. At a high level, I see a few options: 1. Runtime repository is independent of the Vim repository. Bram pulls changes by updating to the latest of the runtime repository and manually copying files into the Vim repository. This would be most similar to the current method but doesn't provide much context to the runtime changes in terms of change history or how it ties to specific version of the C code. On the other hand, the history is "clean" as Bram is used to releasing. 2. Runtime repository is actually a clone of the full Vim repository. Bram uses pull/transplant/merge/whatever Mercurial command to just get the changes. Developers in the runtime repository just know not to modify the .c source files. Reviewers of the "o</pre> Ben Fritz 2012-05-21T14:53:11 http://permalink.gmane.org/gmane.editors.vim.devel/34581 <pre> Perhaps I was not clear. There can be any number people with "push" access to a project. You can see contributors listed under the "members" area on the project home page. What you cannot have more than one committer to, is the server-side clones listed on the same project. These are the clones created if you click the "source" tab on the google code page, then hit the "create a clone" button. You can see a few dozen clones on the Vim project page, on the "source" tab, under "Clones". These clones can only have a single contributor. If the runtime repository was a full clone of the Vim repository, it would make sense to have it listed under this "Clones" area...except that these clones only get a single committer, so that's not really an option. It would be easy enough to create a new project on Google Code which is really a clone of the Vim repository, but the two projects would not (as far as I know, and as far as Google Code is concerned) be linked in any way. </pre> Ben Fritz 2012-05-21T14:30:03 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.editors.vim.devel