Re: [vim/vim] Unnecessary multiplications in backspace code (PR #14308)
* zeertzjq [240326 17:58]: > Problem: Unnecessary multiplications in backspace code, as > "col / ts * ts" is the same as "col - col % ts". > Solution: Change "col / ts * ts" to "col - col % ts". > Adjust the loop > and the comments ins_bs() to be easier to understand. Update > tests to reset 'smarttab' properly. > > You can view, comment on, or merge this pull request online at: > > https://github.com/vim/vim/pull/14308 Did you examine the assembler produced by the compiler for these? I expected that any reasonable optimizing compiler would produce identical code, and in fact, gcc -O2 on amd64 (linux) does for a very simple source program comparing them: multmod.c /* multmod compares int division and modulus * * To compile to assembler with some optimization: cc -S -O2 multmod.c */ #include int mult(int a, int b) { return a / b * b; } int mod(int a, int b) { return a - a % b; } int main(int argc, char* argv[]) { int a = 76; int b = 7; int c; c = mult(a, b); printf("c = %d\n", c); c = mod(a, b); printf("c = %d\n", c); } Examining the produced assembler, mult and mod are identical (only one idivl, with the expected subl). It is certainly possible that for the specific source you are changing, the compiler does not recognize the opportunity for optimization, but until you inspect the assembler for the original code, you will not know. I did not actually compile to assembler and examine the code you are changing, so I cannot say definitively. Unless there is a reason (such a particular architecture that is giving problems with not-good-enough optimizations), I would avoid source churn for zero benefit. ...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/ZgNsNtE8KOUDTzOh%40basil.wdw.
Re: [vim/vim] Update usr_51.txt (PR #13496)
* D. Ben Knoble [231107 11:30]: > Sticking our heads in the sand and refusing to deal with it because it > isn't "technical" only means we are content with the status quo and > won't change it. I'm not content with the status quo of "he" as > "gender neutral" in technical writing. Singular "they" is accepted and > encouraged in academic and technical writing: > - https://gist.github.com/0xabad1dea/8870b192fd1758743f66 > - https://apastyle.apa.org/blog/singular-they > - https://writing.stackexchange.com/q/2979/33198 > > The use of "they" is very established and poses practically no > problems (when ambiguity is introduced, we should be writing without > pronouns anyway to remove it). I'm sorry, but this is political correctness gone _very_ wrong. Taking a pronoun that has since the beginning of the English language been specifically plural, and trying to use it as sometimes-plural, sometimes-singular, is extremely confusing in many circumstances. Attempting to claim otherwise is sticking your head in the sand. The analogy that "you" can be either singular or plural does not hold any water at all. Again, this has been that way from the beginning of the English language, and it still causes confusion occasionally, but _everyone_ is aware of the potential confusion, and clarification is usually made when necessary. This is not so with written documents that may easily outlive any current political correctness, where the context may be lost in the future. Especially in technical writing, the use of "he" as gender-nonspecific is absolutely clear; there is no specific person to whom the pronoun refers, so it _must_ be nonspecific. Several other suggestions from the gender variant community, such as ze/zir, have been made that are completely unambiguous. Choose one of those. Everyone, especially the gender variant community, should be pushing back on the use of "they" as singular. ...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/ZUqCBEF2hx3lOr%2Be%40basil.wdw.
Re: Re[2]: [vim/vim] www.vim.org website certificate expired (Issue #13079)
* SAQUIB AKHTAR [230927 02:23]: > Hi - It's a great news to see the www.vim.org hosted very quickly to new > provider. Everything now works fine. But vim.org --->does not resolves or > redirects to www.vim.org , can someone fix this by adding 1 CNAME in DNS ? First, there have been several attempts in the past by others to convince Bram to do this. Bram was adamant that he would not. vim.org is a domain, not a host, and the host serving the Vim website is www.vim.org. (In DNS RFC parlance, a host name is also a domain name, but not necessarily the other way around.) This is an organizational decision of those running the domain; there is nothing, such as an HTTP standard, that requires or even encourages what you are asking. If the current Vim website managers want to make vim.org redirect to www.vim.org, there is nothing wrong with that, but it is entirely their decision. I have no opinion one way or the other on this. I supported Bram in the past, and will support the new maintainers whichever way they go. If they do want to make vim.org redirect, the rest of this message is important. According to the relevant RFCs (1034 and 1035), a CNAME must not be used at the apex of a zone (e.g. vim.org), so your proposed implementation is wrong (i.e. non-compliant). The alias (left side of the CNAME in a zone file) cannot have any other records associated with it (e.g. it must not be the name of an SOA, MX, SRV, or other record). If the current maintainers decide to do this, there are a few ways, but there is really only one viable way if they wish to keep the canonical name of the web server as www.vim.org: Add an A (and possibly ) record for vim.org, and run a small HTTP/HTTPS server that redirects to www.vim.org. The IP address(es) for vim.org can be the same as www.vim.org if the web server handles virtual domains correctly. It should respond with a redirect (preferably 301 rather than 302) to handle browser history and caching correctly. If the website maintainers would like to change the canonical URI to vim.org, with www.vim.org redirecting to that, use the above method, just changing which host is redirected to the other. Another way (of changing the canonical to vim.org) would be to give vim.org the IP address(es) and have www.vim.org be the CNAME alias. This is standards-compliant, whereas having vim.org be the CNAME alias is not. One problem with using a CNAME is that the web browser is unaware of it; the DNS resolver simply returns the IP address for the canonical name of the alias that it was told to look up. This effectively results in two different web sites with identical content. Think about how your browser handles this. If you go to www.vim.org/about.php, and also to vim.org/about.php, the browser considers these to be two different pages. History and cache treat these as different pages. Using CNAME should be avoided when possible. It generally has non-obvious side effects, like the browser history and cache above. If you really want to have two names where one is an alias for the other, and both hames are in the same zone, simply use duplicate A and records with different names and the same IP addresses. This can have some of the same problems as CNAMEs (e.g. if the web server serves the same site from both names without redirection), but avoids extra DNS traffic to resolve the CNAME and then resolve the A record for the response. If an alias and a canonical name are in the same zone, use multiple address records rather than a CNAME record. If you still think you want a CNAME record, read the above two paragraphs again, and then reread this paragraph and follow its directions. ...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/ZRRBis9h6jt2%2B86z%40basil.wdw.
Re: IMPORTANT: Certificate for www.vim.org has expired.
* Christian Brabandt [230910 12:49]: > Hi, > thanks. I wasn't aware of this. I need to find out who used to manage > the SSL Certs. I am afraid this was done by Bram. May take a while until > this get's resolved :( > > Thanks, > Chris > > On Sa, 09 Sep 2023, Paul wrote: > > > PLEASE DO NOT CLICK ON ANYTHING IN THIS EMAIL THAT RENDERS AS A LINK. > > > > That said, this is nothing to panic about. However, the www.vim.org > > certificate appears to have expired at Fri, 08 Sep 2023 04:38:42 GMT. > > > > I am posting this to alert to the community and those in a position to work > > on fixing the problem. > > > > It is unlikely, but possible that the certificate is OK and I am a victim, > > hence do not trust any link in this email and do not hit your client's > > replay button. This is very odd. Is www.vim.org served by multiple hosts behind a load balancer? When this was first reported yesterday, I went there and didn't have a problem. I looked at the certificate, and it was issued 2023-08-26, valid until 2023-11-24. When I went there just now, I received the security warning due to an expired certificate. I refreshed the page (without accepting the security exception), and I didn't have any trouble, and got the same new certificate that I saw yesterday. The certificate is issued by Let's Encrypt, so the update is likely handled automatically. If a load balancer is being used, perhaps the updated certificate is not being propagated to all hosts. ...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/ZP33ZGl9/jO/Kv68%40basil.wdw.
Re: Updates on the Vim project
* Tony Mechelynck [230824 05:45]: > On Wed, Aug 23, 2023 at 10:18 PM Christian Brabandt > wrote: > [...] > > For a similar reason and because of the mess I created with the > > mercurial mirror, I am thinking to retire the mercurial repository. I > > think it is pretty clear that nowadays git is the preferred VCS of > > choice for most programmers. > > Ah, too bad. I never got around to really understand how git "thinks" > while I understand Mercurial well enough and, as with Vim, when I > forget something about Mercurial I find it easily and quickly in the > online help. Lately I used "hg help merge" to get out of the > above-mentioned "mess" and it seems more or less OK. If you retire the > Mercurial repository I shall have to scrap what I have and start again > from scratch with a fresh clone of the git master. I daresay I am not > enchanted with the prospect. I rarely need bleeding-edge features, and James McCoy keeps the Debian version more than close enough to the latest for my needs (Thanks, James!), so I have only built from source a small number of times in the past decade. In the early years, before Vim had a public Mercurial repo, I was building from source more often. However I, too, strongly prefer Mercurial over Git. Git is the most over-engineered piece of software from this millennium. One of its most touted features, the index, is really its biggest wart and hindrance to usability. Almost anything you want to do is simpler to understand and at least as simple to do in Mercurial. In another part of this thread, someone suggested sourcehut.org. I hadn't heard of them, but from their website, I think it might be work a try. ...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/ZOdYA8nHPeItm7WG%40basil.wdw.
Re: Where is Bram?
* Christian Brabandt [230808 12:37]: > > After fighting with mysql for a while, this should be done now: > https://www.vim.org/news/news.php sharing here: Christian, just a suggestion for a minor grammatical correction: > , > | [2023-08-09] The Vim project is deeply shocked and sad by the sudden ^ saddened > | passing of Bram. We certainly will miss him, his guidance and his > | humour. > | > | The Vim project wouldn't exist without his ongoing passion to lead and > | develop Vim and the community for more than 30 years. > | > | Our deepest condolences to all his family and may they have enough > | strengths to come through these sad times. We lost a great guy way too > | early, who should have had the chance to enjoy and live for at least > | several more years! > | > | In addition he was well-known for collecting donations for the ICCF > | foundation and helping many children in Uganda. And despite the sad > | news, during the last 7 days an incredible amount of EURO 60,000 was > | donated. That is so awesome. Thank you all contributors! > | > | An incredible amount of people have been giving respect and saying > | goodby at here and you'll find obituary articles and links here. > | > | It is in Brams interest to continue the Vim project even if development > | now will slow down, but hopefully the community is being able to step up > | and continue the work in the next years. (Christian Brabandt) > ` I would like to take this opportunity to express my appreciation to Christian, Ken, Yegappan, and Dr. Chip for all the work they have done in the past, and now in this very difficult time, for the work they are doing to keep this project as strong as it was under Bram's care. ...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/ZNJ9gi5ks4ZjDtop%40basil.wdw.
Re: [vim/vim] :help iccf does not work :-( (Issue #12186)
* Christian Brabandt [230323 18:19]: > I downloaded the `vim-runtime` Debian bullseye [package > ](https://packages.debian.org/bullseye/all/vim-runtime/download). It > is compressed of size 6MB. uncompressed 35MB. > `/usr/share/vim/vim82/doc` alone has 8.6MB. I then removed everything > except for `/usr/share/doc` and `/usr/share/vim/vim82/doc`, and > packaged it back as tar.xz package (which seems to be used by the > Debian package internally). The new archive was then 2MB. > > That does not seem too bad, also I am still surprised it is that much > documentation. > > In comparison, the vim-tiny package is 700K, the `vim-tiny` binary has > 1.4MB. Okay that is still significant less than just the hypothetical > vim-help package, so maybe not such a good idea after all. I was about to suggest that vim-tiny include its own copy of uganda.txt, which vim-runtime would then divert like it does for help.txt, but I think the best solution is just to move uganda.txt into vim-common. It increases the installed size of vim-tiny and dependencies by only 13k, makes uganda.txt available to all versions of vim, and is trivial to do (alright, maybe there is some packaging trickiness when moving an existing file from one package to another, but it is doable). ...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/ZB19QgyEQoCfQgSe%40basil.wdw.
Re: collection->foreach(func)
* Bram Moolenaar [230314 13:24]: > > Ernie Rael wrote: > > > I sometimes want "collection->foreach((_, v) => ...v...)", a simple > > one liner, no return or return ignored. I know it's not a performance > > winner, or I'd want it more. > > > > After a quick look at the code, it looks like simply introducing > > another filtermap_T, FILTERMAP_FOREACH, and there's not much coding > > needed (I only looked at list). Probably more work doing tests/doc. > > > > Any objections or other considerations? > > So, this would iterate over the items in a List or Dictionary and invoke > a function for each one. I assume the List or Dictionary is not > modified, otherwise you would use map(). Thus it's a short version of a > for loop. This seems useful. > > I would suggest first writing the help and think of any error conditions > that need to be handled. Perhaps the collection should be locked > (frozen) to avoid trouble? Would this have any functionality that is not provided by using mapnew and ignoring or throwing away the result? ...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/ZBDOze8DACtOID%2Bj%40basil.wdw.
Re: [vim/vim] Decrementing 2**64 gives wrong result (Issue #12103)
* Bram Moolenaar [230306 15:15]: > Marvin Renich wrote: > > After your change (I'm going by your description; I haven't built a new > > vim to test it), it seems you treat too-large numbers as one more than > > the largest representable number (2^64) for decrement but as 2^64-1 for > > increment, and similarly for too-small numbers. > > Not exactly. The number is rounded off to the nearest representable > number, but the addition or subtraction is not done. Ah, okay. This is an easily documentable and consistent behavior. I'm happy with it. > I would think that "2 ** 64" appears much more often than "2 ** 64 + 1". Perhaps, or perhaps someone was just testing edge conditions. > For the old behavior a bug was reported, which is an indication it is > not what users expect to happen. The rest of the discussion is > speculating what would be the least-worst solution. In cases like this > would rather go with an actual complaint than speculation. That's a perfectly reasonable approach. Thanks for listening to my arguments for a different solution and helping me understand the reasoning behind your solution. ...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/ZAZQi%2BoZtgA6c5QD%40basil.wdw.
Re: [vim/vim] Decrementing 2**64 gives wrong result (Issue #12103)
* vim-dev ML [230305 16:16]: > Marvin Renich wrote: > > * Bram Moolenaar ***@***.***> [230304 15:47]: > > > > > > > ### Steps to reproduce > > > > > > > > Create a buffer with the number `18446744073709551616`. > > > > Press `Ctrl-x` with the cursor on the number. > > > > Number is changed to `18446744073709551614`. > > > > > > > > ### Expected behaviour > > > > > > > > Number is changed to `18446744073709551615` > > > > > > The problem is that 2 ** 64 does not fit in the variable being used. > > > Getting the number from the text results in the maximum number that can > > > be represented, which is 18446744073709551615. Then one is subtracted. > > > > > > I think the best we can do is keep a flag for the "overflow" and then > > > not subtract one. That makes this corner case work, although it won't > > > be fixed in the general case. Still better than doing nothing. > > > > I don't think this is the right fix. I think you should either document > > that 64-bit arithmetic is being used, and load the original number as 0 > > (the correct modulo-64 representation) and decrement gives -1 and > > increment gives 1, or decide to use arbitrary-precision arithmetic and > > give the correct answer for numbers larger than 2^64. > > > > Either of these two approaches give consistent results for numbers > > larger than 2^64-1, whereas the fix you suggest only makes one > > 'out-of-bounds' value work. I would prefer the current behavior to > > applying the fix you are suggesting. > > > > I would be willing to write the arbitrary-precision code so that no > > external library need be used, but I might not get to it right away. > > Interpreting a large number as zero is a terrible solution. I don't see > how this can ever do what the user wants. I don't see how decrementing 18446744073709551618 and getting 18446744073709551615 could be what the user wants, either. Incrementing 18446744073709551615 and getting -18446744073709551615 is also unexpected (for pure math) but correct (for 64-bit arithmetic). I'll agree that hooking up arbitrary precision may not be worth the effort. I think the best compromise is to have a consistent and documented behavior for numbers not representable by 64-bit signed ints. The behavior before you made this change appears to be to treat all positive, too-large numbers as the largest representable number (for both increment and decrement) and all negative, too-small numbers as the smallest representable number for both increment and decrement. After your change (I'm going by your description; I haven't built a new vim to test it), it seems you treat too-large numbers as one more than the largest representable number (2^64) for decrement but as 2^64-1 for increment, and similarly for too-small numbers. This moves the seemingly anomalous behavior by one (18446744073709551616 gives the correct result for decrement, but 18446744073709551617 gives a result that is off by one), at the expense of requiring more verbiage to explain, and treating increment and decrement of out-of-range values differently. I think the previous behavior is more consistent and easier to explain and justify. Either way has values which give very close, but wrong (for pure math) results. If arbitrary precision is not worth the effort, I would stick with the previous behavior and document it. ...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/ZAXduGEMQG/Tn5WN%40basil.wdw.
Re: [vim/vim] Decrementing 2**64 gives wrong result (Issue #12103)
* Bram Moolenaar [230304 15:47]: > > > ### Steps to reproduce > > > > Create a buffer with the number `18446744073709551616`. > > Press `Ctrl-x` with the cursor on the number. > > Number is changed to `18446744073709551614`. > > > > ### Expected behaviour > > > > Number is changed to `18446744073709551615` > > The problem is that 2 ** 64 does not fit in the variable being used. > Getting the number from the text results in the maximum number that can > be represented, which is 18446744073709551615. Then one is subtracted. > > I think the best we can do is keep a flag for the "overflow" and then > not subtract one. That makes this corner case work, although it won't > be fixed in the general case. Still better than doing nothing. I don't think this is the right fix. I think you should either document that 64-bit arithmetic is being used, and load the original number as 0 (the correct modulo-64 representation) and decrement gives -1 and increment gives 1, or decide to use arbitrary-precision arithmetic and give the correct answer for numbers larger than 2^64. Either of these two approaches give consistent results for numbers larger than 2^64-1, whereas the fix you suggest only makes one 'out-of-bounds' value work. I would prefer the current behavior to applying the fix you are suggesting. I would be willing to write the arbitrary-precision code so that no external library need be used, but I might not get to it right away. ...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/ZATMw7uo9w/xcfcs%40basil.wdw.
Re: [vim/vim] Decrementing octal number does not preserve lenght (Issue #11889)
* Gurran [230206 04:34]: > I've recompiled Vim and issue still exists on version 9.0 Included patches: > 1-1285 The discussion of this happened on vim_dev@googlegroups.com (msgs from the github issue tracker seem to be forwarded here). You can read the thread on googlegroups, but in summary, the current behavior is correct and is not going to change. Bram said he may try to make the help a little more clear (which may be why he didn't close the issue). When I replied to your original msg, I didn't realize you may not be subscribed to the mailing list, so I neglected to CC you; I apologize. (I am subscribed to vim_dev, so no need to CC me in msgs sent to the group.) ...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/Y%2BESkuIoH2WJsMWQ%40basil.wdw.
Re: [vim/vim] Decrementing octal number does not preserve lenght (Issue #11889)
* Gurran [230126 07:44]: > ### Steps to reproduce > > In normal mode decrement (`Ctrl-X`) the following number > `0` > it returns > `017` > > ### Expected behaviour > > The result should preserve the length of the number and result in > `01777` I'm not sure the current behavior is wrong. Octal numbers are treated as unsigned, and 64-bit arithmetic is being used. The help says "Vim preserves the number of characters in the number when possible." Note that if you use Ctrl-A on 077 you get 0100. The result of Ctrl-X on is (2*64)-1, which requires more digits to represent. Bram should determine what he intended here, and what makes most sense, but I think the current behavior makes more sense and obeys the docs. ...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/Y9KZAf9Axytr7ZGZ%40basil.wdw.
Re: [vim/vim] Alias 'big' version to 'normal' (PR #11283)
* James McCoy [221008 10:18]: [snipped very nice explanation of the problems with dynamically linking the language bindings] Thanks for the explanation. ...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/Y0HxC7eXn9OsUnQ/%40basil.wdw.
Re: [vim/vim] Alias 'big' version to 'normal' (PR #11283)
* Bram Moolenaar [221005 07:32]: > Fortunately, this is what has been done. Martin more or less did it, > but used the name "small". I prefer to use the name "tiny", since this > is what more people will recognize. Thanks! I, too, think tiny is a better name; it really emphasizes why that version exists. > Dropping "big" is more complicated, since there are more features to > either move to "normal" or "huge". And there is no clear policy of what > goes where. At the same time "big" is not a good name either, it adds a > random set of features on top of "normal". Might as well take "normal" > and add any features that you need on top of that. Or just take "huge" > and get everything. SGTM. I don't really have an opinion here. Perhaps a preference for "normal" to continue to not have support for external (non-vim) scripting languages; put them all in "huge". For the Debian maintainers (Is that just you, James? Thanks for your long-time support in Debian): it would be nice to have a gtk version without all the external scripting languages. I know this increases the maintenance load, so the status quo is certainly acceptable. Thanks for a great editor, Bram. ...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/Yz14MhIG3iBQZRMB%40basil.wdw.
Re: [vim/vim] Alias 'big' version to 'normal' (PR #11283)
[I sent this yesterday, but it went to the List-Post address, which apparently points to the github issue tracker rather than the vim-dev list. I'm resending to the list.] * Martin Tournoij [221004 14:16]: > > This change does not make the code simpler, #ifdefs remain. It does > > remove a choice, which has always been a bit confusing, there is no > > clear argumentation why a feature is in normal, big or only in huge. > > Yes, my motivation was that I was looking at what exactly the > different feature sets actually do and I found that the differences > between "small" and "tiny" and "normal" and "big" were actually pretty > small. > > IMHO it's confusing now what the differences are. It's not really a > "code thing" to make the code easier, but to make it easier for people > who want to build Vim. That's also why I sent the other patch to merge > the "tiny" and "small" builds; that it removed a bunch of #ifdefs was > more of a side-effect than anything else. I haven't been following this thread, so I may not understand what the actual changes are. That being said, I would be very hesitant to remove tiny in favor of small; rather, I would do it the other way around. The purpose of tiny (or at least the way it is currently being used in Debian and Ubuntu; probably others) is to have a usable version of Vim that is not only as small as possible on disk, but uses as little memory as possible while running. It is used when you are on systems or in situations where resources are scarce. The differences between small, normal, big, and huge are really user preferences, while tiny has a very specific functional mandate that cannot be replaced by a larger version. I.e. if a user wants normal, but it is not available, big will usually suffice. However, when a user needs tiny, small will not do. ...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/Yz1mRkzK1W9yNYy9%40basil.wdw.
Re: Vim9 import [was Vim9 script feature-complete]
* Bram Moolenaar [220104 12:26]: > Marvin Renich wrote: > > * Bram Moolenaar [220103 12:33]: [snip] > > I agree that using the (cleansed) file name is suboptimal, but it was > > the simplest choice. There are a couple other possibilities. One is to > > require the "as" clause. [snip] > > Every vim9 script file already has a vim9script statement. You could > > say that in order for the script to be imported the vim9script statement > > must be of the form «vim9script ScriptId» where ScriptID must be a > > capitalized identifier. If you import two different scripts with the > > same script ID, you must use the "as" clause for at least one of them. > > > > Alternatively, you could require either the script ID on the vim9script > > statement or the "as" clause on the import statement. > > Adding a script ID adds another mechanism and I don't see enough > advantage in it. It raises questions, such as what happens if two > completely unrelated plugins use the same ID? Yes, the more I think about this, the more I like requiring "as" and requiring using the prefix. > Since the import can use a relative file name, a short file name can > work. It's only when using a file name in 'runtimepath' that we can > expect the name to be longer. Thus requiring the use of "as" up front > does not seem necessary. Then we would be back to cleansing the filename. I was the one who originally suggested that, but I think that was not a great idea. Require "as" (with Capitalized identifier), and require using that identifier as prefix. > > > > I personally find that using an imported name without a prefix (as it is > > > > currently possible) makes my code terse, and I think that in the limited > > > > scope a plugin that works well. > > > > My opinion is the opposite, here. Even in small, simple scripts, the > > prefix makes the code more readable; there is no question from where the > > identifier came. > > Right. Somehow code writers can be very lazy typing things, and then > spend lots of time (possibly much later) figuring out what the code is > doing. Unfortunately I'm not aware of any studies being done on this > (it's more computer art than computer science). I think this agrees with requiring both "as" and using the prefix. > > > Throwing everything from "Other" into the current namespace is going to > > > cause trouble, because someone may add an item to myclass.vim that > > > conflicts with what is in your script. Thus extending one script may > > > break another script, that is bad. > > > > This is probably the best reason to not allow blindly importing all > > identifiers from one script into the local namespace of another. > > I'm starting to more and more like the idea of the simplistic import. The > main reason is that the Javascript way suggests that it is possible to > import individual items from a script, which in reality the whole script > is read, while some items can't be adressed. > > Also since it's possible to do this: > > import FuncOne from "thatscript.vim" > import FuncTwo from "thatscript.vim" > import FuncThree from "thatscript.vim" > > This doesn't actually load the script three times, but you'll have to do > digging in the help to know that. Thus there is some hidden knowledge. > It can be written as: > > import {FuncOne, FuncTwo, FuncThree} from "thatscript.vim" > > Which turns it into a one-liner, but adds the need for a syntax that > isn't used anywhere else. > > While using: > > import "thatscript.vim" > > Or: > > import "thatscript.vim" as that > > Is nice and short, no need for "from". The help for ":import" becomes > much shorter. The implementation will also be much simpler. > > The discussion about the need for using the prefix, whether "as" should > be required and other things, seem less important. Actually, I think the local namespace pollution is the more important issue, and requiring "as" and the prefix gives the simpler import syntax as an added benefit. ...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/YdSJ6HFjh34Wek4N%40basil.wdw.
Re: Vim9 import [was Vim9 script feature-complete]
* Bram Moolenaar [220103 12:33]: > > On 2022-01-03, Marvin Renich wrote: > > > Don't bother with the > > > > > import MyClass from "myclass.vim" > > > import {someValue, MyClass} from "thatscript.vim" > > > > > > syntax, and only provide > > > > > > import "myclass.vim" > > > import "myclass.vim" as Other > > > > > > and require use of the namespace prefix: > > > > > > Other.MyClass > > > > > > The first case, without the "as" would default to the file name, with > > > leading directories and trailing ".vim" removed > > > > I do not think that using a filename as an identifier is a good idea. > > For instance, calling a script 1.vim would automatically make it > > non-importable (without "as"). I agree that using the (cleansed) file name is suboptimal, but it was the simplest choice. There are a couple other possibilities. One is to require the "as" clause. Another is to do something similar to Go (a language I like, if you couldn't tell :-) ). Every Go source file has a package statement, «package frob», and when importing, this package identifier, «frob», is used as the prefix (if not overridden in the import statement). Every vim9 script file already has a vim9script statement. You could say that in order for the script to be imported the vim9script statement must be of the form «vim9script ScriptId» where ScriptID must be a capitalized identifier. If you import two different scripts with the same script ID, you must use the "as" clause for at least one of them. Alternatively, you could require either the script ID on the vim9script statement or the "as" clause on the import statement. > Since a script needs to use "export" to be able to be imported, having > to use a nice name for the script is clearly needed. The only thing is > that it may be a long name to avoid name collisions, but then the "as > {name}" form can be used to shorten the name. > > > I personally find that using an imported name without a prefix (as it is > > currently possible) makes my code terse, and I think that in the limited > > scope a plugin that works well. My opinion is the opposite, here. Even in small, simple scripts, the prefix makes the code more readable; there is no question from where the identifier came. > > But I understand that Vim9 scripts might > > have a broader use, such as generic libraries of functions that can be > > used by many scripts. In that context, stricter scoping rules, such as > > in Go, are likely a cleaner approach. > > > > How about always requiring a prefix, but allowing explicit namespace > > pollution? As in > > > > import "myclass.vim" as Other > > use Other # Makes Other.F() available as just F() I like this very much; it works regardless of how the prefix gets defined ("as" clause, vim9script statement, or cleansed filename). I think if I had to pick, I would require the "as" clause. It is simple, and doesn't depend on the script author keeping the same script ID with newer versions of the script. The author of the script doing the importing is required to be in control. > Throwing everything from "Other" into the current namespace is going to > cause trouble, because someone may add an item to myclass.vim that > conflicts with what is in your script. Thus extending one script may > break another script, that is bad. This is probably the best reason to not allow blindly importing all identifiers from one script into the local namespace of another. ...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/YdR996IMMD14X29I%40basil.wdw.
Re: Vim9 import [was Vim9 script feature-complete]
* Bram Moolenaar [220103 07:07]: > > > On 2021-12-30, Bram Moolenaar wrote: > > > If you have remarks on something in Vim9 script that you think should be > > > different, speak up now! Soon we'll only make backwards compatible > > > changes to avoid breaking existing plugins. > > > > There was a thread about this on HN a few days ago, and one of the > > comments suggested to reverse the import syntax so that the imported > > script is named first and the imported entities next. A rationale for > > this is that it would help automatic completion. > > Is there another language that works like this? The current syntax > resembles Javascript, which hopefully some users are familiar with. I have to agree that putting the file being imported first is much better. In Go, by default every imported identifier must be prefixed by the package name, much like the current Vim9 "as" clause. Requiring an "as" clause (or defaulting to some form of the script name for the value of the "as" clause), and requiring that all imported identifiers be prefixed by this identifier make the code _much_ clearer and easier to follow. I very much dislike the JavaScript style where importing, by default, places the imported names in the current namespace rather than in a separate namespace (identified by the "as" clause in Vim9). Given that even when you are only importing one identifier from a script, the whole script must be read and executed, I think the Go way is better. Don't bother with the import MyClass from "myclass.vim" import {someValue, MyClass} from "thatscript.vim" syntax, and only provide import "myclass.vim" import "myclass.vim" as Other and require use of the namespace prefix: Other.MyClass The first case, without the "as" would default to the file name, with leading directories and trailing ".vim" removed, and with the first letter capitalized. Non-identifier characters and leading digits would be removed as well. In the case without "as" above, you would reference the imported MyClass identifier as Myclass.MyClass With this, every use of an imported identifier is clear and explicit. ...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/YdL35xfbRHlaYZU5%40basil.wdw.
Re: home setting
* Joseph [200821 12:50]: > Hello, I am using vim 8.1.1 on Windows 10 on a network where we have > network drives as our home directory: H:. I still have a directory on the C > drive C:\Users\ > > I am trying to set the cdpath variable to the following: > set cdpath=.,H:\,C:\Users\\Downloads\ > > The problem is that this becomes > cdpath=.,~,~\Downloads\ > > If I change my HOME environment variable to C:\Users\ it mostly > works, but of course I want to leave the network drive as the home > directory. Is there a way to force vim to use the fully qualified path > names instead of automatically transforming them to ~. > > I believe, though I am not certain, that this worked with vim 8.0. I'm not sure, but at first glance, this seems like a bug to me. Vim should not change both "H:\" and "C:\Users\" to "~" when parsing cdpath. I assume you are setting this in your vimrc? What does Vim think your $HOME is immediately before setting cdpath (try adding echo $HOME immediately before your cdpath command). I'm adding vim_dev to CC; perhaps someone there can give a more definite answer. ...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/20200821175454.fovx5k4fwm5b52hb%40basil.wdw.
Re: Patch 8.1.0757
* Bram Moolenaar [190115 16:52]: > > Patch 8.1.0757 > Problem:Not enough documentation for Blobs. > Solution: Add a section about Blobs. > Files:runtime/doc/eval.txt [snip] > ! Part of a blob ~ > ! > ! A part of the Blob can be obtained by specifying the first and last index, > ! separated by a colon in square brackets: > > ! :let myblob = 0z00112233 > ! :let shortblob = myblob[2:-1] " get 0z2233 I would make the first example use an explicit non-(-1) index for the last index, then after that say that -1 means the last element and give this example. ...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Moving away from SourceForge
* François Ingelrest [180222 01:39]: > For some reason, the person in charge of the DNS (I don't think it's > Bram) is kind of old-school and dogmatic, and has decided that vim.org > is the domain name and not the address of the website. While true, > this was and is still a ridiculous justification of a stubborn > behavior. > > Oh well... To the contrary, the idea that all public facing web sites should mirror or redirect so that www.example.com and example.com serve the same content, and those who don't are doing something wrong, is what is ridiculous. The name of the web site is entirely the choice of the domain owner and/or sysadmin. The repeated attempts by a small group of people on this mailing list to attempt to force the issue after those in charge of the domain have made it clear that they do not wish to do it that way is the stubborn behavior. I have no affiliation with the vim.org administrators, but I applaud their refusal to give in to the bullying they have been subjected to on this list in the past over this issue. ...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] Search for Russian letter range `[а-яА-Я ]` misses the letters `ё` and `Ё` (#1751)
* Marvin Renich [171114 14:57]: > It suggests using [[:lower:][:upper:]] to do something close to what you > want (it will also find non-Russian letters). The help does not mention > any character class that includes exactly Russian letters, so the best > you are going to be able to do is [А-яЁё]. If encoding is cp1251, [[:alpha:]] might work (i.e. find ASCII and Russian letters, including Ё and ё), since that is an 8-bit encoding, but I haven't tried it. ...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] Search for Russian letter range `[а-яА-Я ]` misses the letters `ё` and `Ё` (#1751)
* sergeevabc [171114 08:15]: > @10110111, stumbled upon your comment accidentally and decided to test on my > end. > ``` > $ set LC_ALL=ru_RU.utf8 > > $ grep --version > grep (GNU grep) 3.0 > > $ echo Ёжик под зелёной ёлкой. | grep --color "[а-яА-Я ]" > Ёжик под зелёной ёлкой. > ^ ^^^ > ``` > Ё, ё and . are not painted red. In vim patterns, [a-z] is a character range, not a character class. It specifically searches for characters whose code values are within the range. Ё and ё are outside the range [а-яА-Я ] for both cp1251 and utf-8. If you read at :help /collections and go down to the discussion of character classes, you will notice that it has character classes for [:alpha:], [:lower:], and [:upper:], among others. It also says These items only work for 8-bit characters, except [:lower:] and [:upper:] also work for multi-byte characters when using the new regexp engine. It suggests using [[:lower:][:upper:]] to do something close to what you want (it will also find non-Russian letters). The help does not mention any character class that includes exactly Russian letters, so the best you are going to be able to do is [А-яЁё]. Vim's regexp engine is working as defined; the fact that Unicode and cp1251 do not have all the Russian alphabetic characters in a single range is the issue. You could request that a character class be added to do what you want; if you can also provide a patch, that would significantly increase the chance that the feature would be added. ...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Security risk of vim swap files
* Zdenek Dohnal [171103 09:27]: > On 11/03/2017 02:07 PM, Marvin Renich wrote: > > * zdoh...@redhat.com [171103 03:45]: > Can other users open original file, which has .swp file belonging to > certain user:group with permissions 0600, as read-only with your > solution? If not, it could be change of behavior, which can make some > people unhappy -> that' why I thought it could be configurable behavior. Yes. My current version (from Debian package; see below) will give the "recovery" prompt, and then allow the user to edit it anyway (based on the answer to the prompt). This looks like it is working just right. VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Oct 13 2017 22:38:50) Included patches: 1-1144 ...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Security risk of vim swap files
* zdoh...@redhat.com [171103 03:45]: > > Another solution would be to always use the editing user's user:group > > and perm 0600. > > I agree with this solution. And IMO the best way would be to create > option for configure script+create option for vimrc configuration > file, which can turn on/off this behavior (IMHO it's good to have > option for users, who doesn't want this behavior). I think having this behavior configurable is overkill and unnecessary in practice. After thinking about it, I like my second solution (the one above) best. My first solution has the advantage that anyone who has permission to edit the file will be able to recover a crashed editing session. But I don't see this as a real-world scenario. The above solution is simpler to implement, simpler to understand, and makes it easier to identify security implications. I also think my first solution might cause problems if the containing directory has the restricted deletion flag permission bit. ...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Security risk of vim swap files
* Christian Brabandt [171102 16:50]: > > On Do, 02 Nov 2017, z...@z5t1.com wrote: > > > > > However, there is another problem with the swap file permissions > > that has not yet been discussed: when Vim creates swap files, the > > .swp file is created with the owner and group set to the user who is > > editing the file (hereafter referred to as the "editor") and the > > editor's primary group respectively. The permission bits on the swap > > file are the same as the original file. > > > > This is a problem, as the editor's primary group may be different > > from the group of the file being edited. Take /etc/shadow for > > example. That file is supposed to have the permissions 640 with > > owner: root, group: shadow as a quick `ls -l` shows: > > > > -rw-r- 1 root shadow 1195 Sep 16 20:09 /etc/shadow > > > > However, shadow is not the root user's primary group; on this system > > it happens to be 'users', which every other user on the system is > > also a member of. Now if root goes to edit the file, a swap file is > > created in /etc/.shadow.swp with the following permissions: > > > > -rw-r- 1 root users 4096 Nov 2 13:52 /etc/.shadow.swp > > > > This swap file is now readable by every user on the system. Keep in > > mind the /etc/shadow file contains hashes of every user's password, > > so now the password for every single user on the system may have > > been compromised. > > That looks like a problem. I agree. One solution is if the user doing the editing has permission to create the swap file with the original file's user:group, then do that with the original file's perms. Otherwise use the editing user's user:group and perm 0600. Another solution would be to always use the editing user's user:group and perm 0600. There might need to be more logic added to recover to check if the current user has rw permission on the swap file. However, this might very well just 'work' (i.e. fail gracefully) with the current code. Re Bram's question about root's default group being users: While that seems like a bad idea in general, the situation could still come up with very reasonable user/group combinations. Take a 'normal' user whose default group is users, but who also happens to be a member of group staff. A file with root:staff ownership and 0660 perms would have a swap file with someone:users and perms 0660, thus giving most users rw access to the swap file when they had neither r nor w access to the original. ...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Security risk of vim swap files
* zdoh...@redhat.com [171102 10:36]: > can VIm provide a way how to set permissions for swap files? So users > which consider this VIm behavior as security risk can set permissions > differently? Would that be possible for VIm (like setting set > swap_file_perm=775 in vimrc file)? What security risk do you see? The original file and swap file are conceptually treated as one unit. If someone can do something to the original (such as writing), preventing that person from writing the swap file has absolutely no security benefit. The purpose of umask is to allow a newly created file to have specific permissions unset at time of creation, preventing a race condition between file creation and subsequently setting file permissions with chmod. With vim and a swap file, using umask to create the swap file with permissions more restrictive than the original does not prevent anyone from doing anything he or she can still do with the original. ...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Security risk of vim swap files
* Hanno Böck [171031 06:32]: > I wanted to point out an issue here with vim swap files that make them > a security problem. > > By default vim creates a file with the name .filename.swp in the same > directory while editing. They contain the full content of the edited > file. This usually gets deleted upon exit, but not if vim crashes or > gets killed (e.g. due to a reboot). > > On web servers this can be a severe security risk. One can e.g. scan > for web hosts that have swap files of PHP configuration files and thus > expose settings like database passwords. (e.g. wget > http://example.com/.wp-config.php.swp ) See the 'directory' option. I don't see this as a problem with Vim; Vim gives the user appropriate means to avoid it. The problem is one or both of (1) a web server that serves files that the admin did not intend to serve and (2) the admin's Vim configuration that puts temporary files in a location that the web server serves without appropriate filtering. Both problems are fixable with appropriate configuration. It would be inappropriate for Vim's default to be to assume that having both the file being edited and its swap file in the same directory would be a security issue. The implication is that in most cases, if someone can read the swap file, they can also read the original. This happens to not always be true in the case of a web server that filters the PHP configuration files but not Vim's swap files in the same directory. ...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [patch] Clean up Mac code
* Kazunobu Kuriyama [170418 00:15]: > The proposed changes are rather fixes to address a certain issue than those > that possibly break existing scripts. > > The issue is this: Currently, 'mac' does not cover all versions of vim > running on Mac. To be more specific, vim configured with --disable-darwin > gives 0 to has('mac'). > > To address the issue, a new feature list item called 'osx' was introduced > about a year ago. With that, the following condition covers all possible > vim instances running on Mac: > > has('mac') || has('osx') > > Although this is logically correct, it looks clumsy and is turned out to be > error-prone. > > Naturally, people does not expect that there's a case where has('mac') > returns 0 for a vim actually running on Mac. The proposed patch would > eliminate this counter-intuitive case. Okay, SGTM. > Also, we are now in the process of improving the test coverage. Through > the process, we sometimes came across the cases where a newly written test > failed inadvertently for darwin-disabled vim due to missing has('osx'). > > If all test writers were familiar with Mac, it would be quite reasonable to > ask them not to forget that. In reality, however, they are not. We need > to provide a feature list item easier to use for test writers to write > tests which are expected to work well on Mac even if they are not on Mac to > write them. The proposed patch would help those people. > > The --disable-darwin configuration is highly unlikely to be used by package > managers and non-dev users, because that configuration is meant to kill the > clipboard service from the system. So I think dropping 'osx' won't make > much trouble because those who know both --disable-darwin and has('osx') > and understand their implications have already had a working knowledge as > to how to handle trouble caused by them. I think this is a reasonable justification for your proposed change. > 2017-04-18 2:49 GMT+09:00 Marvin Renich : > > I think for this to work, the existing names should > > be left as is and marked as deprecated, and then add new names, such as > > mac_any, mac_unix, and mac_osx with the new meanings. > > Now we come to know adding new names does not necessarily address an issue > satisfactorily and would cause trouble later, as we've seen a case with > 'osx'. That's another reason why the patch is of 10k SLOC instead of usual > 0.1k for this sort of changes. We need to neutralize the root cause of > name proliferation, too :) I definitely agree that name proliferation should be avoided when possible, but it is less important than preventing breakage of existing scripts. Documenting the old names as deprecated with an explanation of why using them is bad would be preferable to breaking changes, but your justification above is sufficient to assuage my concerns in this particular case. Thanks for working on this and also for taking the time to explain your reasoning for the design. ...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [patch] Clean up Mac code
* Kazunobu Kuriyama [170417 05:19]: > This is a followup to > https://groups.google.com/forum/#!topic/vim_dev/5RFo3q8xvfo where we talked > about the feature list items relevant to Mac: > > 2017-04-09 21:58 GMT+09:00 Bram Moolenaar : > > We should make the feature list a bit more clear about what > those features mean. > > > > I now have: > > > > gui_mac Compiled with Macintosh GUI. > > mac Any Macintosh version of Vim, but not all OS X. > > macunix Compiled for OS X, with darwin > > osx Compiled for OS X, with or without darwin > > > Proposal > - > > My proposal is to change them as follows: > > 'gui_mac' will be abolished by discontinuing maintaining the Carbon GUI > code and dropped from the list. > > The rest of the items will be changed for eval.txt as follows: > > mac Any macOS versions of Vim > macunix Compiled for macOS with pasteboard support (default) > osx (Deprecated. Use "mac" instead) > > Not to mention, macOS implies Mac OS X and OS X. > > Personally, I think the item 'osx' can also be dropped on this occation if > we don't worry much about the backwards compatibility of that particular > item. Bram usually does not make changes that have a reasonable chance to break existing scripts. I'm not a Mac user, but it seems to me that changing the meaning of existing feature names is very likely to break existing scripts. I think for this to work, the existing names should be left as is and marked as deprecated, and then add new names, such as mac_any, mac_unix, and mac_osx with the new meanings. This is just a suggestion, as it is Bram's decision. ...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: conflicts with in windows console vim (vim.exe), bug ?
* skywind3000 [160921 14:18]: > has been mapped to something in my vimrc, which works fine in > win32-gvim/macvim and linux/mac terminal vim (with backspace set to > 127/ctrl-? ) > > but in windows console vim, mapping will cause unable to > work properly (it appears that backspace also get mapped), > > After reading a lot of docs, I still can't figure out how to fix it . > > Is that a bug ? or something misconfiguration ? > > Can console behave exactly in the same way like other platforms ? , the ASCII character, is exactly Ctrl-h. , the keyboard key, in a terminal emulator (windows console, i.e. cmd.exe, is a terminal emulator) sends to the program whatever the terminal emulator decides, which is usually , but sometimes (the ASCII character). Many terminal emulators allow you to configure this to some degree. Most terminal emulators use VT102 or VT220 key codes and escape sequences by default. If you can configure the terminal emulator to send your own escape sequence, you can set the t_kb option to recognize it. I am pretty sure that Vim will treat this escape sequence separately from Ctrl-h in mappings. I don't know if you can get cmd.exe to send anything other than an ASCII character. ...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] Vim cryptmethod is not authenticated (#638)
* Ben Fritz [160826 18:05]: > Well, here's the sort of thing I worry about the most far most users: > > http://www.vim.org/scripts/script.php?script_id=5340 > http://usevim.com/2013/11/27/password-manager/ > https://invert.svbtle.com/using-vim-as-a-password-manager > https://stelfox.net/blog/2013/11/using-vim-as-your-password-manager/ > http://vim.wikia.com/wiki/Keep_passwords_in_encrypted_file > > And then of course somebody could get the bright idea of encrypting a > 20GB CSV file of medical data to put on a flash drive or something. > > I'd hope dissidents and the like use tools more designed for the task already. I'm not sure whether you are agreeing or disagreeing with me. Here is a summary of my POV: • The encryption algorithm used by Vim used to be considered strong, but is now considered weak. • Newer, stronger encryption should be added to Vim. (Hopefully with a well thought out plan that allows adding new encryption algorithms without recompiling Vim.) • Removing Vim's existing encryption does not help users who currently use it, even though it is weak. If you are simply pointing out that some people believe Vim is the right tool for some cryptographic applications, I certainly agree with that. If you are saying that we should remove Vim's current algorithm because some people are using it without realizing that it is no longer considered as strong as it use to be, I strongly disagree. The help file should document this concern, and if the script and blog authors wish to make it more obvious to users, that is good, too. My soapbox statement really boils down to two points: • Known-weak encryption has valid uses. • The idea that an encryption algorithm that used to be considered strong must always be removed soon after it is decided that it is weak is wrong. The second point is, in my opinion, especially true in the case of Vim at the moment, because there is no alternative. However, even when a better algorithm is added to Vim, there are bound to be many files out there that are already encrypted using the older algorithm. We should not require users to keep an old version of Vim just to be able to read those files. Bugs in Vim's encryption algorithms should, of course, be fixed if possible, but not in a way that prevents access to older encrypted data files. That includes keeping, for a significant amount of time (two years? I'm not sure how long), the ability to write files that can be read by older versions of Vim. Requiring a confirmation when using a deprecated algorithm is certainly reasonable. ...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] Vim cryptmethod is not authenticated (#638)
* fritzophrenic [160825 20:34]: Thanks, fritzophrenic, for a very well thought out and constructive response to this thread. I, too, think Vim's crypto could use a well-planned overhaul, and I fully agree with deprecating (after better encryption is implemented) but not discarding the existing crypto. The help file, especially under 'cryptmethod', should also give appropriate warnings about the level of security given (or not given) by the various methods. For the others in this thread, it bothers me when security enthusiasts make arguments that boil down to "use strong encryption or no encryption". Security is always a trade-off between usability and keeping something safe, whether it is financial information or jewelry. > I am not suggesting there is nothing to fix. I think Vim's crypto is too > weak for it to be very useful for important data. ^ That is the salient point. What type of data do people use Vim to secure, and why do they choose Vim over other cryptographic tools to do it? Vim's existing weak encryption is probably perfectly fine for keeping your snooping neighbor from reading your love letters to your fiance, but it would not be appropriate for a dissident under a hostile dictatorial regime to use to hide information being sent to Amnesty International. Would the dissident choose Vim to do the cryptography? If it were me, I wouldn't, even if Vim's encryption were believed to be strong; it is simply not the right tool. That is how I interpret Bram's responses to the repeated requests to remove the existing encryption code due to its lack of strength. Vim's encryption was never intended to replace tools whose purpose was to give strong encryption; it was meant to give a simple-to-use encryption where the potential damage resulting from cracking was low, as opposed to the potential for cracking being low. There was, in the recent past, a request on the Debian development ML to remove all fingerprint reader code from Debian because biometric identification is known to be weak security. While I believe the requests on this list for the removal (immediate or not) of Vim's existing crypto to be well intentioned, I also think they are as over-zealous as the request for removal of all fingerprint reader code. Match the level of security with the use-case, especially when using a higher level has significant usability downsides. In this case, removing the old crypto from Vim will negatively impact many existing users who _do not require_ higher security. ...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Mail from Vim Github Repository
* Christian Brabandt [150824 16:28]: > On Mo, 24 Aug 2015, Marvin Renich wrote: > > (I have set up an forwarding of all notifications from the vim > repository to the vim-dev ml). > > > I have started getting mail from "Vim Github Repository"; apparently > > they are pull-requests forwarded to vim-dev. I have two problems with > > this mail. > > First, the person who sent the PR isn't identified. (This > > was also a problem with the Vim problem tracker.) Any chance this can be fixed? Is this how github works for all projects that it hosts? If so, I won't bother considering github for any of my projects unless they fix this (and I would have voiced my opinion before Vim switched if I had known). > > Second, the List-ID headers are different, depending, I think, on the > > repository where the PR originated. Here is a sample: > > > > List-ID: dyng/ctrlsf.vim > > I apologize, I did cause this by not being careful enough. That > happened, when commenting on an issue, while still being logged in as > the vim-ml user. That shouldn't happen anymore. Ideally, I shouldn't > need to log in as that user anymore. No problem. I saw three different List-ID's and jumped to the conclusion that the list-id depended on the user who sent the PR. Does that mean that in the future, all of these notifications will have list-id ? > I am not going to start rewriting mails, that are sent from github. It's > just a simple forwarding, Understandable. > > Also, vim-dev has a lot of discussion that is not directly related to > > PRs. I think it would be nice for the PRs to go to a separate list, > > such as vim-repo or vim-source. > > This could be discussed. I actually think, it is nice that issues can be > discussed on this list and also we should see how much additional > traffic will be created by the issue tracker. > > However you could filter the Header List-ID: vim/vim > to a different folder. If there are not too many PRs, that will be fine. If the number of PRs gets large, a separate read-only mailing list (only the PR notifications are posted, discussion referencing the PRs still happens on vim-dev) should be considered. > [1] Currently there is a X-Github-Reply-To Header, which contains the > reply address for github. So if replying to that address the message > should show up at github. Actually, I found X-Github-Recipient-Address after sending my email. That is what I am now using. Thanks...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Mail from Vim Github Repository
I have started getting mail from "Vim Github Repository"; apparently they are pull-requests forwarded to vim-dev. I have two problems with this mail. First, the person who sent the PR isn't identified. (This was also a problem with the Vim problem tracker.) Second, the List-ID headers are different, depending, I think, on the repository where the PR originated. Here is a sample: List-ID: dyng/ctrlsf.vim I think the fact that vim occurs at all in the list-id is purely coincidental based on the fact that the repo name contains vim. The list-id should be constant and based on the list to which I am subscribed, not the list where the message originated. One of the major purposes of the list-id and related headers, such as list-unsubscribe, is so that the recipient can identify why he/she is receiving the email and do something about it if the emails are unwanted (either because someone else subscribed him or he is no longer interested). Another purpose, which is more important to me at the moment, is that the list-id allows sorting incoming mail (at delivery time for some of us). Also, vim-dev has a lot of discussion that is not directly related to PRs. I think it would be nice for the PRs to go to a separate list, such as vim-repo or vim-source. Many people who are currently subscribed to vim-dev will want to subscribe to the new list, but not all. Having the PRs separated from general development discussion would be a benefit. ...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
* Bram Moolenaar [150821 16:39]: > The idea is that all events on GitHub are forwarded to the vimdev > maillist. Christian had setup something for that. I believe this also > applies to pull requests. > > I indeed prefer to discuss changes on the maillist, since everybody can > join and it keeps everything in one place. I also plan to keep > including patches as before, not directly using the pull request. > > We'll see how it goes. That sounds good to me. Thanks...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Repository cleanup (Was: Preparations for moving to github)
* Bram Moolenaar [150821 14:59]: > Looks like most things are ready, I'll soon announce that GitHub is > ready for our business. > > What remains to be filled in is the section "Moving over to github - if > you have local changes" on http://www.vim.org/movetogithub.php > Who has a good text for that? There was a longish thread on debian-devel a while back (I can't find it right now) about using github for development. One of the points raised was that if you accept github pull requests (from their web UI), then those developers who do not have (and perhaps do not wish to get) github accounts cannot participate. If you disallow github pull requests and only accept git PRs (perhaps with a dedicated mailing list), than anyone can participate. I have never used the github UI, so I don't know how true this is, and I may have misunderstood what the problems were, but it is at least something to consider. ...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: vim.org is down
* MC Andre [150428 13:26]: > No, the point is for **newbies** to be able to reach vim.org and have > an automatic redirect to www.vim.org, without requiring any special > user configuration. Tips like "modify your hosts file" assume the user > is already an advanced user, defeating the whole purpose of this > request. > > Could the DNS admin please drop in whatever configuration is necessary > to achieve this redirect? No, the point is that in «http://example.org/some/page», example.org is a host name, not a domain name or service name. This is by design. The hostmaster is free to make www.example.org and example.org point to the same host, if he desires, but it is not now, nor ever has been, mandatory. If you are given a URL, use it; don't strip the leading www. If you are not given a URL, Google for Vim to get the correct URL. This is what I would expect a newbie to do. I see nothing wrong with not having the domain name be a synonym for the web-serving host. This topic has been discussed on this list several times before, with the same answer every time. If the hostmasters were so inclined, they would have changed this already. ...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: bash syntax: incorrect highlighting of escaped double quote
* Marvin Renich [131021 10:07]: > Thanks, Ben; that's exactly what I was looking for. Hopefully, Dr. Chip > can figure out why the highlighting is wrong. BTW, did you try to > reproduce the incorrect highlighting? I would like to at least know if > this is easily reproducible by others. Dr. Chip sent me an updated sh.vim that works. Thank you! ...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: bash syntax: incorrect highlighting of escaped double quote
* Ben Fritz [131021 09:12]: > On Sunday, October 20, 2013 4:07:20 PM UTC-5, Marvin Renich wrote: > > > > How can you determine what syntax group is used for a particular character? > > > > http://vim.wikia.com/wiki/Identify_the_syntax_highlighting_group_used_at_the_cursor Thanks, Ben; that's exactly what I was looking for. Hopefully, Dr. Chip can figure out why the highlighting is wrong. BTW, did you try to reproduce the incorrect highlighting? I would like to at least know if this is easily reproducible by others. Thanks again...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
bash syntax: incorrect highlighting of escaped double quote
The sh.vim syntax file does not recognize the escaped double quote inside the double-quoted string in the following bash snippet: ---8< #!/bin/bash for r in $reqFields ; do if [[ -z "${keys[$r]}" || "${keys[$r]}" == "\"\"" ]] ; then missing="$missing $r" fi done --->8 It looks like the shDoubleQuote region has a skip clause that is supposed to handle this, but it isn't working for me. If you can't reproduce this, I'll try to narrow it down more. b:is_bash is being set correctly, and syntax list shDoubleQuote shows the expected contents. How can you determine what syntax group is used for a particular character? Thanks...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
options.txt: Sorry, no help for ('patchmode'
[vim 7.3.547 from Debian wheezy] I just noticed that in options.txt under the help for 'backupdir', the link to 'patchmode' doesn't work. Putting a space between the open parenthesis and the 'patchmode' fixes the problem. I assume that this is a consequence of 'isk' for help files containing most printable characters. The solution is probably just to put a space there, or reword so that the link is not adjacent to the paren. ...Marvin -- -- 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://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Suggested improvement to starting.txt
* Tony Mechelynck [121023 23:32]: > ---help *-h* *--help* > --h Give usage (help) message and exit. {not in Vi} > +-h Give usage (help) message and exit. {not in Vi} *-h* > See |info-message| about capturing the text. > > +-? *-?* > + Give GTK-specific help, then exit. {only in GTK versions} > + See |info-message| about capturing the text. > + > +--help {not in Vi} *--help* > + * GTK versions: give both Vim help (as with -h) and GTK help > + (as with -?), then exit > + * Other versions: same as |-h| > + See |info-message| about capturing the text. > + > + Note: If the X11 server is not reachable, both -? and --help > + will (instead of the GTK-specific help) give error |E233| > + followed by the |hit-enter-prompt|, and start the editor in > + the terminal. > + That's odd. I have the GTK2 (not GNOME) version 7.3.547 (Debian package). -? gives «unknown option argument: "-?"» for both vim and gvim (both symlinks to the same executable). And -h and --help both give the same help (including GTK+ help) for both symlinks, regardless of whether or not DISPLAY is set. (I am not running a GNOME DE.) Perhaps -? is GNOME-specific, rather than GTK-specific. I would be inclined to say that giving E233 when no display is available is a bug, and should be fixed rather than documented, however I'm not familiar enough with how the GNOME-specific options work to be sure. ...Marvin -- 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://www.vim.org/maillist.php
Re: How to search in digraphs?
* Benjamin R. Haskell [120413 17:14]: > On Fri, 13 Apr 2012, Marvin Renich wrote: > >Using :dig! to display and :dig! xy to delete is terribly > >inconsistent. To remove a highlight, vim uses :hi clear, to > >remove a map, :unmap. I would suggest :undig {char}{char} or > >:undig {number} to remove a digraph. > > > >:dig! {char}{char} or :dig! {number} could be used to list > >digraphs matching certain criteria. > > Is there any current Vim command that uses "!" to indicate that > things will be listed? If not, this seems even more inconsistent. > "!" usually means "watch out!" (because something will be deleted, > e.g. :au!), or "I really mean it!" (because some safety check is > being removed, e.g. :[range]w!, or :w! {existing-file}). > > So, why not extend dig to take a first argument, the way :hi[light] > does, and add '!' to mean 'remove'? Ending up with something > similar to :au[tocmd]{,!}: > > " lack of {number} means list > :dig " list all digraphs > :dig user" list user-defined digraphs > :dig {char}{char}" list digraph for {char}{char} > > " specifying {number} means definition > :dig {char}{char} {number} " define digraph {char}{char} as {number} > > " ! means delete, with same arguments as the "list" forms > :dig!" delete all digraphs > :dig! user " delete all user-defined digraphs > :dig! {char}{char} " delete the digraph for {char}{char} > > > " specifying {number} and ! means replace (delete and then define) > :dig! {char}{char} {number} " replace {char}{char} digraph w/ {number} I agree that ! usually means "override a safety feature," but I don't like it being used for delete; au! is the only example I can come up with where :foo adds something and :foo! deletes it. I much, much prefer :undig or :deldig. The analogy between the usage of :dig and :au is tenuous at best; :dig is more closely related to :map or :ab, both of which use :un prefix to delete. While I think that :dig! would be a very poor choice for delete, I am not at all set on using :dig! for listing. I would be just as happy to use :ldig or something else for listing and leave :dig! undefined. :dig with a single argument would be okay, but I have a mild preference for something more explicit, which is why I extended the original suggestion of using :dig!. ...Marvin -- 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://www.vim.org/maillist.php
Re: How to search in digraphs?
* Bram Moolenaar [120413 05:42]: > Christian Brabandt wrote: > > Here is a patch, that makes :dig! display only user-defined digraphs and > > :dig! xy remove the digraph, that is defined by the chars xy > > > > This sounds like a useful addition. > > If ":dig! xy" deletes a digraph I would expect ":dig!" to delete all > user-defined digraphs. Thus have "!" mean delete. > > Can we use another command to list user-defined digraphs? Perhaps > ":dig ?"? > > This patch would also need documentation. And a test would be good too. Using :dig! to display and :dig! xy to delete is terribly inconsistent. To remove a highlight, vim uses :hi clear, to remove a map, :unmap. I would suggest :undig {char}{char} or :undig {number} to remove a digraph. :dig! {char}{char} or :dig! {number} could be used to list digraphs matching certain criteria. I would even go so far as to allow :dig! {char} to find all digraphs with the specified char in either position. If char is ambiguous (i.e. a single digit or two digits) treat is as both {char} or {char}{char} and {number} (list all matches). While :dig! without arguments would list user-defined digraphs, :dig! with an argument would list all matching digraphs, both pre-defined and user-defined. ...Marvin -- 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://www.vim.org/maillist.php
Re: Complex Scripts in Vim/gVim
* Ujjwol (उज्जवल लामिछाने) [100924 13:09]: > Ok here is the file. (I didn't know how to add file here so I posted > it there, Sorry!) > -- > अनन्त: वै वेद: । > कार्त्स्न्या । > 1.001.01a अ॒ग्निमी॑ळे पु॒रोहि॑तं य॒ज्ञस्य॑ दे॒वमृ॒त्विज॑म् । > 1.001.01c होता॑रं रत्न॒धात॑मम् ॥ > 1.001.01a a̱gnim ī̍ḻe pu̱rohi̍taṁ ya̱jñasya̍ de̱vam ṛ̱tvija̍m । > 1.001.01c hotā̍raṁ ratna̱dhāta̍mam ॥ > --- These links show what it looks like for me in gvim [0] and in mutt in gnome-terminal [1]. I am running Debian testing, with many fonts installed. I installed ttf-devanagari-fonts prior to taking the screen shots, but the email seemed to display properly for me (as best as I can tell without having any prior experience with devanagari script) even before I installed that font. I note a slight difference in the placing of a couple marks (I don't know the proper font terminology) between the gvim and the mutt renditions. [0] http://www.renich.org/vim/gvim_scrot.png [1] http://www.renich.org/vim/mutt_scrot.png ...Marvin -- 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://www.vim.org/maillist.php
Re: [Patch] Open new tab at the end of tab stack
* Hari G [100730 12:27]: > Hi, > > Gvim opens a new tab just next to the current tab by default. Is it > acceptable to open the new tab at the end of the tabline by default? > Recently somebody was asking for this in the vim_use group. A patch to > get this behaviour follows: I think this is just a bug in the documentation at :help tabe. When tabs were first implemented, I wondered why :[count]tab was allowed, but [count] was not documented as working for :tabe. In fact, :[count]tabe does work. I think if this had been documented, the OP might have pieced together how to get what he wanted from the help. ...Marvin -- 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://www.vim.org/maillist.php
Re: [PATCH] Set the buffer to be modified after recovery (was: Re: Save recovered file with ZZ?)
* James Vega [100416 11:43]: > On Fri, Apr 16, 2010 at 11:28 AM, Marvin Renich wrote: > > Shouldn't this set curbuf->b_changed based on the "modified" setting > > from the swap file, so that if you "recover" a file that was not > > modified, you don't set the modified flag? > > I'd think that any time you recover from a swap file, the buffer should > be considered "modified". The modified flag indicates that the buffer > is different than the on-disk file with the same name. Whether or not > the buffer was modified at the time that the swap file was last updated > has no bearing on whether the content recovered from the swap file > matches the current contents of the file that was being edited. That's > up to the user to diagnose and decide what steps to take. Maybe I am missing something. If you are recovering from a swap file, doesn't Vim read the current version of the file from disk, then apply the changes that are in the swap file? So, if the swap file has modified=no, the buffer will match the current version of the file on disk. Is there something else going on that I have missed? I don't think this is a big deal; if you are explicitly recovering, you probably are paying attention to what you are doing, but then again, this patch is because people asked to be notified if they try to quit without saving after recovering. ...Marvin -- 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://www.vim.org/maillist.php Subscription settings: http://groups.google.com/group/vim_dev/subscribe?hl=en
Re: [PATCH] Set the buffer to be modified after recovery (was: Re: Save recovered file with ZZ?)
[dropping vim_use] * Christian Brabandt [100416 08:35]: > This has come up on the vim_use mailinglist. The problem seems to be > that after recovery of a swap buffer, the file should be modified so you > are not loosing your changes after e.g. accidently hitting ZZ > > Signed-off-by: Christian Brabandt > --- > src/memline.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/src/memline.c b/src/memline.c > index 102b61e..c4a0d87 100644 > --- a/src/memline.c > +++ b/src/memline.c > @@ -1326,6 +1326,7 @@ ml_recover() > * the buffer. Delete it. > */ > ml_delete(curbuf->b_ml.ml_line_count, FALSE); > +curbuf->b_changed = TRUE; > curbuf->b_flags |= BF_RECOVERED; > > recoverymode = FALSE; > -- > 1.6.5.7 > > regards, > Christian Shouldn't this set curbuf->b_changed based on the "modified" setting from the swap file, so that if you "recover" a file that was not modified, you don't set the modified flag? ...Marvin -- 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://www.vim.org/maillist.php Subscription settings: http://groups.google.com/group/vim_dev/subscribe?hl=en
Re: [bug] netrw-browse/autocmd/nospell
* Charles Campbell [090113 11:42]: > > Marvin Renich wrote: > > Sorry to jump in so late, and after you have a solution, but wouldn't > > putting @NoSpell in the proper places in syntax/netrw.vim be a better > > solution? How often do you really want spell checking on a directory > > listing? We're talking about existing files; if you want spell checking > > on a file name, you want it when you are typing :w filename, not when > > you are browsing to open a file. > > > Good point for the spell option; however, the au FileType netrw ... > allows one to generally > override netrw's "safe" options, which obviously @NoSpells don't > provide. (netrw v135q now available) > > Regards, > Chip Campbell Thanks! However, I think it needs some fine-tuning. The latest (I tried v135r and v135) removes most, but not all, spell highlighting. I have attached the result of :w vim.netrw after :e .vim (to get the text of the netrw window). Make sure you don't have au FileType netrw ...; then, :e vim.netrw and :set ft=netrw (this should give the same syntax highlighting that netrw gives for :e .vim on my .vim directory). For me, "SearchInRuntime", "cyclecolor", "filetype", "lh", and "xml" at the beginning of the lines they are on all have SpellBad highlighting. I also note that the first character of each of those lines has synID of 0 (none?) while the second character has syntax group-name netrwPlain. ...Marvin --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- " " Netrw Directory Listing(netrw v135) " /home/mrvn/.vim " Sorted by name " Sort sequence: [\/]$,\,\.h$,\.c$,\.cpp$,*,\.o$,\.obj$,\.info$,\.swp$,\.bak$,\~$ " Quick Help: :help -:go up dir D:delete R:rename s:sort-by x:exec " ../ after/ autoload/ colors/ doc/ ftplugin/ keymap/ plugin/ sessions/ spell/ syntax/ .VimballRecord .netrwhist SearchInRuntime-changelog.rss SearchInRuntime-changelog.xml SearchInRuntime.xml cyclecolor-blacklist filetype.vim lh-map-tools-changelog.rss lh-map-tools-changelog.xml lh-map-tools.xml mu-template-changelog.rss mu-template-changelog.xml mu-template.filelist mu-template.xml tags xml-plugin.txt
Re: [bug] netrw-browse/autocmd/nospell
* Charles Campbell [090109 11:48]: > > Charles Campbell wrote: > > krudo...@mi.fu-berlin.de wrote: > >> I have `set spell` in my `.vimrc`. This unfortunately clashes with > >> highlighting for `netrw-browse`. Therefore, I'd like to deactivate the > >> setting locally for that file type (`netrw`). > > Please try netrw v135p, available from my website: > http://mysite.verizon.net/astronaut/vim/index.html#NETRW. > Caveat: you'll need to upgrade to vim 7.2 . You can try > > au FileType netrw setlocal nospell > > Regards, > Chip Campbell Sorry to jump in so late, and after you have a solution, but wouldn't putting @NoSpell in the proper places in syntax/netrw.vim be a better solution? How often do you really want spell checking on a directory listing? We're talking about existing files; if you want spell checking on a file name, you want it when you are typing :w filename, not when you are browsing to open a file. Oh, well. ...Marvin --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Update of the mail.vim syntax file
* Gary Johnson <[EMAIL PROTECTED]> [081108 18:18]: > > Not to be a wet blanket, but I do have a couple of comments. > > 1. A proper signature is no more than 4 lines and appears at the > very bottom of the message, so folding it seems hardly > worthwhile. Other people's signatures should not be included in > a reply. > > 2. Similarly, if your mailer includes any of your headers at all in > the file it gives your editor, they should be few and at the > very top of the file. Other people's headers need not be > included in a reply. > > 3. If part of the message you are quoting is not important enough > for you to need to refer to it as you're composing your reply, > it's not important enough to include in the reply. Any part of > a message that you would like to fold away should probably just > be deleted from the message. > > Regards, > Gary > While I agree with you completely that these points hold when using Vim to compose a reply, they do not hold when using Vim to browse messages that have been received from others. (Too) many people don't use proper signatures and don't properly trim quoted material; and when using Vim to view raw messages, e.g. from a Maildir folder, there are usually many headers. ...Marvin --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Update of the mail.vim syntax file
* Gary Johnson <[EMAIL PROTECTED]> [081108 18:18]: > > Not to be a wet blanket, but I do have a couple of comments. > > 1. A proper signature is no more than 4 lines and appears at the > very bottom of the message, so folding it seems hardly > worthwhile. Other people's signatures should not be included in > a reply. > > 2. Similarly, if your mailer includes any of your headers at all in > the file it gives your editor, they should be few and at the > very top of the file. Other people's headers need not be > included in a reply. > > 3. If part of the message you are quoting is not important enough > for you to need to refer to it as you're composing your reply, > it's not important enough to include in the reply. Any part of > a message that you would like to fold away should probably just > be deleted from the message. > > Regards, > Gary > While I agree with you completely that these points hold when using Vim to compose a reply, they do not hold when using Vim to browse messages that have been received from others. (Too) many people don't use proper signatures and don't properly trim quoted material; and when using Vim to view raw messages, e.g. from a Maildir folder, there are usually many headers. ...Marvin --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: exec bit set on samba share
* Tony Mechelynck <[EMAIL PROTECTED]> [080829 10:06]: > > On 29/08/08 14:25, Nikola Knežević wrote: > > Hi, > > > > I have a weird problem on my Mac OS X. If I mount a Linux SMB share > > (manually, with -o noexec), and try to edit any file using either > > plain vim or MacVim, that file gets executable bit set. I don't know > > where to look to disable this behaviour. > > > > Any hints? > > > > Cheers, > > Nikola > > I'm not sure it _can_ be disabled. IIUC, the reason is that samba > usually means Windows at the other end, and typical DOS/Windows > filesystems (such as the variations on the FAT filesystem) have no > executable bit. What they have is "hidden", "system" and "readonly" (the > fourth one, "archive" is not really an access bit). Similarly in Cygwin, > all "Windows" files have their access bits set to -rwxrwxrwx, or > -r-xr-xr-x if they are readonly. > > Best regards, > Tony. I'm not sure about Mac OS X, but samba under Linux allows specifying options file_mode and dir_mode for the mount (on the client side), which should give you the behavior you want if the Mac OS X samba client allows them. Also, if both the client and server recognize CIFS (the successor to SMB), then you shouldn't have this problem at all. The Linux samba suite has used CIFS when possible for years. ...Marvin --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Bug or feature? E670
[Sorry for the late response] * Bram Moolenaar <[EMAIL PROTECTED]> [080821 21:14]: [generous snipping] > > Marvin Renich wrote: > > > * Bram Moolenaar <[EMAIL PROTECTED]> [080821 00:55]: > > > > > > Tony Mechelynck wrote: > > > > > > > >> Bug or feature? > > > > >> 1. Why should it be an error to have various help files from > > > > >> different > > > > >> sources in $VIM/vimfiles/doc, some in UTF-8 with BOM, and others in > > > > >> US-ASCII with of course no BOM but otherwise readable as UTF-8? > > > > > > > > > > Because the tags file can only be in one encoding. > > > > I would have expected :helptags to use the current value of 'fencs', > > which, if encoding=utf-8, defaults to ucs-bom,utf-8,default,latin1, > > which should favor utf-8 over latin1. > > No, because the help files encoding doesn't change between systems, they > are written mostly in latin1. 'fencs' is for user files, not for the > runtime files that come with Vim. > > Utf-8 is only widely used on Linux systems. Most other systems use a > wide variety of encodings. It's quite rare on MS-Windows. Utf-8 is rare on Windows, but Unicode (UCS-2) is fully supported by all modern versions of Window, even if many systems are configured to use an 8-bit NLS by default. > Many Vim executables are build without the utf-8 support, especially the > minimal Vi that comes with Linux. Defaulting to utf-8 causes quite a > bit of trouble. > Okay, I can definitely understand wanting help to be available for minimal builds of Vim without utf-8 support. My reason for suggesting to use utf-8 for official help files was to make it easy for users to add help files in any language without triggering the error message reported by the OP (Tony) when using the :helptags command. Reading farther down in :help help-translated, it says that help files must be in latin1 or utf-8 encoding. I think this should be duplicated under :help write-local-help. As Tony points out, fencs _is_ used when _reading_ the help files. If this is the case, does it matter if the encoding of the tags file doesn't match the encoding of the help file? Isn't each of the help file and tags file translated independently to the current 'encoding' using 'fencs' before the pattern in the help file is used to search for the tag in the local help buffer? If this is the case, can we simply allow :helptags to accept ++enc to specify the output format of the generated tags file? The tags files included by distributions should still try to use latin1, so that standard help is available from non-utf-8-enabled vim, but system-local and user-local help files can mix latin1 and utf-8 if desired (in separate files, of course), generating a utf-8 tags file. ...Marvin --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Bug or feature? E670
* Bram Moolenaar <[EMAIL PROTECTED]> [080821 00:55]: > > Tony Mechelynck wrote: > > > >> E670: Mix of help file encodings within a language: > > >> /usr/local/share/vim/vimfiles/doc/hicolors.txt > > >> > > >> The error is given by the :helptags command. > > >> > > >> Bug or feature? > > >> 1. Why should it be an error to have various help files from different > > >> sources in $VIM/vimfiles/doc, some in UTF-8 with BOM, and others in > > >> US-ASCII with of course no BOM but otherwise readable as UTF-8? > > > > > > Because the tags file can only be in one encoding. > > > > But, is UTF-8 with BOM different from UTF-8 without BOM? And how does > > ":helptags" detect the encoding used by a file? > > Right, that should work. But ASCII is not utf-8, and I think (without > looking at the code) that ASCII files default to latin1 encoding. > I would have expected :helptags to use the current value of 'fencs', which, if encoding=utf-8, defaults to ucs-bom,utf-8,default,latin1, which should favor utf-8 over latin1. Tony, what was fencs when you ran helptags? Bram, if this is not currently how helptags determines fenc, would you consider it a bug? It may not have been the case in the early days of Vim, but now I expect that utf-8 is widely used enough that the help files distributed with Vim should use utf-8. Putting a BOM at the beginning of each help file would facilitate easy detection. I think that using utf-8 for the official help files is the most reasonable way to allow everybody (especially script authors) to add help files that are compatible with the distribution. ...Marvin --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
(forw) Re: RFC: Gatekeeper - control which plugins are loaded
Stefano was having trouble sending to the group, so I am forwarding this for him. ...Marvin --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- --- Begin Message --- [ resent: the first one was bounced back by google groups ] On Tue, Apr 22, 2008 at 06:36:08PM -0400, Marvin Renich wrote: > Actually, I like Debian's approach (thanks Debian Vim Maintainers and > especially Stefano Zacchiroli). Rather than force every plugin to use a Marvin, thanks both for the kudos and for forwarding to us this thread handle. I'm no longer following actively vim-dev these days, but I believe James Vega (the most active vim maintainers in Debian these days, and which deserves the kudos part on our responsiveness :)) does. My thought on this issue is as follows. I don't like reinventing wheels, and it is what possibly happened with Gatekeeper. I hope your message can help fixing this. We would be very happy Debian-side if our vim-addon-manager solution will spread outside Debian boundaries, it is by no means Debian-specific. Our policies for how to handle this are stored in the Debian Vim policy (http://pkg-vim.alioth.debian.org/vim-policy.html/) and can be read be whoever wants. Similarly, the vim-addons source code is available and free software. The implementation is probably suboptimal, but it is not a complicated piece of code, if there is interest in the wider vim-dev community we might even rewrite it from scratch! implementing perceived needs. Just let us know. Please remember to Cc [EMAIL PROTECTED] if you want to be sure that me, or someone else of the Debian vim maintainers, follows this thread. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -<%>- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature --- End Message ---
Re: RFC: Gatekeeper - control which plugins are loaded
* Meikel Brandmeyer <[EMAIL PROTECTED]> [080421 17:46]: > Hello Vim developers, > > some days ago, there was a short discussion on #vim, that one cannot > easily prevent plugins from loading. A distribution could install some > scripts/plugins in the system-wide vimfiles directory, but the user > could not defend against such a "pollution". Each plugin uses a > different guard, so it's tedious to find out which one keeps a script > from loading. > > I thought a bit about this problem and came up with the following > solution: Gatekeeper. Gatekeeper keeps track of which plugins the user > wants to load, which plugins the users dislikes and which he doesn't > care about. So it is easy to disable specific plugins. > [snip] > From the script's perspective using gatekeeper is quite simple. It is a > single function call, which is used in the plugin guard header, which > prevents the script from being sourced multiple times. In fact, > gatekeeper even simplifies this header, since the normally used guard > variable is hidden away. > [snip] > So I'd like to drop this on the list with a request for comments. Any > comments on the idea are appreciated. > > Sincerely > Meikel > Actually, I like Debian's approach (thanks Debian Vim Maintainers and especially Stefano Zacchiroli). Rather than force every plugin to use a common interface to allow enabling/disabling individual plugins in a distribution, they built a vim-addon-manager package that allows the sysadmin to determine which plugins are enabled by default, and allows individual users to enable/disable each plugin separately, overriding the sysadmin's defaults. The global defaults are done by placing the scripts in a directory that is not in Vim's rtp, and then using symlinks to the system-wide enabled ones in a directory that is in rtp. Individual user preferences are likewise symlinks in the user's .vim/ directory structure. The only tricky part is disabling a default-enabled system-wide script. This is done by the Vim maintainers by manually determining for each script what to put in ~/.vim/plugin/000-vim-addons.vim to tell the script not to load (or make it think it is already loaded). More kudos to the Debian Vim Maintainers: Some people are really concerned about having the absolute latest patches to Vim and compile Vim themselves to that end. The Debian maintainers are very responsive, and while you cannot always get the latest patches in a binary Debian package, you can usually get very close. Currently, you can get official Debian packages with Vim 7.1-293, which is, indeed, the most up-to-date version. ...Marvin --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---