I'm creating a small game in python where two players choose 1 of 3 characters and fight each other by turns. So when I launch game in cmd, there are some info that I want to refresh on cmd every turn so I use "import os" and "os.system('cls')". This cleans whole window. The thing is I want some information to stay on screen, like how much one's character done damage on last rounds etc. Is it possible at all?
Or maybe its possible to do that when I open my program, two cmd screens opens, both store different information and communicate with each other?
ANSI escape codes are your friend. Among other things, it allows you to move the cursor around the screen. For example
print('\e[2A\e[3C')
will move the cursor two spaces up and three to the right. This wikipedia article gives a good synopsis, see the section on CSI sequences. These codes work on most Unix/Linux OSs and newer versions of Windows 10.
Related
In the last 2-3 years that I started using Vim as my main editor, I've learned to use windows (splits) when working with multiple files (Because in every task, I need lots of files to work with)
But a few days ago, I ran into this question and it blow my mind (and my workflow :))
So I tried to use buffers and no windows and it's really hard. Imagine having multiple blocks (folders) and each one of them has a model.php and a controller.php in them.
So at the start of the task, I don't know which block I need, so after a few minutes, I'll open multiple model.phps and controller.phps.
Now, if I don't have every file that I need in my buffer, I must search buffer first and when I see that I didn't load it, now I have to use explorer and load the file into buffer. So it's something like this:
:ls<CR>
{If the file that I need is here then}
:b num<CR>
{else}
:FZF {and finding that file}
So it's a lot harder than just working with windows (Where I can see what files are loaded in front of me)
(And of course the overhead of finding buffers and searching them by name/number is like opening the file every time that you needed)
But as said in this question and lots of other places, buffers should make your workflow easier than windows and windows should be used only for diffs and etc.
So is there any better ways to use buffers or am I doing something wrong?
(BTW, I'm currently using :Buffers from fzf.vim)
So I tried to use buffers and no windows and it's really hard.
This means that you misunderstood both the spirit and the letter of the linked answer.
To recap, Vim's exact equivalent of "documents" in regular document-based applications is buffers. Vim also gives you a first layer of abstraction on top of buffers: windows, and another one on top of windows: tab pages in order to give you more flexibility with building your workflow.
Forcing oneself to use buffers instead of windows or instead of tab pages or whatever makes no sense as there is value in all three and such an attitude would only decrease the overall value of your editor. Use the interaction model that best suits your needs, not the interaction model that you convinced yourself is the purest.
As for the confusion between files and buffers, how about the confusion between files and tab pages or between buffers and windows? When you are dealing with abstractions built on top of other abstractions you have to have commands specific to one layer or another and learning how that layered cake works gives you the necessary intuition for deciding what command to use and when.
Basically, you have 3 cases:
Case #
Is a buffer
Is a file
1
Y
Y
2
Y
N
3
N
Y
In case #1, the buffer is associated with a file so you can use both file-centric and buffer-centric commands to reach your target.
In case #2, the buffer is not associated with a file so you can only use buffer-centric commands to reach your target.
In case #3, there is no buffer so yo can only use file-related commands to reach your target.
Another way to think about it is to ask the question "Have I already been there?". If the answer is "no", then use file-centric commands, if the answer is "yes", use buffer-centric commands. If you have no idea or if you don't want to think about any of this, just use file-centric commands as a fallback.
Note that the context of that answer was "buffers vs windows vs tab pages". Abstracting yourself away from the notions of files or documents is the real deal.
When speaking of "best workflow" we inevitably speak of our personal habits and tastes. So just remember that it's your editor, your workflow and your "best practices". Not someone else's.
Windows/tabs and buffers do not prohibit using each other. It is not a problem to open buffer in current window/tab even if it was already opened in another one (or even in dozen ones).
If you feel uncomfortable searching through the buffers list then try doing it with some alternative tools. For example, you like clicking with mouse then run GVim and browse through "Buffers" menu; or you are good at memorizing numbers then make all buffers numbers to show in status line and switch buffers by typing NN<Ctrl-^> directly; or you like reading file contents then find some plugin that shows also "a buffer preview" etc.etc.
Motivation: I'm trying to write scripts which send keystrokes to the currently focused window. Right now I use xdotool, which lets me send raw keystrokes. However, I want the exact keystrokes to be a function of the current text around the input caret in the focused window.
Problem: Is there a generic way of reading the state of the text input caret -- both its current position as well as the text around it? Intuitively, I want the content of the current "text box" as well as the location of the cursor within that text box. Perhaps this is not possible in the general case, but is there a way of doing it which would work for emacs and firefox? I'm running Ubuntu Linux
Further motivation: due to a bad case of RSI I control my computer by voice rather than typing. This works by setting up voice-activated scripts that are triggered by saying different phrases. When dictating English prose, it would be helpful to automatically capitalize words at the beginning of sentences. This automatic capitalization can be accomplished by reading the characters immediately before the input caret, checking if they contain a period, and if so, capitalizing the start of the next phrase that I dictate by voice.
Thanks so much! If anybody can help me here, it would greatly increase my day-to-day accessibility.
Since there is no standard widget toolkit for X11, but only a buch of independently developed arbitrary toolkits, there is no generic way to implement this.
As far as X11 and tools operating on its level (like xdotool) is concerned, there's only windows of either the InputOutput variety (i.e. visible windows, that receive events and one can draw to) or the just Input which are invisible and only receive events. There are no further refined "widgets" so to speak. You get a pixel grid, which you can draw to.
Accessibility interfaces are the burden of the toolkits (or if you don't use a toolkit – then you're a badass – you, the developer), to implement: https://www.freedesktop.org/wiki/Accessibility/
The absolute generic way would be to take a screenshot of the currently focused window, employ a computer vision / machine learning based solution to identify the caret, then OCR the line of text around it. And to be honest, IMHO doing it that way would probably be a lot more reliable than hoping for the accessibility interfaces to be properly implemented.
I'm making a small game where you have to guess if the answer is cp1 or cp2 and I want to give the user some sort of hint. One way of doing that I think is by flashing the answer for a nano or milisecond to user, i.e. a new window would open with a : . Any ideas as to how to do this?
[...] flashing the answer for a nano or millisecond to user [....] in a new window [...]
A millisecond is too short (both for the human player -read about the persistence of vision- and for the Python interpreter); your screen is probably refreshed at 60Hz. Consider flashing for at least one tenth of a second (and probably more than that, you'll need to experiment, and you might make the flashing delay or period configurable). How to do that depends upon the widget toolkit you are using.
If using something above GTK, you'll need to find the Python binding to g_timeout_add, see also this.
If you use something above libSDL (e.g. pygame_sdl2), you need something related to its timers.
There are many other widgets or graphical frameworks usable from Python, and you need to choose one (look also into PyQt). Each of them has its own way to deal with timing, delays, windows, graphical display of text inside a window, etc...
If your system is Linux, see also time(7) for a general overview of time related things. Event loops (like those in graphics libraries) are built above a multiplexing system call such as poll(2) (or the old select, etc...).
You need to spend several days in reading more, choosing your graphical toolkit, before coding a single line of code of your game (which might need more code than what you imagine now).
I think the closest you can easily get to this affect is to just print to the console, but don't print the new-line (\n), just the carriage return (\r). This way you can write over the text after a couple of milliseconds. We do need to know the length of the thing we are printing so that we can be sure to completely override it with the next print.
The code for this would look something like:
import time
ms = 100
s = 'cp1'
print(s, end='\r')
time.sleep(ms / 1000)
print(' ' * len(s))
When I'm writing a program for use on the command line, I notice that there's some limitations. For instance, I can't draw a 1-pixel-thick horizontal or vertical line like tmux does when it separates panes in a window. I can only move the cursor down, not up like VI seemingly does. I can't refresh information on the top of the page if the cursor is at the bottom.
So, when programs like tmux and vi do this, I have to wonder if they are:
drawing the screen from top to bottom every update (which I think is highly unlikely because otherwise I could scroll up in my terminal and see each redraw)
using some library that enables graphics in the terminal, like SDL, which I also think is unlikely.
using some standard syscall I don't know about
or finally
taking advantage of some feature of Linux/Unix of which I'm completely unaware.
So, how do these programs generate such a rich UI in such a seemingly limited shell? So long as the answer gives me just enough fodder to go on a Google rampage, I'll be happy.
I'm also assuming that these programs use some common method to do these things, but if that's wrong let me know.
A typical terminal emulator has a lot more features than are immediately apparent.
Essentially a program just needs to output short sequences of bytes that represent various commands such as move cursor (up|down|left|right), change color, scroll region, erase region, etc.
These commands typically begin with the escape character (the same character that is generated when you press the esc key while typing in a terminal) followed by various other characters, depending on which action is desired.
A good starting point for understanding how it works would be the Wikipedia Article about ANSI escape codes
You can do it by hand by putting the terminal into raw mode and writing directly to the terminal using low-level operations but the standard way to do it is to use the ncurses library.
I find the concept of the programmable, tiling, keyboard-focuessed window manager ion3 very appealing, but I think it takes some time to customize it to your needs until you can really evaluate this totally different UI-concept.
Therefore, I would like to read reviews of people who tried it for a longer time as environment for programming (in particular using emacs/gcc).
(The policies of the ion3-author concerning linux-distros are not easy to follow for me, but this should not be the point here...)
I use ion3 daily. It's a wonderful window manager. The tiling interface really enables you maximize real estate. Once you get it setup to your liking, it is much more efficient to navigate via the keyboard. Even moving applications between tiles isn't that hard once you get used to the tag/attach key sequence.
With ion3, Vimperator and the various shells I have open during the day -- I barely use the rodent.
The author's opinions aside -- a good resource for configuring/extending Ion to your liking can be found at:
Configuring and Extending Ion3 with Lua
I've been using Ion daily for nearly two years now. Good things:
Easy to use from the keyboard.
Handles multiple screens (Xinerama) very well (once you have the mod_xinerama plugin), especially as in my case the screens are different sizes.
Very predictable where windows will appear.
Splitting, resizing and moving windows is very easy.
Multiple, independent workspaces on each screen.
Very fast and reliable.
Bad things:
Too many different shortcuts. e.g. there are separate keys for moving to the next tab, next frame, next screen, and next workspace.
Applications that use lots of small windows together work really badly (e.g. the Gimp) because it maximises all of them on top of each other initially.
Sub-dialogs can cause trouble. Sometimes they open in a separate tab when you want them in the same tab, or sometimes the open in the same tab and take the focus when you want to continue interacting with the main window.
These things can probably be changed in the config files, but I haven't got around to it yet. Also, the actual C code is easy to read, and on the few occasions where I've wanted to fix something it has been very easy. I don't feel tempted to go back to a non-tiling WM, anyway.
I've used it off and on for the last few years, I think its a great window manager, but I keep crawling back to kde3 whatever I use.
Its however difficult to put into quantifiable terms why this happens, but its right up there with the gnome-vs-kde battle. Neither side can understand the other.
I would also just love to have kicker + ion3, but they don't gel awfully well.
Moving applications between tiles ( something I tend to do lots ) also is a bit inefficient ( too addicted to the mouse )
( Kicker + Evilwm is a good combination, but evilwm just can't handle stacking in a user-friendly way )