Re: Mark special characters
* Christian Brabandt [240522 09:01]: > On Mi, 22 Mai 2024, Igor wrote: > > I would like to distinguish normal spaces with characters that are in > > vim displayed as spaces, but are some non-space characters. Is there a > > way to display those characters so that I will spot them as special > > characters? > > Someone shared the following on the list a few years ago > https://groups.google.com/g/vim_use/c/FuEGojGwKCM/m/V1K8VAWWKrEJ > > and since then I have it in my .vimrc even so I should probably change > it to a WinEnter autocommand. Why WinEnter? Won't that set this much more often than necessary? > " Highlight special white space > hi def link WhiteSpaceError Error > match WhiteSpaceError > /[\x0b\x0c\u00a0\u1680\u180e\u2000-\u200a\u2028\u202f\u205f\u3000]/ > > Thanks, > Christian > -- > Almost anything derogatory you could say about today's software design > would be accurate. > -- K. E. Iverson ^ Are you an APL fan? ...Marvin -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/Zk4L5ZS7Sc4r51Jt%40basil.wdw.
Re: How to make gvim/vim-gtk3 behave exactly like vim
* 'Ottavio Caruso' via vim_use [240119 11:44]: > Am 19/01/2024 um 16:25 schrieb Gary Johnson: > > I don't know why you would have to learn different keyboard > > combinations. Please elaborate on that. > > Then you say: > > > > It has been a goal of mine, too, to make gvim indistinguishable from > > terminal vim. That's largely to make gvim on Windows behave the > > same as terminal vim on Linux. I think I've done pretty well. As > > it is, I sometimes have to check the title bar to see which one I'm > > using. > > You answered your own question. Not really. He has given a general answer when he is asking you for a more specific answer (as have several others on this list). An example would be: Ctrl-V on gvim does ..., while on vim it does If you can give a few keystrokes that behave differently, we can help you find out why, and give suggestions for fixing it. You can try «:verbose map» in your vim/gvim sessions and see if the keystrokes you are concerned about have been remapped, and which script remapped it. That might give you enough info to be able to fix it yourself. As others have said, in general a keystroke that does something in vim will do the same thing in gvim, but gvim has some keystrokes that are not available in vim. A script can easily map specific keystrokes differently in vim than gvim, and the above "map" command should give you some clues, if that is the problem. I don't remember if you said which OS/distribution you are using. Different distributions have different system-wide default vim configuration files. This info might also give us a better idea how to help you. ...Marvin -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/ZarcXlKKUOx/G9ZS%40basil.wdw.
Re: Why does (my) Vim leave the cursor to the last mark even if I don't save the file?
* Marvin Renich [230121 10:53]: > * Bram Moolenaar [230120 11:01]: > > > > > I think what he is asking is for the " mark to only be written to the > > > viminfo file for buffers that have been modified. I'm not sure how to > > > do this or if it is even possible, but it seems like a perfectly > > > reasonable behavior to want. > > > > > > Perhaps a VimLeavePre autocommand that wipes unmodified buffers? What > > > other settings for those buffers would not be saved to .viminfo? > > > > How about: > > - When writing the buffer set some flag, e.g. b:did_write_this_buf > > - When exiting, go through all buffers and those that don't have the > > b:did_write_this_buf flag move the cursor to the " mark. > > > > Something like that. > > I don't think we need another flag; just use the 'modified' option. I > think this is what the OP wants, and is simpler. > > I also think Salman Halim's suggestion of using the . mark instead of the > " mark is more useful. Note that what the OP wants (don't update " mark for non-modified buffers) requires changing the code that writes .viminfo, which I think is in the source, not the runtime. If you change defaults.vim to use the . mark instead, the OP is going to get very close to the behavior he wants (he may even like it better than what he asked for), and no change to the Vim source is needed. I suspect that most Vim users will prefer the . mark behavior over the current behavior, but if not, they can easily get the old behavior back; just leave the old BufReadPost as a comment in defaults.vim, and they can copy it to their own vimrc. I think this is the best solution all around. ...Marvin -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/Y8wOqZXZuVPFSJg1%40basil.wdw.
Re: Why does (my) Vim leave the cursor to the last mark even if I don't save the file?
* Bram Moolenaar [230120 11:01]: > > > I think what he is asking is for the " mark to only be written to the > > viminfo file for buffers that have been modified. I'm not sure how to > > do this or if it is even possible, but it seems like a perfectly > > reasonable behavior to want. > > > > Perhaps a VimLeavePre autocommand that wipes unmodified buffers? What > > other settings for those buffers would not be saved to .viminfo? > > How about: > - When writing the buffer set some flag, e.g. b:did_write_this_buf > - When exiting, go through all buffers and those that don't have the > b:did_write_this_buf flag move the cursor to the " mark. > > Something like that. I don't think we need another flag; just use the 'modified' option. I think this is what the OP wants, and is simpler. I also think Salman Halim's suggestion of using the . mark instead of the " mark is more useful. ...Marvin -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/Y8wKilsT9IqIj56h%40basil.wdw.
Re: Why does (my) Vim leave the cursor to the last mark even if I don't save the file?
* Christian Brabandt [230120 05:39]: > > On Fr, 20 Jan 2023, 'Ottavio Caruso' via vim_use wrote: > > > Am 19/01/2023 um 16:40 schrieb Christian Brabandt: > > > On Do, 19 Jan 2023, 'Ottavio Caruso' via vim_use wrote: > > > > $ cat .vim/vimrc > > > > source $VIMRUNTIME/defaults.vim > > > This is where the auto command is defined. If you do not want it, you > > > can delete this after sourcing the defauls.vim file: > > > > > > :augroup vimStartup | au! | augroup END > > > > Thanks, but if do that, I'd then remove this feature from all files, whether > > edited or not, wouldn't I?. Is it possible to have this implemented only on > > files that are saved? > > I would find it inconsistent for somtimes jumping to a different spot in > a file and sometimes not. I might not even remember if I last time saved > that particular file or not (e.g. I just need to check something but did > not save the file). That might be confusing. > > It might be possible to change that behaviour using a custom function > (e.g. set a flag on BufWritePost, check that flag on a BufLeave > autocomamnd and set the '" mark accordingly). Not sure if this will work > or not. > > Mit freundlichen Grüßen > Christian I think what he is asking is for the " mark to only be written to the viminfo file for buffers that have been modified. I'm not sure how to do this or if it is even possible, but it seems like a perfectly reasonable behavior to want. Perhaps a VimLeavePre autocommand that wipes unmodified buffers? What other settings for those buffers would not be saved to .viminfo? ...Marvin -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/Y8qX%2B2Ilouc3PmUq%40basil.wdw.
Re: Vim9 import [was Vim9 script feature-complete]
* Bram Moolenaar [220104 12:26]:
> Marvin Renich wrote:
> > * Bram Moolenaar [220103 12:33]:
[snip]
> > I agree that using the (cleansed) file name is suboptimal, but it was
> > the simplest choice. There are a couple other possibilities. One is to
> > require the "as" clause.
[snip]
> > Every vim9 script file already has a vim9script statement. You could
> > say that in order for the script to be imported the vim9script statement
> > must be of the form «vim9script ScriptId» where ScriptID must be a
> > capitalized identifier. If you import two different scripts with the
> > same script ID, you must use the "as" clause for at least one of them.
> >
> > Alternatively, you could require either the script ID on the vim9script
> > statement or the "as" clause on the import statement.
>
> Adding a script ID adds another mechanism and I don't see enough
> advantage in it. It raises questions, such as what happens if two
> completely unrelated plugins use the same ID?
Yes, the more I think about this, the more I like requiring "as" and
requiring using the prefix.
> Since the import can use a relative file name, a short file name can
> work. It's only when using a file name in 'runtimepath' that we can
> expect the name to be longer. Thus requiring the use of "as" up front
> does not seem necessary.
Then we would be back to cleansing the filename. I was the one who
originally suggested that, but I think that was not a great idea.
Require "as" (with Capitalized identifier), and require using that
identifier as prefix.
> > > > I personally find that using an imported name without a prefix (as it is
> > > > currently possible) makes my code terse, and I think that in the limited
> > > > scope a plugin that works well.
> >
> > My opinion is the opposite, here. Even in small, simple scripts, the
> > prefix makes the code more readable; there is no question from where the
> > identifier came.
>
> Right. Somehow code writers can be very lazy typing things, and then
> spend lots of time (possibly much later) figuring out what the code is
> doing. Unfortunately I'm not aware of any studies being done on this
> (it's more computer art than computer science).
I think this agrees with requiring both "as" and using the prefix.
> > > Throwing everything from "Other" into the current namespace is going to
> > > cause trouble, because someone may add an item to myclass.vim that
> > > conflicts with what is in your script. Thus extending one script may
> > > break another script, that is bad.
> >
> > This is probably the best reason to not allow blindly importing all
> > identifiers from one script into the local namespace of another.
>
> I'm starting to more and more like the idea of the simplistic import. The
> main reason is that the Javascript way suggests that it is possible to
> import individual items from a script, which in reality the whole script
> is read, while some items can't be adressed.
>
> Also since it's possible to do this:
>
> import FuncOne from "thatscript.vim"
> import FuncTwo from "thatscript.vim"
> import FuncThree from "thatscript.vim"
>
> This doesn't actually load the script three times, but you'll have to do
> digging in the help to know that. Thus there is some hidden knowledge.
> It can be written as:
>
> import {FuncOne, FuncTwo, FuncThree} from "thatscript.vim"
>
> Which turns it into a one-liner, but adds the need for a syntax that
> isn't used anywhere else.
>
> While using:
>
> import "thatscript.vim"
>
> Or:
>
> import "thatscript.vim" as that
>
> Is nice and short, no need for "from". The help for ":import" becomes
> much shorter. The implementation will also be much simpler.
>
> The discussion about the need for using the prefix, whether "as" should
> be required and other things, seem less important.
Actually, I think the local namespace pollution is the more important
issue, and requiring "as" and the prefix gives the simpler import syntax
as an added benefit.
...Marvin
--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_use+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_use/YdSJ6HFjh34Wek4N%40basil.wdw.
Re: Vim9 import [was Vim9 script feature-complete]
* Bram Moolenaar [220103 12:33]:
> > On 2022-01-03, Marvin Renich wrote:
> > > Don't bother with the
> >
> > > import MyClass from "myclass.vim"
> > > import {someValue, MyClass} from "thatscript.vim"
> > >
> > > syntax, and only provide
> > >
> > > import "myclass.vim"
> > > import "myclass.vim" as Other
> > >
> > > and require use of the namespace prefix:
> > >
> > > Other.MyClass
> > >
> > > The first case, without the "as" would default to the file name, with
> > > leading directories and trailing ".vim" removed
> >
> > I do not think that using a filename as an identifier is a good idea.
> > For instance, calling a script 1.vim would automatically make it
> > non-importable (without "as").
I agree that using the (cleansed) file name is suboptimal, but it was
the simplest choice. There are a couple other possibilities. One is to
require the "as" clause.
Another is to do something similar to Go (a language I like, if you
couldn't tell :-) ). Every Go source file has a package statement,
«package frob», and when importing, this package identifier, «frob», is
used as the prefix (if not overridden in the import statement).
Every vim9 script file already has a vim9script statement. You could
say that in order for the script to be imported the vim9script statement
must be of the form «vim9script ScriptId» where ScriptID must be a
capitalized identifier. If you import two different scripts with the
same script ID, you must use the "as" clause for at least one of them.
Alternatively, you could require either the script ID on the vim9script
statement or the "as" clause on the import statement.
> Since a script needs to use "export" to be able to be imported, having
> to use a nice name for the script is clearly needed. The only thing is
> that it may be a long name to avoid name collisions, but then the "as
> {name}" form can be used to shorten the name.
>
> > I personally find that using an imported name without a prefix (as it is
> > currently possible) makes my code terse, and I think that in the limited
> > scope a plugin that works well.
My opinion is the opposite, here. Even in small, simple scripts, the
prefix makes the code more readable; there is no question from where the
identifier came.
> > But I understand that Vim9 scripts might
> > have a broader use, such as generic libraries of functions that can be
> > used by many scripts. In that context, stricter scoping rules, such as
> > in Go, are likely a cleaner approach.
> >
> > How about always requiring a prefix, but allowing explicit namespace
> > pollution? As in
> >
> > import "myclass.vim" as Other
> > use Other # Makes Other.F() available as just F()
I like this very much; it works regardless of how the prefix gets
defined ("as" clause, vim9script statement, or cleansed filename).
I think if I had to pick, I would require the "as" clause. It is
simple, and doesn't depend on the script author keeping the same script
ID with newer versions of the script. The author of the script doing
the importing is required to be in control.
> Throwing everything from "Other" into the current namespace is going to
> cause trouble, because someone may add an item to myclass.vim that
> conflicts with what is in your script. Thus extending one script may
> break another script, that is bad.
This is probably the best reason to not allow blindly importing all
identifiers from one script into the local namespace of another.
...Marvin
--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_use+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_use/YdR996IMMD14X29I%40basil.wdw.
Re: Vim9 import [was Vim9 script feature-complete]
* Bram Moolenaar [220103 07:07]:
>
> > On 2021-12-30, Bram Moolenaar wrote:
> > > If you have remarks on something in Vim9 script that you think should be
> > > different, speak up now! Soon we'll only make backwards compatible
> > > changes to avoid breaking existing plugins.
> >
> > There was a thread about this on HN a few days ago, and one of the
> > comments suggested to reverse the import syntax so that the imported
> > script is named first and the imported entities next. A rationale for
> > this is that it would help automatic completion.
>
> Is there another language that works like this? The current syntax
> resembles Javascript, which hopefully some users are familiar with.
I have to agree that putting the file being imported first is much
better.
In Go, by default every imported identifier must be prefixed by the
package name, much like the current Vim9 "as" clause. Requiring an "as"
clause (or defaulting to some form of the script name for the value of
the "as" clause), and requiring that all imported identifiers be
prefixed by this identifier make the code _much_ clearer and easier to
follow.
I very much dislike the JavaScript style where importing, by default,
places the imported names in the current namespace rather than in a
separate namespace (identified by the "as" clause in Vim9).
Given that even when you are only importing one identifier from a
script, the whole script must be read and executed, I think the Go way
is better. Don't bother with the
import MyClass from "myclass.vim"
import {someValue, MyClass} from "thatscript.vim"
syntax, and only provide
import "myclass.vim"
import "myclass.vim" as Other
and require use of the namespace prefix:
Other.MyClass
The first case, without the "as" would default to the file name, with
leading directories and trailing ".vim" removed, and with the first
letter capitalized. Non-identifier characters and leading digits would
be removed as well. In the case without "as" above, you would reference
the imported MyClass identifier as
Myclass.MyClass
With this, every use of an imported identifier is clear and explicit.
...Marvin
--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_use+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_use/YdL35xfbRHlaYZU5%40basil.wdw.
Re: split question
* Kennedy, Marcus A. [211201 12:58]: > > ASCII art of what I want (hopefully LookOut! and Exchange doesn't screw > > this up in flight): > > > > --- > > | | | | > > | | |-| > > |-|-| | > > | | |-| > > | | | | > > | |---| > > | | | > > |-|---| > > > > Additional info: Closest I could come up with was: > > --- > | | | | > | | |-| > |-|-| | > | | |-| > | | | | > |-|---| > | | | > |-|---| > > I cannot seem to make that bottom left window go away. Call the columns A, B, and C. Split the window vertically into A and B. Now splitting A horizontally is independent of the rest. Next, split B horizontally into rows F and G. Now you can split F vertically, giving you column C in F only. Now splitting [F,B] and [F,C] can be split horizontally as desired. ...Marvin -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/YafRezErKAM5/IFh%40basil.wdw.
Re: home setting
* Joseph [200821 12:50]: > Hello, I am using vim 8.1.1 on Windows 10 on a network where we have > network drives as our home directory: H:. I still have a directory on the C > drive C:\Users\ > > I am trying to set the cdpath variable to the following: > set cdpath=.,H:\,C:\Users\\Downloads\ > > The problem is that this becomes > cdpath=.,~,~\Downloads\ > > If I change my HOME environment variable to C:\Users\ it mostly > works, but of course I want to leave the network drive as the home > directory. Is there a way to force vim to use the fully qualified path > names instead of automatically transforming them to ~. > > I believe, though I am not certain, that this worked with vim 8.0. I'm not sure, but at first glance, this seems like a bug to me. Vim should not change both "H:\" and "C:\Users\" to "~" when parsing cdpath. I assume you are setting this in your vimrc? What does Vim think your $HOME is immediately before setting cdpath (try adding echo $HOME immediately before your cdpath command). I'm adding vim_dev to CC; perhaps someone there can give a more definite answer. ...Marvin -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20200821175454.fovx5k4fwm5b52hb%40basil.wdw.
Re: [OT(?)] Ubuntu 18 now defaults to 4-space tabs
* Tobiah [190910 03:01]: > We upgraded a server to 18.04 and now when I start typing > a python file (seems to be triggered by the .py extension) > the tabs default to 4 spaces. We have decades of code that > use tab characters, and it has not been our intention to > change that. > > I found a /usr/share/vim/vim80/indent/python.vim and tried > moving it out of the way, but the behavior was still there. > > I know I can put a modeline in every file but I was hoping > to do it for every user and for every file. I don't know if this is your problem, but a somewhat (but not too) recent change to Vim added a file /usr/share/vim/vim##/defaults.vim that gets sourced automatically by vim if no user vimrc file is found. This file sets some very subjective non-default values, and I find some of its choices highly obnoxious. If this is your problem, there are two possible fixes. The first (assuming the Debian packaging; I'm not sure if Ubuntu uses the Debian package unchanged or not) is to edit /etc/vim/vimrc and uncomment the line: " let g:skip_defaults_vim = 1 The second is to ensure that the user has a vimrc file: mkdir ~/.vim touch ~/.vim/vimrc My opinion is that the defaults.vim file should only set options that almost all vim users will want, and should stay completely away from options that are "personal taste" (i.e. leave them with the vim internal default settings). The most noticeable option that bothers me is the scrolloff setting. Some people like it, and some, like me, are bothered by having it non-zero. The vim default has been 0 (the vi compatible behavior) since the beginning of time^Wvim. A non-zero value was added to defaults.vim, I suppose when vim started conditionally sourcing that file. To repeat myself, defaults.vim should not set any options where there is a wide variety of personal preference. Quite honestly, I don't understand why this feechur was added at all; it means that vim has one set of defaults if the user has a vimrc file and a completely different set of "defaults" (really?) if the user doesn't have his own vimrc file. This complicates vim startup, and adds one more thing a new vim user needs to learn immediately when starting to personalize vim by creating a ~/.vim/vimrc file: Install vim and start using it; decide to create a vimrc just to change one or two options (or maybe not to change any option but to add a key mapping); now vim behaves quite differently, and the new user has to figure out why and how to get all the "original" behavior back. ...Marvin -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20190910125625.6qeqe5wfswcdanuc%40basil.wdw.
Re: Personal syntax highligth for ToDo and else.
* white-wolf [190423 04:25]: > hi, > i use txt to organize my ToDo, my AdresseBook en else. > i would like to colorize my txt by a personnal syntax hightlight. > > how can do ? In addition to the other good answers, if you want to write your own, try «:help syntax» which has all the reference information needed. That help file, in its overview, also points to two sections in the User Manual with more tutorial-oriented help. ...Marvin -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Personal syntax highligth for ToDo and else.
* white-wolf [190423 04:25]: > hi, > i use txt to organize my ToDo, my AdresseBook en else. > i would like to colorize my txt by a personnal syntax hightlight. > > how can do ? In addition to the other good answers, if you want to write your own, try «:help syntax» which has all the reference information needed. That help file, in its overview, also points to two sections in the User Manual with more tutorial-oriented help. ...Marvin -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: how to display current syntax and highlight items
* Marvin Renich [190214 08:06]: > Thanks! That gives the info I want, and it also gave me the clue Wow! Looking at the Received: headers of the previous message, Google's servers first accepted the message immediately on Feb 12, but it spent two days hung up on an internal Google server, finally being delivered yesterday! Thanks for all the answers I got from everyone. ...Marvin -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: how to display current syntax and highlight items
* Magnus Woldrich [190212 11:38]: > Here you go: > https://github.com/trapd00r/configs/blob/master/vim/nancy/000-functions.vim#L159 Thanks! That gives the info I want, and it also gave me the clue to find the help (synID) and the original tip that I was looking for: Tip 99 on the old «https://www.vim.org/tips/» page, now at «http://vim.wikia.com/wiki/Identify_the_syntax_highlighting_group_used_at_the_cursor». I like your use of map over synstack to give all of the contained syntax items. ...Marvin -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
how to display current syntax and highlight items
I have looked through index.txt (especially g commands), syntax.txt, and usr_06.txt, but I could not find any reference to displaying the name of the current syntax item and/or highlight item of the character under the cursor. I am pretty sure that there was a tip about this on this list in the distant past, but cannot find it. Can anyone point me to the correct help tag? Thanks...Marvin -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Locating .vim on Windows
* tu...@posteo.de [180408 13:23]: > On a windows PC I have "installed" vim - that is: I have > unpacked a archive downloaded from here: > https://github.com/vim/vim-win32-installer/releases > > Is there a way to ask vim (for example through vim-internal variabl) > where it exspects the equivalent of .vim (UNIX/Linux) ? :help vimrc will give a detailed explanation of the search order. Note that the documentation says that on Windows, _vimrc is used. However, there is one sentence that says on Windows it will check for both _vimrc and .vimrc. ...Marvin -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: How to get rounded bullet list character
* Tony Mechelynck [160219 16:03]: > On my system (openSUSE lEAP 42.1), the various > /usr/share/X11/locale/*/Compose vary greatly in length, from 44 (44 > empty lines) for C to 564170 bytes for en_US.UTF-8 (which has entries > for incredibly many scripts). > Most (but not all) lines require a (or Compose key) which > is always followed by at least two other keystrokes, so it is not (I > presume) the AltGr key present on my Belgian AZERTY keyboard. I'm not > sure what it is or whether I've got it. Okay, now I am really embarrassed! I looked at en_US.UTF-8/Compose several times (with less) and could swear it only had a couple dozen lines! My terminal window has 72 lines, and less displayed 27 lines of text at the bottom of the screen, which is the behavior I expect for a file with 27 lines. The reality is that the file has 6039 lines, the first 44 of which are blank! It does indeed appear to have all the Compose combinations in it. Thanks Tony! I had actually Googled a couple weeks ago (unrelated to this thread) to figure out how to set up the compose key, so I may be mis-remembering, but some of the pages said that AltGr is the default Compose key for X, and some people said it worked and others said it didn't. You can try it on your system by pressing AltGr ' e (the Compose key acts as a prefix, not a shift-type key). This will display é if it works. If that doesn't work you can try setting XKBOPTIONS as described in my previous message. I'm not sure what values are legal for compose; I know rwin and menu work (I use menu). ...Marvin -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: How to get rounded bullet list character
* Nikolay Aleksandrovich Pavlov [160219 15:20]:
> I do not think that this digraph was plannet to insert a *bullet*.
> Adjacent entries in the `:h digraph-table` are MINUS-OR-PLUS SIGN,
> ASTERISK OPERATOR, RING OPERATOR, {BULLET OPERATOR}, SQUARE ROOT,
> PROPORTIONAL TO, INFINITY. As you see everything here is math, as well
> as BULLET OPERATOR itself.
That's fine; I wasn't suggesting the removal of the existing BULLET
OPERATOR digraph. That does explain why that specific bullet is in the
table.
My point was that Vim would benefit from the addition of the BULLET from
the General Punctuation section, as well. Using the same digraph used by
the X Compose key (.=) would be the obvious choice.
...Marvin
--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_use+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: How to get rounded bullet list character
* Marvin Renich [160219 12:49]: > so it's suggestion of /usr/X11R6/lib/X11/... is wrong. On my system, it s/it's/its/ (I should have proofread before sending!) ...Marvin -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: How to get rounded bullet list character
* 'Guyzmo' via vim_use [160219 10:10]: > or you can directly use the digraph: `Sb` which outputs: `∙`. From > `:he digraph`: > > ∙ Sb 22198729BULLET OPERATOR > > or you could use the compose key feature (using Xorg or some hacks on > OSX/Windows) to use one of your modifier keys to behave like but > throughout your system. On my system (Debian stretch) with locale en_US.UTF-8, Compose .= gives the 0x2022 bullet (in the Unicode General Punctuation section; 2219 is in the Mathematical Operators section). The fact that the vim digraph uses a different bullet is obviously a historical artifact. Perhaps .= could be added to the digraph table to match the X Compose sequence (i.e. with 2022 rather than 2219). > http://www.linuxhowtos.org/Tips%20and%20Tricks/compose.htm On Debian, the correct place to set your compose key is in /etc/default/keyboard. It will then work in a text console (e.g. Alt-Ctrl-F1) as well as in X. Add a line like: XKBOPTIONS="compose:rwin" Editing xorg.conf, as suggested in the above page, may be necessary on systems that don't have the equivalent of the Debian console-setup package, but then it won't work in a text console. > Since I have that, I'm having a lot of fun featuring any text I type > with unicode characters like: →, ⇒, •, ☺, ① ② …, — or even the > non-secable space ` `. I've also added a few ones just for the fun: > 🍻 , 🐦 or 🖕 :-) Where do you get a list of Compose sequences? The above page is out-of-date (and doesn't have any indication of when it was written :-P) so it's suggestion of /usr/X11R6/lib/X11/... is wrong. On my system, it is in /usr/share/X11/locale/..., but the Compose file for my locale only has a few entries, and there are many more combinations that work. I haven't found any way to get the complete list of combinations. Thanks...Marvin -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Unicode input
* Marcel Svitalský [151003 16:24]: > It works all right for common ASCII characters, however for characters > above 127 it creates unexpected results: > > """ > Got from "Convert to HEX" > 3a: > 25% > 73s > 2d- > c2a0 Unicode non-breakable space > c2ad Unicode soft-hyphen > > Test results: > s - put in with Ctrl-V u 0073 - OK > 슠 - put in with Ctrl-V u c2a0 (its real code is ec8aa0) - ERROR > 슭 - put in with Ctrl-V u c2ad (its real code is ec8aad) - ERROR > """ Unicode c2a0 is not non-breaking space; that is 00a0. Soft-hyphen is 00ad. The c2a0 and c2ad characters are in the Hangul Syllables table, and are displayed correctly for me (the same way they display for me in the email you sent). I believe your problem is that you are confusing Unicode code points with utf-8. You should use the code point when using Ctrl-V u to enter Unicode characters. So, if you type Ctrl-V u 00a0 you will get the non-breaking space. If fileencoding is utf-8, then when the file is written, the non-breaking space will be written out as the two-byte sequence c2 a0, because that is the utf-8 encoding for code point 00a0. ...Marvin -- -- You received this message from the "vim_use" 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_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: How to add two lines in vim?
* Bee [130120 18:24]: > > > On Jan 20, 3:13 pm, Bee wrote: > > On Jan 20, 2:52 pm, Peng Yu wrote: > > > > > Hi, > > > > > O can only add one lines. I'm wondering if there is a built in command to > > > add two lines at a time in vim. Does anybody know? > > > > > Thanks, > > > Peng > > > > If you do 2O you will have two lines > > --OR-- > > try 22O and you will have 22 new lines > > > > Bill > > Correction: > > 2Oi > --OR-- > 22Oi Actually, the trailing i is only needed if you want to end up in insert mode, and is not part of the command that inserts multiple lines. Note that any text inserted as part of the O or o command gets inserted multiple times, as well. So that 5OHello will insert the line «Hello» five times. The delay between the and inserting the repetitions of the text only occurs in terminal vim, not gvim or macvim. It is a consequence of the keyboard handling. Terminal vim must wait a little bit to see if the is part of a terminal escape sequence for keys like the arrow keys or function keys. HTH...Marvin -- You received this message from the "vim_use" 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: Problem with a regular expression in Vim
* Xell Liu [121003 03:18]:
> Hi Paul,
>
> By extraction I mean that what I need to match is only the contents
> without the surroundings "==" (i.e. extracting "aaa" from "==aaa==").
>
> I certainly know that I could use \(\) to get the contents afterwards.
> But I want to know how to match the contents solely. For example,
> while using :match command, the surroundings outside \(\) will be
> always highlighted according to your suggestion.
>
> >> In fact, by pseudocode I think I can put my requirement like this:
> >>
> >> 1. Search for the first pair of "==" from the beginning location where
> >> the search starts.
> >> 2. Extract the contents in the pair of "==" as the first match result.
> >> 3. Disable/Invalidate/Remove the matched contents with its "=="
> >> surroundings.
> >> 4. Repeat from 1. until reaching the end of the search range.
> >>
> >> So, is it possible to do that by regular expression? I'm not very
> >> familiar with the concepts of greedy/non-greedy or zero-match (like
> >> the queer things of \@! or \@<= etc.) or . Will they help?
(Please don't top-post.)
The meaning of the terms "extract" and "disable/invalidate/remove" in 2 and
3 above is unclear to me (and apparently others on this list).
It is not clear what your criteria are for what is supposed to match and
what isn't. You seem to want the effects of \zs and \ze, which exclude
the "==" from the part of the text that is considered to match (i.e.
what is highlighted if 'hls' is on, and what would be replaced with
:s//something/). But you say you want to match the "aaa" and "ddd", but
not the "bbbccc". What is not clear is what strings between pairs of
"==" you want to match.
Is it alternating matches, so that if "==" occurs seven times, you match
the first, third, and fifth inner strings, like this:
a==b==c==d==e==f==g==h
would match b, d, and f?
Do you want exactly what is done by /==\zs[^=]\{-}\ze==/ except that you
want to start looking for the next match (e.g. with the normal mode
command 'n') _after_ the trailing "==" of the previous match?
Side note: In the given regex, because you are matching [^=] between
==, there is no difference between greedy and non-greedy. The
expression could be /==\zs[^=]*\ze==/.
...Marvin
--
You received this message from the "vim_use" 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?
* Tim Chase [120414 08:53]: > On 04/14/12 07:42, Bram Moolenaar wrote: > >We don't use ? like this in any command, but somehow it feels right. > > I think it feels right because of the ":set foo?" syntax which is > the "tell me this setting, even if it's boolean". I like it. I like :dig? a lot. However, I still think :dig! to delete is wrong and :undig is much more consistent with :unmap and :unab. I don't think :au! should be used a model for this. ...Marvin -- You received this message from the "vim_use" 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
[OT] shebang; was: Re: how to enable color scheme
* Taylor Hedberg [120111 10:03]: > This is a bit of a digression, but shebang lines are not a feature of > the shell, but a feature of the operating system. So if it works in one > shell, it should (theoretically) work in any shell on the same system. You are right, this is getting OT (subject changed). Shebang started as a feature of, specifically, the Bourne shell. It was soon added to the Unix kernel (perhaps 1980?), and has been in most Unix-like OS's since then, including Linux. Yes, it is now a feature of the kernel exec() system call. The OP said he was writing shell scripts, so I jumped to the conclusion that he was on a Unix-like operating system, which might be incorrect. But if he is, the shebang will almost certainly work. If he is writing ksh scripts for a non-Unix-like OS, why would having the shebang line cause problems? It will allow Vim to correctly determine the file type without having to put set ft=sh in his .vimrc. He stated that he cannot have #! in the file, and I was simply curious what the reason was (mostly whether it was a technical or procedural). ...Marvin -- You received this message from the "vim_use" 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 enable color scheme
* J.Z. [120110 19:43]: > thanks, set ft=sh did the trick. I cannot use.sh extension for files > for ksh funtions, and cannot have #! in them also. (Please do not top-post.) I'm curious why you can't use a shebang line (#!) in ksh. I haven't used ksh since the early '90s, but a quick test here seems to work fine. I installed ksh and created the following simple ksh script named ksh-test: - #!/usr/bin/ksh echo $KSH_VERSION - Typing ksh-test at a bash prompt executed it properly and gave Version JM 93u 2011-02-08 which is evidence that the shebang line was properly parsed. I also invoked ksh and did the same from a ksh prompt, with the same result. Editing the file with vim and with gvim both recognize the filetype as sh as expected. Are you not allowed to use #! because of some corporate coding policy, or is there some technical reason that the shebang interferes with some special way you are processing the scripts? I'm just curious, because in general, using a #! is the "right" way to do this. It both allows the editor to determine the correct file type and allows the OS to invoke the script with the correct interpreter. It also makes it clear to a person reading the script for which shell it is intended. ...Marvin -- You received this message from the "vim_use" 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: :make Success
* Paul [26 18:27]: > I want to do this, but only have the ls bit executed if make is successful: > > :make | !ls > > The help says that "when the command before the '|' generates an > error, the following commands will not be executed". I see that > ':make' is more or less like doing ':!make 2>&1 /tmp/something', which > would always return successful because stderr is redirected to stdout. > My aim is to have '!ls' (actually, any arbitrary shell command) only > happen when make returned no errors in my file. > > Is it not possible, or perhaps I have to do something like > >:make | if empty(errorlist) | norm "!ls" | endif > > In which case, what would be the most efficient way of typing that? Don't confuse :make with :!make. While internally, :make is going to execute the OS's make command (assuming default 'makeprg'), the behavior of | in this context depends on the result of the vim command :make, not the result of the OS make. Apparently, the vim :make does not check the return code of the OS make that it executes. Perhaps this is a bug; I don't know if Bram will change it, though, as it might have consequences to existing vim scripts using :make. Bram is usually very cautious about making incompatible changes to long-standing behavior, even when the existing behavior is clearly not the best. And given that 'makeprg' does not always use make, there are probably lots of scripts out there that assume :make will succeed even if the executed 'makeprg' fails. One possible solution would be to make the return code from the 'makeprg' available to vim script, perhaps in v:makerc. Then you could use that in an :if condition. ...Marvin -- You received this message from the "vim_use" 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: Abbreviation with an @
* Tony Mechelynck [06 22:25]:
> There are three kinds of abbreviations, see :help abbreviations
>
> - full-id
> the {lhs} consists of keyword characters only
> - end-id
> the last character, but none of the others, is a keyword char.
> - non-id
> the last character is not a keyword char, the rest can be anything
> except whitespace.
>
> @ is non-id
> @a is end-id
> @au or @aut or @author are not valid abbreviations.
>
> (letters, but not @, are keyword characters).
>
> Conclusion:
>
> :abbrev @author {rhs}
>
> is invalid for any value of {rhs}. The answer to your question is:
> you can't.
How does vim handle when isk changes so that some existing abbreviations
are no longer valid or change from one type of abbreviation to another?
At first glance, this seems like a bug in the design.
Note that this thread started because someone got an error when defining
an abbrev in one instance but not in another. If changing isk after the
fact simply made some existing abbrev's stop working without any error,
that would be even more confusing and harder to track down.
...Marvin
--
You received this message from the "vim_use" 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: hello
* zhangkai [110614 19:34]: > Hi Susan, > Glad to meet you. > It seems you got my email from "vim_use" maillist, just I haven't use vim > for a long times. > > If you like, we can communicate via email. I'm a Chinese programmer. > Thanks & best regards, > -- zhangkai Please do not reply to spam. ...Marvin -- You received this message from the "vim_use" 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: Determining if Vim is running in text-console mode or X Windows
* Steve Laurie [110201 09:17]:
> Hi Marvin,
>
> On my system, "gui_running" only distinguishes between Vim and gvim.
>
> I put let my_has_gui_running = has("gui_running") early in my
> ~/.vimrc file and did :echo my_has_gui_running
>
> In Vim run from the black and white tty text console, I get 0;
> In Vim run insde of gnome-terminal, I also get 0;
> In gvim, I get a 1
>
> That's why it's not working. I'm trying to distinguish between tty
> text mode and X mode.
> Not between Vim and gvim.
>
> Regards,
> Steve
Ah, you want to distinguish between running in a terminal on a text
console and running in a terminal emulator under X. Does this do what
you want?
if $DISPLAY == ""
let is_x_terminal = 0
else
let is_x_terminal = 1
endif
...Marvin
--
You received this message from the "vim_use" 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: Determining if Vim is running in text-console mode or X Windows
* Steve Laurie [110201 06:57]:
> Thanks for your help. unfortunately, none of these suggestions work.
Hmm. You say in your original message that you have tried
has("gui_running"). This works for me (and has for a long time).
As a test, I put
let my_has_gui_running = has("gui_running")
early in my .vimrc. If I start vim from the command line and type
:echo my_has_gui_running
I get 0. If I do the same with gvim (or vim -g) I get 1. Using
if has("gui_running")
echo "has gui_running"
else
echo "does not have gui_running"
endif
in .vimrc prints (to the terminal before setting up the vim screen) the
correct string for both vim and gvim.
I am using vim 7.2.445 from Debian squeeze.
...Marvin
--
You received this message from the "vim_use" 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: Help with substitute command
* Christian Brabandt [110120 05:39]: > That was actually one of the few things that really annoyed me, > when switching to Linux. > > "Why do I need to script something using > a loop, if Windows can do it much more easily"? > > regards, > Christian With perl installed (at least in Debian): $ prename 's/\.tcl$/.tcp/' *.tcl While is it a little more to type, it is several orders of magnitude more powerful (typical Unix). ...Marvin -- You received this message from the "vim_use" 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: syntax on and .vimrc files
* Kevin R. Bulgrien [110113 21:55]: > > I have a .vimrc that I have used for years. I upgraded the system and now > vim-enhanced is not interpreting the file the same way it used to. It seems > to boil down to "syntax on" or "syntax enable" being in the file. Whenever > one of them is present, it blows away settings like indentexpr that I have > set in the .vimrc file. The position of the command does not seem to > change the behavior. > > What is the new way of setting syntax on as the default while retaining the > proper, expected function of the .vimrc file? > > Thanks, > > Kevin In addition to Ben's suggestions, you can also use :verbose set indentexpr? to find out where it is being clobbered. It is likely being set by a filetype-specific file, perhaps in the $VIMRUNTIME/indent directory. You can override this for specific filetypes by dropping an appropriate file in ~/.vim/after/indent/. ...Marvin -- You received this message from the "vim_use" 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: [OT] top post reminder
* Charlie Kester [090807 19:45]: > I use mutt to read the list, in a full-screen terminal window. Not > counting the header lines, that leaves around 50 lines for each message. > I have mutt configured to display quoted text in a different color than > new text, so I can easily see which is which. If I don't see anything > except quoted text in those 50 lines -- and this is surprisingly common > -- I immediately move on to the next message. I do NOT scroll down in > hopes of eventually finding whatever it was the poster felt moved to > say. Are you aware of "S" (shift-s) in mutt to skip quoted? Also, someone on this list suggested the t-prot package, which hides TOFU and long signatures (when used with mutt, slrn, or inn2). I now use it and find it extremely helpful in ignoring bad posting styles. ...Marvin --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Wiki Category:Omnicomplete (was Re: Omnicomplete not working)
* John Beckett [090519 20:47]: > Interesting, and it looks broken. When I request the above page, > the server reply includes: > > HTTP/1.1 304 Not Modified > Date: Wed, 20 May 2009 00:29:59 GMT > Last-Modified: Tue, 19 May 2009 10:39:21 GMT > Connection: keep-alive > X-Served-By: varnish1 > X-Cache: MISS > X-Cache-Hits: 0 > > Note that I got a different server, and presumably yours is > further down the food chain (and is using an old cache). > > So, I think this is a weirdness from the complex and > overloaded Wikia system. They have announced that a large > upgrade to their infrastructure will occur in a couple of > months (so waiting should cure the problem you see). Okay, thanks for looking into this. ...Marvin --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Wiki Category:Omnicomplete (was Re: Omnicomplete not working)
* John Beckett [090519 08:34]: > The MediaWiki software has lots of aggressive caching, but it > normally works quickly for the above kind of thing. I guess it > was just a caching issue because the "C++ code completion" tip > is now listed. (Sorry, I should have changed the subject a while back to indicate the hijacking of the thread.) Hmm. It still doesn't show up for me on the Category:Omnicomplete page. Live HTTP Headers gives this: http://vim.wikia.com/wiki/Category:Omnicomplete GET /wiki/Category:Omnicomplete HTTP/1.1 Host: vim.wikia.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.7) Gecko/2009030814 Iceweasel/3.0.9 (Debian-3.0.9-1) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://vim.wikia.com/wiki/Category:Searching Cookie: wikiwyg_enabled=true; __utma=196273067.508822174.1231254280.1231254280.1231254280.1; __utmz=196273067.1231254280.1.1.utmccn=(direct)|utmcsr=(direct)|utmcmd=(none) If-Modified-Since: Tue, 03 Mar 2009 07:33:38 GMT Cache-Control: max-age=0 HTTP/1.x 304 Not Modified Date: Tue, 19 May 2009 13:17:06 GMT Last-Modified: Tue, 03 Mar 2009 07:33:38 GMT Connection: keep-alive X-Served-By: r9-8-23 X-Cache: HIT X-Cache-Hits: 35 So, Mozilla is caching it, and Wikia is not properly identifying it as having been changed. Curiouser and curiouser...I cleared Mozilla's cache and refreshed the page. It still does not have C++ code completion, and Live Headers seems to say that it is getting a fresh copy from the server, but the Last-Modified date is still 03 Mar 2009: http://vim.wikia.com/wiki/Category:Omnicomplete GET /wiki/Category:Omnicomplete HTTP/1.1 Host: vim.wikia.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.7) Gecko/2009030814 Iceweasel/3.0.9 (Debian-3.0.9-1) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: wikiwyg_enabled=true; __utma=196273067.508822174.1231254280.1231254280.1231254280.1; __utmz=196273067.1231254280.1.1.utmccn=(direct)|utmcsr=(direct)|utmcmd=(none) HTTP/1.x 200 OK Server: Apache Content-Language: en Vary: Accept-Encoding,Cookie Last-Modified: Tue, 03 Mar 2009 07:33:38 GMT Content-Encoding: gzip Content-Type: text/html; charset=utf-8 Content-Length: 8685 X-Cacheable: YES Date: Tue, 19 May 2009 13:28:20 GMT Connection: keep-alive X-Served-By: varnish1, r9-8-23 X-Cache: HIT, HIT X-Cache-Hits: 1, 38 X-Age: 904203 Cache-Control: private, s-maxage=0, max-age=0, must-revalidate I thought maybe my ISP was caching this (I am pretty sure they don't, but thought I'd check), so I asked my brother, who is in a different state with a different ISP, and he sees the same thing as I do; only the four pages listed for Category:Omnicomplete. However, when I click on History at the top of the page, and then click on any of the versions listed, the "C++ code completion" page is listed! Note that the URL is http://vim.wikia.com/wiki/Category:Omnicomplete which is where I am taken when I type omnicomplete into the search box just under the Vim logo. The URL for the first version on the history page is http://vim.wikia.com/index.php?title=Category:Omnicomplete&oldid=14555 and if I remove "&oldid=14555", I still get the C++ code completion page. BTW, I do see the Omnicomplete category listed at the bottom of the C++ code completion page, and it wasn't there when I first looked at that page last night. ...Marvin --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Omnicomplete not working
* John Beckett [090518 19:33]: > > Marvin Renich wrote: > > Thanks! That does indeed have that info. I didn't find it > > because I searched for omnicomplete, where it does not show up. > > Are you sure?? I just tried each of the following (typing in the > search box under the Vim logo): > C++ > omni complete > omnicomplete > > Each of the above listed the tip (the search has drastically > improved in the last few months). The only one I had tried previously (when attempting to find this topic) was omnicomplete. It does not list matching pages, it goes directly to the "Category:Omnicomplete" page, which doesn't list "C++ code completion". > > Will someone please add the category omnicomplete to this tip? > > OK I've done it. I've been ignoring categories until we get time > to sort them out (it's really hard categorising Vim features). Does the "Category:Omnicomplete" page need to be updated manually, or does it just take a while to index pages that have newly added categories? This page still (for me) only lists the following four pages: Compile a separate copy of Vim for Python coding Continue omnicompletion for python modules Omni completion Omni completion popup menu Thank you, John, and all the others who have put so much work into making the Vim Wiki such a good reference. ...Marvin --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Omnicomplete not working
* Brett Stahlman [090518 13:31]: > Looks as though someone has already added a tip for configuring C++ > omni completion: > > http://vim.wikia.com/wiki/C%2B%2B_code_completion > > Brett Stahlman Thanks! That does indeed have that info. I didn't find it because I searched for omnicomplete, where it does not show up. Will someone please add the category omnicomplete to this tip? Thanks...Marvin --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Omnicomplete not working
* Brett Stahlman [090518 12:42]: [useful tips snipped] Would you mind putting this on the Vim Tips Wiki? Thanks...Marvin --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: How to ask for input and use it
* Raúl Núñez de Arenas Coronado [090506 10:51]: > Looks like redspider is not an spammer, so this message may be a mistake > on his/her part or a spammer faking the From. Since some text from a > message from Tony is present, I know think that the problem may be a > mistake, a private message going to the list by mistake. > > I've deleted the message but I've NOT banned redspider (who I invite to > contact me or John Beckett if he/she wants). Yes, I thought I had seen redspider post here before, and it was a reply to a current thread, which usually is not spam. That is why I posted. >From bill's translation (thanks, bill!) it looks like a case of replying to the wrong thread. ...Marvin --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: How to ask for input and use it
* redspider red [090506 06:00]: > 今天上班有点忙，只写了2页，见附件，您看看有没有什么问题。 > 几个不确定的地方我在附件的 PDF 中做了标记。 Please be polite and do not send 2.6M attachments to the mailing list. Use a pastebin or send the attachment in private mail to the interested person. Also, this mailing list uses the English language (though sometimes there are interesting OT diversions related to other languages :-) ). If you are having trouble expressing your question in English, but believe someone on the list can understand your native language, at least try to provide an English summary of what you are asking, even if you don't know how to give all the details in English. Thanks...Marvin --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: NERDTree converts local filename to absolute
* James Kanze [090109 20:10]:
>
> On Jan 10, 12:46 am, Tony Mechelynck wrote:
> > You could e.g. use ":set columns+=50" when calling whatever
> > opens the vertically split window, in order to set the GUI
> > screen to 50 columns more than before or to the full width of
> > your monitor, whichever is smaller.
>
> OK. That's useful for other things as well: I think I'll alias
> gvimdiff to "gvimdiff -c 'set columns+=81'", for example. And
> gvimproject becomes something like:
> gvimproject() {
> dir=$1
> shift
> gvim -c 'set columns+=32' -c "NERDTree $dir" $*
> }
In my ~/.vimrc I use:
if has("gui_running")
if &diff
set columns=150
endif
endif
(Adjust to taste.) This avoids an alias, and works when you are using a
different shell than you usually use. It also helps keep Vim settings
in one place.
...Marvin
--~--~-~--~~~---~--~~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Rules for replying to posts on this list
* bill lam [090107 11:31]: > On Wed, 07 Jan 2009, Marvin Renich wrote: > > Inter-posting (or interleaved posting) *is* bottom posting[0]. Bottom > > posting is putting the reply after the text to which you are responding. > > > > I was going to expand on this, but the cited reference does a much > > better job. > > > > ...Marvin > > > > [0] http://mailformat.dan.info/quoting/bottom-posting.html > > Then what is the name for *this* type of posting? This is bottom posting. Interleaved posting is also bottom posting. If you read the reference, Dan acknowledges that the term "bottom posting" is only accurate for this specific type of interleaved posting where there is only one query and one response, but that in practice the term "bottom posting" is used to refer to general interleaved posting as well. This is roughly what I was going to expand on, but felt Dan explains it better. "Pure" bottom posting, where the complete original message, having several distinct points, is quoted at the top, and the multiple, distinct responses are below the entire quoted message, is less useful (with exception to very short messages), than top posting, and experienced usenet posters (alt.* excluded) generally don't do that. ...Marvin --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Rules for replying to posts on this list (Was: Easiest way to insert a blank line?)
* Tom Link [090107 03:29]: > > > > Inter-posting (like this) is even better, but harder, and > > > (I think) will not be enforced. > > > > [...] > > (but I won't try to promote inter-posting). > > IIRC there is a rfc about quoting (maybe it's part of the netiquette) > and "inter-posting" is widely considered good practice. IMHO the > function of a quote is to make clear what you're referring to not to > repeat what has been said. Inter-posting (or interleaved posting) *is* bottom posting[0]. Bottom posting is putting the reply after the text to which you are responding. I was going to expand on this, but the cited reference does a much better job. ...Marvin [0] http://mailformat.dan.info/quoting/bottom-posting.html --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: How to subscribe to vim-dev mailing list?
* John Beckett [090106 04:26]: > > anhnmncb wrote: > >> Some ISPs have very overloaded email systems, and it can be > >> a day or two before mail is actually sent. > > > > Yup, thank you, but my messages sent to vim_use seems have no > > such problem. > > True. OK, I have no idea why your subscription request to vim_dev was > delayed (yet mine, using a test non-gmail account worked in minutes). > > John > Just a heads-up: SpamAssassin has a rule called FROM_LOCAL_NOVOWEL that increases the spam score of a message if the local part of the "From" email address contains a sequence of seven or more non-vowel characters. The default Debian configuration adds 3.19, which is a significant increase. In my configuration, very few legitimate messages to vim_use or vim_dev are marked as "marginal" (SA score between 1 and 5), but all of anhnmncb's messages are in that range because of this test. Some mail servers (including mine) use greylisting; SA-Exim (which I use) only greylists the first message from a recipient, and only if the SA score is high enough. This might (or might not) have anything to do with why your subscription messages were delayed. BTW, the policy for the Vim lists is to use your real name. Is anhnmncb the Romanization of your real name? ...Marvin --~--~-~--~~~---~--~~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
