ismail-yilmaz / bobcat Goto Github PK

Every time I press Alt + Win (pretty often, since I have a shortcut Alt+Win+Enter to open new Bobcat instance), weird unicode character is printed in the terminal. The character is ￫ (U+FFEB "HALFWIDTH RIGHTWARDS ARROW"). Interestingly, it only happens when I first press Alt and then Win, if I press Win first then nothing is printed.

I'm not sure if this might be Bobcat related or not. However, it doesn't happen in any other application (neither Xwayland nor native).

I have tried to debug with wev, but the keys seem to emit just the expected Mod1 and Mod4 keyboard events.

[14:     wl_keyboard] key: serial: 991067; time: 625637069; key: 64; state: 1 (pressed)
                      sym: Alt_L        (65513), utf8: ''
[14:     wl_keyboard] modifiers: serial: 0; group: 0
                      depressed: 00000008: Mod1 
                      latched: 00000000
                      locked: 00000000
[14:     wl_keyboard] key: serial: 991069; time: 625637457; key: 133; state: 1 (pressed)
                      sym: Super_L      (65515), utf8: ''
[14:     wl_keyboard] modifiers: serial: 0; group: 0
                      depressed: 00000048: Mod1 Mod4 
                      latched: 00000000
                      locked: 00000000

We have this technology in U++, TerminalCtrl supports it, and it's easy to integrate.
Users should be able to deploy bobcat on their servers and access it via any web browser that supports HTML5/Canvas:

Bobcat on Gnome web & Firefox, (localhost):

I'd love to be able to simply click on anything that looks like URL and open it in default browser.

Other terminals (e.g. Gnome terminal or anything libVTE based), underscore links (not really necessary IMHO), allow to open or copy it by context menu or open it via Ctrl + click.

I'd be perfectly happy if you could implement a click handler that would check the text underneath the cursor and open it in browser if it appears to be an URL.

This topic will contain tasks to further improve profile management.

• Streamline the Finder profile settings code.
• Streamline the Linkifier profile settings code.
• Add Smart selection settings (extended word/block selection).

I have noticed that the profile names are take from two different sources:

• The settings dialog displays the profiles names based on the filename
• The title bar displays value of "Name" field in the configuration file.

There should be only one source of truth for this information.

How did I found this? I wanted to duplicate a profile, because I only needed to change the command and keep everything else same. Since the UI doesn't support that yet, I just went to the config directory and made a copy of the profile. After some time, I noticed that the title bar still shows the original name.

Also, the work with profiles could use some more features:

• duplication (to create similar profile, as it happened to me)
• rename (sometimes you need to change the name, to distinguish similar profile, or to unify the naming scheme)
• ordering (to keep related profiles near each other)

Regarding the last point: I'm not 100% sure, but I think the order sometimes randomly changes, perhaps depending in which order are the files listed on the filesystem?

I think I will have some free time next week, so I can try to actually contribute some code, if you don't mind. It'd be fun to write something in U++ after so many years of using other languages :-)

See this task.

Once finished, we'll utilize the feature.

Working prototype (can use plain text or qtf (or possibly md | html) for rich text, as shown below):

When application produces large output quickly, Bobcat uses 100% CPU and practically freezes. The text is rendered later, but veeeeery slowly.

To reproduce, just run curl -L https://github.com/json-iterator/test-data/raw/master/large-file.json. This produces ~30 Mb of JSON.

Sakura terminal renders this in about 4s. Bobcat takes minutes and the whole time the CPU goes full throttle :-(

I have configured On exit: Don't close terminal for one of my profiles, because sometimes it is useful to see what happened before ssh connection broke.

Today I've noticed, that there is no way to close terminal in this "exited but not closed" state, without closing entire application. Which might not be desirable if you have other terminals running.

I have found "Close" button on the title bar, but that only kills the process, so it actually brings the terminal into the uncloseable state.

Is there some way to close such terminal that I have missed?

When I try to set a keyboard shortcut to Enter, Esc or Del, the dialog doesn't respond correctly.

Del simply removes previous selection. Enter and Esc bring the OK and Cancel respectively in the pushed state. It is even possible to make them both look pushed at the same time :-)

Is there some way to set the shortcuts manually? I have found config files in $HOME/u++/bobcat, but none of them contains the shortcuts. At first I thought they are stored someplace else, but maybe they're not stored at all. After I close and reopen Bobcat, any changes I do to the shortcuts are reverted to the defaults.

I have noticed a minor misbehavior with the hyperlinks. If I point mouse cursor on a link, it gets highlighted. That is good and helpful. But if there is multiple links with the same target, then they are all highlighted, which seems a bit odd. So is this a bug or intentional feature?

Example:

In README.md there is information about the license and it is BSD. However, in license file you have GNU GPL.

This is a feature request to make the Text search feature easier to use with keyboard only.

I suggest:

• Move to the next occurrence on Enter
• Move to previous occurrence on Shift + Enter
• Close the dialog on Esc

As a side note: It would be great if all occurrences were highlighted, while the current is distinguished by different color. Similar to how for example Chrome browser works. It makes orientation in the results much faster for me.

