Re: [vim/vim] Unnecessary multiplications in backspace code (PR #14308)

[Marvin Renich]

* 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)

[Marvin Renich]

* 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)

[Marvin Renich]

* 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.

[Marvin Renich]

* 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

[Marvin Renich]

* 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?

[Marvin Renich]

* 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)

[Marvin Renich]

* 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)

[Marvin Renich]

* 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)

[Marvin Renich]

* 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)

[Marvin Renich]

* 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)

[Marvin Renich]

* 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)

[Marvin Renich]

* 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)

[Marvin Renich]

* 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)

[Marvin Renich]

* 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)

[Marvin Renich]

* 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)

[Marvin Renich]

[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]

[Marvin Renich]

* 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]

[Marvin Renich]

* 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]

[Marvin Renich]

* 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

[Marvin Renich]

* 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

[Marvin Renich]

* 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

[Marvin Renich]

* 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]

* Marvin Renich <m...@renich.org> [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)

[Marvin Renich]

* 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

[Marvin Renich]

* Zdenek Dohnal <zdoh...@redhat.com> [171103 09:27]:
> On 11/03/2017 02:07 PM, Marvin Renich wrote:
> > * zdoh...@redhat.com <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

[Marvin Renich]

* 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

[Marvin Renich]

* 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

[Marvin Renich]

* 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

[Marvin Renich]

* 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

[Marvin Renich]

* Kazunobu Kuriyama <kazunobu.kuriy...@gmail.com> [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 <m...@renich.org>:
> > 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

[Marvin Renich]

* 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 ?

[Marvin Renich]

* 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)

[Marvin Renich]

* 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)

[Marvin Renich]

* 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.

Mail from Vim Github Repository

[Marvin Renich]

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 ctrlsf.vim.dyng.github.com

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: Mail from Vim Github Repository

[Marvin Renich]

* Christian Brabandt cbli...@256bit.org [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 ctrlsf.vim.dyng.github.com
 
 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 vim.vim.github.com?

 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 vim.vim.github.com
 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.

Re: Repository cleanup (Was: Preparations for moving to github)

[Marvin Renich]

* Bram Moolenaar b...@moolenaar.net [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: Repository cleanup (Was: Preparations for moving to github)

[Marvin Renich]

* Bram Moolenaar b...@moolenaar.net [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: vim.org is down

[Marvin Renich]

* MC Andre andrew.penneba...@gmail.com [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]

* Ben Fritz fritzophre...@gmail.com [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.

Re: bash syntax: incorrect highlighting of escaped double quote

[Marvin Renich]

* Marvin Renich m...@renich.org [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.

bash syntax: incorrect highlighting of escaped double quote

[Marvin Renich]

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'

[Marvin Renich]

[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

[Marvin Renich]

* Tony Mechelynck antoine.mechely...@gmail.com [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?

[Marvin Renich]

* Bram Moolenaar b...@moolenaar.net [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

[Marvin Renich]

* Ujjwol (उज्जवल लामिछाने) ujjwollamichh...@gmail.com [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

[Marvin Renich]

* Hari G harig...@gmail.com [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?)

[Marvin Renich]

[dropping vim_use]

* Christian Brabandt cbli...@256bit.org [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 c...@256bit.org
 ---
  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: [PATCH] Set the buffer to be modified after recovery (was: Re: Save recovered file with ZZ?)

[Marvin Renich]

* James Vega james...@jamessan.com [100416 11:43]:
 On Fri, Apr 16, 2010 at 11:28 AM, Marvin Renich m...@renich.org 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: [bug] netrw-browse/autocmd/nospell

[Marvin Renich]

* 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

[Marvin Renich]

* 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

[Marvin Renich]

* 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: Bug or feature? E670

[Marvin Renich]

[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: exec bit set on samba share

[Marvin Renich]

* 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
-~--~~~~--~~--~--~---

(forw) Re: RFC: Gatekeeper - control which plugins are loaded

[Marvin Renich]

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
-~--~~~~--~~--~--~---

---BeginMessage---
[ 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

[Marvin Renich]

* 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
-~--~~~~--~~--~--~---