I was going through AHK documentation on hotstrings, and found the Options section particularly interesting
The one question I have is about turning off options, for example:
C: Case sensitive: When you type an abbreviation, it must exactly match the case defined in the script. Use C0 to turn case sensitivity back off.
There are no examples of how you would do this, so that is my first question
How would you do it?
That is, what are the steps and some code examples I could use to accomplish it?
As for the second question, one that is not as important
Why would you do it?
To answer your first question, there are two main ways of creating a Case-sensitive hotstring.
Method 1- Single use Options modifiers:
Stick the options between the first and second colons of the hotstring. Ex:
;Case Sensitive
:C:ROFL:: Rolling on floor laughing
:C:ICYMI:: In case you missed it
:C:TL;DR:: Too long, didn’t read
;Non case-sensitive
::atot::A Tale of Two Cities
::ctbc::Cry, the Beloved Country
Method 2- #Hotstring directive
If you have a longer list of hotstrings you want some certain properties to apply to, you can use this directive. The directive will apply to all hotstrings following it, which is why there exists options like #Hotstring C0 that can turn off a previously declared #Hotstring C. Ex:
#Hotstring C
::ROFL:: Rolling on floor laughing
::ICYMI:: In case you missed it
::TL;DR:: Too long, didn’t read
#Hotstring C0
::atot::A Tale of Two Cities
::ctbc::Cry, the Beloved Country
(Both of these code blocks are functionally identical)
To answer your second question, if you meant why would you need to use the C0 option, please see Method 2 above. If you meant why would you use the Case Options in general, that would be a matter of personal preferences.
Related
Try running the following code yourself, and you would notice that "/hello" changes to "/HELLO", but I want it to change it to "hi". On the other hand, I want to keep the 1.st line of code, which changes "hello" to "HELLO". How could I achieve this(?)
This code problem is very related to my last problem:
Collision with two lines of code make code does not work the way it is meant by me, what could I do different to get this work(?)
The soltuion for my last problem was good for that problem, but it is not working for the new above mentioned problem.
::hello::HELLO
::/hello::hi
That is interesting. I really expected it to work by removing / from the EndChars. But after looking at it for a while, it becomes obvious why it's behaving this way. When you type "/hello" it actually matches to both hotstrings, so AHK chooses the first one defined. Anyway, there are two solutions that I know of:
Reorder your hotstrings. Place ::/hello::hi above the other one and you'll always get the desired result. Additionally, you don't need to change the EndChars since / is the first character.
Use the asterisk option on the second hotstring. This will make it update immediately, which may or may not be desirable (I prefer it).
I'm trying to have my Vim setup automatically fold import statements when I open a Scala file. This is similar to what Intellij does when you open a file. I currently have the following lines in my .vimrc file from the wiki.
set foldmethod=syntax
set foldenable
syn region foldImports start=/(^\s*^import\) .\+/ end=/^\s*$/ transparent fold keepend
However when I open a .scala file it doesn't fold the imports but the body of objects. I am also using the vim-scala plugin. Thanks for the help!
You were pretty close to getting this to work. There are a few funky factors at play that we should consider.
setting foldmethod to syntax (btw this is not documented on learn Vimscript the Hardway..so :help foldmethod was key to figure this out)
SYNTAX fold-syntax
A fold is defined by syntax items that have the "fold" argument.
|:syn-fold|
The fold level is defined by nesting folds. The nesting of folds is
limited with 'foldnestmax'.
Be careful to specify proper syntax syncing. If this is not done
right, folds may differ from the displayed highlighting. This is
especially relevant when using patterns that match more than one line.
In case of doubt, try using brute-force syncing:
:syn sync fromstart
The main thing to note is the sync fromstart this is a useful helper if you have regex that would match throughout the file and only want to catch the header. In your case you should be able to ignore this but just something to be aware of.
top down regex scanning
Since the import block is fairly predictable we can simplify the start and end to look something like this:
syn region foldImports start="import" end=/import.*\n^$/ fold keepend
Since the region is just looking for some string to start the matching on we can just use "import"(or /import/) and then for the end value we want to use a little bit more carefully crafted statement. The key is that we want have the end be the last line of the import with a blank line following it (/import.*\n^$/)
Hopefully that does the trick for you (I do not work with scala so you may have to adjust the regex a bit as needed)
I am defining a variable in the beginning of my source code in MATLAB. Now I would like to know at which lines this variable effects something. In other words, I would like to see all lines in which that variable is read out. This wish does not only include all accesses in the current function, but also possible accesses in sub-functions that use this variable as an input argument. In this way, I can see in a quick way where my change of this variable takes any influence.
Is there any possibility to do so in MATLAB? A graphical marking of the corresponding lines would be nice but a command line output might be even more practical.
You may always use "Find Files" to search for a certain keyword or expression. In my R2012a/Windows version is in Edit > Find Files..., with the keyboard shortcut [CTRL] + [SHIFT] + [F].
The result will be a list of lines where the searched string is found, in all the files found in the specified folder. Please check out the options in the search dialog for more details and flexibility.
Later edit: thanks to #zinjaai, I noticed that #tc88 required that this tool should track the effect of the name of the variable inside the functions/subfunctions. I think this is:
very difficult to achieve. The problem of running trough all the possible values and branching on every possible conditional expression is... well is hard. I think is halting-problem-hard.
in 90% of the case the assumption that the output of a function is influenced by the input is true. But the input and the output are part of the same statement (assigning the result of a function) so looking for where the variable is used as argument should suffice to identify what output variables are affected..
There are perverse cases where functions will alter arguments that are handle-type (because the argument is not copied, but referenced). This side-effect will break the assumption 2, and is one of the main reasons why 1. Outlining the cases when these side effects take place is again, hard, and is better to assume that all of them are modified.
Some other cases are inherently undecidable, because they don't depend on the computer states, but on the state of the "outside world". Example: suppose one calls uigetfile. The function returns a char type when the user selects a file, and a double type for the case when the user chooses not to select a file. Obviously the two cases will be treated differently. How could you know which variables are created/modified before the user deciding?
In conclusion: I think that human intuition, plus the MATLAB Debugger (for run time), and the Find Files (for quick search where a variable is used) and depfun (for quick identification of function dependence) is way cheaper. But I would like to be wrong. :-)
I'm producing a function for imenu-create-index-function, to index a source code module, for csharp-mode.el
It works, but delivers completely unacceptable performance. Any tips for fixing this?
The Background
I looked at js.el, which is the rebadged "espresso" now included, since v23.2, into emacs. It indexes Javascript files very nicely, does a good job with anonymous functions and various coding styles and patterns in common use. For example, in javascript one can do:
(function() {
var x = ... ;
function foo() {
if (x == 1) ...
}
})();
...to define a scope where x is "private" or inaccessible from other code. This gets indexed nicely by js.el, using regexps, and it indexes the inner functions (anonymous or not) within that scope also. It works quickly. A big module can be indexed in less than a second.
I tried following a similar approach in csharp-mode, but it's quite a bit more complicated. In Js, everything that gets indexed is a function. So the starting regex is "function" with some elaboration on either end. Once an occurrence of the function keyword is found, then there are 4 - 8 other regexps that get tried via looking-at - the number depends on settings. One nice thing about js mode is that you can turn on or off regexps for various coding styles, to speed things along I suppose. The default "styles" work for most of the code I tried.
This doesn't work in csharp-mode. It works, but it performs poorly enough to make it not very usable. I think the reason for this is that
there is no single marker keyword in C#, as function behaves in javascript. In C# I need to look for namespace, class, struct, interface, enum, and so on.
there's a great deal of flexibility with which csharp constructs can be defined. As one example, a class can define base classes as well as implemented interfaces. Another example: The return type for a method isn't a simple word-like string, but can be something messy like Dictionary<String, List<String>> . The index routine needs to handle all those cases, and capture the matches. This makes it run sloooooowly.
I use a lot of looking-back. The marker I use in the current approach is the open curly brace. Once I find one of those, I use looking-back to determine if the curly is a class, interface, enum, method, etc. I read that looking-back can be slow; I'm not clear on how much slower it is than, say, looking-at.
once I find an open-close pair of curlies, I call narrow-to-region in order to index what's inside. not sure if this is will kill performance or not. I suspect that it is not the main culprit, because the perf problems I see happen in modules with one namespace and 2 or 3 classes, which means narrow gets called 3 or 4 times total.
What's the Question?
My question is: do you have any tips for speeding up imenu-like indexing in a C# buffer?
I'm considering:
avoiding looking-back. I don't know exactly how to do this because when re-search-forward finds, say, the keyword class, the cursor is already in the middle of a class declaration. looking-back seems essential.
instead of using open-curly as the marker, use the keywords like enum, interface, namespace, class
avoid narrow-to-region
any hard advice? Further suggestions?
Something I've tried and I'm not really enthused about re-visiting: building a wisent-based parser for C#, and relying on semantic to do the indexing. I found semantic to be very very very (etc) difficult to use, hard to discover, and problematic. I had semantic working for a while, but then upgraded to v23.2, and it broke, and I never could get it working again. Simple things - like indexing the namespace keyword - took a very long time to solve. I'm very dissatisfied with it and don't want to try again.
I don't really know C# syntax, and without looking at your elisp it's hard to give an answer, but here goes anyway.
looking-back can be deadly slow. It's the first thing I'd experiment with. One thing that helps a lot is using the limit arg to, say, restrict your search to the beginning of the current line. A different approach is when you hit the open curly do backward-char then backward-sexp (or whatever) to get to the front of the previous word, then use looking-at.
Using keywords to search around instead of open curly is probably what I would have done. Maybe something like (re-search-forward "\\(enum\\|interface\\|namespace\\|class\\)[ \t\n]*{" nil t) then using match-string-no-properties on the first capture group to see which of the keywords was found. This might help with the looking-back problem as well.
I don't know how expensive narrow-to-region is, but could be avoided by when you find a open curly do save-excursion forward-sexp and keep point as a limit for the current iteration of your (I assume recursive) searches.
Any refactoring tool like this?
Windows
After you press Alt+Shift+R as mentioned by kostja, you can select the text you want to change, then
Ctrl+Shift+Y for lowercase, or
Ctrl+Shift+X for uppercase.
Mac OS
Cmd+Shift+Y lowercase
Cmd+Shift+X uppercase
There is no intelligence in this. It just blindly changes the case on the selected characters.
note: This tip comes from eclipse help. If you need to find it, click Help, Search, then type "uppercase". You'll find a page with lots of shortcuts.
What I find useful is column select using Alt+Shift+A and select a column of letters.
Then use Ctrl+Shift+Y or Ctrl+Shift+X to lower case or uppercase letters.
This works for eclipse on windows.
There are a number of problems:
fooBar -> FooBar and vice-versa are unlikely to occur unless someone has been ignoring the Java style guidelines. (I rarely encounter such code, and when I do my initial reaction is to write off the code as beyond salvage.)
fooBar -> FOO_BAR and vice-versa are plausible, but pretty unusual.
foobar -> fooBar is also plausible, but it is problematic. It would entail Eclipse figuring out where the intended word boundaries are in a sequence of characters, and that is hard to get right.
If you look at these, they are all either unlikely to be needed much, or too hard to do properly. Hence, it doesn't surprise me that they are not supported by the standard Eclipse codebase.
Pressing Alt+Shift+R gives you all the power to refactor your variable name to your liking. AFAIK, there is no tool or shortcut that does just the capitalizing.
No. You'll have to use the standard rename refactoring and retype the variable name in capital letters.
Capitalizing variable names should be limited to those cases, where we change a class attribute to a "constant", and this doesn't happen that often...