Debug and fix image preview (reoccurring)

Hi,

On release page I can read this: "The following two 'Bugs' will be resolved by removing the dependency on the Scrollback patch which is currently work in progress: (...)".

My questions are:

• Do you have an idea on when the dependency on scrollback patch will be removed and those bugs fixed?
• I can see a lot of branches. Is one of them the "work in progress" of vim-browse not based on scrollback?

• color coded fg / bg for the command string on the bottom right corner, displayed in normal mode

• clean yank code, combine into one commit, split features, move them where they belong
• submit yank patch
  • a) with history patch directly applied
  • b) patch supposed to be put on top of history patch in case new updates arrive.
• submit alpha patch
  • a) with original alpha patch applied
  • b) to be placed on top of alpha patch)

Yank in normal mode copies the stuff in a ATTR_INVERSE mode, as it is currently selected. That is to be fixed.

• clean up the code conveyed in the vim patch
  • keep changes modular / in a different location from the st code for maintainability
  • make sure that 'public' functions can be called with arbitrary arguments and do not fail (e.g. check against inputs that currently cannot occur, but could occur if the function were used in a different was)
  • try to break down large (new) chunks of code into small ones (functions / files).
  • check the new code with static analysers
  • adhere to the code style used in the proj

Running xrdb -merge [file] seems to crash the terminal 🙈 (even if the file does not exist). Also on raw...

Provide implementation of the 'i' motion infix, such that yiw and viw or others work.

