sefr (Search Engine FRontend)
Terminal program for interactively opening search engines / parametric URLs It's kinda like surfraw but with interactive suggestions (via parsing opensearch json).
I use custom url bar search engines a lot, but browser support for them is frustrating.
- Firefox has a really obtuse way of defining them, doesn't let you specify suggestion endpoints, and still doesn't sync them.
- Chrome makes defining them easy, syncs them, but doesn't let you specify suggestion endpoints.
- Vivaldi makes defining them easy, lets you specify suggestion endpoints, but doesn't sync them.
e.g. in stock Firefox, while you can create a bookmark keyword so that when you type "r foo" in your url bar, it automatically goes to "reddit.com/r/foo", you can't get completions, and you can't set it as the default search engine.
This is meant to be a customizable crossplatform solution, and since it uses your default browser (more details), you can integrate it into a GUI workflow with a global hotkey (see below).
There are two ways to install
- Clone this repository, install the Rust toolchain, and either call
cargo runin the cloned directory to try it out, or
cargo buildto create a binary located at
- Install via cargo by calling
cargo install sefr. This should make it runnable from anywhere.
A convenient way to integrate it into your desktop environment is by mapping a global hotkey to launch it in a lightweight terminal, making for rofi-like UX.
For example, I currently use this in KDE (using the fantastically lightweight suckless terminal), globally bound to Super+s, with a kwin rule that hides window decorations for wmclass=
st -n sefr -g 70x18 -f 'Monospace:size=14' -e ~/src/sefr/target/debug/sefr
For i3, this works well. Not sure why I have to specify
for_window [instance="^sefr$"] floating enable, resize set 640 480, move position center bindsym Mod4+s exec BROWSER=/usr/bin/firefox st -n sefr -f 'Monospace:size=14' -e ~/src/sefr/target/debug/sefr
Configuration / Customization
On its first startup,
sefr will automatically generate a TOML configuration file in the config directory provided by the directories crate. Any subsequent changes should be made inside it.
e.g. For Linux, the config file will be found in
Adding new engines
Warning: The current configuration format might be changed in the future!
New engines can be added for use by
sefr by adding them to the
A basic engine definition looks like this:
[engines.yt] name = "YouTube" search_url = "https://www.youtube.com/results?q=%s" suggestion_url = "http://suggestqueries.google.com/complete/search?client=firefox&ds=yt&q=%s"
[engines.PREFIX]defines what prefix (also known as a keyword or trigger) activates the engine.
nameis the name of the engine, used for the prompt text if not defined in the prompt section (more on that later).
search_urlis opened in your browser with
%sreplaced by the search term when enter is pressed.
suggestion_url(optional) is the endpoint queried for suggestions (with
%sreplaced by the search term) while typing. It must return OpenSearch suggestions schema json.
- In the default config,
engines.r(Subreddit) has it set to a blank string, because subreddits can't have spaces in their names (note that this value prevents spaces from being entered into the input buffer when the engine is selected so that space can be used to select a suggestion without performing a search).
- If you wanted to have a wikipedia search engine that goes directly to the article without the redirect in the default config, you could set
_in order to format the article name in the correct format.
- In the default config,
The engine used when no prefix is entered is defined as
_default in the config, and it is obligatory for the program to start. Example:
[engines._default] name = "Google" search_url = "https://www.google.com/search?q=%s" suggestion_url = "https://www.google.com/complete/search?client=chrome&q=%s"
Along with this, there is also an optional
prompt section which handles the prompt displayed when the engine is called. It will usually look like this:
[engines.yt.prompt] icon = " ▶ " icon_bg = "Red" icon_fg = "White" text = " Youtube " text_bg = "White" text_fg = "Black"
The following fields are supported, and all are optional:
icon: the icon displayed in the prompt
icon_bg: background color of the icon
icon_fg: foreground color of the icon
text: The text displayed after the icon in the prompt
text_bg: background color for the text
text_fg: foreground color for the text
text are padded with whitespace for aesthetics in the example configuration, but this is not required.
The fields are all strings except for colors (
*_fg). They can be strings (corresponding to the color names here), 8-bit numbers (corresponding to Ansi color codes), or 8-bit RGB tuples like
If this section is left out for a particular engine, a basic prompt displaying the engine's name will be used.
Keybindings are a work in progress, but all of the current functions are rebindable under the
Keybinds are in a vim-like syntax (e.g.
<F12>), but there are a few things to note:
The binding and action are double quoted. So the entire binding is a line like
"<Backspace>" = "DeleteChar".
All bindings are in except single characters (e.g. the literal letter
p, as in
"p" = "Exit"). But why would you make a binding like that?
Ctrlis represented by
<C-w>means 'control + w').
Altis represented by either
>is case-insensitive except the normal key after a modifier. That is,
<M-p>all mean the same thing ('alt + p') but
<m-P>means 'alt + shift + p'.
So that means there is no "shift" modifier. To register 'alt + shift + s' you'd write
'shift + tab' is represented by
'enter' can be
<Enter>. 'backspace' can be
An empty string represents the
NULLcharacter, whatever that is.
If you assign two functions two the same key, the one registered later will override the first.
Excerpt from the default config:
[keybinds] "<BackTab>" = "SelectPrev" "<Backspace>" = "DeleteChar" "<C-c>" = "Exit"
This project is currently in its alpha stage but is relatively stable.
- Suggestions request / json parse
- Definable engines with prefixes, prompts, and endpoints
- Browser launching
- Selection of suggestions w/ prefix edge cases
- TOML file config
- Use real cursor for rendering input buffer, and be able to move it
- Configurable keybindings
- Better feedback for when suggestion endpoints misbehave
- CLI args, e.g. providing the initial input buffer through an argument for aliasing.