I am using sublime text 3 build 3059 in Linux. I open the UI using the command line with -new-window option and point to a file or a directory. I may do this multiple times so several UI instances will be open simultaneously. I would like separate instances of the UI to act independent of each other. Using the --new-window option gets me close but I have found that closing one instance of the UI using ctlr+q / menu->file->quit will close all open UI instances. This is not the case when I close using the X button in the upper right corner which only closes the current instances. This can be painful when there are open instances located in various virtual desktops. Then when you open a file for a quick edit and close it using ctrl+q, all UI instances are closed. This not a good user experience. Does anyone know of an option that would allow me to have ctrl+q close only the current UI instance? My real need is to have the instances to act independently.
BTW, I have found sublime text 2 post that answer this question but sublime text 3 seems to behavior differently in this regard.
The reason for that is that ctrl+q shortcut is the shortcut to exit the application and alt+f4 is the shortcut to close window. This is simply a usability thing and it's somewhat a convention used in may more applications other than Sublime Text.
The ctrl+q shortcut is not mapped in ST settings rather is built-in for Linux version of ST. The OS X version allows remapping this through it's system hotkey settings but not the Linux one.
Thus I suggest simply trying to retrain yourself and use alt+f4 instead.
Related
I want to have "two vim open" because I have multiple monitors.
Also I would like them to share buffers, clipboards, etc.
So I'd like to share the same instance across two different windows.
I have found:
vim --remote file.txt
but this opens the file in the first vim; it doesn't open a new window within the same vim instance.
How can multiple vim windows share the same instance?
Although I don't believe there is a native way this can be achieved in VIM, there are however other ways to get similar behavior :
Expand your terminal to be available on both monitors, that way you can use vim splits and have one split in each monitor and hence work on the same file in both monitors. Although this is probably less cool.
Use something like tmux / screen. This way you can just launch multiple terminal windows and have them in separate monitors and connect to the same tmux session from both. You can then edit / view your vim session in either monitor and it will be perfectly mirrored in the other.
I'd like to run some code in Sublime Text every time I open a file. Is there any way of doing this?
The background, if you want more context: I recently started using Sublime Text as my main editor, and although I love having Vim mode available through the Vintageous plug-in, I just want it to be available, not forcing its way into being turned on every time I open a file.
The author does not seem open to adding an option for being turned off by default--which is entirely okay: I'm not trying to be critical of his choices, and I'm glad he's made his code available to me--so it occurred to me that Sublime Text might offer some way of running some code every time you open a file. If so, I would simply run something that sets the mode to the normal Sublime Text mode (as opposed to Vim's "normal" mode).
You can run code in response to various events by creating a plugin and subclassing sublime_plugin.EventListener. The methods you would be most interested in are on_load() and on_new(). From there, you can either run an existing command, or you can make your own in a different class (probably subclassing sublime_plugin.TextCommand).
When working in GUI we do alt-tab (or cmd-tab in mac) to switch between multiple programs, for example I am writing a text file in a text editor and then I do alt-tab to switch to already running browser to google up something then I alt-tab again to come back to keep editing.
How do you perform such "switch between" programs in command line interface - for example working with a ssh command line shell?
EDIT: I forgot to mention it, I am using ssh to connect to my university's server, and they don't have screen & tmux installed, and my account have no right to install any new apps... Is there any built-in functionality to perform this task, or any work around? For exmaple can I "minimize" running proggram and come back to regular shell interface, do some work, then display the "minimized" process again?
Another workaround: use the shell's job control, eg if you're editing a file, CTRL-z pauses the editor and brings you back to the shell, where you can compile, see manpages, browse the web or whatever -- and of course you can background the browser or anything else.
Screen command offers the ability to detach a long running process (or program, or shell-script) from a session and then attach it back at a later time.
As a crude workaround, run multiple terminal windows on your computer, and alt-tab between them.
Incidentally, at the Linux console, you can switch virtual terminals with ctrl+alt+F for at least F1 through F6, commonly F8 or more (depends on how the distro sets them up). Not your case, I know, but in case future visitors should benefit.
If you are comfortable in Emacs, it allows you to run multiple independent ansi-term buffers.
You can also use "GNU screen" to emulate multiple terminals in one terminal.
I want to implement a simple specialized window manager for presentations (not user-controllable) that supports only the following operations:
Moving and resizing of windows
Switching desktops
Starting applications not on current desktop (in background) without disrupting current image.
I don't need any user input, button/titles, ...
What existing window manager should I use as example? There are many little "hello world" window managers, but they usually does not support desktop switching.
You don't need to reimplement the wheel.
openbox will do everything you mention and more besides.
Simply edit the rc.xml to disable the root menu, and re-launch.
Openbox also allows per app setting so that certain applications can open on a particular desktop by default, or with a particular size, or open hidden.
It also supports wildcards in the window selection, so that settings can apply to all windows.
devilspie2 is a window matching utility that can perform actions whenever a window opens.
It is highly hackable and the code is available on github. It will match windows by name/class/etc when they open, and perform actions on them. (including matching all windows and moving them to a different desktop. It will work with most window managers.
Based on the original devilspie which does not have Lua scripting, but is configured using s-exprs instead.
xdotool will also allow you to perform complex actions on windows without hacking any code. It will even fake user input (mouse/kbd) if you need it.
There are a few window managers written in Python that could be good starting points. Qtile and whimsy both describe themselves as hackable.
I have a gVIM script that parses current buffer and offers user to select one of multiple choices. It is implemented as console input, but since i'm using graphical version of gVIM, maybe it's possible to use graphical version of multiple choice dialog? I have tried to use python + Tkinter but it's very unstable and is not working on some NIX boxes :(. Any ideas?
GVim has, in its functions and settings, nothing that would enable showing GUI elements (with a few noble exceptions, like closing dialog and such.).
That being said, GVim is open source, and nothing stops you from downloading the source and messing with it.
After some research i have found a solution. VIM supports so-called "clientserver" mode and external application can send a command to it. So this task (and many others) can be solved with following technique (tested on Windows, OSX and Ubuntu):
VIMscript that handles a command launches standalone GUI script in
separate process and returns.
Standalone GUI script (python/ruby/.exe/whatever) displays GUI and
waits for user interaction.
After user interaction, standalone GUI script closes it's window,
communicates back to VIM via "clientserver" interface (call another
script, open file, move cursor etc) and exits.