• functionality: implement i{'w', '{', ...}} as key combination
  • viw <=> bvw;
  • vi{ <=> ?{v/{

in general:

[operation]i[Letter] <=> b[motion]w i                      if letter is motion
                         ?[Letter]\n[operation]/[Letter]\n else

Conceptual Decision:
It is possible to issue a key combination when a key is pressed. For this scenario, when i is pressed, a part of the key combination is unknown, and the combination has to be triggered when the next letter is pressed. I guess the only way to solve this is to introduce a new state in the normal mode structure.

First off thanks for the fantastic st fork I couldn't use st without these features. However the only thing I cant find is an option to change the highlight color of the visual line/visual mode as it always seems to be the default white no matter what color option I change in config.h. The active row/column respect the color var but once I move them around in visual mode they only leave behind white highlighting.

When browsing while another command executes, the screen & buffer are filled incorrectly. Change that

• This can only be fixed if the schrollBack Patch is replaced by a better implementation; Ideally there is one large roundbuffer and the stuff currently displayed can be found in that roundbuffer at an offset.
  • There are to be distinct cursor positions for browsing and inserting.
  • in case the terminal width is resized, only increase the terminal buffer's width; when a terminal is resized after making it smaller, the content of the previous commands is not lost.
• port the current implementation to use the history patch that is created in the aforementioned task.

Patch developed here

Fix

• when searching in debug mode, a search string highlight is displayed and wals down when a letter is typed,
• reverse searching sometimes behaves strangely.
• double-reverse seems to be somewhat bugged
• when searching, and then exiting the norrmalMode by hitting 'i', the position is (sometimes) not reset correctly.

Releases + Feature

• new alpha release (formatting)
• new vim release (viw + {u,d,f,b}

• for now, based on alpha patch;

• in the future, it might be beneficial to provide the possibiltiy to execute custom code, but maybe that is too bloated; not requried to be changed on the fly and can be forked.

• search: do not start at the top when exceeding bottom and vice versa.
• position percentage at botom
• search string: change reset time.
• sometimes the command string / search string are not visible
• redo last command

• provide a special search mode which does not abort the search when the first entry was found, but searches the entire terminal history and reports the amount of occurrences and the current position when jumping between the occurrences).

• evoke same behavior as pressing ESC when pressing 'i' in normal mode

Hey there, I've been using this patch across the past several versions of ST and just wanted to say first off that it is one of my favorite patches available, but I've always had an issue with intermittent flickering of the background color when ST has focus -- but only appears to flicker when moving through the stack with the keyboard to give a window focus; using the mouse to hover over and focus a window does not reproduce the flicker.

Today I tested it out on the newset version of ST 0.8.4 to see if that somehow improves things, but its a lot worse than in 0.8.3, I can't seem to nail it down as to why. The issue is acknowledged for the previous version on i3wm and appears to describe exactly what I'm experiencing in DWM:

In i3WM, the focus event is triggered twice for one specific window on a workspace (could be the root); hence the alpha values are applied twice which appears as blinking.

I still had my old build based on ST 0.8.3 and the flickering is noticeable but significantly reduced, and appears at random. It seems to affect larger terminal windows more.

I've tried adjusting my picom.conf file as described in the one you have provied: https://github.com/juliusHuelsmann/Config/blob/master/.config/picom/picom.conf -- but this doesn't appear to have any effect

Interestingly, with the same build of both dwm and st on my laptop using the same picom configuration the issue is fine - my laptop has a 60hz panel. I only notice this flickering on my desktop which is connected to a 165hz panel -- not sure if that has anything to do with it, but I have a hunch it could be related.

Do you have any ideas about why the flickering is present more on 0.8.4 over 0.8.3? Again, I still have the flickering on 0.8.3 but it is intermittent and much less frequent. On 0.8.4 it is almost constant - but only when focusing windows with my keyboard rather than the mouse.

Hoping you have some insights! Please let me know if there is any other information you need from me.

Forwarding this issue here in hopes that patch maintainer take a look at this.
aligrudi/neatvi#16

I'm setting up st-0.9 on my new Gentoo machine using Gentoo's user patching facility. The alpha patch is working against this version, as are three scrollback patches. I have the alpha patch set as patch 1 and Alpha Focus Highlight as patch 2. This is the output I'm getting:

tux /home/rogue # emerge -av st

These are the packages that would be merged, in order:

Calculating dependencies... done!
Dependency resolution took 0.58 s.

[ebuild R ] x11-terms/st-0.9::gentoo USE="-savedconfig" 0 KiB

Total: 1 package (1 reinstall), Size of downloads: 0 KiB

Would you like to merge these packages? [Yes/No] Yes

Verifying ebuild manifests

Emerging (1 of 1) x11-terms/st-0.9::gentoo

• st-0.9.tar.gz BLAKE2B SHA512 size ;-) ... [ ok ]

Unpacking source...
Unpacking st-0.9.tar.gz to /var/tmp/portage/x11-terms/st-0.9/work
Source unpacked in /var/tmp/portage/x11-terms/st-0.9/work
Preparing source in /var/tmp/portage/x11-terms/st-0.9/work/st-0.9 ...

• =============================================================================================================================================================================================================================================================================
• Applying user patches from /etc/portage/patches ...
• Applying 01-st-alpha-20220206-0.8.5.diff ... [ ok ]
• Applying 02-st-alphaFocusHighlight-20200216-26cdfeb.diff ...
  patching file config.def.h
  Hunk #1 succeeded at 96 with fuzz 2 (offset 14 lines).
  Hunk #2 FAILED at 113.
  Hunk #3 FAILED at 121.
  2 out of 3 hunks FAILED -- saving rejects to file config.def.h.rej
  patching file config.mk
  Hunk #1 FAILED at 16.
  1 out of 1 hunk FAILED -- saving rejects to file config.mk.rej
  patching file st.h
  Hunk #1 FAILED at 121.
  1 out of 1 hunk FAILED -- saving rejects to file st.h.rej
  patching file x.c
  Hunk #2 FAILED at 106.
  Hunk #3 FAILED at 243.
  Hunk #4 succeeded at 254 with fuzz 2 (offset 3 lines).
  Hunk #5 FAILED at 721.
  Hunk #6 succeeded at 794 (offset 35 lines).
  Hunk #7 FAILED at 795.
  Hunk #8 FAILED at 1105.
  Hunk #9 FAILED at 1119.
  Hunk #10 FAILED at 1139.
  Hunk #11 succeeded at 1810 (offset 78 lines).
  Hunk #12 succeeded at 2081 with fuzz 2 (offset 75 lines).
  7 out of 12 hunks FAILED -- saving rejects to file x.c.rej [ !! ]
• ERROR: x11-terms/st-0.9::gentoo failed (prepare phase):
• patch -p1 failed with /etc/portage/patches/x11-terms/st-0.9/02-st-alphaFocusHighlight-20200216-26cdfeb.diff
• Call stack:

•           ebuild.sh, line  136:  Called src_prepare
  

•         environment, line 1717:  Called default
  

•  phase-functions.sh, line  872:  Called default_src_prepare
  

•  phase-functions.sh, line  948:  Called __eapi8_src_prepare
  

•         environment, line  324:  Called eapply_user
  

•         environment, line  635:  Called eapply '/etc/portage/patches/x11-terms/st-0.9/02-st-alphaFocusHighlight-20200216-26cdfeb.diff'
  

•         environment, line  598:  Called _eapply_patch '/etc/portage/patches/x11-terms/st-0.9/02-st-alphaFocusHighlight-20200216-26cdfeb.diff'
  

•         environment, line  536:  Called __helpers_die 'patch -p1  failed with /etc/portage/patches/x11-terms/st-0.9/02-st-alphaFocusHighlight-20200216-26cdfeb.diff'
  

• isolated-functions.sh, line 112: Called die
• The specific snippet of code:

•          die "$@"
  

• If you need support, post the output of emerge --info '=x11-terms/st-0.9::gentoo',
• the complete build log and the output of emerge -pqv '=x11-terms/st-0.9::gentoo'.
• The complete build log is located at '/var/tmp/portage/x11-terms/st-0.9/temp/build.log'.
• The ebuild environment file is located at '/var/tmp/portage/x11-terms/st-0.9/temp/environment'.
• Working directory: '/var/tmp/portage/x11-terms/st-0.9/work/st-0.9'
• S: '/var/tmp/portage/x11-terms/st-0.9/work/st-0.9'

Failed to emerge x11-terms/st-0.9, Log file:

'/var/tmp/portage/x11-terms/st-0.9/temp/build.log'

I've tried using different versions of the patch with no luck. The output above is from the patch posted at this issue: #24.

I really need this functionality. Can you please update the patch for st-0.9?

I think making the search circular is counter-intuitive; hence stop the search at the top / bottom of the terminal history

Branch: plainVimPatchV1

• Implement page up / down as Ctrl+{f,b}
• In order to do this, move the code chunk that is responsible to sort out the current vim motion kpressNormalMode from st.{c,h} to x.c; only issue calls to subroutines in st.c from there. This is necessary in order to have access to the x header files / xkey.

Branch: plainVimPatchV1

Search for regular expressions (e.g. search mode entered through 'r' / 'R'). This search mode can be used for instance in order to find links.

• provide a second distinct default background color for the focused window in addition to the different alpha value

Backward / forward search when pressing key, ranging over the entire terminal history and jumping to the last position.

Could -- at first glance -- also be made using external pipe, but integration with terminal will suck (goto position).

they only gain transparency when the focus is moved away from them, i used unmodified st other than scrollback support added, and no compilation errors when building. this is from the latest version found on the suckless.org website on st 0.9.

sorry if there is something obvious i'm missing.

The vimbrowse patch contains the following hunk for st.h:

@@ -33,6 +36,8 @@ enum glyph_attribute {
        ATTR_WRAP       = 1 << 8,
        ATTR_WIDE       = 1 << 9,
        ATTR_WDUMMY     = 1 << 10,
+       ATTR_HIGHLIGHT  = 1 << 11 | ATTR_UNDERLINE,
+       ATTR_CURRENT    = 1 << 12,
        ATTR_BOLD_FAINT = ATTR_BOLD | ATTR_FAINT,
 };

This causes all underlined text to be white on a red background. However, if I just use:

        ATTR_WRAP       = 1 << 8,
        ATTR_WIDE       = 1 << 9,
        ATTR_WDUMMY     = 1 << 10,
+       ATTR_HIGHLIGHT  = 1 << 11,
+       ATTR_CURRENT    = 1 << 12,
        ATTR_BOLD_FAINT = ATTR_BOLD | ATTR_FAINT,

then I don't have this issue.

I suspect you wanted to toggle underline for highlighted text, or always enable/disable underline for it, however:

	if (base.mode & ATTR_HIGHLIGHT) {
		base.bg = highlightBg;
		base.fg = highlightFg;
	} else if ((base.mode & ATTR_CURRENT) && (win.mode & MODE_NORMAL)) {
		base.bg = currentBg;
		base.fg = currentFg;
	}

will also match ATR_UNDERLINE. I think you better drop ATTR_UNDERLINE from ATTR_HIGHLIGHT, and define and use e.g. ATTR_UNDERLINE_HIGHLIGHT when setting the mode, or just use ATTR_UNDERLINE directly.

Apart from that: thank you for your work. I had combined keyboard-selection and scrollback, but your patch finally convinced me to use st as my default terminal emulator.