Context
So I finally give a try to Fish, and as one would expect I encounter some frictions due to differences with my usual routines.
The most astonishing for me, as for many other, was the absence of the bang operator. I'm fine with the lose of sudo !!, as the suggested function replacement seems even better to me, I named it gar which means "To make, compel (someone to do something); to cause (something to be done." However I'll need a replacement for !<abc><enter> which grab the last history line starting with <abc> and run it without further ado, suggestions are welcome.
Now, for the more personal things:
- I use a Typematrix 2030 keyboard
- I use a bépo layout
- I like to configure default finger position keys with the most used actions
Aims
As on my keybord <enter> is well positioned and is semantically relevant for that, ideally I would like to achieve the following key binding:
ctrl-enter: accept the whole suggestion and run it without further confirmation
ctrl-tab: accept the whole suggestion and wait for further edit
alt-enter: redo the last command without further confirmation
But according to xev it appears that, at least with Gnome-terminal, this combinations are not recognized. Are they terminal that supports it? For now I remapped these three to <ctrl>-i, <alt>-i and <alt>-I respectively:
bind --preset \ci forward-char execute
bind --preset \ei forward-char
bind --preset \eI forward-word
This works as expected, but it seems that now the tab key will also map to the first item. I guess that tab map to <alt>-i at some point in the shell stack. I wasn't aware of that, so I don't know yet if it will be possible for Fish to separate each of them.
To manage jobs, I also came with
bind --preset \es fg
bind --preset \eS bg
The first works as expected, but the second one doesn't. With application like vim, the binding should be operated in the application configuration itself of course. But for things as trivial as yes, <alt>-S won't work as expected while <crl>-z continue to operate normally.
I also would like to bind some commands like ls -alh and git status --short to a directly executed command, showing the result bellow the currently edited line, allowing to further type seamlessly, but didn't find the way to do it yet.
Summary of remaining question
So here are my more precise questions summarised:
how do I bind the sleep signal to <alt>-S?
is there a terminal I can use where <alt>-<enter> and <ctrl>-<enter> works?
how to seamlessly run command while maintaining the current line edition in place?
can you bind something to <alt>-i without altering <tab>?
how do I bind the sleep signal to -S?
What you are doing with bind \es fg is to alter a binding inside the shell.
But when you execute yes, the shell isn't currently in the foreground, so shell bindings don't apply.
What you'd have to do instead is change the terminal settings via stty susp \cs,
but fish resets the terminal settings when executing commands (so you can't accidentally break them and end up in an unusable environment), so there currently is no way to do this in fish.
can you bind something to <alt>-i without altering <tab>?
Sure. You bind \ei. Which is escape+i, which is alt-i (because in a terminal alt is escape).
Your problem is with ctrl-i, which in the way terminals encode control+character is tab. The application receives an actual tab character, and at that point the information has been lost.
is there a terminal I can use where - and - works?
Most terminals should send \e\r for alt-enter. ctrl-enter again is unencodable with the usual code (because \r is ctrl-m), just like ctrl-tab is.
Any fix to this requires the terminal to encode these combination differently.
how to seamlessly run command while maintaining the current line edition in place?
I don't know what you mean by this. I'm guessing you want fish to remain open and editable while a command also runs in the foreground. That can't work. There's no way to synchronize output from two commands to a terminal, not with cursor movement being what it is.
Related
I am using Sublime Text 3 and am trying to access the command palette using ctrl-shift-P. This shortcut is not working. I am running Ubuntu 16.04. Any help to fix this would be greatly appreciated.
The two main reasons for this sort of situation (regardless of the key sequence in question) are:
A user installed plugin or custom key binding is bound to the same key, which is taking precedence and stopping the action that you expect from happening
Some external process is eating the keystroke before Sublime even gets to see it.
In order to diagnose which it might be, you can open the Sublime console with View > Show Console or by pressing Ctrl+`, then enter the following commands:
sublime.log_commands(True)
sublime.log_input(True)
Once you've done that, press the key sequence in question and check the output in the console. In your specific case, you should see this:
key evt: shift+control+p
command: show_overlay {"overlay": "command_palette"}
Not seeing the command that you expect indicates that some other action is bound to the key in question, and usually the command will lead you to what's causing the problem.
Not seeing the key event means that some external process is eating the key. This could be some global program or it could be something in the OS doing it (in the case of Linux, the window manager).
It's also possible that you see a different key event entirely, which indicates that your keyboard layout is not what Sublime expects.
Depending on the situation you may be able to disable whatever is eating the key. Presuming you can't find what that is or otherwise don't want to disable it, or if the event shows that Sublime is seeing a different key, the solution is to change the key binding.
The procedure for this is to find the binding that's not working and copy it to your custom key bindings, changing the key as appropriate to something that Sublime can see.
For core Sublime key bindings, look in Preferences > Key Bindings to find the key in question. For packages, that's generally in Preferences > Package Settings > PACKAGENAME > Key Bindings.
In your case, the setting is a default key binding, so looking in the default key bindings yields the following binding, which you can put in your custom key bindings and change as needed:
{
"keys": ["ctrl+shift+p"],
"command": "show_overlay",
"args": {"overlay": "command_palette"}
},
Something that I found:
Weirdly my Sublime Text 3 doesn't recognise the command if I use LCTRL abd LSHIFT. Using RCTRL+RSHIFT+p opens the command palette, so try that.
In my case it was an app called https://noiz.io which had stolen this shortcut. It can take a bit of time as there isn't (AFAIK) a way to find the application which is bound to a shortcut.
In my case a Pomodoro app I just installed had a command for starting clock defined with the same shortcut and it was stealing the event from Sublime. Just removed the shortcut assignment and it works now.
I use Xcode7 to debug a App.
Seems step into behave like the step over, can't jump into the execution of a sub procedure? It's just jump to the next line in the source code each time.
And if I'm debug in the UIKit method(I don't have source code), it's jump to the next instruction.
As you have found, step-in avoids frames with no debug information. Most people like to just hit one step command, rather than switching between step & next depending on the line they are on, and in my experience, tend to choose step. This is made more pleasant if the debugger doesn't stop in printf & other code you have no debug info for.
However, lldb's "step" command has an option to control this:
-a <boolean> ( --step-in-avoids-no-debug <boolean> )
A boolean value that sets whether stepping into functions will step over functions with no debug information.
If you use this frequently, you can either reset the step alias to include this option, or make another alias that includes it. Use the command alias command to do this.
And if you always want step-in to step into code with no debug information, just set the global setting:
settings set target.process.thread.step-in-avoid-nodebug 0
either at the start of a debug session or in your .lldbinit.
Note, most of lldb's commands are documented in the help system. For instance, help step would have shown the above option for the step command, and apropos step would have shown the setting.
From GDB Manual:
Also, the step command only enters a function if there is line number information for the function. Otherwise it acts like the next command. This avoids problems when using cc -gl on MIPS machines. Previously, step entered subroutines if there was any debugging information about the routine.
And I found Step into works well when I have source file.
So maybe I have make a mistake. But the lldb is very lack of documents.
I have an application that uses GLib's commandline option parser to handle commandline arguments (as described here).
What I've found is that the description for each option entry has to be very short - in order to fit within the width of a terminal of standard size (when the application is called with the --help argument). If a description for an option is too long it wraps around, and this looks pretty bad. Is there an accepted way to tidy this up?
For example, here's what part of the help output from my application looks like in an 80 character wide terminal window:
Application Options:
-i, --ip-addr Sets the IP address to which the video strea
ms will be sent. If this option is not used then the default IP address of 127.0
.0.1 is used.
-p, --port Sets the port to send the video streams to.
If not chosen this defaults to 1234.
Ideally it would look something like this:
Application Options:
-i, --ip-addr Sets the IP address to which the video
streams will be sent. If this option is not
used then the default IP address of
127.0.0.1 is used.
-p, --port Sets the port to send the video streams to.
If not chosen this defaults to 1234.
I could just get the above result manually, by working out the required length of each line of my option descriptions. Then I could manually enter newlines and spaces into the strings to get the right indentation. But this seems like a really rough approach, and I'm sure there must be a better and less time-consuming way of formatting the output.
I'm sure this problem must have come up before for others, but I haven't found a solution, does anybody here know of a better way to get nicer formatting?
I have the exact same issue. At present I am using the ghetto fix of adding spaces. This however is not possible with the argument description (rather than just the description, which is what is printed at the end). If you add newlines to break the argument description the spacing of the proceeding arguments is messed up.
I just caught myself doing something I do a lot, and wanted to generalize it, express it, share it and see who else is following this general practice, to find some other example situations where it might be relevant.
The general practice is getting something wrong first, on purpose, to establish that everything else is right before undertaking the current task.
What I was trying to do, specifically, was to find examples in our code base where the dojo TextArea widget was used. I knew (because I had it in front of me - existence proof) that the TextBox widget was present in at least one file. So I looked first for what I knew was there:
grep -r digit.form.TextBox | grep -v
svn
This wasn't right - I had made a common (for me) mistake of leaving off the star, so I fixed that:
grep -r digit.form.TextBox * | grep
-v svn
which found no results! Quick comparison with the file I was looking at showed me I had misspelled "dijit":
grep -r dijit.form.TextBox * | grep
-v svn
And now I got results. Cool; doing it wrong first on purpose meant my query was correct except for looking for the wrong thing, so now I could construct the right query:
grep -r dijit.form.TextArea * | grep
-v svn
and be confident that when it gave me no results, it was because there are no such files, and not because I had malformed the query.
I'll add three other examples as answers; please add any others you're aware of.
TDD
The red-green-refactor cycle of test-driven development may be the archetype of this practice. With red, demonstrate that the functionality doesn't exist; then make it exist and demonstrate that you've done so by witnessing the green bar.
http://support.microsoft.com/kb/275085
This VBA routine turns off the "subdatasheets" property for every table in your MS Access database. The user is instructed to make sure error-handling is set to "Break only on unhandled errors." The routine identifies tables needing the fix by the error that is thrown. I'm not sure this precisely fits your question, but it's always interesting to me that the error is being used in a non-error way.
Here's an example from VBA:
I also use camel case when I Dim my variables. ThisIsAnExampleOfCamelCase. As soon as I exit the VBA code line if Access doesn't change the lower case variable to camel case then I know I've got a typo. [OR, Option Explicit isn't set, which is the post topic.]
I also use this trick, several times an hour at least.
arrange - assert - act - assert
I sometimes like, in my tests, to add a counter-assertion before the action to show that the action is actually responsible for producing the desired outcome demonstrated by the concluding assertion.
When in doubt of my spelling, and of my editor's spell-checking
We use many editors. Many of them highlight misspelled words as I type them - some do not. I rely on automatic spell checking, but I can't always remember whether the editor of the moment has that feature. So I'll enter, say, "circuitx" and hit space. If it highlights, I'll back up over the space and the "x" and type another space - and learn that I spelled circuit correctly - but if it doesn't, I'll copy the word and paste it into a known spell-checker to see whether I did.
I'm not sure it's the best way to act, as it does not prevent you from mispelling the final command, for example typing "TestArea" or something like that instead of "TextArea" (your finger just have to slip a little for such a mistake).
IMHO the best way is to run your "final" command, but on two sample files first : one containing the requested text, another that doesn't.
In other words, instead of running a "similar" command, run the real one, but over "similar" data.
(Not sure if this would be a good idea to try for real!)
For example, you might give the system to the users for testing and tell them the password to get started is "Apple".
You know the users are fully up and ready to test (everything is installed and connections to databases working) when they contact you and say the password doesn't work (it's actually "Orange").
Finding dead code in Delphi is usually real simple: just compile and then scan for routines missing their blue dots. The smart linker's very good about tracking them down, most of the time.
Problem is, this doesn't work for event handlers because they're published methods, which (theoretically) could be invoked via RTTI somehow, even though this almost never happens in actual practice.
I'm trying to clean up a large VCL form unit that's been bent, folded, spindled and mutilated various times throughout its history. It would sure be nice if I had some way to find event handlers that aren't actually referenced by the form's DFM and delete them. Is there any easy way to do this? A plug-in IDE Expert, for example?
This is a bit ugly (OK, it's a lot ugly), but for one unit it's close to foolproof, and requires no additional tools:
Make sure that the current version of the form is checked into source control!
Go to the top of the interface of the class where the event handlers are. Delete all of the event handler method interfaces.
Look at Code Explorer/Error Insight. The methods which have implementations but no interfaces will be highlighted. Delete the implementations.
Now save the unit. Delphi will, one at a time, complained about the missing event handler for each event that is actually handled. Write these down as the errors come up.
Check out the original version of the form, and remove the event handlers for anything not on your list.
Use the "Rename Method" refactoring to rename each event handler. Check the "View references before refactoring" checkbox.
Check the Refactoring window. If the event handler is linked to a control, there will be a "VCL Designer Updates" section show which control(s) are linked to the method.
This will also show if the method is called from any other units, or is assigned programmatically.
Note: this is for D2006, may be slightly different in later versions.
ModelMaker Code Explorer contains an so-called Event handler view. It also shows event handlers not connected to any component.
I dont think this is possible from an automatic point of view. event handlers are activated when a particular event occurs inside an object. That the even is not triggered in a given run doesnt mean that there isnt an execution pathway to lead to it.
also you can assign handlers dynamically at runtime so whats used in one situation is not garuanteed.
e.g.
button.onclick := DefaultClickHandler;
button.onClick := SpecialClickHandler;
Assuming that the click handlers match the onclick event signature, but you wouldnt get a compile if the signature was incorrect.
however, you can probably find all the abandoned handlers by looking for all the methods that find have a (Sender: TObject) method signature and comparing that his of methods to those in the .dfm (make sure you save it as text if you are working with an older version of delphi), antyhing not wired up automatically would be suspect in my book.
--
if you dont want to go down the cygwin path, you can load the src and dfm into two TStirngLists and rip out the name/idents from each and generate a list with a couple of loops and some string manipulations. my guess is about 20 minutes of work to get something you can live with .
There is no solution that is guaranteed to give a correct answer in the most general case (based, as you note, on the possibility of calling them via RTTI).
One solution would be to do code coverage tests and look carefully at handlers that were never reached.
I'm not aware of a preexisting app or plugin to do this, but it shouldn't be hard to script.
Assuming you're not using RTTI or manually assigning event handlers: (I'm a C++Builder user rather than Delphi, so the following may not be quite correct.)
Make a list of all published methods in your code.
The proper way to do this is to read *.pas. Find each text block that starts with a class declaration or a published directive and ends with a end, private, or public. Within each of these text blocks, extract each procedure.
The easy way to do this is to make a list of common event handler types and assume they're published.
Once you have this list, print everything from the list that's not found in your DFM file.
I'm most comfortable using Cygwin or Linux tools for scripting. Here's a bash script that works in Cygwin and should do what you want.
#!/bin/bash
for file in `find -name *.pas`; do
echo $file:
# Get a list of common event handling procedures.
# Add more types between the | symbols.
egrep '^[[:space:]]+procedure.*(Click|FormCreate|FormClose|Change|Execute)\(' $file |
awk '{print $2}' | cut -f 1 -d '(' > published.txt
# Get a list of used event procedures.
egrep '^[[:space:]]+On.* =' ${file%.pas}.dfm | awk '{print $3}' > used.txt
# Compare the two.
# Files listed in the left column are published but not used, so you can delete them.
# Files in the right column were not by our crude search for published event
# handlers, so you can update the first egrep command to find them.
comm -3 published.txt used.txt
echo
done
# Clean up.
rm published.txt used.txt
To actually use this, if you're not familiar with Cygwin:
Download and install Cygwin. I think the default install should give you all of the tools I used, but I'm not positive.
Save the script to your source directory as cleanup.sh.
Start a Cygwin command prompt.
If your source is in c:\MyApp, then type cd /cygdrive/c/myapp
Type ./cleanup.sh and press Enter.
There's a much easier approach than Craig's.
Go to a suspect event handler. Rename it in a consistent way--I do this by putting an x in front of the name, go down to the implementation and do the same thing. See what the compiler thinks of it.
If it's not happy you just change the names back.
You can use the same approach to eliminate data elements that no longer do anything.