Search Results

Search found 5 results on 1 pages for 'weeble'.

Page 1/1 | 1 

  • What are safe keys to remap in vim?

    - by Weeble
    So far I've been trying to use Vim in as vanilla a configuration as possible, so as to save myself hassle when moving between machines. However, there are a few things I'd really like to bind keys, such as to shorten "_diwP which I use often to delete the word under the cursor and replace it with one from the clipboard. Are there any particular keys that are conventionally reserved for user-defined mappings? The point of this question is mostly that I would like to avoid hassle later on when I decide to install some plugin or take my configuration files to vim on another OS and find that my key mappings clash with something else.

    Read the article

  • What are safe keys to remap in vim?

    - by Weeble
    So far I've been trying to use Vim in as vanilla a configuration as possible, so as to save myself hassle when moving between machines. However, there are a few things I'd really like to bind keys, such as to shorten "_diwP which I use often to delete the word under the cursor and replace it with one from the clipboard. Are there any particular keys that are conventionally reserved for user-defined mappings? The point of this question is mostly that I would like to avoid hassle later on when I decide to install some plugin or take my configuration files to vim on another OS and find that my key mappings clash with something else.

    Read the article

  • How does Visual Studio's source control integration work with Perforce?

    - by Weeble
    We're using Perforce and Visual Studio. Whenever we create a branch, some projects will not be bound to source control unless we use "Open from Source Control", but other projects work regardless. From my investigations, I know some of the things involved: In our .csproj files, there are these settings: <SccProjectName <SccLocalPath <SccAuxPath <SccProvider Sometimes they are all set to "SAK", sometimes not. It seems things are more likely to work if these say "SAK". In our .sln file, there are settings for many of the projects: SccLocalPath# SccProjectFilePathRelativizedFromConnection# SccProjectUniqueName# (The # is a number that identifies each project.) SccLocalPath is a path relative to the solution file. Often it is ".", sometimes it is the folder that the project is in, and sometimes it is ".." or "..\..", and it seems to be bad for it to point to a folder above the solution folder. The relativized one is a path from that folder to the project file. It will be missing entirely if SccLocalPath points to the project's folder. If the SccLocalPath has ".." in it, this path might include folder names that are not the same between branches, which I think causes problems. So, to finally get to the specifics I'd like to know: What happens when you do "Change source control" and bind projects? How does Visual Studio decide what to put in the project and solution files? What happens when you do "Open from source control"? What's this "connection" folder that SccLocalPath and SccProjectFilePathRelativizedFromConnection refer to? How does Visual Studio/Perforce pick it? Is there some recommended way to make the source control bindings continue to work even when you create a new branch of the solution?

    Read the article

  • Why does Microsoft advise against readonly fields with mutable values?

    - by Weeble
    In the Design Guidelines for Developing Class Libraries, Microsoft say: Do not assign instances of mutable types to read-only fields. The objects created using a mutable type can be modified after they are created. For example, arrays and most collections are mutable types while Int32, Uri, and String are immutable types. For fields that hold a mutable reference type, the read-only modifier prevents the field value from being overwritten but does not protect the mutable type from modification. This simply restates the behaviour of readonly without explaining why it's bad to use readonly. The implication appears to be that many people do not understand what "readonly" does and will wrongly expect readonly fields to be deeply immutable. In effect it advises using "readonly" as code documentation indicating deep immutability - despite the fact that the compiler has no way to enforce this - and disallows its use for its normal function: to ensure that the value of the field doesn't change after the object has been constructed. I feel uneasy with this recommendation to use "readonly" to indicate something other than its normal meaning understood by the compiler. I feel that it encourages people to misunderstand the meaning of "readonly", and furthermore to expect it to mean something that the author of the code might not intend. I feel that it precludes using it in places it could be useful - e.g. to show that some relationship between two mutable objects remains unchanged for the lifetime of one of those objects. The notion of assuming that readers do not understand the meaning of "readonly" also appears to be in contradiction to other advice from Microsoft, such as FxCop's "Do not initialize unnecessarily" rule, which assumes readers of your code to be experts in the language and should know that (for example) bool fields are automatically initialised to false, and stops you from providing the redundancy that shows "yes, this has been consciously set to false; I didn't just forget to initialize it". So, first and foremost, why do Microsoft advise against use of readonly for references to mutable types? I'd also be interested to know: Do you follow this Design Guideline in all your code? What do you expect when you see "readonly" in a piece of code you didn't write?

    Read the article

  • Run arbitrary subprocesses on Windows and still terminate cleanly?

    - by Weeble
    I have an application A that I would like to be able to invoke arbitrary other processes as specified by a user in a configuration file. Batch script B is one such process a user would like to be invoked by A. B sets up some environment variables, shows some messages and invokes a compiler C to do some work. Does Windows provide a standard way for arbitrary processes to be terminated cleanly? Suppose A is run in a console and receives a CTRL+C. Can it pass this on to B and C? Suppose A runs in a window and the user tries to close the window, can it cancel B and C? TerminateProcess is an option, but not a very good one. If A uses TerminateProcess on B, C keeps running. This could cause nasty problems if C is long-running, since we might start another instance of C to operate on the same files while the first instance of C is still secretly at work. In addition, TerminateProcess doesn't result in a clean exit. GenerateConsoleCtrlEvent sounds nice, and might work when everything's running in a console, but the documentation says that you can only send CTRL+C to your own console, and so wouldn't help if A were running in a window. Is there any equivalent to SIGINT on Windows? I would love to find an article like this one: http://www.cons.org/cracauer/sigint.html for Windows.

    Read the article

1