Re: Choices for Vim9 class implementation
- declaring a class inside a function allows me put related code together
- can be used to simulate a closure function.
example for java:
button.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
AsyncTaskRunner runner = new AsyncTaskRunner();
String sleepTime = time.getText().toString();
runner.execute(sleepTime);
}
});
and python:
def subscript(event_list):
class MyListener(EventListener):
def __init__ (self, id):
self.id = id
def on_enter (self):
# do something
return -1
def on_leave (self):
# done
for event in event_list:
x = MyListener(event)
scheduler.add_listener(x)
在2023年1月13日星期五 UTC+8 04:05:46 写道：
>
> > One more thing about vim9 class:
> >
> > can we define a named or anonymous class inside a function ?
> > That can be used to simulate a closure,
>
> It can be made possible, but the usefulness might be minimal. Perhaps
> you can give an example (possibliy in another language) of what you want
> to do.
>
> The idea of class support is to just implement the basics, what most
> other languages also have. Not adding all kinds of "nice to have"
> features.
>
> > And maybe, someday, we can translate javascript or lua to vim9script
> with
> > this feature.
>
> Javascript is a bit of a weird language, it will be very hard to
> translate into another language, because it has some constructs that
> most other languages don't have.
>
> Anyway, I don't see this as a goal.
>
> --
> I think that you'll agree that engineers are very effective in their social
> interactions. It's the "normal" people who are nuts.
> (Scott Adams - The Dilbert principle)
>
> /// Bram Moolenaar -- br...@moolenaar.net -- http://www.Moolenaar.net \\\
> /// \\\
> \\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
> \\\ help me help AIDS victims -- http://ICCF-Holland.org ///
>
--
--
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/7b3616e4-52bc-49d4-a0cf-aa699c830137n%40googlegroups.com.
Re: Choices for Vim9 class implementation
One more thing about vim9 class: can we define a named or anonymous class inside a function ? That can be used to simulate a closure, And maybe, someday, we can translate javascript or lua to vim9script with this feature. 在2022年12月28日星期三 UTC+8 00:29:24 写道： > > > > > This following currently defines a field and is, without context, > > > > indistinguishable from any other assignment. Is that intended? > > > > > > With "var" it's indistinguishable from another declaration, I don't > > > think it matters much that it looks like an assignment otherwise. > > > > > > > There's only one declaration per class assuming either a qualified name > is > > used in the declaration or normal shadowing rules apply. > > > > So, ignoring subjective aesthetic issues, this would allow for tooling to > > more easily identify the declaration. > > Yes, there are some reasons to declare object members with "var". > It's hard to decide what matters most. Perhaps "making it look like a > declaration" is more important than other reasons. The space taken up > by the extra "var" keyword probably doesn't matter much. > > > > > It seems from the documentation that static fields can be referenced > as > > > > bare identifiers? This feels a bit unexpected to me given that > instance > > > > fields are always qualified. > > > > > > Static fields (class members) are totally different from object > members. > > > I have always found it confusing, in many languages it's hard to tell > > > them apart, especially if the declaration is further away. Always using > > > "this" for object members helps a lot for this. I would not know what > > > to use for class members. The only thing I have seen is using the class > > > name, which can be long (and gets tricky when using inheritance). > > > I believe most languages access class members directly, without a > > > prefix. > > > > I think they're much the same in terms of the problems the required > "this" > > qualifier is attempting to address. Static fields also need > disambiguation > > in shadowed contexts and could, arguably, also use better identification. > > Assigning to a static class member in a constructor is unusual, thus the > common problem that an argument name matches a member name is unlikely > to happen for a class member. We could probably disallow shadowing a > class member. We can at least start with that and see if that doesn't > cause annoyance. > > > Are methods going to need to be qualified too? > > Object methods are always called on an object "obj.method()". > I suppose "this.method()" also works (don't see this very often). > Just using "method()" probably needs to be disallowed. Especially if we > require prefixing "this." for object members. > > > Cards on the table, I'm not in favour of requiring qualified > > references. I just found it surprising that only unqualified instance > > fields were considered a problem. > > That is the reality. All this is much more about what a developer > encounters on a regular basis than theory or philosophy. Especially > when it comes to what mistakes people tend to make and whether it's > possible to give a helpful error for them. Every time I have started > using a new language (usually advertised as being the best ever) I have > run into things that don't work well in practice. > > -- > ARTHUR: Charge! > [They all charge with swords drawn towards the RABBIT. A tremendous twenty > second fight with Peckinpahish shots and borrowing heavily also on the > Kung Fu and karate-type films ensues, in which some four KNIGHTS are > comprehensively killed.] > ARTHUR: Run away! Run away! > "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD > > /// Bram Moolenaar -- br...@moolenaar.net -- http://www.Moolenaar.net \\\ > /// \\\ > \\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ /// > \\\ help me help AIDS victims -- http://ICCF-Holland.org /// > -- -- 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/a650df7d-f737-453d-b774-ba36263a3dfen%40googlegroups.com.
Re: Choices for Vim9 class implementation
Hi Bram, Before everything becomes unchangeable, can I suggest to use "new ClassName" instead of "ClassName.new" to create an instance ? According to the description in `vim9class.txt`: > An object can only be created by a class. A class provides: > - A new() method, the constructor, which returns an object for the class. > This method is invoked on the class name: MyClass.new(). An object can be created by: var pos = TextPosition.new(1, 1) Is it possible to change it to: var pos = new TextPosition(1, 1) this makes me feel more nature/familiar. Since the vim9-class is built from scratch without any backward-compatible problems, why not choose some intuitive grammars ? 在2022年12月20日星期二 UTC+8 17:49:10 写道： > For what it's worth, I feel that the formal "var memberVariable : Type" > syntax for member is (while more verbose) more likely to stand out. The > `var` keyword is a signpost and so is likely to be syntax highlighted. > Simple `memberVariable : Type` doesn't stand out anywhere and contains > mostly identifiers without keywords. > > Additionally, I personally prefer the symmetry with local variables. If > all declarations look the same, then it's one less rule to remember. > > You can then also use const: `const memberVarConstant : Type` maybe? > > On Tuesday, December 20, 2022 at 12:30:50 AM UTC ch...@createng.com wrote: > >> >>> The difference between a regular method and a constructor is that for a >>> constructor it is very common to assign the argument to an object >>> member. >>> >>> The idea comes from Dart, and I don't think Dart supports this for >>> anything but constructors. >>> >> >> That's a good point, it is usually constructors where it get tedious. >> I really appreciate your considered replies. >> Thanks >> >> > -- -- 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/541eca9a-be1e-452c-87a8-6ff1bb4ee839n%40googlegroups.com.
Re: RFC: Support for customizing the text displayed in the quickfix window
Or use one of:
set qbe=*
set qbe=$
set qbe=-
set qbe=?
to distinguish from function names ??
在 2019年12月31日星期二 UTC+8上午2:20:37，skywind3000写道：
>
> Please provide a `raw` reserved option for qfbufexpr, and if it is
> initialized as:
>
> set qbe=raw
>
> Just keep the original text and don't run any filter function ?? for the
> speed purpose. And I don't need to write a
>
> function! ReturnAsItIs(is_qf, qfid, eidx)
> if a:isqf
> let qfl = getqflist({'id' : a:qfid, 'idx' : a:eidx, 'items' :
> 1}).items
> else
> let qfl = getloclist(0, {'id' : a:qfid, 'idx' :
> a:eidx, 'items' : 1}).items
> endif
> let e = qfl[0]
> return e.text
> endfunc
>
> set qbe=ReturnAsItIs
>
> It's totally unnecessary for every one to write such function, and it's
> too slow, so just a
>
> set qbe=raw
>
> can be much helpful.
>
>
--
--
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/729e96f8-92e1-4fed-ad1c-47c5ace9f802%40googlegroups.com.
Re: RFC: Support for customizing the text displayed in the quickfix window
Please provide a `raw` reserved option for qfbufexpr, and if it is
initialized as:
set qbe=raw
Just keep the original text and don't run any filter function ?? for the
speed purpose. And I don't need to write a
function! ReturnAsItIs(is_qf, qfid, eidx)
if a:isqf
let qfl = getqflist({'id' : a:qfid, 'idx' : a:eidx, 'items' :
1}).items
else
let qfl = getloclist(0, {'id' : a:qfid, 'idx' :
a:eidx, 'items' : 1}).items
endif
let e = qfl[0]
return e.text
endfunc
set qbe=ReturnAsItIs
It's totally unnecessary for every one to write such function, and it's too
slow, so just a
set qbe=raw
can be much helpful.
--
--
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/da1c7c43-5055-4694-9bd3-a47e9a21efe9%40googlegroups.com.
Re: So, how about Vim 9?
Great idea, a universal script to locate project.
Emacs has a plugin named `projectile` which is definitely the "universal
script" for emacs,
It has been widely used and many other emacs plugins (helm / ivy / rails /
...) use it to
retrive project location of the current file.
Here I present a simple one, `projectile.vim`:
" root markers used to locate project
if !exists('g:projectile#marker')
let g:projectile#marker = '.svn,.git,.projectile'
endif
" returns nearest parent directory contains one of the markers
function! projectile#find_root(name)
let name = fnamemodify((a:name != '')? a:name : bufname(), ':p')
let finding = ''
" iterate all markers
for marker in split(g:projectile#marker, ',')
if marker != ''
" search as a file
let x = findfile(marker, name . '/;')
let x = (x == '')? '' : fnamemodify(x, ':p:h')
" search as a directory
let y = finddir(marker, name . '/;')
let y = (y == '')? '' : fnamemodify(y, ':p:h:h')
" which one is the nearest directory ?
let z = (strchars(x) > strchars(y))? x : y
" keep the nearest one in finding
let finding = (strchars(z) > strchars(finding))? z : finding
endif
endfor
return (finding == '')? '' : fnamemodify(finding, ':p')
endfunc
" returns nearest parent directory contains one of the markers
" if matching failed, returns the directory containing the file
function! projectile#find_home(name)
let name = fnamemodify((a:name != '')? a:name : bufname(), ':p')
let path = projectile#find_root(name)
if path != ''
return path
else
return isdirectory(name)? name : fnamemodify(name, ':p')
endif
endfunc
Sorry I don't know how to handle `!` in your proposal, but it is simple
enough.
It can be used to perform a project-wide grep:
" project-wide grep
function! projectile#grep(what)
let home = projectile#find_home('') " get the project home of current
file
if home != ''
exec "vimgrep /" . a:what . "/g " . fnameescape(home) . '**/*'
endif
endfunc
or press F9 to return project home:
" goto project home
function! projectile#go_home()
let home = projectile#find_home('')
if home != ''
exec "e " . fnameescape(home)
endif
endfunc
noremap :call projectile#go_home()
here is the gist:
https://gist.github.com/skywind3000/690618557f22de7aaab9aa0226b7edef
For old vim compatibility, if a new plugin using projectile.vim want to
work in
old vims, then can just copy these two function into their own source, not
hard.
Is it simple enough ? Could it be shipped with Vim now ?
在 2019年12月21日星期六 UTC+8上午2:53:24，Gary Johnson写道：
>
> On 2019-12-20, skywind3000 wrote:
> > Obviously, there are project related problems needs to be solved. At
> least we
> > have consensus below:
> >
> > 1. use something which seems to have been established as standard.
> > 2. which is easy to be implemented by plugins with minimal dependency.
> >
> > editorconfig seems like a good choice, but only one thing, there can by
> > multiple `.editorconfig` file
> > in one project.
> >
> > And you need to parse the `.editorconfig` to check if there is a `root =
> true`
> > in it, without actually
> > parsing one `.editorconfig` file, the project tree cannot be located.
> >
> > It is not simple to implemented by plugins without introducing new
> dependency
> > (the `EditorConfig` plugin).
> >
> > So, let's find some alternatives.
> >
> > OK, here is a new one:
> >
> > The vscode's `.vscode` folder
> >
> > 1. it can be used for both locating project tree and storing
> project-specific
> > configs,
> > 2. it is well known and nearly a standard.
> > 3. it is easy to be implement by plugins respectively without any
> dependency
> > and can also run in old vims.
> >
> > how about this ??
>
> Using .vscode would probably work great for users of Visual Studio
> Code. I do almost all my development on Linux, never use Visual
> Studio and had to look up what .vscode was. .vscode is not well
> known by other than VSC users. This is a good example of why and
> how plugins are a good solution for this. VSC users can use
> a plugin that looks for .vscode directories; git users can use
> a plugin that looks for .git directories; etc.
>
> Another consideration is that some of us use Vim for a lot of little
> editing tasks, not just long project editing sessions, and we
> wouldn't want it to spend a lot of start-up time determining
> whether or not it's in a project environment.
>
> On
Re: So, how about Vim 9?
Obviously, there are project related problems needs to be solved. At least we have consensus below: 1. use something which seems to have been established as standard. 2. which is easy to be implemented by plugins with minimal dependency. editorconfig seems like a good choice, but only one thing, there can by multiple `.editorconfig` file in one project. And you need to parse the `.editorconfig` to check if there is a `root = true` in it, without actually parsing one `.editorconfig` file, the project tree cannot be located. It is not simple to implemented by plugins without introducing new dependency (the `EditorConfig` plugin). So, let's find some alternatives. OK, here is a new one: The vscode's `.vscode` folder 1. it can be used for both locating project tree and storing project-specific configs, 2. it is well known and nearly a standard. 3. it is easy to be implement by plugins respectively without any dependency and can also run in old vims. how about this ?? -- 在 2019年12月20日星期五 UTC+8下午8:30:03，Christian Brabandt写道： > > > On Do, 19 Dez 2019, skywind3000 wrote: > > > a `.vim_project` file to mark the project root ? It's fine, but give us > a > > standard, or: > > > > plugin A uses `.vim_project1`, plugin B uses `.vim_root`, plugin C > > uses `.project_root` and plugin C uses `.root`. > > > > And plugin D uses `.git`, and due to submodule, or some other reasons > > > > You will get totally different project roots for the same file. > > > > what a mess ? > > Agree, but I suppose it's not Vim that sets the standard, we should only > support whatever seems to have been established as standard. Perhaps > editorconfig could be used for that (see also the open issue: > https://github.com/vim/vim/issues/2286 > ) > > > Best, > Christian > -- > Als Gott den Mann erschuf, übte sie nur. > -- -- 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/e2afb8ad-38c5-4368-81ed-e236e2e09d55%40googlegroups.com.
Re: So, how about Vim 9?
a `.vim_project` file to mark the project root ? It's fine, but give us a standard, or: plugin A uses `.vim_project1`, plugin B uses `.vim_root`, plugin C uses `.project_root` and plugin C uses `.root`. And plugin D uses `.git`, and due to submodule, or some other reasons You will get totally different project roots for the same file. what a mess ? 在 2019年12月20日星期五 UTC+8上午5:24:09，Gary Johnson写道： > > On 2019-12-19, skywind3000 wrote: > > Please provide a standard way to locate project root directory. > > This is an attractive idea, but there is no standard way to locate > a project root directory. > > I have a plugin that attempts to do this. It has evolved over many > years and contains several different methods for identifying project > root directories. Each company I have worked for has had different > ideas of how project directories should be structured and where they > should be put. For company, open-source and personal projects, some > have VCS files in the project root and some don't. For a project > using git submodules, is a submodule a project or does the top-level > directory contain the project? > > I want to be able to identify a project even if it is not my own > directory and the owner doesn't use vim, so putting a file such as > .vim_project in the root directory is out. Also, I really don't > want dot files cluttering every directory that I consider a project. > (My own plugin uses heuristics and a database of exceptions that > resides under ~/.vim.) > > We can't impose a standard on the world's projects and personal > requirements and preferences vary a lot, so I think this problem is > best solved by using plugins, not by adding something to the Vim > executable. > > Regards, > Gary > > -- -- 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/2166c84d-8834-42d3-844b-ff8e8d5b056f%40googlegroups.com.
Re: So, how about Vim 9?
Please provide a standard way to locate project root directory. Many famous plugins (including: CtrlP, LeaderF, Fzf, YouCompleteMe, Gutentags, ALE) require to identify the project root of current file. And they don't have standard to follow, So, some of plugins take current directory as project root, some of them take the nearest ancestor directory containing .git or .svn as the project root. some of them seek the nearest Makefile / CMakeList.txt ... what a mess ? And most of them have project-wide configurations like: 1. ALE: project-wide linting configurations. 2. YouCompleteMe: ycm_extra_conf.py, used to generate clang compiling flags (include dir, ...) for sources 3. vim-clang: compile_commands.json 4. local_vimrc: _vimrc_local.vim 5. gutentags: gtags / ctags parameter config file. These config files pollute my source tree. and can easily get committed to svn/git by accident. Consider supporting vscode's `.vscode` folder ? it can be used to locate project root (nearest parent dir containing .vscode). And can be used to store many project-wide configs. Or with a different name like `.vim` ?? benefits: 1. all plugins can have a standard to locate project. 2. all plugins can have a place to store project-wide configs. 3. possible for plugins to share information and collaborate together. -- -- 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/e8aedd9a-92ed-4e96-9895-fd5cb21958c5%40googlegroups.com.
Re: popup window design
What about implement both of them and give them two different names ? First, implement the list of lines, the api design( https://github.com/vim/vim/blob/957f85d54ebd5a3bd0d930de9603190f0876f977/runtime/doc/popup.txt) is very simple and clear, it requires less work and can give us something to use after a short time. Then, implement the popup buffer, it requres to modified a lot of existing window/buffer code. and many details have not been decided yet. We have planty of time to consider and implement it in a nice way. But the buffer solution is really similar to neovim's floating window, neovim uses nearly two years to bring it out. So it's no doubt that popup buffer solution will take a long time in the future and many thing may change. So, give plugin authors something to use (like list of lines) at first please. and collect feedback to iterate the popup buffer. -- -- 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/14f04146-9a2f-4562-b1ae-4705038b2c13%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [proposal] Project Information for vim
> ### Modifiers > > ``` > %:j- same as v:projectroot, project root directory of current buffer > %:i- file path relative to current project root > ``` > > These modifiers can be used in command line or passing to `expand(xxx)`. More about modifiers: - cd to the project root: :cd %:j - open netrw in the project root: :Explore %:j - open nerdtree in the project root: :NERDTree %:j -- -- 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: [proposal] Project Information for vim
在 2019年2月22日星期五 UTC+8下午8:32:40，lith写道： > While a basically agree, wrt > > - root directory > > Why not allow many root markers? Since a VCS directory is usually created in > the project's root directory, these VCS directories would be a natural > choice. The autoproject plugin[1] does it this way, and IMHO (but I'm biased > :-)) it works quite well. I think it would be a mistake to require the > existence of some magic marker. The `.vimprj` folder is not only for root locating, but also used for storing project local setting files. Plugins will look into it for project-specific configuration. Storing these files inside a VCS directory will pollute them. That's why vscode use a standalong `.vscode` folder. But if you insist, you can also `set rootmarker=.git` and save configurations in your `.git` folder. > > - file list > > I'm not sure this should be provided by vim. Sooner or later you'd want to > cache this information. Then you'd have to check if the info is still up to > date. I'm not sure if this is within the scope of the standard vim > distribution. In this respect, one could ask whether vim should actually > provide the functionality or just define a standard api that is provided for > by a user-chosen plugin -- i.e. let one plugin provide filelists for > projects. One plugin uses more clever chaching, the other relies on this or > that external tool. > This can be done by a vim script shipped with vim, including: - return the file list. - apis to manipulate the filelist (add/remove with glob). - if `filelist` absents, but the project is inside a git repository, use `git ls-tree` to generate file list. -- -- 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.
[proposal] Project Information for vim
Readable Page:
https://github.com/skywind3000/vim-proposal/blob/master/project_info.md
Markdown plain text:
# Introducing VSCode's workspace mechanism
## Problem
https://github.com/vim/vim/issues/3573#issuecomment-433705924
> It would be great to have a standardized APIs for project-related information
> (e.g. file lists, root directory, VCS type, a way to set project-specific
> buffer-local options / variables etc.). Much of this can be implemented in
> vim plugins but it would be preferable if vim provided a standard way to do
> this.
## Project Information
Vim can introduce a way to provide following information:
- root directory
- file list
- buffer-local options
Plugins can have a place to store project-specific configurations:
- ctags/cscope parameters
- linter parameters
- include folders (c/c++)
- CFLAG / CXXFLAG / LDFLAGS (c/c++)
- actions: command to run, debug etc.
## Goals
- A way to locate project root (use root markers).
- A place for plugins to read project local configurations (like `.vscode`
folder in vscode).
- A standard that plugins can follow even if running in old vims.
- Very simple to implement.
## Solution
Use something like vscode's `.vscode` folder:
```
project1
├── include
├── src
│ ├── module1
│ └── module2
└── .vscode <- located in the project root directory
├── settings.json<- project-specific settings
└── tasks.json <- how to "debug" this project or "build" this
project
```
The `.vscode` folder in vscode is used to store project local settings and it
locates in the project root directory. Every file inside `project1` will use
the settings defined in `.vscode/settings.json`. And the `.vscode` folder can
be used to locate project root for current file.
Similar to `.vscode`, this solution will start by defining a new `.vimprj`
folder (the name is configurable).
### Root marker
Introduce a new option `rootmarker` for locating project root of current file,
it defaults to `.vimprj` and can be set:
```VimL
set rootmarker=.vimprj
set rootmarker=.vscode
set rootmarker=.git
set rootmarker=.project
```
By default, there will be an `.vimprj` folder (can be renamed by `set
rootmarker=xxx`) in your project root directory. Like vscode use a `.vscode`
folder in every project root to store workspace settings. Plugins can put their
project related configuration file in the `.vimprj` folder.
### Locating project root
The project root of current file is the nearest parent directory with a folder
named `.vimprj` (can be changed by set rootmarker=xxx) in it.
A buffer-specific variable `v:project` is used to store the project root
directory of current buffer, it is initialized when you open a file as:
```VimL
let v:projectroot = fnamemodify(find(, '.;'), ':h')
```
If `.vimprj` can not be found in the parent directories, an empty string will
be used. For files already opened by vim, `v:projectroot` can be updated when
you close the file and open again.
**Plugins can use the same algorithm to calculate project root directory even
if running in old vims.**
### Modifiers
```
%:j- same as v:projectroot, project root directory of current buffer
%:i- file path relative to current project root
```
These modifiers can be used in command line or passing to `expand(xxx)`.
### Buffer local settings
Like `.vscode/settings.json` in vscode, if there is a `settings.json` file
located in `.vimprj` folder, it will be loaded when you open a file in this
project:
```json
{
"shiftwidth": 2,
"tabstop": 2,
"expandtab": false
}
```
Each key/value pair in `settings.json` will be initialized as a buffer local
setting.
**Alternative way** for this is to create a `local.vim` in the `.vimprj` folder
and it will be sourced in `sandbox` for every file in the project.
This can be done by a vimscript shipped with vim (like matchit.vim).
### Old vim compatibility
Plugins running in old vims can calculate project root themself:
```VimL
if !exists('g:rootmarker')
let g:rootmarker = exists('+rootmarker')? : ".vimprj"
endif
if !exists('v:projectroot')
let b:_project_root = fnamemodify(find(g:rootmarker, '.;'), ':h')
else
let b:_project_root = v:projectroot
endif
```
With this standard, even if running in old vims, plugin can get the project
root directory of current file.
### File list
There can be a `.vimprj/filelist` file to describe the filelist in this project:
```
inc/interface.h
src/hello.c
src/world.c
src/module/xp.c
```
This file is optional, if it doesn't exist, all files inside root directory
will be considered as project files.
If a plugin need generate ctags database for current project or need grep
symbol in current project, the filelist can be used for that.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the t
Re: How about a release?
>From terminal.c: * - add an optional limit for the scrollback size. When reaching it remove * 10% at the start. Could it be possible before 8.1 ?? At least I can monitor log files while editing, just like running 'tail -f' for hours in all other terminals. 在 2018年3月13日星期二 UTC+8下午12:04:52，skywind3000写道： > One thing important for terminal: open file directly in the terminal > > Presume the shell in the vim's terminal and vim itself are always under the > different working directory. It is quite in-productive to switch to > terminal-normal mode and use vim's command to find and open a file. > > Emacs can open a file from eshell: > > ~ $ ls > myfile > ~ $ (find-file "myfile") > > +clientserver is not always supported. > > This case has been discussed in reddit and can't find a better solution. > > https://www.reddit.com/r/vim/comments/83ve6g/how_to_open_file_in_current_vim_instance_from/ > > You will find it is obviously an important feature when you actually used the > builtin terminal for 3 days. > > Expecting a nice solution before vim 8.1 -- -- 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: How about a release?
One thing important for terminal: open file directly in the terminal Presume the shell in the vim's terminal and vim itself are always under the different working directory. It is quite in-productive to switch to terminal-normal mode and use vim's command to find and open a file. Emacs can open a file from eshell: ~ $ ls myfile ~ $ (find-file "myfile") +clientserver is not always supported. This case has been discussed in reddit and can't find a better solution. https://www.reddit.com/r/vim/comments/83ve6g/how_to_open_file_in_current_vim_instance_from/ You will find it is obviously an important feature when you actually used the builtin terminal for 3 days. Expecting a nice solution before vim 8.1 -- -- 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 8.0.1570
I know what you want, this plugin: http://vimuiex.sourceforge.net/ The plugin uses python + curses library in terminal to provide ui extension, but requires a patch for gvim. If you use terminal vim only, it doesn't require any modification. -- -- 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 8.0.1558
+1 for ":popup PopUp" and ":popup ]something" -- -- 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: RFC: Signature help/argument hints in a second popup menu
+1 +1 -- -- 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 8.0.0695
"E319: Sorry, the command is not available in this version" -- -- 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: Adding terminal emulator support in Vim
Another possible choise: http://www.dotnetsurfers.com/blog/2013/12/15/developer-tools-screencast-7-conemu/ -- -- 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 8.0.0626
It would be very nice if we can get rid of other flicker in gvim (eg.
scrolling).
I have tried twice to implement a double buffer for gvim. but failed.
MacVim will not flicker and nvim-qt will not flicker too,
Is it possible to have a non-flicker gvim ? since it's 2017 now.
Erasing and drawing directly on the screen without a back buffer
is something as old as windows 95.
在 2017年6月6日星期二 UTC+8上午1:32:57，Bram Moolenaar写道：
> Patch 8.0.0626
> Problem:In the GUI the cursor may flicker.
> Solution: Check the cmd_silent flag before updating the cursor shape.
> (Hirohito Higashi, closes #1637)
> Files: src/getchar.c
>
>
> *** ../vim-8.0.0625/src/getchar.c 2017-04-08 18:41:07.339941299 +0200
> --- src/getchar.c 2017-06-05 19:28:16.696484466 +0200
> ***
> *** 2913,2920
> }
> #ifdef FEAT_GUI
> /* may unshow different cursor shape */
> ! if (gui.in_use && shape_changed)
> ! gui_update_cursor(TRUE, FALSE);
> #endif
>
> --vgetc_busy;
> --- 2913,2928
> }
> #ifdef FEAT_GUI
> /* may unshow different cursor shape */
> ! if (gui.in_use)
> ! {
> ! if (cmd_silent)
> ! gui_dont_update_cursor(TRUE);
> ! else
> ! gui_can_update_cursor();
> !
> ! if (shape_changed)
> ! gui_update_cursor(TRUE, FALSE);
> ! }
> #endif
>
> --vgetc_busy;
> *** ../vim-8.0.0625/src/version.c 2017-06-05 18:46:20.497845949 +0200
> --- src/version.c 2017-06-05 19:06:06.449739127 +0200
> ***
> *** 766,767
> --- 766,769
> { /* Add new patch number below this line */
> + /**/
> + 626,
> /**/
>
> --
> "How is your new girlfriend?"
> "90-60-90 man!"
> "What, pale purple?"
>
> /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
> ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
> \\\ an exciting new programming language -- http://www.Zimbu.org///
> \\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
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: Asynchronous balloonexpr handling
在 2017年2月2日星期四 UTC+8下午6:14:37，Davit Samvelyan写道： > Take a look to my fork https://github.com/davits/vim you may find it useful > in your endeavors. > It introduces several function to show balloons at need (works only with gtk): > overlayshow(row, col, [list of items], is_pango_markup) > overlaynext() > overlayprev() > overlayclose() > > Here is a small demo > https://files.gitter.im/Valloric/ycmd/l1M8/popup-overlay.gif this is very impressive !! -- -- 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.
Ask for help about implementing double buffer in gui_win32.c
Recently, I am trying to implement a double buffer for gui_win32.c by: 1. rename s_hdc to s_hdc_real 2. creat a off-screen HDC named s_hdc, all the drawing from gui_win32.c should be redirected to it. 3. BitBlt from s_hdc to s_hdc_real after WndProc, the screen should be updated. It works in most of time, but when I press CTRL+D to scroll down half a screen I find only the bottom half of TextArea has been updated, the top half hasn't been updated yet, there are still old characters before CTRL+D on the top half. I search all the reference of s_hdc and s_textArea but can not find any clue. Can anybody figure out what's wrong here ? -- -- 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.
Can I write a patch for gui_win32.c to get rid of flicker in gvim like these ?
Use gvimevery day, and love it as well. The only thing I can't stand is the flicker. Recently, I am reading the source code of gvim.exe, and realize that the flicker could be eliminated by introducing a double-buffer + dirty-rectangle mechanism: 1. s_dc is initialized by GetDC(s_textArea), change it to an off-screen hdc (the memory buffer). and create another HDC named s_dc_real just like the old s_dc. So every drawing stuff will be redirected to the off-screen HDC (clear, mch_draw_string) without changing the code in many places. 2. divide the screen (text area) into grids, each cell contains 32x16 characters. They will be marked as "dirty" if updating happens inside the cell boundary. 3. At the end of _WndProc, flush the dirty cells to the s_dc_real by BitBlt. 4. Make an option in "guioptions" to enable these "dirty-rectangle". I suppose drawing can only be triggered after a win32 event: WM_TIMER / WM_KEY_PRESS, the right place to flush dirty rectangles is the end of _WndProc. Am I right ? What do you think if you are familiar with gui_win32 ? -- -- 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] Is it possible that vim support php like Python? (#1172)
Rick Woo wrote： > I personally don't think it is worthwile to have yet another language > embedded into Vim. > > Then why put lua, perl, python 2 and 3 and tcl in Vim. > Why phper can't have right or fun like them??? > As I know, even Vim website use php. > Just let php can use like python in vim. > > Phper is very big community, is good for vim and phper. > Hope you can do this for phper! Thanks! > As a java developer, can I ask why java can't use like python in vim ? Javaer is the biggest community, is good for vim and javaer. As a c# developer, can I ask why c# can't use like python in vim ? CSharper is the 6th biggest community (TIOBE), is good for vim and csharper. . If every body ask to support their favorite language in vim, the code size will bloat and soon will be out of control. Introducing a new feature is cheaper than maintaining it. Would you please just learn some VimScript ? It is very similar to php. If you want to extend your vim, spending 2-3 days in vimscript is worthy and enough. Why we need python here ? Python is a general purpose language which has countless modules/packages. Most of time, we don't need write a DLL/so in C++ like the old days. Now we can use python to achieve same thing, like calling foreign languages/DLLs, threading, networking, databases . Why we need lua here ? Lua got a flexible syntax, can use less code to do the samething than vimscript and run faster than python and vimscript, most important thing it is very tiny. What benefit can vim get if we embed another new language right now ? except making some people who don't want to study new things happy ? I don't write much python code too, I am not a python developer either. But when I need to extend my vim, I can study python and vimscript as well. Even if vim support php, nobody can use only php to write plugin without fully understand vimscript. -- -- 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] netrw bug: If toggle banner (hit 'I') is done when the cursor is on the line "Showing/Hiding", the "normal/hiding/show" status is also toggled. (#1333)
cecamp wrote： > Please try v162h of netrw which I believe fixes this. You can get it from > http://www.drchip.org/astronaut/vim/index.html#NETRW. Thank you for > reporting this. > I love netrw more and more after reading this: http://vimcasts.org/blog/2013/01/oil-and-vinegar-split-windows-and-project-drawer/ @Bram, could you please update the built-in netrw to the latest version ? many bugs have been fixed. -- -- 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 8.0.0105
Bram Moolenaar wrote：
> Skywind wrote:
>
> > Bram Moolenaar wrote：
> >
> > > You can improve this a lot by changing:
> > >
> > >if ch_canread(ch)
> > > let text = ch_read(ch, {'timeout':0})
> > > caddexpr text
> > > cbottom
> > > endif
> > >
> > > To:
> > >
> > >if ch_canread(ch)
> > > while ch_canread(ch)
> > > let text = ch_read(ch, {'timeout':0})
> > > caddexpr text
> > > endwhile
> > > cbottom
> > > endif
> >
> > Yes, I intentionally do so to make reading really slower than writing.
> >
> > > But, you might still miss some messages if the job exits early.
> > >
> > > I suppose we will need to add an option to tell Vim that you will read
> > > the messages, not using a callback. I think this should do it:
> > >
> > > "drop"Specifies when to drop messages:
> > > "auto" When there is no callback to handle a message.
> > > The "close_cb" is also considered for this.
> > > "never" All messages will be kept.
> > >
> >
> > It's very nice if I can have the "drop" option in job_start !
>
> Should work with patch 8.0.0107. Took a bit of debugging to figure out
> why the channel was reported as being closed. I thought messages were
> being dropped somewhere, but it turned out to be a problem with
> ch_canread().
>
Finally, thanks very much :D
--
--
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 8.0.0105
Bram Moolenaar wrote：
> You can improve this a lot by changing:
>
>if ch_canread(ch)
> let text = ch_read(ch, {'timeout':0})
> caddexpr text
> cbottom
> endif
>
> To:
>
>if ch_canread(ch)
> while ch_canread(ch)
> let text = ch_read(ch, {'timeout':0})
> caddexpr text
> endwhile
> cbottom
> endif
Yes, I intentionally do so to make reading really slower than writing.
> But, you might still miss some messages if the job exits early.
>
> I suppose we will need to add an option to tell Vim that you will read
> the messages, not using a callback. I think this should do it:
>
> "drop"Specifies when to drop messages:
> "auto" When there is no callback to handle a message.
> The "close_cb" is also considered for this.
> "never" All messages will be kept.
>
It's very nice if I can have the "drop" option in job_start !
--
--
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 8.0.0105
Bram Moolenaar wrote： > When writing the test I also had problems with messages being dropped. > I thought that adding a close callback should fix it, but perhaps there > is another situation where they are still dropped. > > Can you enable the channel log and see where the messages are dropped? > I reduced loop times in timerjob.py from 8 to 100 times The full file is still too long, I have uploaded it on gist: https://gist.github.com/skywind3000/3a2f6016240e33e97587e1181563b163 Here is an abbreviated version: start log session 14.983871 : Starting job: /usr/bin/python timerjob.py 14.983992 on 0: Created channel 15.006013 : looking for messages on channels 15.013262 RECV on 0: 'timer job: this is line 0 timer job: this is line 1 timer job: this is line 2 timer job: this is line 3 timer job: this is line 4 timer job: this is line 5 ' 15.013299 RECV on 0: 'timer job: this is line 6 timer job: this is line 7 timer job: this is line 8 ' 15.013314 RECV on 0: 'timer job: this is line 9 timer job: this is line 10 ' () 15.014157 RECV on 0: 'timer job: this is line 142 timer job: this is line 143 ' 15.014168 RECV on 0: 'timer job: this is line 144 timer job: this is line 145 ' 15.014253 on 0: Blocking NL read, timeout: 0 msec 15.014271 on 0: Returning 25 bytes 15.014401 RECV on 0: 'timer job: this is line 146 timer job: this is line 147 timer job: this is line 148 timer job: this is line 149 () timer job: this is line 176 timer job: this is line 177 timer job: this is line 178 timer job: this is line 179 timer job: this is line 180 ' 15.014903 RECV on 0: 'timer job: this is line 181 timer job: this is line 182 timer job: this is line 183 timer job: this is line 184 timer job: this is line 185 timer job: this is line 186 timer job: this is line 187 timer job: this is line 188 timer job: this is line 189 timer job: this is line 190 timer job: this is line 191 timer job: this is line 192 timer job: this is line 193 timer job: this is line 194 timer job: this is line 195 timer job: this is line 196 timer job: this is line 197 timer job: this is line 198 timer job: this is line 199 ' 15.027015 : looking for messages on channels 15.027154 on 0: Blocking NL read, timeout: 0 msec 15.027171 on 0: Returning 25 bytes 15.039816 : looking for messages on channels 15.039939 on 0: Blocking NL read, timeout: 0 msec 15.039956 on 0: Returning 25 bytes 15.052561 : looking for messages on channels 15.052716 on 0: Blocking NL read, timeout: 0 msec 15.052733 on 0: Returning 25 bytes () 15.974655 : looking for messages on channels 15.974805 on 0: Blocking NL read, timeout: 0 msec 15.974822 on 0: Returning 26 bytes 15.987733 : looking for messages on channels 15.987887 on 0: Blocking NL read, timeout: 0 msec 15.987904 on 0: Returning 26 bytes 16.000733 : looking for messages on channels 16.000856 on 0: Blocking NL read, timeout: 0 msec 16.000873 on 0: Returning 26 bytes 16.013597 : looking for messages on channels 16.013730 on 0: Blocking NL read, timeout: 0 msec 16.013746 on 0: Returning 26 bytes 16.018591 RECV on 0: '[done in 0 seconds] ' 16.018602 : looking for messages on channels 16.019356 on 0: channel_select_check(): Read EOF from ch_part[1], closing 16.019387 : looking for messages on channels 16.019399 on 0: Closing channel because all readable fds are closed 16.019409 on 0: Closing channel 16.019425 on 0: Invoking callbacks before closing 16.019438 on 0: Invoking close callback MyClose 16.022167 on 0: Dropping message 'timer job: this is line 78 timer job: this is line 79 ' 16.022207 on 0: Dropping message 'timer job: this is line 80 timer job: this is line 81 ' 16.00 on 0: Dropping message 'timer job: this is line 82 ' 16.022231 on 0: Dropping message 'timer job: this is line 83 timer job: this is line 84 ' 16.022241 on 0: Dropping message 'timer job: this is line 85 timer job: this is line 86 ' 16.022252 on 0: Dropping message 'timer job: this is line 87 timer job: this is line 88 ' 16.022263 on 0: Dropping message 'timer job: this is line 89 timer job: this is line 90 ' 16.022273 on 0: Dropping message 'timer job: this is line 91 timer job: this is line 92 ' 16.022299 on 0: Dropping message 'timer job: this is line 93 timer job: this is line 94 ' 16.022311 on 0: Dropping message 'timer job: this is line 95 timer job: this is line 96 ' 16.022321 on 0: Dropping message 'timer job: this is line 97 ' 16.022332 on 0: Dropping message 'timer job: this is line 98 timer job: this is line 99 ' 16.022342 on 0: Dropping message 'timer job: this is line 100 timer job: this is line 101 ' 16.022352 on 0: Dropping message 'timer job: this is line 102 timer job: this is line 103 ' 16.022362 on 0: Dropping message 'timer job: this is line 104 timer job: this is line 105 timer job: this is line 106 timer job: this is
Re: Patch 8.0.0105
Kazunobu Kuriyama wrote：
> Looks you are trying to simplify the issue too much.
>
> Your argument looks good for utilities such as grep, tail, cut and so on.
>
> However, Vim (or any other programs having UI which is driven by events) is
> different from them in that, while Vim is made busy to handle a deluge of
> input from an external program, it also has to ask the terminal or the GUI to
> update its contents simultaneously (in appearance, at least).
>
>
> Actually, the event loop cannot handle the both tasks simultaneously; it
> tries to do only one thing when select() or poll() is called, and it can
> execute a thing only after it makes sure another is staying idle at that
> time. IOW, an illusion that both external input handling and UI update
> appear to happen simultaneously is made possible only if both of them can
> stay idle alternatively.
>
>
> The GUI will be locked if it is not given a chance to run the event loop for
> its own sake.
>
>
> The third element UI makes your issue very tough, and that issue itself is
> inherently difficult; while the user is asking an external program to do its
> job asynchronously, he is also asking Vim to show the result as if they were
> working synchronously, using the UI which inherently works asynchronously. A
> awful set of simultaneous equations.
>
>
> That said, I never mean that any effort done here so far doesn't make sense.
> Actually, I already enjoy the fruit; as far as the examples skywind3000
> raised (except the one after 8.0.105) are concerned, the issue appears to be
> fixed for me.
>
>
> --
>
> --
>
> 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+u...@googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.
Thanks for your reply,
You mean I spoke too much on the same topic ?
I think I know what a event-loop is, I wrote a lot of gui programs
with win32 and qt before.
This is not as complex as you said before, for example: EditPlus/GEdit can get
background jobs working correctly.
Last week when I was trying to get grep working with vim's job system. It just
worked, but wasn't so perfect.
Vim got freezed when grep trying to output a lot of messages in a short time
(this can be reproduced by running grep in your document root with a very
simple word). Channel callback consumes too much time.
I was curious that what will happen if I run the same grep command in other
editors like EditPlus or GEdit.
Switching to EditPlus and setting grep as an "User Tool" in EditPlus, I found
EditPlus never got freezed, it just slow down the speed of grep.
So I am trying to solve it by introducing a flow control like mechanism:
invoking ch_read(..., {"timeout":0}) fixed times in a timer. If vim doesn't
read as faster as the child process, child should block when system pipe is
full.
Child process could be slow down and Vim can run as smooth as usual.
After digging a lot in the channel.txt, I suppose a channel (without callbacks)
can work as a traditional non-blocking socket. Just like other runtime
libraries of many programming language.
It's much simply then the callback implementation. We don't even need to put
these fds into the fd-set of select/poll if a channel is created without
callbacks.
Everything is fine if the channel (without callbacks) can just work like a
nonblocking socket. (that is it has a nonblocking "read" function and can
returns some messages or tells me EAGAIN/EWOULDBLOCK).
Thanks to Bram, we have job/channel system now and sure it is awesome. And I am
thinking these asychronous apis will be used in the next decade or even longer.
Great plugins will be born under the advantage of them.
If we can get grep to work perfectly with vim today. We can expect many
gorgeous plugins tomorrow.
--
--
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 8.0.0105
skywind3000 wrote:
> we can see:
>
> 1. there is a "sleep" in the parent process, parent works slower than child.
>
> 2. calling "write" block the child process successfully when pipe is full
> (4096 bytes on linux by default). The child process does not exit immediately.
>
> 3. 10 seconds later after child process exist, we can still read messages
> from the parent process.
>
> This is exactly the right behavior of inter-processes communication.
>
> Since we can't add a sleep in grep, tail, less, more, cut. and we don't
> know how long should we sleep either.
>
> How can we prevent message dropping when we are using ch_read ?
I can reproduce it with popen in python:
--
parent.py
--
import sys, os, time
fp = os.popen('python child.py', 'r')
while 1:
text = fp.readline()
if text == '':
break
print text.rstrip()
sys.stdout.flush()
time.sleep(0.001)
child.py
#! /usr/bin/env python2
import sys, time
t = time.time()
for i in xrange(2):
sys.stdout.write('timer job: this is line %d\n'%(i))
sys.stdout.flush()
t = time.time() - t
print '[done in %d seconds]'%int(t)
# as channel.txt said, we need a sleep here
time.sleep(1)
reproduce
$ python parent.py
timer job: this is line 0
timer job: this is line 1
timer job: this is line 2
.
timer job: this is line 19996
timer job: this is line 19997
timer job: this is line 19998
timer job: this is line 1
[done in 21 seconds]
-
1. there is a sleep in parent.py, parent works slower than child too.
2. the child.py can be blocked successfully by parent.py
3. no sleep in child.py
4. no message dropped.
it behaves the same way just like the c version in my previous post.
--
--
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 8.0.0105
skywind3000 wrote:
> I can sleep longer in timerjob.py, but I can't add a single sleep if I start
> grep as a job. And I can't decide how long should I sleep to avoid dropping.
latest channel.txt said:
Note that if the job exits before you read the output, the output may be lost.
This depends on the system (on Unix this happens because closing the write end
of a pipe causes the read end to get EOF). To avoid this make the job sleep
for a short while before it exits.
It is strange if a sleep is required in every command line utility, half of
shell commands (with pipe) we used every day may break down.
I wrote another test to verify this issue:
the child process is repeating calling write
the parent process is repeating calling read & sleep
child process exits quickly, but we don't have any message dropped
pipesleep.c
#include
#include
#include
#include
#include
#include
#define READ 0
#define WRITE 1
int main(void)
{
int fd[2], pid;
if (pipe(fd) < 0) {
perror("pipe");
exit(1);
}
if ((pid = fork()) == -1) {
perror("fork");
exit(1);
}
if (pid == 0) { // child
char text[100];
int i;
close(fd[READ]);
for (i = 0; i < 2000; i++) {
sprintf(text, "this is very loonnng line
%d\n", i);
write(fd[WRITE], text, strlen(text));
}
fprintf(stderr, "[child exit here]\n");
fflush(stderr);
}
else { // parent
char text[100];
int i;
close(fd[WRITE]);
for (i = 0; i < 1; i++) {
int hr = read(fd[READ], text, 100);
if (hr <= 0) {
printf("\n[done, errno is %d]\n", errno);
break;
}
else {
text[hr] = 0;
printf("%s", text);
fflush(stdout);
}
usleep(10 * 1000);
}
}
return 0;
}
output of pipesleep.c
this is very loonnng line 0
this is very loonnng line 1
this is very loonnng line 2
this is very loonnng line 3
this is very loonnng line 4
this is very loonnng line 5
this is very loonnng line 6
this is very loonnng line 7
this is very loonnng line 8
..
this is very loonnng line 829
[child exit here]
this is very loonnng line 830
this is very loonnng line 831
..
this is very loonnng line 1997
this is very loonnng line 1998
this is very loonnng line 1999
[done, errno is 0]
we can see:
1. there is a "sleep" in the parent process, parent works slower than child.
2. calling "write" block the child process successfully when pipe is full (4096
bytes on linux by default). The child process does not exit immediately.
3. 10 seconds later after child process exist, we can still read messages from
the parent process.
This is exactly the right behavior of inter-processes communication.
Since we can't add a sleep in grep, tail, less, more, cut. and we don't
know how long should we sleep either.
How can we prevent message dropping when we are using ch_read ?
--
--
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 8.0.0105
Bram Moolenaar wrote：
> Patch 8.0.0105
> Problem:When using ch_read() with zero timeout, can't tell the difference
> between reading an empty line and nothing available.
> Solution: Add ch_canread().
> Files: src/evalfunc.c, src/channel.c, src/proto/channel.pro,
> src/testdir/test_channel.vim, src/testdir/shared.vim,
> runtime/doc/eval.txt, runtime/doc/channel.txt
This is fabulous, thanks for ch_canread()
However, a lot of messages are still dropped in spite of adding a sleep before
exiting:
-
timerjob.vim
-
function! MyTimer(id)
let ch = job_getchannel(g:job)
let st = ch_status(ch)
if st == "fail" || st == "closed"
return
endif
if ch_canread(ch)
let text = ch_read(ch, {'timeout':0})
caddexpr text
cbottom
endif
endfunc
" according to channel.txt, add a close callback
function! MyClose(channel)
caddexpr "[channel closed]"
cbottom
endfunc
copen 8
cexpr "[python output]"
wincmd k
let cmd = ['/usr/bin/python', 'timerjob.py']
let opt = {"out_io": "pipe", "err_io": "out", "close_cb": "MyClose"}
let job = job_start(cmd, opt)
let timer = timer_start(10, "MyTimer", {"repeat":-1})
-
timerjob.py
-
#! /usr/bin/env python2
import sys, time
for i in xrange(8):
sys.stdout.write('timer job: this is line %d\n'%(i))
sys.stdout.flush()
# as channel.txt said, we need a sleep here
time.sleep(1)
-
output in quickfix
-
|| [python output]
|| timer job: this is line 0
|| timer job: this is line 1
|| timer job: this is line 2
|| timer job: this is line 3
|| timer job: this is line 4
|| timer job: this is line 5
.
|| timer job: this is line 57
|| timer job: this is line 58
|| timer job: this is line 59
|| timer job: this is line 60
|| timer job: this is line 61
|| [channel closed]
Only 62 messages have been received, almost 8 - 62 = 79938 messages have
been dropped.
I can sleep longer in timerjob.py, but I can't add a single sleep if I start
grep as a job. And I can't decide how long should I sleep to avoid dropping.
--
--
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: "ch_read()" couldn't tell the difference between "not enough message" and "a empty line"
skywind3000 wrote： > Bram Moolenaar wrote: > > > Skywind wrote: > > > > > Bram Moolenaar wrote： > > > > > This will not break the plugins, and will make ch_read better. > > > > > It could be used in a timer for congestion control manually. > > > > > > > > That changes what you get back, that is a bit strange. > > > > How about adding a function that returns whether there is something to > > > > read? Could call it ch_canread(). > > > > > > > > > > I think "ch_canread()" is a nice design ! > > > > Please try out patch 8.0.0103, it should no longer get stuck. > > > > After trying 8.0.0103 several times on windows/mac/debian(via ssh), > I believe stuck issue is fixed. > > however, cpu usage is still high with this test (exceeds 92%), and I can feel > the lag between a keystroke and screen update, especially through a ssh > terminal. > > At first I suppose my network bandwidth is fully filled with UI/quickfix > update messages. After removing the ":cbottom" lines, I find vim is still > very busy (cpu usage exceeds 90%) even if UI is not updated in the job > callback. -- I just tried "ch_read()" in a 10Hz timer without any callback (both "callback", "out_cb" and "err_cb" is unset) and :caddexpr what I readed from ch_read() to quickfix. I got these on quickfix window: --- || [python output] benchjob|8328| this is line 8328 benchjob|19927| this is line 19927 benchjob|31094| this is line 31094 benchjob|42038| this is line 42038 benchjob|53045| this is line 53045 benchjob|64103| this is line 64103 benchjob|75220| this is line 75220 It appears many data have been missed when I am calling ch_read. I suppose I can read all the data, one by one from ch_read if I don't set the callbacks. -- -- 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: "ch_read()" couldn't tell the difference between "not enough message" and "a empty line"
Bram Moolenaar wrote: > Skywind wrote: > > > Bram Moolenaar wrote： > > > > This will not break the plugins, and will make ch_read better. > > > > It could be used in a timer for congestion control manually. > > > > > > That changes what you get back, that is a bit strange. > > > How about adding a function that returns whether there is something to > > > read? Could call it ch_canread(). > > > > > > > I think "ch_canread()" is a nice design ! > > Please try out patch 8.0.0103, it should no longer get stuck. > After trying 8.0.0103 several times on windows/mac/debian(via ssh), I believe stuck issue is fixed. however, cpu usage is still high with this test (exceeds 92%), and I can feel the lag between a keystroke and screen update, especially through a ssh terminal. At first I suppose my network bandwidth is fully filled with UI/quickfix update messages. After removing the ":cbottom" lines, I find vim is still very busy (cpu usage exceeds 90%) even if UI is not updated in the job callback. -- -- 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: "ch_read()" couldn't tell the difference between "not enough message" and "a empty line"
Bram Moolenaar wrote： > > This will not break the plugins, and will make ch_read better. > > It could be used in a timer for congestion control manually. > > That changes what you get back, that is a bit strange. > How about adding a function that returns whether there is something to > read? Could call it ch_canread(). > I think "ch_canread()" is a nice design ! -- -- 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: "ch_read()" couldn't tell the difference between "not enough message" and "a empty line"
What about provide an option "nl" in ch_read to make it better ?
:call ch_read(mych, {"timeout": 0, "nl":1})
returns "abc\n" for a line "abc"
returns "\n" for an empty line
returns "" for not enough data
This will not break the plugins, and will make ch_read better.
It could be used in a timer for congestion control manually.
--
--
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: "ch_read()" couldn't tell the difference between "not enough message" and "a empty line"
Thanks for the patch,
I wrote a test :
(benchjob.vim for starting job, benchjob.py for printing 8 lines)
---
benchjob.vim:
function! MyCallback(job, text)
" make cpu a little busy
for i in range(100)
for j in range(10)
cbottom
endfor
endfor
let text = iconv(a:text, "gbk", )
caddexpr a:text
cbottom
endfunc
copen 8
cexpr "[python output]"
wincmd k
let cmd = ['/usr/bin/python', 'benchjob.py']
let opt = {"out_cb": "MyCallback", "out_io": "pipe", "err_io": "out"}
let job = job_start(cmd, opt)
--
benchjob.py:
#! /usr/bin/env python2
import sys
for i in xrange(8):
sys.stdout.write('benchjob:%s: this is line %d\n'%(i, i))
sys.stdout.flush()
I can move cursor with the latest version (8.0.101), gui doesn't freeze as the
older versions. But I also find some issues:
1. Although I can move cursor while benchjob.py is running, but I nearly can't
input any thing, when I type a single character in insert mode, I can see the
character appears in the screen, cursor moves right and then cursor rewinds to
the head of the line, and then redraw the whole line. (delete the whole line at
first, then display them again). It seems gui is very busy, especially
accessing a remote vim from terminal.
2. After a while, the output in quickfix stopped (benchjob.py isn't finished
yet), until I move cursor or type something in vim, and it resumes and updates
a few lines in quickfix and stops again until I type something again. If I
don't touch my keyboard, the the output will pause forever.
--
--
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: "ch_read()" couldn't tell the difference between "not enough message" and "a empty line"
skywind3000 wrote： > The callback of "out_cb" is convenience to use, but has performance issue: > Gui gets freezed if the background job continues outputing massive data (eg, > grep a high frequency word "to" on the documents root, or some crazy stl > errors). > > Vim is busy in receiving the data and invoking "out_cb" which cause gui no > responsed for a very noticeable period. > > The practice way to prevent gui freeze is introducing a flow control for > background process by reading the fixed number of lines from the channel on a > timer (eg, read 50 lines from stdout each 100ms interval). > > If the grep output is faster then the reader in the timer, system pipe will > be full and "invoking write()" will block the child process until the system > pipe buffer has free space again (some data have been readed out by vim). > > In order to process the job output more smoothly, I tried to use this > approach but when I am ready to read data from the channel in a timer, It is > confused that both "\n" (empty line) and "not enough data" return "" from > ch_read(). > > If I want to read out at most 100 lines from a channel in an interval, how > can I tell if there is no data at the moment or it's just a "\n" from child > process ? > > No clue to decide whether to continue reading or just break out. > > When I am using "(pipe object).readline()" from python's subprocess module, > "abc\n" means a line "abc", "\n" means an empty line and "" means not enough > data. It's very simple without any ambiguity. > > But when I am using "ch_read()" in vim. "abc" means a line "abc", and both > (empty line) and (no message) return "". > > Is it a "logic fallacy" of "ch_read()" ?? btw, the "ch_read()" referenced before is invoked with "timeout=0" in "NL" mode. -- -- 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.
"ch_read()" couldn't tell the difference between "not enough message" and "a empty line"
The callback of "out_cb" is convenience to use, but has performance issue: Gui gets freezed if the background job continues outputing massive data (eg, grep a high frequency word "to" on the documents root, or some crazy stl errors). Vim is busy in receiving the data and invoking "out_cb" which cause gui no responsed for a very noticeable period. The practice way to prevent gui freeze is introducing a flow control for background process by reading the fixed number of lines from the channel on a timer (eg, read 50 lines from stdout each 100ms interval). If the grep output is faster then the reader in the timer, system pipe will be full and "invoking write()" will block the child process until the system pipe buffer has free space again (some data have been readed out by vim). In order to process the job output more smoothly, I tried to use this approach but when I am ready to read data from the channel in a timer, It is confused that both "\n" (empty line) and "not enough data" return "" from ch_read(). If I want to read out at most 100 lines from a channel in an interval, how can I tell if there is no data at the moment or it's just a "\n" from child process ? No clue to decide whether to continue reading or just break out. When I am using "(pipe object).readline()" from python's subprocess module, "abc\n" means a line "abc", "\n" means an empty line and "" means not enough data. It's very simple without any ambiguity. But when I am using "ch_read()" in vim. "abc" means a line "abc", and both (empty line) and (no message) return "". Is it a "logic fallacy" of "ch_read()" ?? -- -- 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.
RFC: Can we have a bang (!) modifier after ":caddexpr" and ":cexpr" ?
Thanks to the new apis in vim 8. I have just released a plugin "asyncrun" to
run a shell command in background and display the output to the quickfix window
in realtime:
https://github.com/skywind3000/asyncrun.vim
This is a better alternative to old "vim-dispatch" plugin by using the
advantage of vim 8.
My friends and I has been using and improving it for months. Usually we start
exploring the error output in quickfix window immediately while the command is
still running. We added a condition on whether invoke ":cbottom" after append a
new line in quickfix window by ":caddexpr":
1. if current cursor in qf window is on the last line before ":caddexpr",
invoke ":cbottom" after ":caddexpr", and scroll the qf window.
2. if current cursor in qf window isn't on the last line, skip ":cbottom" and
call ":caddexpr" to populate qf directly.
The code is like these:
" quickfix window cursor check
function! s:AsyncRun_Job_Cursor()
if == 'quickfix'
if line('.') != line('$')
let s:qf_cursor_on_last_line = 0
endif
endif
endfunc
" check if quickfix window can scroll now
function! s:AsyncRun_Job_CheckScroll()
let s:qf_cursor_on_last_line = 1
let l:winnr = winnr()
windo call s:AsyncRun_Job_Cursor()
silent exec ''.l:winnr.'wincmd w'
return s:qf_cursor_on_last_line
endfunc
-
":cbottom" is only invoked if AsyncRun_Job_CheckScroll returns non-zero.
So, if someone need read the output while executing, they just need to go to
the qf window, and move cursor to the line above, auto scroll will stop, if
they want to continue read the newest output, they just need press 'G' in qf
window, ":cbottom" will continue be invoked and qf window will start scrolling
again.
It works fine and have a very good user experience.
but one downside is lack of performance, especially display some crazy STL
error output to quickfix window, vim alyways get unresponsed while cpu usage
exceeds 100%.
another little downside is calling ":windo" before each ":caddexp" will make
the cursor blink in a strange frequency. (maybe a little bug in vim).
due to this we have to disable these "last line checking" feature by default.
So, can we have a "!" after ":caddexpr" and ":cexpr" ?
If there is a "!" after ":caddexpr" or ":cexpr", they can detect cursor
position of the qf window in current tab-page, and make scroll after append
text if cursor in qf window is on the last line ?
Quickfix is a fundamental module which becomes more useful after introducing
async job system in vim.
It could be much helpful not only for my asyncrun, but a lot of other plugins
who use quickfix window and async jobs together.
require for comments.
--
--
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 ?
Marius Gedminas wrote： > > After downloading msys2 and installing gcc, ncurses-devel ... with pacman, > > I started to build latest vim inside msys2, and found these: > > > > checking for tgetent in -ltinfo... (cached) no > > checking for tgetent in -lncurses... (cached) yes > > ncurses library is not usable > > You need to figure out why that is (check config.log for clues). > > Alternatively, install Git for Windows and you get a nice set of tools > that include bash, vim and a better console (mintty). > > The vim might be a bit feature-limited, though, so I understand your > desire to build something newer. I can manage to build vim in the msys2 now by clone a refresh vim repository. thank you very much, msys2 + vim is right what I need -- -- 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: Does any one know how to build a msys+mintty compatible vim (like vim in GitBash) ?
Ken Takata wrote： > Not sure. How about installing pkg-config? > You can find the detail log in src/auto/config.log. I can manage to build vim in the msys2 now by clone a refresh vim repository. -- -- 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 ?
Magnus Woldrich： > >Thanks, very disappointted with cmd.exe > > Here you go: https://msys2.github.io/ After downloading msys2 and installing gcc, ncurses-devel ... with pacman, I started to build latest vim inside msys2, and found these: checking for tgetent in -ltinfo... (cached) no checking for tgetent in -lncurses... (cached) yes ncurses library is not usable checking for tgetent in -ltermlib... no checking for tgetent in -ltermcap... no checking for tgetent in -lcurses... no no terminal library found checking for tgetent()... configure: error: NOT FOUND! You need to install a terminal library; for example ncurses. Or specify the name of the library with --with-tlib. msys2 is a wonderful console, but latest vim can't be build in it , do you know what's wrong ? -- -- 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: Does any one know how to build a msys+mintty compatible vim (like vim in GitBash) ?
Ken Takata wrote： > Hi, > > 2016/9/23 Fri 13:00:40 UTC+9 skywind3000 wrote: > > Ken Takata wrote: > > > Hi, > > > > > > 2016/9/23 Fri 4:46:48 UTC+9 skywind3000 wrote: > > > > Yesterday, I started vim in GitBash (msys+mintty) by chance on windows. > > > > and found that vim worked very well in mintty, and mintty is far more > > > > better than cmd.exe. > > > > > > > > Trying to build vim from msys, and only find a cmd.exe compatible > > > > version which can not run properly under mintty. > > > > > > > > Does any body know how can GitBash/msys developers build it ? > > > > what building parameters did they use ? > > > > > > Git for Windows (a.k.a. GitBash) uses msys2 and msys2 is a fork of Cygwin. > > > So, basically you can build Vim as the same way with Cygwin. However > > > GitBash > > > doesn't have GCC by default. You need to install "Git for Windows SDK" to > > > build > > > a program for GitBash. > > > > > > Regards, > > > Ken Takata > > > > Thanks, is there any instructions to build on msys2 ? > > this one (https://gist.github.com/rpuntaie/8510218) seems out of date > > > > I tried to build from msys2, and get an error when I try to execute it . > > > > Linwei@weilin0 MINGW32 ~/software/vim/src > > $ ./vim > > Vim: Error: This version of Vim does not run in a Cygwin terminal > > The instruction cannot be applied to your case. > You built Win32 (native) vim.exe using MSYS2/MinGW, but actually you need is > MSYS2 version of vim.exe which is linked with msys-2.0.dll. They are totally > different things. > > If you use the official version of MSYS2, you should open "MSYS2 Shell" > shortcut, > then install necessary packages using pacman. (gcc, make, ncurses-devel, > gettext-devel, libiconv-devel, etc.) > If you use GitBash, you should install "Git for Windows SDK". (I haven't tried > this though.) > Then you should build Vim as normal Unix (or Cygwin). > E.g.: > cd src > ./configure; make > > Regards, > Ken Takata Thanks to figure out the difference between mingw-w64 and msys2 Following your tutorials, I got these: checking for tgetent in -ltinfo... (cached) no checking for tgetent in -lncurses... (cached) yes ncurses library is not usable checking for tgetent in -ltermlib... no checking for tgetent in -ltermcap... no checking for tgetent in -lcurses... no no terminal library found checking for tgetent()... configure: error: NOT FOUND! You need to install a terminal library; for example ncurses. Or specify the name of the library with --with-tlib. - I have install both ncurses-devel and ncurses. What's wrong with that ? -- -- 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: Does any one know how to build a msys+mintty compatible vim (like vim in GitBash) ?
Ken Takata wrote: > Hi, > > 2016/9/23 Fri 4:46:48 UTC+9 skywind3000 wrote: > > Yesterday, I started vim in GitBash (msys+mintty) by chance on windows. > > and found that vim worked very well in mintty, and mintty is far more > > better than cmd.exe. > > > > Trying to build vim from msys, and only find a cmd.exe compatible version > > which can not run properly under mintty. > > > > Does any body know how can GitBash/msys developers build it ? > > what building parameters did they use ? > > Git for Windows (a.k.a. GitBash) uses msys2 and msys2 is a fork of Cygwin. > So, basically you can build Vim as the same way with Cygwin. However GitBash > doesn't have GCC by default. You need to install "Git for Windows SDK" to > build > a program for GitBash. > > Regards, > Ken Takata Thanks, is there any instructions to build on msys2 ? this one (https://gist.github.com/rpuntaie/8510218) seems out of date I tried to build from msys2, and get an error when I try to execute it . Linwei@weilin0 MINGW32 ~/software/vim/src $ ./vim Vim: Error: This version of Vim does not run in a Cygwin terminal -- -- 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.
Does any one know how to build a msys+mintty compatible vim (like vim in GitBash) ?
Yesterday, I started vim in GitBash (msys+mintty) by chance on windows. and found that vim worked very well in mintty, and mintty is far more better than cmd.exe. Trying to build vim from msys, and only find a cmd.exe compatible version which can not run properly under mintty. Does any body know how can GitBash/msys developers build it ? what building parameters did they use ? -- -- 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 wrote： > * skywind3000 <skywind3...@gmail.com> [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 Thanks, very disappointted with cmd.exe -- -- 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: Compilation of vim 8 with mingw on windows fails: diff.c:891:12: error: storage size of 'st' isn't known
Nyffenegger wrote： > I am trying to compile vim 8 on Windows with mingw. > > These are the steps I executed: > > git clone https://github.com/vim/vim.git > cd vim\src > \mingw\bin\mingw32-make.exe -f Make_ming.mak ARCH=i686 > > The compilation of diff.c failes with the following error message:diff.c: In > function 'ex_diffpatch': > diff.c:891:12: error: storage size of 'st' isn't known > diff.c:891:12: warning: unused variable 'st' [-Wunused-variable] > mingw32-make: *** [gobji686/diff.o] Error 1 > > Is there something I can do about it? > > Thanks for any pointer. Sure, you can modify vim.h and change size_T from _stat64 to stat and comment HAVE_STAT64, this works for me index a787575..308c9cd 100644 --- a/src/vim.h +++ b/src/vim.h @@ -2093,8 +2093,8 @@ typedef int VimClipboard; /* This is required for the prototypes. */ /* Use 64-bit stat structure if available. */ #if (defined(_MSC_VER) && (_MSC_VER >= 1300)) || defined(__MINGW32__) -# define HAVE_STAT64 -typedef struct _stat64 stat_T; +//# define HAVE_STAT64 +typedef struct stat stat_T; #else typedef struct stat stat_T; #endif -- -- 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.
conflicts with in windows console vim (vim.exe), bug ?
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 ? -- -- 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 8.0 released!
skywind3000 wrote: > Bram Moolenaar wrote： > > Hello Vim users! > > > > > > Announcing: Vim (Vi IMproved) version 8.0 > > > > > > This the first major Vim release in ten years. There are interesting > > new features, many small improvements and lots of bug fixes. > > At last ! > Hope package maintainers of debian / ubuntu can update vim to version 8.0 > as soon as possible. I just wonder is it possible to make a embedded terminal in vim by using python + timer ? If so, that will be unnecessary to write a terminal in C any more. -- -- 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 8.0 released!
Bram Moolenaar wrote： > Hello Vim users! > > > Announcing: Vim (Vi IMproved) version 8.0 > > > This the first major Vim release in ten years. There are interesting > new features, many small improvements and lots of bug fixes. At last ! Hope package maintainers of debian / ubuntu can update vim to version 8.0 as soon as possible. -- -- 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.
Anyway to invoke 'replace_makeprg' in vim script ?
I am writing a plugin to launch shell command in background by using jobs. How can I escape and expand '%' in in my command ? just like replace_makeprg does, Currently, I split command args by using and check each argument, if a argument starts with '%' it needs to be expanded by calling `expand()`. It's a little stupid, this will work in '!': :!gcc "hello 1 2 3.c" but if I use in command, arguments in :MyRunAsyncCmd gcc "hello 1 2 3.c" will be splited into: [ 'gcc', '"hello ', '1', '2', '3.c"' ] so I must write like this to ensure works correctly: :MyRunAsyncCmd gcc hello\ 1\ 2\ 3.c Which is complete a different user experience from '!'. I wish to use directly and pass it to job_start(['sh', '-c', '?'], ...) so that it will work just like '!' but macros like '%' will not get replaced. after checking the vim source, I found a replace_makeprg is very close to this. So, how can vimscript invoke replace_makeprg or something like that to expands '%' in a string ? -- -- 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.
Will the default 8-bit meta mode in vim conflict with utf-8 characters in terminal ?
As ':help :map-alt-keys': By default Vim assumes that pressing the ALT key sets the 8th bit of a typed character. Most decent terminals can work that way, such as xterm, aterm and rxvt. If your mappings don't work it might be that the terminal is prefixing the character with an ESC character. But you can just as well type ESC before a character, thus Vim doesn't know what happened (except for checking the delay between characters, which is not reliable). As of this writing, some mainstream terminals like gnome-terminal and konsole use the ESC prefix. There doesn't appear a way to have them use the 8th bit instead. Xterm should work well by default. Aterm and rxvt should work well when started with the "--meta8" argument. You can also tweak resources like "metaSendsEscape", "eightBitInput" and "eightBitOutput". - in the modern terminals (like iTerm / gnome-terminal), typing unicode characters will be encoded as utf-8 and transfer to vim, which may contains the 8th bit. Will vim recognize utf-8 data stream as some meta-* key strokes ? Should I always set - to ^[a - ^[z in terminal to avoid that mistake ? -- -- 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 8 pre-announcement
Christian: > Hi skywind3000! > > On Di, 23 Aug 2016, skywind3000 wrote: > > > so Can I have a command ':bell' to ring the bell to notify myself that my > > async-build job has finished and I should check the quickfix output now > > while I am focusing on editing or navigating source. > > You mean like > :com Bell exe "norm! \" very tricky !! That's what I need -- -- 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 8 pre-announcement
> Bram: > > > Work on Vim 8.0 is coming close to an end. I hope version 8.0 can be > > released in about two weeks. > > > > This is a last chance to modify new features in a way that is not > > backwards compatible. Once 8.0 is out we can't make changes that would > > break plugins. > > > > > Visual C++ 6 can play a sound when build stop. > > so Can I have a command ':bell' to ring the bell to notify myself that my > async-build job has finished and I should check the quickfix output now while > I am focusing on editing or navigating source. afplay or other command line utilities could be used to play a .wav file in the desktop gvim, but there is no way to make a voice in a terminal vim. -- -- 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 8 pre-announcement
Bram: > Work on Vim 8.0 is coming close to an end. I hope version 8.0 can be > released in about two weeks. > > This is a last chance to modify new features in a way that is not > backwards compatible. Once 8.0 is out we can't make changes that would > break plugins. > Visual C++ 6 can play a sound when build stop. so Can I have a command ':bell' to ring the bell to notify myself that my async-build job has finished and I should check the quickfix output now while I am focusing on editing or navigating source. -- -- 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 8 pre-announcement
Bram: > Hello Vim users, > > Work on Vim 8.0 is coming close to an end. I hope version 8.0 can be > released in about two weeks. > > This is a last chance to modify new features in a way that is not > backwards compatible. Once 8.0 is out we can't make changes that would > break plugins. Can we have a binary mode in channels ? Which could be used to implement a virtual terminal inside vim in VimScript. According to the ":help channel", There is a "raw" mode in channels, but it will treat the whole message as a string, not a binary data. -- -- 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 7.4.2149
在 2016年8月4日星期四 UTC+8上午3:48:10，skywind3000写道：
> 在 2016年8月4日星期四 UTC+8上午3:45:32，skywind3000写道：
> > 在 2016年8月4日星期四 UTC+8上午3:05:11，Bram Moolenaar写道：
> > > Christian Brabandt wrote:
> > >
> > > > On Mi, 03 Aug 2016, Christian Brabandt wrote:
> > > >
> > > > > On Mi, 03 Aug 2016, Christian Brabandt wrote:
> > > > > > On Mi, 03 Aug 2016, Bram Moolenaar wrote:
> > > > > > > Christian Brabandt wrote:
> > > > > > > > Am 2016-08-02 23:05, schrieb Bram Moolenaar:
> > > > > > > > > Patch 7.4.2149
> > > > > > > > > Problem:If a test leaves a window open a following test
> > > > > > > > > may fail.
> > > > > > > > > Solution: Always close extra windows after running a test.
> > > > > > > > > Files: src/testdir/runtest.vim,
> > > > > > > > > src/testdir/test_popup.vim
> > > > > > > >
> > > > > > > > I think, this patch broke the appveyor build:
> > > > > > > > https://ci.appveyor.com/project/chrisbra/vim/build/1670/job/l38go72qo1ucc694#L2247
> > > > > > >
> > > > > > > Why would it break only there? The tests pass for me.
> > > > > >
> > > > > > I don't know. But if you go on history, you can see, that the
> > > > > > failure
> > > > > > started exactly with this patch (also happened at the
> > > > > > win32-installer
> > > > > > builds).
> > > > > >
> > > > > > I pushed the rebuild commit button, perhaps, that was just a
> > > > > > temporary
> > > > > > flaw?
> > > > >
> > > > > Something is seriously broken. On windows, I can reproduce the
> > > > > problem.
> > > > > When the command :lhelpgrep quickfix has been executed and the
> > > > > location
> > > > > list has been opened, w:quickfix_title is still ':lexpr ""'
> > > > >
> > > > >
> > > > > I'll try to debug this later.
> > > >
> > > > I think, it is opening the locationlist of the wrong window.
> > > > However, I don't understand, why it only happens on Windows.
> > > >
> > > > This patch fixes it for me:
> > > > diff -r ecc1173685b0 src/testdir/test_quickfix.vim
> > > > --- a/src/testdir/test_quickfix.vim Tue Aug 02 23:15:07 2016 +0200
> > > > +++ b/src/testdir/test_quickfix.vim Wed Aug 03 17:00:17 2016 +0200
> > > > @@ -407,6 +407,7 @@
> > > >
> > > > function Test_helpgrep()
> > > >call s:test_xhelpgrep('c')
> > > > + helpclose
> > > >call s:test_xhelpgrep('l')
> > > > endfunc
> > >
> > > Thanks. I do wonder why the behavior differs on Windows...
> > >
> >
> > Seems like somewhere in the heap was destroyed by an invalid memory
> > accessing,
> > which was caused by some old bugs long long ago both in unix build and
> > windows build.
> >
> > Some un-important variables in the heap had already been modified by
> > accident in the previous releases, and they had not been noticed before.
> >
> > As the code base is growing, heap structure is changing too, these old bugs
> > become harmful.
> >
> > Issues are both in unix and windows, but the heap structures in unix and
> > windows are different. It just didn't lead to serious consequences in unix.
> >
> > If we have enough test, we may also find some strange behaviors caused by
> > these bugs.
> >
> > if so, something really bad
> > Just a guess, hope I am wrong.
>
> If we have enough test, we may also find some strange behaviors caused by
> these bugs in unix.
I think we should not modify our test to adapt bugs, maybe it is an opportunity
to find them out.
--
--
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 7.4.2149
在 2016年8月4日星期四 UTC+8上午3:45:32，skywind3000写道：
> 在 2016年8月4日星期四 UTC+8上午3:05:11，Bram Moolenaar写道：
> > Christian Brabandt wrote:
> >
> > > On Mi, 03 Aug 2016, Christian Brabandt wrote:
> > >
> > > > On Mi, 03 Aug 2016, Christian Brabandt wrote:
> > > > > On Mi, 03 Aug 2016, Bram Moolenaar wrote:
> > > > > > Christian Brabandt wrote:
> > > > > > > Am 2016-08-02 23:05, schrieb Bram Moolenaar:
> > > > > > > > Patch 7.4.2149
> > > > > > > > Problem:If a test leaves a window open a following test may
> > > > > > > > fail.
> > > > > > > > Solution: Always close extra windows after running a test.
> > > > > > > > Files: src/testdir/runtest.vim, src/testdir/test_popup.vim
> > > > > > >
> > > > > > > I think, this patch broke the appveyor build:
> > > > > > > https://ci.appveyor.com/project/chrisbra/vim/build/1670/job/l38go72qo1ucc694#L2247
> > > > > >
> > > > > > Why would it break only there? The tests pass for me.
> > > > >
> > > > > I don't know. But if you go on history, you can see, that the failure
> > > > > started exactly with this patch (also happened at the win32-installer
> > > > > builds).
> > > > >
> > > > > I pushed the rebuild commit button, perhaps, that was just a
> > > > > temporary
> > > > > flaw?
> > > >
> > > > Something is seriously broken. On windows, I can reproduce the problem.
> > > > When the command :lhelpgrep quickfix has been executed and the location
> > > > list has been opened, w:quickfix_title is still ':lexpr ""'
> > > >
> > > >
> > > > I'll try to debug this later.
> > >
> > > I think, it is opening the locationlist of the wrong window.
> > > However, I don't understand, why it only happens on Windows.
> > >
> > > This patch fixes it for me:
> > > diff -r ecc1173685b0 src/testdir/test_quickfix.vim
> > > --- a/src/testdir/test_quickfix.vim Tue Aug 02 23:15:07 2016 +0200
> > > +++ b/src/testdir/test_quickfix.vim Wed Aug 03 17:00:17 2016 +0200
> > > @@ -407,6 +407,7 @@
> > >
> > > function Test_helpgrep()
> > >call s:test_xhelpgrep('c')
> > > + helpclose
> > >call s:test_xhelpgrep('l')
> > > endfunc
> >
> > Thanks. I do wonder why the behavior differs on Windows...
> >
>
> Seems like somewhere in the heap was destroyed by an invalid memory
> accessing,
> which was caused by some old bugs long long ago both in unix build and
> windows build.
>
> Some un-important variables in the heap had already been modified by accident
> in the previous releases, and they had not been noticed before.
>
> As the code base is growing, heap structure is changing too, these old bugs
> become harmful.
>
> Issues are both in unix and windows, but the heap structures in unix and
> windows are different. It just didn't lead to serious consequences in unix.
>
> If we have enough test, we may also find some strange behaviors caused by
> these bugs.
>
> if so, something really bad
> Just a guess, hope I am wrong.
If we have enough test, we may also find some strange behaviors caused by these
bugs in unix.
--
--
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 7.4.2149
在 2016年8月4日星期四 UTC+8上午3:05:11，Bram Moolenaar写道：
> Christian Brabandt wrote:
>
> > On Mi, 03 Aug 2016, Christian Brabandt wrote:
> >
> > > On Mi, 03 Aug 2016, Christian Brabandt wrote:
> > > > On Mi, 03 Aug 2016, Bram Moolenaar wrote:
> > > > > Christian Brabandt wrote:
> > > > > > Am 2016-08-02 23:05, schrieb Bram Moolenaar:
> > > > > > > Patch 7.4.2149
> > > > > > > Problem:If a test leaves a window open a following test may
> > > > > > > fail.
> > > > > > > Solution: Always close extra windows after running a test.
> > > > > > > Files: src/testdir/runtest.vim, src/testdir/test_popup.vim
> > > > > >
> > > > > > I think, this patch broke the appveyor build:
> > > > > > https://ci.appveyor.com/project/chrisbra/vim/build/1670/job/l38go72qo1ucc694#L2247
> > > > >
> > > > > Why would it break only there? The tests pass for me.
> > > >
> > > > I don't know. But if you go on history, you can see, that the failure
> > > > started exactly with this patch (also happened at the win32-installer
> > > > builds).
> > > >
> > > > I pushed the rebuild commit button, perhaps, that was just a temporary
> > > > flaw?
> > >
> > > Something is seriously broken. On windows, I can reproduce the problem.
> > > When the command :lhelpgrep quickfix has been executed and the location
> > > list has been opened, w:quickfix_title is still ':lexpr ""'
> > >
> > >
> > > I'll try to debug this later.
> >
> > I think, it is opening the locationlist of the wrong window.
> > However, I don't understand, why it only happens on Windows.
> >
> > This patch fixes it for me:
> > diff -r ecc1173685b0 src/testdir/test_quickfix.vim
> > --- a/src/testdir/test_quickfix.vim Tue Aug 02 23:15:07 2016 +0200
> > +++ b/src/testdir/test_quickfix.vim Wed Aug 03 17:00:17 2016 +0200
> > @@ -407,6 +407,7 @@
> >
> > function Test_helpgrep()
> >call s:test_xhelpgrep('c')
> > + helpclose
> >call s:test_xhelpgrep('l')
> > endfunc
>
> Thanks. I do wonder why the behavior differs on Windows...
>
Seems like somewhere in the heap was destroyed by an invalid memory accessing,
which was caused by some old bugs long long ago both in unix build and windows
build.
Some un-important variables in the heap had already been modified by accident
in the previous releases, and they had not been noticed before.
As the code base is growing, heap structure is changing too, these old bugs
become harmful.
Issues are both in unix and windows, but the heap structures in unix and
windows are different. It just didn't lead to serious consequences in unix.
If we have enough test, we may also find some strange behaviors caused by these
bugs.
if so, something really bad
Just a guess, hope I am wrong.
--
--
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] Is it very difficult to hide cmd window when calling 'system()' on windows ? (#922)
char101： > I have created a proof-of-concept plugin that hide the console window using > api hooking. > > https://github.com/char101/vim-hidecmd/ > that's great !! thanks -- -- 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] Is it very difficult to hide cmd window when calling 'system()' on windows ? (#922)
Bram: > I'm not sure if that can be made to work. CTRL-Break sometimes behaves > strange. > > On Unix you would use "kill" to stop the process. On MS-Windows you can > use the task manager for this, right? > > In general I don't mind the flickering, it's feedback that something is > happening. (I liked to hear my harddisk rattling, to know how busy it > is, SSDs broke that. I liked to hear my modem produce noise, so that I > knew what was going over the line. Now I have fiber...). > Yes, ctrl_break is not important, we can stop process by `kill` or `task manager`. I like the modem noise in the old days too, but these feedbacks are sound feedback, not graphics feedbacks. We can see windows users asking for help to hide the cmd window, they need to focus on editing, and solutions are everywhere including patch of os_win32.c, python/perl script to emulate unix `system()` experience for vim. But none of these are perfect (depend on python or need modify official source code). Can we get the ability to choose what ever we like ? Could windows gvim users have an option to enable SW_HIDE in `system()` ? -- -- 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] Is it very difficult to hide cmd window when calling 'system()' on windows ? (#922)
> I am on the fence on this one. > If Vim shells out to run something and that something is taking a _very_ long > time, your Vim is essentially hung. > This happens to me frequently. > At least with the Window there, I can close it, which returns an error to Vim > (via the system() call) and I get my Vim back. > Without that I have to terminate Vim, and that is a real pain. > > David -- So, how can you stop these __very__ long time tasks from non-windows platform, which won't pop up a cmd window ? __very__ long time tasks are supposed to be launched via async jobs in the latest vim version. Could windows gvim stop the child processes by a Ctrl_C/Ctril_Break ? There is an internal win32 message loop at line 4159 of os_win32.c: https://github.com/vim/vim/blob/master/src/os_win32.c#L4159 which is used to update gui while waiting for child process finished. Can we add a Ctrl_C/Ctrl_Break detection there to allow user stop a long time running process ? (I haven't read the whole part of os_win32.c, just do some search and find this routine.) If the child processes of 'system()' could be stop by ctrl_break/ctrl_c, could we make `system()` act the same way to the other vim versions ? -- -- 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] The order issue of 'exit_cb' and 'close_cb' in job-options (vim 7.4.1832) (#815)
sorry,I don't know issues in github will be redirect to this group. 在 2016年5月18日星期三 UTC+8下午4:21:32，Linwei写道： > Trying to make a async building system with +jobs in the latest vim, I find > sometimes 'exit_cb' is invoked after 'close_cb' but sometimes 'close_cb' is > invoked after 'exit_cb': > > > That's what I done in my plugin: > > 1. output text to quickfix window when 'callback' / 'out_cb' / 'err_cb' happen > > 2. output "(close)" to quickfix window when 'close_cb' happen, and flush all > the text in channel to quickfix. > > 3. output "[Finished in xx seconds]" to quickfix when 'exit_cb' happen and > clean my job state. > > > Sometimes I get this in quickfix: > > hello.c:1: x -> from 'callback' > hello.c:2: x -> from 'callback' > hello.c:3: x -> from 'callback' > hello.c:4: x -> from 'callback' > (close) -> from 'close_cb' > [Finished in 2 seconds] -> from 'exit_cb' > > > > but sometimes I get this: > > hello.c:1: x -> from 'callback' > hello.c:2: x -> from 'callback' > hello.c:3: x -> from 'callback' > [Finished in 2 seconds] -> from 'exit_cb' > hello.c:4: x -> from 'callback' > (close) -> from 'close_cb' > > > > I just can't figure out which one will happened at last ? 'close_cb' or > 'exit_cb' ? and which one should I rely to do the clean stuff ? > > > If I reset my building state in 'close_cb' (reset variables and unlet job > object and output 'finished') when 'exit_cb' comes after 'close_cb' the > environment is already destroyed. > > > And if I reset my building state in 'exit_cb' when 'close_cb' comes after > 'exit_cb' the environment is already destroyed too. > > > I have created a similar plugin for atom text editor ( atom-shell-commands ) > with javascript by using a 'child_process' module in node.js. The "process > exit callback" in always invoked after all pipe callbacks, so I can simply > > delete the child-process object and do the destruction things in "process > exit callback" without worry about any other callbacks will come after that. > > > Is this possible to guarantee that 'exit_cb' will alway be invoked after all > other callbacks (close_cb/out_cb/err_cb etc) ? If so, it will be much easier > for me to write my async building plugin for vim. > > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly or view it on GitHub -- -- 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.
The order issue of close_cb and exit_cb in job-options.
Using jobs to write an async building system, I can not find a callback which I can relay on it to clean my build state (unlet job object and output 'finished' to quickfix window): Sometimes 'close_cb' is invoked after 'exit_cb' and sometimes 'exit_cb' is invoked after close_cb and even 'callback'will happen **after** 'exit_cb' and I always get something in quickfix window like: hello.c:1: xxx -> 'callback' hello.c:2: xxx -> 'callback' hello.c:3: xxx -> 'callback' [Finished in 2 seconds] -> 'exit_cb' hello.c:4: xxx -> 'callback' hello.c:5: xxx -> 'callback' (pipe close) -> 'close_cb' and sometimes it become this: hello.c:1: xxx -> 'callback' hello.c:2: xxx -> 'callback' hello.c:3: xxx -> 'callback' hello.c:4: xxx -> 'callback' hello.c:5: xxx -> 'callback' (pipe close) -> 'close_cb' [Finished in 2 seconds] -> 'exit_cb' I just can't figure out which callback is the last one ? and when should I dispose my job state ? 'exit_cb' or 'close_cb' ? Is this possible to guarantee that 'exit_cb' will always be called at last (after 'close_cb' and any other 'callback' / 'out_cb' / 'err_cb') ? If so, my building system will be much easier. -- -- 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.