Sometimes, the rendered text looks weirdly "highlighted". As if it was rendered bold, or twice with small offset. I have tried with multiple fonts, to make sure it is not problem with just one particular font.

Another example, from running umk:

I suspect that it only happens if the line is too long and has to wrap, so that might be a place to start looking.

Steps to reproduce:

1. Open long enough file with less
2. Press End

Expected behavior:

Less scrolls to the end of file.

Actual behavior:

Nothing happens.

Additional info:

Pressing end while editing command in bash works fine. I only noticed this problem in less so far.

My less is version 643.

Upp's Esc scripting language is ideal for this job.

Esc can be embedded in Bobcat and would allow a great degree of flexibility in implementing secondary stuff.

TerminalCtrl has a selector mode where users can navigate the terminal's buffer, using the keyboard and select text/word and rectangles. Bobcat can greatly benefit from this mode.

• Implement selector mode in Bobcat.

Configurable shortcut:

Available hard-coded shortcuts (for the time being):

Sometimes (I'm still not exactly sure in what exact circumstances), the terminal is kind of confused about it's size. It seems to fallback to 80x24, even though the screen size is different:

$ echo $COLUMNS $LINES
80 24

This leads to weird artifacts when rendering apps, e.g.:

Changing the window size fixes the problem. It might be related to the fact that I use tiling window manager (sway).

Most of the time, changing the window geometry works just as expected. This weird thing happens only sometimes. I'll try to keep an eye on it, maybe I'll be able to better pinpoint what leads to this phenomenon.

Steps to reproduce:

Press Ctrl + Left while editing a command in Bash.

Expected behavior:

In other terminals, this results in cursor moving one word to the left. Similarly for Ctrl + Right to move one word to the right.

Actual behavior:

Nothing happens, cursor stays at the same position.

Additional info:

I'm using Bash 5.2.21 on Sway (wayland compositor). I believe that this should be handled by bash itself, the shortcut is loaded from /etc/inputrc:

$ bind -P | grep -E '^(for|back)ward-word'
backward-word can be found on "\e\e[D", "\e[1;3D", "\e[1;5D", "\e[5D", "\eb".
forward-word can be found on "\e\e[C", "\e[1;3C", "\e[1;5C", "\e[5C", "\ef".

Here \e[1;5C and \e[1;5C correspond to Ctrl + Left or Right respectively.

When I select some text in the terminal, the selection stays in the same area when the buffer scrolls.
It doesn't happen when I scroll using mouse wheel, only when new text is added to the buffer.

I'd expect the selection either to disappear when the buffer moves or to keep moving with it. Current situation is that I select something and there is a chance that it will move away before I can copy it. And even worse, I might copy something completely different than I wanted.

Simple steps to reproduce: Select something, then press Enter few times.

Is there a way to permanently disable the size hint? It can be done using the context menu, which is not preserved across restarts. I couldn't find it neither in the profiles nor in general settings.

I've notice a minor difference in behavior between Bobcat and other terminals (tested with sakura and xfce4-termianl). When I run htop in those other terminals, the screen returns to "original state", hiding everything rendered by the htop. In Bobcat, the data from htop stay on the screen. Illustrative (hopefully) screenshot:

Not sure if it some glitch in rendering, or something wrongly configured on my side.

When new text appears in the buffer, it always scrolls down to show the new output. I'd prefer this to be configurable, i.e. to be able to make the buffer stay where I scrolled even as the new data appear at the bottom.

This comes in handy for example when tailing logs from application. Currently I can't scroll to some interesting part and read it, because the viewport moves back down each time new line appears, usually faster then I can read it.

Finder's powerful search functionality can be further exploited. Enter "Harvester".

• Add a method to harvest and save the matched patterns in regexp search mode.
  • map mode (keeps the horizontal order)
  • list mode
• Add a configurable delimiter for map mode.
• Add a configurable keyboard shortcut to Finder to activate harvester.
• Add the ability to save the harvested data as csv, json, xml, or plain text.
  • to file
  • to clipboard
  • as plain text
  • as CSV

Currently, double clicking in text selects a word, where word is defined as continuous run of alphanumeric characters or underscore (if I interpret the code in TerminalCtrl::GetWordSelection correctly). That is technically correct, but not always much useful.

Sometimes it would be much more pleasant to use, if the selection was smarter and could recognize bigger blocks of text that form single unit of information. Common use cases (for me) would be to use double click to select and then copy:

• file paths (contain also slashes and dots)
• links (can contain a lot of different characters)

I imagine that the exact rules how the double click selection works might be customizable, similar to how Linkifier works. User could configure a regular expresion(s) that would define what is a "word". The default could be the same as current behavior (so something like \b\B*\b or [_[:alnum:]]*).

Note that this is a low priority feature, I can happily live without it. But I believe it is one of those little things, that could make people happy when using this terminal :-)

The help system is in place. It's time to improve help documentation.

I have selected a piece of code from terminal and pasted it by middle click in editor and noticed some broken unicode chars at the point where the line was wrapped. The same thing also happens with Ctrl+Shift+C/V, even when pasting directly to terminal.

Here is a screenshot where I pasted the code directly to hexdump -C, to see what the extra bytes are:

Here is the text file used for the test: test.txt.