The fish shell does syntax highlighting while I type commands. For example, unclosed strings appear as red, closed strings appear as yellow.
My question is: Can I interact with the syntax highlighting for specific commands?
I'd like to achieve the following behavior: When I type
git commit -m "Some commit message"
the message string should get a different color when it's longer than 50 chars.
This is a sweet idea, but unfortunately it can't be done in fish! The syntax highlighting has to run without executing any shell script, so there's no way to inject custom logic.
Related
I typically work in another text editor and simply copy and paste my work into Stata's command prompt. However, I have noticed a difference between the way the command prompt and the do file editor handle comments.
The code below reproduces the things I have discovered:
mata
//test comment
/* test comment 2 */
end
//test comment 3
*test comment 4
/* test comment 5*/
When run from the do file editor, the code runs without issue.
But when I run it after copying and pasting into the command prompt, I receive a number of r(3000) errors in mata and r(199) errors in Stata.
The sole exception is that the * comments in regular Stata work fine in both interfaces.
I also see that the // comment in mata gives an "expression invalid" error message along with the r(3000) notification, but I only receive the r(3000) message when I use the /* text */ comment. In regular Stata, both comment types that are not * give "/ is not a valid command name" messages along with the r(199).
My main question is:
What is the reason behind this difference? Is there anything I can do to suppress these errors?
Also, this is something like a red flag for me:
Are there other behaviors that differ when I run things via the command prompt rather than the do file editor?
The following Technical Note from the 16th Stata manual about Do-files explains:
"...The /* */, //, and /// comment indicators can be used in do-files and ado-files only; you may not use them interactively. You can, however, use the ‘*’ comment indicator interactively..."
So there is nothing surprising here. You can easily prevent errors like these by following the conventions. Just read the relevant section of the aforementioned manual for more details.
Only StataCorp knows for sure, but such differences probably arise from how Stata interprets the code internally when this is parsed from a do file or the command prompt.
See the following post for another (unrelated) example of an inconsistent behaviour:
Stata axis labels off-center when broken over multiple lines
Personally, after using Stata extensively for years, i have not noticed any other major differences when running code from do files and interactively.
In iTerm2 you can create triggers that highlight a line if your regex matches. This is great for some cases but I was wondering if it was possible to highlight only a word on a specific line.
The purpose of this is to help read my server logs where specific keywords can be easily pointed out. Highlighting the entire line is a bit distracting
A Profile-based trigger can highlight as much or little of a line as you choice (via the regex).
To highlight just a "word" in a line, you can create a simple Highlight Text trigger, i.e.:
Results in:
Ref: https://iterm2.com/documentation-triggers.html
Below is where you will find Triggers
As an additional usage of the selected answer, I'd like to suggest adding a tigger for "smart quotes" with the regex [”“’‘]
This will save you some day when a coworker sends you a line of code via a chat mechanism (like Slack) and the quotes get automagically "improved". The trigger won't fire as you paste/type them, but they will happen after the line scrolls up your terminal. So, it won't prevent the mistake, but it will save you time wondering why the command failed.
Open up irb and
type gets. It should work fine.
Then try system("choice /c YN") It should work as expected.
Now try gets again, it behaves oddly.
Can someone tell me why this is?
EDIT: For some clarification on the "odd" behavior, it allows me to type for gets, but doesn't show me the characters and I have to press the enter key twice.
Terminal input-output handling is dark and mysterious art. Anyone trying to make colorized output of bash work in windows PowerShell via ssh knows that. (And various shortcutting habits like Ctrl+Backspace only make things worse.)
One of the possible reasons for your problem is special characters handling. Every terminal out there can type characters in number of different modes, and it parses its own output in search for certain character sequences in order to toggle states.
F.e. here one can find ANSI escape code sequences, one of possible supported standards among different kind of terminals.
See there Esc[5;45m? That will make all the following output to blink on magenta background. And there is significantly more stuff like that out there.
So, the answer to your question taken literally is — your choice command messes something with output modes using special escape sequences, and ruby's gets breaks in that quirk special mode of terminal operation.
But more useful will be the link to HighLine gem documentation. Why one might want to implement platform-specific and obtrusive behavior when it is possible to implement the same with about 12 LOC? All the respect for the Gist goes to botimer, I've only stumbled into his code using search.
I'm trying out the coffee script repl inside Emacs (under ArchLinux) and I'm seeing these escape characters surrounding the prompt:
[1Gcoffee> [0K[9G
These shouldn't be colors as I already enabled the ansi-color-for-comint-mode. So does anyone recognize these?
P.S.: Funny thing is I don't have this issue under my Emacs+Cygwin setup!
I don't know where they're coming from (something to do with your shell prompt, obviously, but it's hard to say more than that).
I read them as:
ESC[1G - Move to column 1 (Cursor Character Absolute)
ESC[0K - Erase to right
ESC[9G - Move to column 9
It looks like an attempt by the shell to ensure that the prompt is at the far left of an empty line. Not sure what shell you have, but zsh does something similar when the PROMPT_SP option is enabled. I don't think it uses the above sequences, though.
Many, many, control sequences can be found here. Note that the sequence "ESC[" is interpreted as a "Control Sequence Introducer" (CSI) and is shown as that on that page.
I had the same problem and was able to solve it by adding
export NODE_NO_READLINE=1
to my .bashrc file.
So, the characters appear to have come from the CoffeeScript REPL's use of Readline. Perhaps the reason you didn't have the issue in Cygwin was because Readline wasn't available there.
Question: I have a question that is apparently not answered by this already-asked Bash completion question on Stack Overflow. The question is, how to get Bash alias completion (for any alias) on a partial substring.
Example:
For example, assume I have the following aliases:
open.alicehome="cd /usr/home/alice"
open.bakerhome="cd /usr/home/baker"
open.charliehome="cd /usr/home/charlie"
gohomenow="shutdown -now"
I would like to lazily just type "baker{{TAB}}" to invoke the second alias.
I would like to lazily just type "home{{TAB}}" to get a list of all of the above aliases that I can then choose from with the keyboard (optimal) or choose by typing an unambiguous substring that distinguishes among the three options (less than optimal).
.. OR ..
I would like to lazily just type "home" and then repeatedly press {{TAB}} until the specific alias I want shows up, then press {{ENTER}} to execute it.
Feel free to be creative:
If you have a way to do this, even if it requires resorting to extreme guru hackery, please feel free to share it and feel free to explain your guru hackery to the level of a five-year-old who will have to try to implement your idea for himself.
Links to existing web-pages or RTFMs are welcome.
If you really want to change bash's tab behavior,
# ~/.inputrc
# The default binding for [Tab] is ``complete'', which is what we're used to.
# ``menu-complete'' gives you irssi-like behavior: cycle through completions.
"\t": menu-complete
This is documented in The GNU Readline Library # Letting Readline Type For You.
You can generate the matches for a specified substring with compgen -c -X'!*substring*'
To include this in bash autocompletion you can create a .bash_completion file in your home directory containing something like this:
_comp() {
local cur
cur=${COMP_WORDS[$COMP_CWORD]}
COMPREPLY=( $( compgen -c -X '!*'$cur'*' ) )
}
complete -F _comp $nospace eval
This match function will run when you press <TAB> on the arguments to the eval command. I haven't found a way to include a new matching function for the first command search in bash, I've only found documentation on how to add custom completions for a specific command, like eval above.
But I'm a bit skeptical to how useful this is... There is no easy way to select which match you want from the list.
Probably you can achieve what you want with custom bash_completion settings, but I'm not going to do the job for you, ok? :-)
If you don't know what I'm talking about, see here and here for details. By the way, I would find very annoying this
I would like to lazily just type
"home" and then repeatedly press
{{TAB}} until the specific alias I
want shows up, then press {{ENTER}} to
execute it.
which I think is the M$ style of "completion" (are you coming for DOS/windows environment?)