Testing GIFs.

Source imgur mp4 is attached to my first post above (44 kB)

Imgur mp4 passed through https://imgur.com/vidgif  (107 kB)


Imgur mp4 passed through https://cloudconvert.com/mp4-to-gif (166 kB)


Edit: yes that worked.

If you don't need audio - convert to GIF

-Stephen66515 (October 26, 2020, 09:23 AM)

I don't need audio, but mp4 file animations tend to have better quality and smaller filesize.

The FARR command dosearch lets an alias perform a new search and display the results. We can use search folder modifier keys and trigger long search patterns from a short alias. Great! But dosearch has no options to adjust the results line for each search match.

This request is an enhanced dosearch command, call it dosearchformatresults, that lets us format the search result lines.

One idea for the syntax is to put result formatting at the end after a frontslash and keyword, like for the FARR window options and /icon=... instructions. Like this

The result formatting part would have the syntax we can use for results in aliases plus special variables related to each search match file. Example:
In this example FARR would perform a dosearch for .html files and then for each match show a result line that when triggered shows the .html files inside FARR, rather than open it in the default .html application (external browser).

Probably some more complex escaping of characters and other ways to avoid weird conflicts/loops would be needed (recursive dosearchformatresults might cause weird issues for example  :D).

We can already achieve something like what I'm requesting via external scripts and appcapresults. But that is complex and FARR could probably do it quicker. The external workflow steps goes like this:
- FARR alias that passes a regex match from the typed string in FARR to an external script via dolaunch and appcapresult
- external script that searches some folder for e.g. .html files with filenames that match the passed string(s)
- for each match prepare a result line with the showfilehtml command
- result lines are passed back to FARR via stdout when the script exits
- FARR's appcapresult reads the results and displays them
- the user selects a result and presses Enter to view the HTML page inside FARR
In this external workflow FARR starts an external process and waits for it to finish for each typed character, which I've seen can cause some slowdowns.

This animation illustrates how it looks.
https://i.imgur.com/6LEOsFM.mp4

The .html files in the illustration are derived from the TLDR project - a neat collection of short usage examples for CLI commands in Linux/Windows -  that I've converted from Markdown (previous post related to that).

Background: I'm using FARR to show HTML files generated by Pandoc from Markdown source files with CSS similar to that of GitHub.

I ran into some CSS issues which got me searching for details on the browser engine/mode used by FARR. The forum posts I find on that are quite old and I'm not sure if they reflect the current state of FARR. Thus questions:

1. What browser engine/mode (not sure what the correct term is here) does FARR by default use on a fresh install of Windows 10 with latest updates? Edit: answered in edits below.
2. Are some FARR settings available to adjust what browser is used or some details on how it is used?

The help page https://www.donationcoder.com/Software/Mouser/findrun/help/html_view_mode.htm says

Html view mode is currently rendered using the IE activex dll as an embedded web browser.  This means that it will use the version of the Internet Explorer engine installed on the user's pc, and can support displaying anything that can be displayed in a normal browser.

It is not so clear if that means IE11.

One of my CSS issues was that FARR did not show the background color of inline code blocks in the HTML I tested with.

How it looks in Firefox/Chrome/Edge


How it looks in FARR


I tracked this down to the CSS using the color function RGBA which IE seems to not support
edit: My mistake. The correct RBGA() compatibility page says IE9+ is supported, IE6-8 is not.

Adding this line to the HTML
makes FARR show the code element background color just like in the external browsers.
I found that on https://stackoverflow.com/a/22964400 , with much more background on https://stackoverflow.com/a/6771584 .

So, workaround achieved, I suppose. But I'm unsure what other changes in how FARR renders HTML that line causes. Does it make FARR use Edge? Or adjust the IE1 version/mode used? I hope for feedback from mouser or others on this topic.

edit: Answering myself. We can check browser document mode by adding this line to the HTML document, which shows a popup when FARR renders it
Findings: Before adding the "<meta ..." line my FARR used document mode IE7. After adding the line FARR uses IE11.

That explains why the CSS RGBA() function, which required IE9+, only worked after adding the line. Note also that the "IE=edge" part does not mean that the browser Edge is used, it instead means that the newest available Internet Explorer document mode will be used. Which is IE11 on a fully updated Windows 10 PC today.


To reproduce my exact steps do this:

- download cmd.md from the tldr project GitHub.
- download this style.css that mimics GitHub's looks.
- download Pandoc
- run this to output the file cmd.html

- edit cmd.html and remove these lines (otherwise FARR will freeze and not show the HTML)

- create a FARR alias with this as result

- trigger the alias and notice that the code elements lack background color
- edit cmd.html again and add this below the <head> line
- trigger the alias again - now the background color should show.

BTW I'm reworking some of my FARR stuff which explains my many recent FARR posts. Bear with me mouser :)