ctags-lang-python

title: ctags-lang-python(7)

text:
# ctags-lang-python(7)

## NAME
ctags-lang-python - Random notes about tagging python source code with Universal Ctags

## SYNOPSIS

```
ctags ... --languages=+Python ...
ctags ... --language-force=Python ...
ctags ... --map-Python=+.py ...
```

## DESCRIPTION
This man page gathers random notes about tagging python source code.

## TAGGING IMPORT STATEMENTS

### Summary
import X

name

kind

role

other noticeable fields

X

module

imported

N/A

import X as Y

name

kind

role

other noticeable fields

X

module

indirectlyImported

N/A

Y

namespace

definition

nameref:module:X

from X import *

name

kind

role

other noticeable fields

X

module

namespace

N/A

from X import Y

name

kind

role

other noticeable fields

X

module

namespace

N/A

Y

unknown

imported

scope:module:X

from X import Y as Z

name

kind

role

other noticeable fields

X

module

namespace

N/A

Y

unknown

indirectlyImported

scope:module:X

Z

unknown

definition

nameref:unknown:Y

### Examples
"input.py"

```
import X0
```

"output.tags" with "--options=NONE -o - --extras=+r --fields=+rzK input.py"

```
X0      input.py        /^import X0$/;" kind:module     roles:imported
```

A tag for an imported module has module kind with imported role. The module is not defined here; it is defined in another file. So the tag for the imported module is a reference tag; specify --extras=+r (or --extras=+{reference}) option for tagging it. "roles:" field enabled with --fields=+r is for recording the module is "imported" to the tag file.

"input.py"

```
import X1 as Y1
```

"output.tags" with "--options=NONE -o - --extras=+r --fields=+rzK --fields-Python=+{nameref} input.py"

```
X1      input.py        /^import X1 as Y1$/;"   kind:module     roles:indirectlyImported
Y1      input.py        /^import X1 as Y1$/;"   kind:namespace  roles:def       nameref:module:X1
```

"Y1" introduces a new name and is defined here. So "Y1" is tagged as a definition tag. "X1" is imported in a way that its name cannot be used in this source file. For letting client tools know that the name cannot be used, indirectlyImported role is assigned for "X1". "Y1" is the name for accessing objects defined in the module imported via "X1". For recording this relationship, nameref: field is attached to the tag of "Y1". Instead of module kind, namespace kind is assigned to "Y1" because "Y1" itself isn't a module.

"input.py"

```
from X2 import *
```

"output.tags" with "--options=NONE -o - --extras=+r --fields=+rzK input.py"

```
X2      input.py        /^from X2 import *$/;"  kind:module     roles:namespace
```

The module is not defined here; it is defined in another file. So the tag for the imported module is a reference tag. Unlike "X0" in "import X0", "X2" may not be used because the names defined in "X2" can be used in this source file. To represent the difference namespace role is attached to "X2" instead of imported.

"input.py"

```
from X3 import Y3
```

"output.tags" with "--options=NONE -o - --extras=+r --fields=+rzKZ input.py"

```
X3      input.py        /^from X3 import Y3$/;" kind:module     roles:namespace
Y3      input.py        /^from X3 import Y3$/;" kind:unknown    scope:module:X3 roles:imported
```

"Y3" is a name for a language object defined in "X3" module. "scope:module:X3" attached to "Y3" represents this relation between "Y3" and "X3". ctags assigns unknown kind to "Y3" because ctags cannot know whether "Y3" is a class, a variable, or a function from the input file.

"input.py"

```
from X4 import Y4 as Z4
```

"output.tags" with "--options=NONE -o - --extras=+r --fields=+rzKZ input.py"

```
X4      input.py        /^from X4 import Y4 as Z4$/;"   kind:module     roles:namespace
Y4      input.py        /^from X4 import Y4 as Z4$/;"   kind:unknown    scope:module:X4 roles:indirectlyImported
Z4      input.py        /^from X4 import Y4 as Z4$/;"   kind:unknown    roles:def       nameref:unknown:Y4
```

"Y4" is similar to "Y3" of "from X3 import Y3" but the name cannot be used here. indirectlyImported role assigned to "Y4" representing this. "Z4" is the name for accessing the language object named in "Y4" in "X4" module. "nameref:unknown:Y4" attached to "Z4" and "scope:module:X4" attached to "Y4" represent the relations.

## LAMBDA EXPRESSION AND TYPE HINT

### Summary
id = lambda var0: var0

name

kind

role

other noticeable fields

id

function

definition

signature:(var0)

id_t: Callable[[int], int] = lambda var1: var1

name

kind

role

other noticeable fields

id_t

variable

definition

typeref:typename:Callable[[int], int] nameref:function:anonFuncN

anonFuncN

function

definition

signature:(var1)

### Examples
"input.py"

```
from typing import Callable
id = lambda var0: var0
id_t: Callable[[int], int] = lambda var1: var1
```

"output.tags" with "--options=NONE -o - --sort=no --fields=+KS --fields-Python=+{nameref} --extras=+{anonymous} input.py"

```
id      input.py        /^id = lambda var0: var0$/;"    function        signature:(var0)
id_t    input.py        /^id_t: Callable[[int], int] = lambda var1: var1$/;"\

        variable        typeref:typename:Callable[[int], int]   nameref:function:anonFunc84011d2c0101
anonFunc84011d2c0101    input.py        /^id_t: Callable[[int], int] = lambda var1: var1$/;"\

        function        signature:(var1)
```

If a variable ("id") with no type hint is initialized with a lambda expression, ctags assigns function kind for the tag of "id".

If a variable ("id_t") with a type hint is initialized with a lambda expression, ctags assigns variable kind for the tag of "id_t" with typeref: and nameref: fields. ctags fills typeref: field with the value of the type hint. The way of filling nameref: is a bit complicated.

For the lambda expression used in initializing the type-hint'ed variable, ctags creates anonymous extra tag ("anonFunc84011d2c0101"). ctags fills the nameref: field of "id_t" with the name of anonymous extra tag: "nameref:function:anonFunc84011d2c0101".

You may think why ctags does so complicated, and why ctags doesn't emit following tags output for the input:

```
id      input.py        /^id = \\$/;"   function        signature:(var0)
id_t    input.py        /^id_t: \\$/;"  function        typeref:typename:Callable[[int], int]   signature:(var1)
```

There is a reason. The other languages of ctags obey the following rule: ctags fills typeref: field for a tag of a callable object (like function) with the type of its return value. If we consider "id_t" is a function, its typeref: field should have "typename:int". However, for filling typeref: with "typename:int", ctags has to analyze "Callable[[int], int]" deeper. We don't want to do so.

## SEE ALSO
ctags(1), ctags-client-tools(7), ctags-lang-iPythonCell(7)


ctags-lang-r

package: universal-ctags

title: ctags-lang-r(7)

text:
# ctags-lang-r(7)

## NAME
ctags-lang-r - Random notes about tagging R source code with Universal Ctags

## SYNOPSIS

```
ctags ... --languages=+R ...
ctags ... --language-force=R ...
ctags ... --map-R=+.r ...
```

## DESCRIPTION
This man page gathers random notes about tagging R source code with Universal Ctags.

## KINDS
If a variable gets a value returned from a well-known constructor and the variable appears for the first time in the current input file, the R parser makes a tag for the variable and attaches a kind associated with the constructor to the tag regardless of whether the variable appears in the top-level context or a function.

Well-known constructor and kind mapping

Constructor

kind

function()

function

c()

vector

list()

list

data.frame()

dataframe

If a variable doesn't get a value returned from one of well-known constructors, the R parser attaches globalVar or functionVar kind to the tag for the variable depending on the context.

Here is an example demonstrating the usage of the kinds:

"input.r"

```
G <- 1
v <- c(1, 2)
l <- list(3, 4)
d <- data.frame(n = v)
f <- function(a) {

        g <- function (b) a + b

        w <- c(1, 2)

        m <- list (3, 4)

        e <- data.frame(n = w)

        L <- 2
}
```

"output.tags" with "--options=NONE --sort=no --fields=+KZ -o - input.r"

```
G       input.r /^G <- 1$/;"    globalVar
v       input.r /^v <- c(1, 2)$/;"      vector
l       input.r /^l <- list(3, 4)$/;"   list
d       input.r /^d <- data.frame(n = v)$/;"    dataframe
n       input.r /^d <- data.frame(n = v)$/;"    nameattr        scope:dataframe:d
f       input.r /^f <- function(a) {$/;"        function
g       input.r /^      g <- function (b) a + b$/;"     function        scope:function:f
w       input.r /^      w <- c(1, 2)$/;"        vector  scope:function:f
m       input.r /^      m <- list (3, 4)$/;"    list    scope:function:f
e       input.r /^      e <- data.frame(n = w)$/;"      dataframe       scope:function:f
n       input.r /^      e <- data.frame(n = w)$/;"      nameattr        scope:dataframe:f.e
L       input.r /^      L <- 2$/;"      functionVar     scope:function:f
```

## SEE ALSO
ctags(1)


ctags-lang-rmarkdown

title: ctags-lang-rmarkdown(7)

text:
# ctags-lang-rmarkdown(7)

## NAME
ctags-lang-rmarkdown - Random notes about tagging R Markdown source code with Universal Ctags

## SYNOPSIS

```
ctags ...--extras=+{subparser}{guest} --languages=+RMarkdown ...
ctags ...--extras=+{subparser}{guest} --language-force=RMarkdown ...
ctags ...--extras=+{subparser}{guest} --map-RMarkdown=+.rmd ...
```

## DESCRIPTION
RMarkdown parser is an exclusive subparser stacked on top of the Markdown parser. It works when:

- the Markdown parser is enabled,

- the subparser extra is enabled, and

- the RMarkdown parser itself is enabled.

The RMarkdown parser extends the way of detecting codeblocks from the Markdown parser. This extension is for running guest parsers on code chunks.

The Markdown parser expects the following syntax represents codeblocks:

````
```language-name

        ...
```
````

For an example

````
```r

        ...
```
````

The RMarkdown parser accepts the following syntax for code chunks:

````
```{language-name chunk-label, ...}

        ...
```
````

For an example

````
```{r precalc fig.height=4}

        ...
```
````

Give --extras=+{guest} for enabling guest to command line if you want to run proper parsers on lines inside code chunks.

The parser extracts chunk labels coming after language-name as chunklabel kind objcts. In the exapmle, the RMarkdown parser extracts precalc as a chunklabel kind object. The chunklabel kind is enabled by default.

## EXAMPLES
"input.rmd"

````
# Section 1
```{r myblock}

        zero_fun <- function () {

                return 0

        }
```
# Section 2
````

"output.tags" with "--options=NONE --extras=+{guest} --fields=+KZln -o - input.rmd"

````
Section 1       input.rmd       /^# Section 1$/;"       chapter line:1  language:Markdown
Section 2       input.rmd       /^# Section 2$/;"       chapter line:9  language:Markdown
myblock input.rmd       /^```{r myblock}$/;"    chunklabel      line:3  language:RMarkdown
zero_fun        input.rmd       /^      zero_fun <- function () {$/;"   function        line:4  language:R
````

## SEE ALSO
ctags(1), ctags-client-tools(7), ctags-lang-r(7), R Markdown: The Definitive Guide


ctags-lang-sql

title: ctags-lang-sql(7)

text:
# ctags-lang-sql(7)

## NAME
ctags-lang-sql - The man page of the SQL parser for Universal Ctags

## SYNOPSIS

```
ctags ... [--extras={guest}] --languages=+SQL ...
```

## DESCRIPTION
The SQL parser supports various SQL dialects. PostgreSQL is one of them.

PostgreSQL allows user-defined functions to be written in other languages (procedural languages) besides SQL and C [PL].

The SQL parser makes tags for language objects in the user-defined functions written in the procedural languages if the guest extra is enabled.

The SQL parser looks for a token coming after LANGUAGE keyword in the source code to choose a proper guest parser.

```
... LANGUAGE plpythonu AS '... user-defined function ' ...
... AS $$ user-defined function $$ LANGUAGE plv8 ...
```

In the above examples, plpythonu and plv8 are the names of procedural languages. The SQL parser trims pl at the start and u at the end of the name before finding a ctags parser. For plpythonu and plv8, the SQL parser extracts python and v8 as the candidates of guest parsers.

For plpythonu, ctags can run its Python parser. ctags doesn't have a parser named v8. However, the JavaScript parser in ctags has v8 as an alias. So ctags can run the JavaScript parser as the guest parser for plv8.

## EXAMPLES
tagging code including a user-defined function in a string literal [GH3006]:

"input.sql"

```
CREATE OR REPLACE FUNCTION fun1() RETURNS VARCHAR AS '
DECLARE

        test1_var1 VARCHAR(64) := $$ABC$$;

        test1_var2 VARCHAR(64) := $xyz$XYZ$xyz$;

        test1_var3     INTEGER := 1;
BEGIN

        RETURN  TO_CHAR(test_var3, ''000'') || test1_var1 || test1_var2;
END;
' LANGUAGE plpgsql;
```

"output.tags" with "--options=NONE -o - --sort=no --extras=+{guest} input.sql"

```
fun1    input.sql       /^CREATE OR REPLACE FUNCTION fun1() RETURNS VARCHAR AS '$/;"    f
test1_var1      input.sql       /^      test1_var1 VARCHAR(64) := $$ABC$$;$/;"  v
test1_var2      input.sql       /^      test1_var2 VARCHAR(64) := $xyz$XYZ$xyz$;$/;"    v
test1_var3      input.sql       /^      test1_var3     INTEGER := 1;$/;"        v
```

tagging code including a user-defined function in a dollar quote [GH3006]:

"input.sql"

```
CREATE OR REPLACE FUNCTION fun2() RETURNS VARCHAR LANGUAGE plpgsql AS $$
DECLARE

        test2_var1 VARCHAR(64) := 'ABC2';

        test2_var2 VARCHAR(64) := 'XYZ2';

        test2_var3        INTEGER := 2;
BEGIN

        RETURN  TO_CHAR(test2_var3, '000') || test2_var1 || test2_var2;
END;
$$;
```

"output.tags" with "--options=NONE -o - --sort=no --extras=+{guest} input.sql"

```
fun2    input.sql       /^CREATE OR REPLACE FUNCTION fun2() RETURNS VARCHAR LANGUAGE plpgsql AS $\$$/;" f
test2_var1      input.sql       /^      test2_var1 VARCHAR(64) := 'ABC2';$/;"   v
test2_var2      input.sql       /^      test2_var2 VARCHAR(64) := 'XYZ2';$/;"   v
test2_var3      input.sql       /^      test2_var3        INTEGER := 2;$/;"     v
```

tagging code including a user-defined written in JavaScript:

```
-- Derived from https://github.com/plv8/plv8/blob/r3.0alpha/sql/plv8.sql
CREATE FUNCTION test(keys text[], vals text[]) RETURNS text AS
$$

        var o = {};

        for (var i = 0; i < keys.length; i++)

                o[keys[i]] = vals[i];

        return JSON.stringify(o);
$$
LANGUAGE plv8 IMMUTABLE STRICT;
```

"output.tags" with "--options=NONE -o - --sort=no --extras=+{guest} input.sql"

```
test    input.sql       /^CREATE FUNCTION test(keys text[], vals text[]) RETURNS text AS$/;"    f
o       input.sql       /^      var o = {};$/;" v
```

## KNOWN BUGS
Escape sequences ('') in a string literal may make a guest parser confused.

## SEE ALSO
ctags(1), ctags-client-tools(7)

## REFERENCES
[PL]

PostgreSQL 9.5.25 Documentation, "Chapter 39. Procedural Languages", https://www.postgresql.org/docs/9.5/xplang.html

[GH3006]

@bagl's comment submitted to https://github.com/universal-ctags/ctags/issues/3006


ctags-lang-systemtap

title: ctags-lang-systemtap(7)

text:
# ctags-lang-systemtap(7)

## NAME
ctags-lang-systemtap - Random notes about tagging SystemTap source code with Universal Ctags

## SYNOPSIS

```
ctags ... --languages=+SystemTap ...
ctags ... --language-force=SystemTap ...
ctags ... --map-SystemTap=+.stp ...
```

## DESCRIPTION
This man page gathers random notes about tagging SystemTap scripts.

### Guests
The SystemTap parser runs CPreProcessor as a guest parser on the areas surrounded by %{ and %}.

"input.stp"

```
%{
#define X 1
%}
```

"output.tags" with "--options=NONE -o - --sort=no --extras=+{guest} input.stp"

```
X       input.stp       /^#define X /;" d       file:
```

## VERSIONS

### Change since "0.0"
•

New role attached for probe kind

## SEE ALSO
ctags(1), SystemTap Language Reference (https://sourceware.org/systemtap/langref/)


ctags-lang-tcl

title: ctags-lang-tcl(7)

text:
# ctags-lang-tcl(7)

## NAME
ctags-lang-tcl - Random notes about tagging tcl source code with Universal Ctags

## SYNOPSIS

```
ctags ... --languages=+Tcl ...
ctags ... --language-force=Tcl ...
ctags ... --map-Tcl=+.tcl ...
```

## DESCRIPTION
This man page gathers random notes about tagging tcl source code.

## TAGGING LANGUAGE OBJECTS OF OO EXTENSIONS
TclOO parser and ITcl parser are subparsers running on the Tcl parser. As the names of parsers show, they are for tagging language objects of object oriented programming extensions for the Tcl language.

A pattern, "namespace import oo" in an input file activates the TclOO parser. A pattern, "namespace import itcl" in an input file activates the ITcl parser.

There are cases that one of the OO extensions is used though neither pattern are appeared in an input file.

Consider the following input files:

"main.tcl"

```
package require Itcl
namespace import itcl::*
source input.tcl
```

"input.tcl"

```
class MyClass {

        public method foo {} {

        }
}
```

The pattern for activating the ITcl parser is not appeared in "input.tcl" though "class" command is used. As a result, ctags cannot extract "MyClass".

The parameters TclOO.forceUse=true|[false] and ITcl.forceuse=true|[false] for handling this situation. With the parameter, you can force ctags to activate one of the subparsers.

You can use the parameters like --param-ITcl.forceuse=true in a command-line.

Note that you can enable only one of ITcl parser or TclOO parser. Enabling both parsers with specifying the parameters can cause unexpected results.

## SEE ALSO
ctags(1)


ctags-lang-terraform

title: ctags-lang-terraform(7)

text:
# ctags-lang-terraform(7)

## NAME
ctags-lang-terraform - Random notes about tagging Terraform files with Universal Ctags

## SYNOPSIS

```
ctags ... --languages=+Terraform ...
ctags ... --language-force=Terraform ...
ctags ... --map-Terraform=+.tf ...
ctags ... --extras=+{reference} --languages=+TerraformVariables ...
ctags ... --extras=+{reference} --language-force=TerraformVariables ...
ctags ... --extras=+{reference} --map-Terraform=+.tfvars ...
```

## DESCRIPTION
This man page gathers random notes about tagging Terraform files.

## TIPS

### Extracting variables assigned in Variable definitions
Specify --extras=+{reference} and --languages=+TerraformVariables to extract variables assigned in variables definitions (*.tfvars). The TerraformVariables parser extracts variables in *.tfvars files with variable kind with assigned role of Terraform language.

## KNOWN BUGS

- The parser doesn't ignore strings inside a block comment (/* ... */).

- The parser doesn't extract variables defined with locals keyword.

## SEE ALSO
ctags(1), Configuration Syntax (https://developer.hashicorp.com/terraform/language/syntax/configuration), Variable Definitions (.tfvars) Files (https://developer.hashicorp.com/terraform/language/values/variables#variable-definitions-tfvars-files)


ctags-lang-verilog

title: ctags-lang-verilog(7)

text:
# ctags-lang-verilog(7)

## NAME
ctags-lang-verilog - The man page about SystemVerilog/Verilog parser for Universal Ctags

## SYNOPSIS

```
ctags ... [--kinds-systemverilog=+Q] [--fields-SystemVerilog=+{parameter}] ...
ctags ... [--fields-Verilog=+{parameter}] ...
```

Language

Language ID

File Mapping

SystemVerilog

SystemVerilog

.sv, .svh, svi

Verilog

Verilog

.v

## DESCRIPTION
This man page describes about the SystemVerilog/Verilog parser for Universal Ctags. SystemVerilog parser supports IEEE Std 1800-2017 keywords. Verilog parser supports IEEE Std 1364-2005 keywords.

### Supported Kinds

```
$ ctags --list-kinds-full=SystemVerilog
#LETTER NAME       ENABLED REFONLY NROLES MASTER DESCRIPTION
A       assert     yes     no      0      NONE   assertions (assert, assume, cover, restrict)
C       class      yes     no      0      NONE   classes
E       enum       yes     no      0      NONE   enumerators
H       checker    yes     no      0      NONE   checkers
I       interface  yes     no      0      NONE   interfaces
K       package    yes     no      0      NONE   packages
L       clocking   yes     no      0      NONE   clocking
M       modport    yes     no      0      NONE   modports
N       nettype    yes     no      0      NONE   nettype declarations
O       constraint yes     no      0      NONE   constraints
P       program    yes     no      0      NONE   programs
Q       prototype  no      no      0      NONE   prototypes (extern, pure)
R       property   yes     no      0      NONE   properties
S       struct     yes     no      0      NONE   structs and unions
T       typedef    yes     no      0      NONE   type declarations
V       covergroup yes     no      0      NONE   covergroups
b       block      yes     no      0      NONE   blocks (begin, fork)
c       constant   yes     no      0      NONE   constants (parameter, specparam, enum values)
d       define     yes     no      0      NONE   text macros
e       event      yes     no      0      NONE   events
f       function   yes     no      0      NONE   functions
i       instance   yes     no      0      NONE   instances of module or interface
l       ifclass    yes     no      0      NONE   interface class
m       module     yes     no      0      NONE   modules
n       net        yes     no      0      NONE   net data types
p       port       yes     no      0      NONE   ports
q       sequence   yes     no      0      NONE   sequences
r       register   yes     no      0      NONE   variable data types
t       task       yes     no      0      NONE   tasks
w       member     yes     no      0      NONE   struct and union members
```

Note that prototype (Q) is disabled by default.

```
$ ctags --list-kinds-full=Verilog
#LETTER NAME     ENABLED REFONLY NROLES MASTER DESCRIPTION
b       block    yes     no      0      NONE   blocks (begin, fork)
c       constant yes     no      0      NONE   constants (parameter, specparam)
d       define   yes     no      0      NONE   text macros
e       event    yes     no      0      NONE   events
f       function yes     no      0      NONE   functions
i       instance yes     no      0      NONE   instances of module
m       module   yes     no      0      NONE   modules
n       net      yes     no      0      NONE   net data types
p       port     yes     no      0      NONE   ports
r       register yes     no      0      NONE   variable data types
t       task     yes     no      0      NONE   tasks
```

### Supported Language Specific Fields

```
$ ctags --list-fields=Verilog
#LETTER NAME      ENABLED LANGUAGE JSTYPE FIXED DESCRIPTION
-       parameter no      Verilog  --b    no    parameter whose value can be overridden.
$ ctags --list-fields=SystemVerilog
#LETTER NAME      ENABLED LANGUAGE      JSTYPE FIXED DESCRIPTION
-       parameter no      SystemVerilog --b    no    parameter whose value can be overridden.
```

### parameter field
If the field parameter is enabled, a field parameter: is added on a parameter whose value can be overridden on an instantiated module, interface, or program. This is useful for a editor plugin or extension to enable auto-instantiation of modules with parameters which can be overridden.

```
$ ctags ... --fields-Verilog=+{parameter} ...
$ ctags ... --fields-SystemVerilog=+{parameter} ...
```

On the following source code fields parameter: are added on parameters P*, not on ones L*. Note that L4 and L6 is declared by parameter statement, but fields parameter: are not added, because they cannot be overridden.

"input.sv"

```
// compilation unit scope
parameter L1 = "synonym for the localparam";
module with_parameter_port_list #(

        P1,

        localparam L2 = P1+1,

        parameter P2)

        ( /*port list...*/ );

        parameter  L3 = "synonym for the localparam";

        localparam L4 = "localparam";

        // ...
endmodule
module with_empty_parameter_port_list #()

        ( /*port list...*/ );

        parameter  L5 = "synonym for the localparam";

        localparam L6 = "localparam";

        // ...
endmodule
module no_parameter_port_list

        ( /*port list...*/ );

        parameter  P3 = "parameter";

        localparam L7 = "localparam";

        // ...
endmodule
```

```
$ ctags -uo - --fields-SystemVerilog=+{parameter} input.sv
L1      input.sv        /^parameter L1 = "synonym for the localparam";$/;"      c       parameter:
with_parameter_port_list        input.sv        /^module with_parameter_port_list #($/;"        m
P1      input.sv        /^      P1,$/;" c       module:with_parameter_port_list parameter:
L2      input.sv        /^      localparam L2 = P1+1,$/;"       c       module:with_parameter_port_list
P2      input.sv        /^      parameter P2)$/;"       c       module:with_parameter_port_list parameter:
L3      input.sv        /^      parameter  L3 = "synonym for the localparam";$/;"       c       module:with_parameter_port_list
L4      input.sv        /^      localparam L4 = "localparam";$/;"       c       module:with_parameter_port_list
with_empty_parameter_port_list  input.sv        /^module with_empty_parameter_port_list #()$/;" m
L5      input.sv        /^      parameter  L5 = "synonym for the localparam";$/;"       c       module:with_empty_parameter_port_list
L6      input.sv        /^      localparam L6 = "localparam";$/;"       c       module:with_empty_parameter_port_list
no_parameter_port_list  input.sv        /^module no_parameter_port_list$/;"     m
P3      input.sv        /^      parameter  P3 = "parameter";$/;"        c       module:no_parameter_port_list   parameter:
L7      input.sv        /^      localparam L7 = "localparam";$/;"       c       module:no_parameter_port_list
```

### Supported Roles

```
$ ./ctags --list-roles=SystemVerilog
#KIND(L/N) NAME ENABLED DESCRIPTION
m/module   decl on      declaring instances
$ ./ctags --list-roles=Verilog
#KIND(L/N) NAME ENABLED DESCRIPTION
m/module   decl on      declaring instances
```

The parser extracts names of modules used in instance declarations as reference tags. decl is the role for the tags. See "TAG ENTRIES" section of ctags(1) about reference tags and roles.

WARNING:

The support for references in Universal Ctags is still experimental; the names of the roles may be changed in the future.

### TIPS
If you want to map files *.v to SystemVerilog, add --langmap=SystemVerilog:.v option.

## KNOWN ISSUES
See https://github.com/universal-ctags/ctags/issues/2674 for more information.

## VERSIONS

### Change since "0.0"
•

New kind define

## SEE ALSO

- ctags(1)

- ctags-client-tools(7)

- Language Reference Manuals (LRM)

- IEEE Standard for SystemVerilog — Unified Hardware Design, Specification, and Verification Language, IEEE Std 1800-2017, https://ieeexplore.ieee.org/document/8299595

- IEEE Standard for Verilog Hardware Description Language, IEEE Std 1364-2005, https://ieeexplore.ieee.org/document/1620780


ctags-optlib

title: ctags-optlib(7)

text:
# ctags-optlib(7)

## NAME
ctags-optlib - Universal Ctags parser definition language

## SYNOPSIS

```
ctags [options] [file(s)]
etags [options] [file(s)]
```

## DESCRIPTION
Exuberant Ctags, the ancestor of Universal Ctags, has provided the way to define a new parser from command line. Universal Ctags extends and refines this feature. optlib parser is the name for such parser in Universal Ctags. "opt" intends a parser is defined with combination of command line options. "lib" intends an optlib parser can be more than ad-hoc personal configuration.

This man page is for people who want to define an optlib parser. The readers should read ctags(1) of Universal Ctags first.

Following options are for defining (or customizing) a parser:

- --langdef=<name>

- --map-<LANG>=[+|-]<extension>|<pattern>

- --kinddef-<LANG>=<letter>,<name>,<description>

- --regex-<LANG>=/<line_pattern>/<name_pattern>/<kind-spec>/[<flags>]

- --mline-regex-<LANG>=/<line_pattern>/<name_pattern>/<kind-spec>/{mgroup=<N>}[<flags>]

Following options are for controlling loading parser definition:

- --options=<pathname>

- --options-maybe=<pathname>

- --optlib-dir=[+]<directory>

The design of options and notations for defining a parser in Exuberant Ctags may focus on reducing the number of typing by user. Reducing the number of typing is important for users who want to define (or customize) a parser quickly.

On the other hand, the design in Universal Ctags focuses on maintainability. The notation of Universal Ctags is redundant than that of Exuberant Ctags; the newly introduced kind should be declared explicitly, (long) names are approved than one-letter flags specifying kinds, and naming rules are stricter.

This man page explains only stable options and flags. Universal Ctags also introduces experimental options and flags which have names starting with _. For documentation on these options and flags, visit Universal Ctags web site at https://ctags.io/.

### Storing a parser definition to a file
Though it is possible to define a parser from command line, you don't want to type the same command line each time when you need the parser. You can store options for defining a parser into a file.

ctags loads files (preload files) listed in "FILES" section of ctags(1) at program starting up. You can put your parser definition needed usually to the files.

--options=<pathname>, --options-maybe=<pathname>, and --optlib-dir=[+]<directory> are for loading optlib files you need occasionally. See "Option File Options" section of ctags(1) for these options.

As explained in "FILES" section of ctags(1), options for defining a parser listed line by line in an optlib file. Prefixed white spaces are ignored. A line starting with '#' is treated as a comment. Escaping shell meta character is not needed.

Use .ctags as file extension for optlib file. You can define multiple parsers in an optlib file but it is better to make a file for each parser definition.

--_echo=<msg> and --_force-quit=<num> options are for debugging optlib parser.

### Overview for defining a parser
1.

Design the parser You need know both the target language and the ctags' concepts (definition, reference, kind, role, field, extra). About the concepts, ctags(1) of Universal Ctags may help you.

2.

Give a name to the parser Use --langdef=<name> option. <name> is referred as <LANG> in the later steps.

3.

Give a file pattern or file extension for activating the parser Use --map-<LANG>=[+|-]<extension>|<pattern>.

4.

Define kinds Use --kinddef-<LANG>=<letter>,<name>,<description> option. Universal Ctags introduces this option. Exuberant Ctags doesn't have. In Exuberant Ctags, a kind is defined as a side effect of specifying --regex-<LANG>= option. So user doesn't have a chance to recognize how important the definition of kind.

5.

Define patterns Use --regex-<LANG>=/<line_pattern>/<name_pattern>/<kind-spec>/[<flags>] option for a single-line regular expression. You can also use --mline-regex-<LANG>=/<line_pattern>/<name_pattern>/<kind-spec>/{mgroup=<N>}[<flags>] option for a multi-line regular expression.

As <kind-spec>, you can use the one-letter flag defined with --kinddef-<LANG>=<letter>,<name>,<description> option.

## OPTIONS
--langdef=<name>

Defines a new user-defined language, <name>, to be parsed with regular expressions. Once defined, <name> may be used in other options taking language names. <name> must consist of alphanumeric characters, '#', or '+' ('[a-zA-Z0-9#+]+'). The graph characters other than '#' and '+' are disallowed (or reserved). Some of them ([-=:{.]) are disallowed because they can make the command line parser of ctags confused. The rest of them are just reserved for future extending ctags.

all is an exception. all as <name> is not acceptable. It is a reserved word. See the description of --kinds-(<LANG>|all)=[+|-](<kinds>|*) option in ctags(1) about how the reserved word is used.

NONE is another exception. NONE as <name> is not acceptable.

The names of built-in parsers are capitalized. When ctags evaluates an option in a command line, and chooses a parser, ctags uses the names of parsers in a case-insensitive way. Therefore, giving a name started from a lowercase character doesn't help you to avoid the parser name confliction. However, in a tags file, ctags prints parser names in a case-sensitive way; it prints a parser name as specified in --langdef=<name> option. Therefore, we recommend you to give a name started from a lowercase character to your private optlib parser. With this convention, people can know where a tag entry in a tag file comes from a built-in parser or a private optlib parser.

--kinddef-<LANG>=<letter>,<name>,<description>

Define a kind for <LANG>. Be not confused this with --kinds-<LANG>. <letter> must be an alphabetical character ('[a-zA-EG-Z]') other than "F". "F" has been reserved for representing a file since Exuberant Ctags.

<name> must start with an alphabetic character, and the rest must be alphanumeric ('[a-zA-Z][a-zA-Z0-9]*'). Do not use "file" as <name>. It has been reserved for representing a file since Exuberant Ctags.

Note that using a number character in a <name> violates the version 2 of tags file format though ctags accepts it. For more detail, see tags(5).

<description> comes from any printable ASCII characters. The exception is { and \. { is reserved for adding flags this option in the future. So put \ before { to include { to a description. To include \ itself to a description, put \ before \.

Both <letter>, <name> and their combination must be unique in a <LANG>.

This option is newly introduced in Universal Ctags. This option reduces the typing defining a regex pattern with --regex-<LANG>=, and keeps the consistency of kind definitions in a language.

The <letter> can be used as an argument for --kinds-<LANG> option to enable or disable the kind. Unless K field is enabled, the <letter> is used as value in the "kind" extension field in tags output.

The <name> surrounded by braces can be used as an argument for --kind-<LANG> option. If K field is enabled, the <name> is used as value in the "kind" extension field in tags output.

The <description> and <letter> are listed in --list-kinds output. All three elements of the kind-spec are listed in --list-kinds-full output. Don't use braces in the <description>. They will be used meta characters in the future.

--regex-<LANG>=/<line_pattern>/<name_pattern>/<kind-spec>/[<flags>]

Define a single-line regular expression. The /<line_pattern>/<name_pattern>/ pair defines a regular expression replacement pattern, similar in style to sed substitution commands, s/regexp/replacement/, with which to generate tags from source files mapped to the named language, <LANG>, (case-insensitive; either a built-in or user-defined language).

The regular expression, <line_pattern>, defines an extended regular expression (roughly that used by egrep(1)), which is used to locate a single source line containing a tag and may specify tab characters using \t.

When a matching line is found, a tag will be generated for the name defined by <name_pattern>, which generally will contain the special back-references \1 through \9 to refer to matching sub-expression groups within <line_pattern>.

The '/' separator characters shown in the parameter to the option can actually be replaced by any character. Note that whichever separator character is used will have to be escaped with a backslash ('\') character wherever it is used in the parameter as something other than a separator. The regular expression defined by this option is added to the current list of regular expressions for the specified language unless the parameter is omitted, in which case the current list is cleared.

Unless modified by <flags>, <line_pattern> is interpreted as a POSIX extended regular expression. The <name_pattern> should expand for all matching lines to a non-empty string of characters, or a warning message will be reported unless {placeholder} regex flag is specified.

A kind specifier (<kind-spec>) for tags matching regexp may follow <name_pattern>, which will determine what kind of tag is reported in the kind extension field (see tags(5)).

<kind-spec> has two forms: one-letter form and full form.

The one-letter form in the form of <letter>. It just refers a kind <letter> defined with --kinddef-<LANG>. This form is recommended in Universal Ctags.

The full form of <kind-spec> is in the form of <letter>,<name>,<description>. Either the kind <name> and/or the <description> can be omitted. See the description of --kinddef-<LANG>=<letter>,<name>,<description> option about the elements.

The full form is supported only for keeping the compatibility with Exuberant Ctags which does not have --kinddef-<LANG> option. Supporting the form will be removed from Universal Ctags in the future.

About <flags>, see "FLAGS FOR --regex-<LANG> OPTION".

For more information on the regular expressions used by ctags, see either the regex(5,7) man page, or the GNU info documentation for regex (e.g. "info regex").

--list-regex-flags

Lists the flags that can be used in --regex-<LANG> option.

--list-mline-regex-flags

Lists the flags that can be used in --mline-regex-<LANG> option.

--mline-regex-<LANG>=/<line_pattern>/<name_pattern>/<kind-spec>/{mgroup=<N>}[<flags>]

Define a multi-line regular expression. This option is similar to --regex-<LANG> option except the pattern is applied to the whole file’s contents, not line by line.

See "FLAGS FOR --mline-regex-<LANG> OPTION" about {mgroup=<N>}. {mgroup=<N>} flag is a must.

--_echo=<message>

Print <message> to the standard error stream. This is helpful to understand (and debug) optlib loading feature of Universal Ctags.

--_force-quit[=<num>]

Exits immediately when this option is processed. If <num> is used as exit status. The default is 0. This is helpful to debug optlib loading feature of Universal Ctags.

### FLAGS FOR --regex-<LANG> OPTION
You can specify more than one flag, <letter>|{<name>}, at the end of --regex-<LANG> to control how Universal Ctags uses the pattern.

Exuberant Ctags uses a <letter> to represent a flag. In Universal Ctags, a <name> surrounded by braces (name form) can be used in addition to <letter>. The name form makes a user reading an optlib file easier.

The most of all flags newly added in Universal Ctags don't have the one-letter representation. All of them have only the name representation. --list-regex-flags lists all the flags.

basic (one-letter form b)

The pattern is interpreted as a POSIX basic regular expression.

exclusive (one-letter form x)

Skip testing the other patterns if a line is matched to this pattern. This is useful to avoid using CPU to parse line comments.

extend (one-letter form e)

The pattern is interpreted as a POSIX extended regular expression (default).

pcre2 (one-letter form p, experimental)

The pattern is interpreted as a PCRE2 regular expression explained in pcre2syntax(3). This flag is available only if the ctags is built with pcre2 library. See the output of --list-features option to know whether your ctags is built-with pcre2 or not.

icase (one-letter form i)

The regular expression is to be applied in a case-insensitive manner.

placeholder

Don't emit a tag captured with a regex pattern. The replacement can be an empty string. See the following description of scope=... flag about how this is useful.

postrun

Match the pattern at the end of all the parsing processes, including:

- running the built-in code for <LANG>,

- applying --mline-regex-<LANG> patterns,

- applying --_mtable-regex-<LANG> patterns, and

- applying non-postrun --regex-<LANG>= patterns.

This flag is helpful when combined with scope=intervaltab.

The built-in code processes source files line-by-line delivered by the main part of ctags. The main part applies non-postrun --regex-<LANG>= patterns to a line just after delivering the line to the code of built-in code. Thus, non-postrun --regex-<LANG>= patterns cannot refer to the tags information finally extracted by the built-in code.

This is where the postrun comes into play. The main part never applies postrun --regex-<LANG>= patterns when delivering lines to the code of built-in code. Instead, it applies the postrun patterns in batch after delivering all lines to the built-in code. The postrun patterns can refer to the tags information extracted by the built-in code.

--mline-regex-<LANG> and --_mtable-regex-<LANG> have no {postrun} flag because the main part always applies the patterns specified with the options after running the built-in code for <LANG>.

See also the description of scope=intervaltab flag.

scope=intervaltab

Use the interval table maintaind by the main part of ctags to fill in the scope: field. This flag is useful for extending a built-in parser with the --regex-<LANG>= option with postrun flag. The interval table holds tag entries having both line: and end: fields. These tag entries are stored in a table keyed by their line: and end: field pairs. Therefore, the table can answer queries like, "Is there a tag entry that includes this line?" or "Which tag entry contains this line?"

The source line, where postrun --regex-<LANG> pattern finds a language object, can be a key for such queries. The tag entry returned by the table is set in the scope: field of the newly created tag entry for the language object.

postrun flag is needed for running the built-in parser that stores tag entries before applying patterns specified with --regex-<LANG>.

See also the example in "Using the interval table".

scope=(ref|push|pop|clear|set|replace)

Specify what to do with the internal scope stack. A parser programmed with --regex-<LANG> has a stack (scope stack) internally. You can use it for tracking scope information. The scope=... flag is for manipulating and utilizing the scope stack.

If {scope=push} is specified, a tag captured with --regex-<LANG> is pushed to the stack. {scope=push} implies {scope=ref}.

You can fill the scope field (scope:) of captured tag with {scope=ref}. If {scope=ref} flag is given, ctags attaches the tag at the top to the tag captured with --regex-<LANG> as the value for the scope: field.

ctags pops the tag at the top of the stack when --regex-<LANG> with {scope=pop} is matched to the input line.

Specifying {scope=clear} removes all the tags in the scope. Specifying {scope=set} removes all the tags in the scope, and then pushes the captured tag as {scope=push} does.

{scope=replace} does the three things sequentially. First it does the same as {scope=pop}, then fills the scope: field of the tag captured with --regex-<LANG>, and pushes the tag to the scope stack as if {scope=push} was given finally. You cannot specify another scope action together with {scope=replace}.

You don't want to specify {scope=pop}{scope=push} as an alternative to {scope=replace}; {scope=pop}{scope=push} fills the scope: field of the tag captured with --regex-<LANG> first, then pops the tag at the top of the stack, and pushes the captured tag to the scope stack finally. The timing when filling the end field is different between {scope=replace} and {scope=pop}{scope=push}.

In some cases, you may want to use --regex-<LANG> only for its side effects: using it only to manipulate the stack but not for capturing a tag. In such a case, make <name_pattern> component of --regex-<LANG> option empty while specifying {placeholder} as a regex flag. For example, a non-named tag can be put on the stack by giving a regex flag "{scope=push}{placeholder}".

You may wonder what happens if a regex pattern with {scope=ref} flag matches an input line but the stack is empty, or a non-named tag is at the top. If the regex pattern contains a {scope=ref} flag and the stack is empty, the {scope=ref} flag is ignored and nothing is attached to the scope: field.

If the top of the stack contains an unnamed tag, ctags searches deeper into the stack to find the top-most named tag. If it reaches the bottom of the stack without finding a named tag, the {scope=ref} flag is ignored and nothing is attached to the scope: field.

When a named tag on the stack is popped or cleared as the side effect of a pattern matching, ctags attaches the line number of the match to the end: field of the named tag.

ctags clears all of the tags on the stack when it reaches the end of the input source file. The line number of the end is attached to the end: field of the cleared tags.

warning=<message>

print the given <message> at WARNING level

fatal=<message>

print the given <message> and exit

### FLAGS FOR --mline-regex-<LANG> OPTION
mgroup=<N>

decide the location of the tag extracted with --mline-regex-<LANG> option. <N> is the number of a capture group in the pattern, which is used to record the line number location of the tag. mgroup=<N> flag is not an optional. You must add an mgroup=<N> flag, even if the <N> is 0 (meaning the start position of the whole regex pattern).

scope=intervaltab

See the description for the flag in "FLAGS FOR --regex-<LANG> OPTION". Unlike --regex-<LANG> option, you don't have to specify postrun flag.

## EXAMPLES

### Perl Pod
This is the definition (pod.ctags) used in ctags for parsing Pod (https://perldoc.perl.org/perlpod.html) file.

```
--langdef=pod
--map-pod=+.pod
--kinddef-pod=c,chapter,chapters
--kinddef-pod=s,section,sections
--kinddef-pod=S,subsection,subsections
--kinddef-pod=t,subsubsection,subsubsections
--regex-pod=/^=head1[ \t]+(.+)/\1/c/
--regex-pod=/^=head2[ \t]+(.+)/\1/s/
--regex-pod=/^=head3[ \t]+(.+)/\1/S/
--regex-pod=/^=head4[ \t]+(.+)/\1/t/
```

### Using scope regex flags
Let's think about writing a parser for a very small subset of the Ruby language.

input source file (input.srb):

```
class Example

  def methodA

        puts "in class_method"

  end

  def methodB

        puts "in class_method"

  end
end
```

The parser for the input should capture Example with class kind, methodA, and methodB with method kind. methodA and methodB should have Example as their scope. end: fields of each tag should have proper values.

optlib file (sub-ruby.ctags):

```
--langdef=subRuby
--map-subRuby=.srb
--kinddef-subRuby=c,class,classes
--kinddef-subRuby=m,method,methods
--regex-subRuby=/^class[ \t]+([a-zA-Z][a-zA-Z0-9]+)/\1/c/{scope=push}
--regex-subRuby=/^end///{scope=pop}{placeholder}
--regex-subRuby=/^[ \t]+def[ \t]+([a-zA-Z][a-zA-Z0-9_]+)/\1/m/{scope=push}
--regex-subRuby=/^[ \t]+end///{scope=pop}{placeholder}
```

command line and output:

```
$ ctags --quiet --fields=+eK \
--options=./sub-ruby.ctags -o - input.srb
Example input.srb       /^class Example$/;"     class   end:8
methodA input.srb       /^  def methodA$/;"     method  class:Example   end:4
methodB input.srb       /^  def methodB$/;"     method  class:Example   end:7
```

### Using the interval table
Let's try to extract kernel threads defined in Linux kernel.

kthread_run is the function for creating and starting a kernel thread. For example, kswapd kernel thread is created with the function like (quoted from linux/mm/vmscan.c):

```
void kswapd_run(int nid)
{

                /* ... */

                pgdat->kswapd = kthread_run(kswapd, pgdat, "kswapd%d", nid);

                /* ... */
```

kthread-v1.ctags illustrates the way to extract the name of kernel threads appeared at the third argument of kthread_run.

kthread-v1.ctags:

```
--kinddef-C=K,kernelThread,the name of kernel thread in Linux kernel
--regex-C=/kthread_run\([^"]+"([^"]+)"/\1/K/
```

With kthread-v1.ctags, ctags emits the following tags:

```
$ ctags --options=linux/kthread-v1.ctags  -o - vmscan.c
...
kswapd%d        vmscan.c        /^... = kthread_run(kswapd, pgdat, "kswapd%d"...$/;"    K
...
```

Using the interval table, you can attach the name of the function where the kernel thread is defined.

kthread-v2.ctags:

```
--kinddef-C=K,kernelThread,the name of kernel thread in Linux kernel
--regex-C=/kthread_run\([^"]+"([^"]+)"/\1/K/{postrun}{scope=intervaltab}
```

With kthread-v2.ctags, ctags emits the following tags:

```
$ ctags --options=linux/kthread-v2.ctags  -o - vmscan.c
...
kswapd%d        vmscan.c        /^... = kthread_run(kswapd, pgdat, "kswapd%d"...$/;"    K       function:kswapd_run
...
```

With the new .ctags file, function:kswapd_run is attach to the tag entry as its scope field.

## SEE ALSO
The official Universal Ctags web site at:

https://ctags.io/

ctags(1), tags(5), regex(3), regex(7), egrep(1), pcre2syntax(3)

## AUTHOR
Universal Ctags project https://ctags.io/ (This man page partially derived from ctags(1) of Executable-ctags)

Darren Hiebert <dhiebert@users.sourceforge.net> http://DarrenHiebert.com/


unixODBC

package: unixODBC

title: unixODBC(7)

text:
# unixODBC(7)

## NAME
unixODBC - An ODBC implementation for Unix

## DESCRIPTION
ODBC is an open specification providing application developers with a predictable API with which to access data sources. Data sources include SQL servers and any data source with an ODBC driver.

The unixODBC project goals are to develop and promote unixODBC as the definitive standard for ODBC on non-Windows platforms.

The HTML-formatted "Administrator Manual" shipped with unixODBC provides additional details on configuration and usage to supplement these man pages.

## ENVIRONMENT VARIABLES
ODBCSYSINI

Sets the full path to the directory containing the unixODBC configuration files. By default, this is '/etc'.

ODBCINSTINI

Sets the name of the unixODBC driver configuration file. The file name is relative to ODBCSYSINI and is set by default to 'odbcinst.ini'.

ODBCINI

Sets the full path to the system-wide unixODBC configuration file containing Data Source Names (DSNs). By default, this is set to '/etc/odbc.ini'.

ODBCINSTUI

Sets the library name for the UI. The final name that is searched for is evaluated as "lib$ODBCINSTUI". By default, this variable is set to 'odbcinstQ4', so the resulting library name is 'libodbcinstQ4'.

ODBCSEARCH

Sets the configuration mode and determines where to look for configuration files. This variable must be set to one of ODBC_SYSTEM_DSN, ODBC_USER_DSN or ODBC_BOTH_DSN, which is the default value.

## SEE ALSO
isql(1), odbc_config(1), odbcinst(1), odbc.ini(5), odbcinst.ini(5)

"The unixODBC Administrator Manual (HTML)"

## AUTHORS
The authors of unixODBC are Peter Harvey <pharvey@codebydesign.com> and Nick Gorham <nick@lurcher.org>.

For a full list of contributors, refer to the AUTHORS file.

## COPYRIGHT
unixODBC is licensed under the GNU Lesser General Public License. For details about the license, see the COPYING file.


UPower

package: upower

title: UPower(7)

summary: System\-wide Power Management

text:
# UPower(7)

## NAME
UPower - System-wide Power Management

## DESCRIPTION
UPower provides an interface to enumerate power sources on the system and control system-wide power management. Any application can access the org.freedesktop.UPower service on the system message bus.

## AUTHOR
Written by David Zeuthen <davidz@redhat.com>, Richard Hughes <richard@hughsie.com> and with a lot of help from many others.

## BUGS
Please send bug reports to either the distribution or the DeviceKit mailing list, see http://lists.freedesktop.org/mailman/listinfo/devkit-devel on how to subscribe.

## SEE ALSO
PolicyKit(8), upowerd(8), upower(1)


vlfeat

package: vlfeat

title: vlfeat(7)

summary: VisionLab Features Library

text:
# vlfeat(7)

## NAME
VLFeat - VisionLab Features Library

## DESCRIPTION
VLFeat is a collection of computer vision algorithms with a special focus on image features such as SIFT and MSER.

The functionalities offered by the library can be accessed either through its API, or by means of command line and MATLAB programs. See the SEE ALSO section for a list of the related command line programs and for a pointer to the general documentation of the library.

## FILE SPECIFIERS (FILESPEC)
Some commands in VLFeat make use of `file specifiers' to associate to one or more input files the appropriate output/auxiliary files. A file specifier is a string such as `ascii://%.txt' and contains two pieces of information:

- The file format (in this case ascii). The supported formats depend on the particular application. Two common formats are ascii and bin(ary).

- A name transformation rule (in this case %.txt). This is used to transform the name an input file into the name of the corresponding output/auxiliary file. The transformed name is comput by extracting the basename of the input file substituting it to all occurences of the wildcard characer `%' in the transformation rule (`%%') passes the wildcard character untouched.

Recall that the basename of a file name is obtained by stripping the directory prefix (everything from the beginning up to the last `/' or `\' character) and extension (everything from the last `.' characeter (excluding the prefix) to the end).

For instance, the filespec `ascii://%.txt' and the input file `test.data' specify a file named `test.txt' in ascii (text) format.

### Partial file specifiers
Normally, a program provides default values for its file specifiers. In this case, partial file specifier (with only the file format or the name transformation rule are acceptable).

### File specifiers equivalent to a file name
A partial specifier such as `file.txt' is in effect equivalent to the file name `file.txt'. If the specifier is used in conjunction with multiple input files, this causes the same file to be accessed multile times.

## SEE ALSO
sift(1), mser(1)

A. Vedaldi and B. Fulkerson. VLFeat Library. http://www.vlfeat.org/


weston-bindings

package: weston

title: weston-bindings(7)

summary: a list of keyboard bindings for

text:
# weston-bindings(7)

## NAME
weston-bindings - a list of keyboard bindings for Weston - the reference Wayland compositor

## INTRODUCTION
The Weston desktop shell has a number of keyboard shortcuts. They are listed here.

## DESCRIPTION
Almost all keyboard shortcuts for Weston include a specified modifier mod which is determined in the file weston.ini(5).

mod + Shift + F

Make active window fullscreen

mod + K

Kill active window

mod + Shift + M

Maximize active window

mod + Shift + KEY_LEFT

Make the active window tiled left.

mod + Shift + KEY_RIGHT

Make the active window tiled right.

mod + Shift + KEY_UP

Make the active window tiled top.

mod + Shift + KEY_DOWN

Make the active window tiled bottom.

mod + Tab

Switch active window

Ctrl + Alt + Backspace

If supported, terminate Weston. (Note this combination often is used to hard restart Xorg.)

Ctrl + Alt + F

Toggle if Weston is fullscreen; only works when nested under a Wayland compositor

Ctrl + Alt + S

Share output screen, if possible

Ctrl + Alt + F1/F2/F3/F4/F5/F6/F7/F8

Switch virtual terminal, if possible

Super + S

Make a screenshot of the desktop

Super + R

Start or stop recording video of the desktop

### TOUCH / MOUSE BINDINGS
There are also a number of bindings involving a mouse:

<Touch>, <Left button>, <Right button>

Activate clicked window

Super + Alt + <Vertical Scroll>

Change the opacity of a window

mod + <Left button>

Click and drag to move a window

mod + Shift + <Left button>, mod + <Right button>, mod + <Touch>

Click and drag to resize a window

mod + <Middle button>

Rotate the window (if supported)

### DEBUG BINDINGS
The combination mod + Shift + Space begins a debug binding. Debug bindings are completed by pressing an additional key. For example, pressing M may cycle through the GL renderer debug modes. Most debug effects can be disabled again by repeating the command. Debug bindings are often tied to specific backends. Below are the debug bindings available.

- KEY_D : Subscribe for flight recorder.

- KEY_C : Enable/Disable cursor planes.

- KEY_V : Enable/Disable overlay planes.

- KEY_Q : Start VAAPI recorder.

- KEY_M : Cycle through gl-renderer debug modes: none, wireframe, batches, damage, opaque.

- KEY_R : Enable repaint debugging for Pixman.

## SEE ALSO
weston(1), weston-drm(7), weston.ini(5), xkeyboard-config(7)


weston-drm

title: weston-drm(7)

summary: the DRM backend for Weston

text:
# weston-drm(7)

## NAME
weston-drm - the DRM backend for Weston

## SYNOPSIS
weston --backend=drm

## DESCRIPTION
The DRM backend is the native Weston backend for systems that support the Linux kernel DRM, kernel mode setting (KMS), and evdev input devices. It is the recommended backend for desktop PCs, and aims to provide the full Wayland experience with the "every frame is perfect" concept. It also relies on the Mesa GBM interface.

With the DRM backend, weston runs without any underlying windowing system. The backend uses the Linux KMS API to detect connected monitors. Monitor hot-plugging is supported. Input devices are found automatically by udev(7). Compositing happens mainly in GL ES 2, initialized through EGL. It is also possible to take advantage of hardware cursors and overlays, when they exist and are functional. Full-screen surfaces will be scanned out directly without compositing, when possible. Hardware accelerated clients are supported via EGL.

The backend chooses the DRM graphics device first based on seat id. If seat identifiers are not set, it looks for the graphics device that was used in boot. If that is not found, it finally chooses the first DRM device returned by udev(7). Combining multiple graphics devices is not supported yet.

The DRM backend also supports virtual outputs that are transmitted over an RTP session as a series of JPEG images (RTP payload type 26) to a remote client. Virtual outputs are configured in the remote-output section of weston.ini.

## CONFIGURATION
The DRM backend uses the following entries from weston.ini.

### Section core
gbm-format=format

Sets the default pixel format for DRM KMS framebuffers. Format can be xrgb8888, xrgb2101010, rgb565 or others. Weston recognizes the names of most pixel formats defined by the kernel DRM subsystem in drm_fourcc.h header without the DRM_FORMAT_ prefix. The actually supported pixel formats depend on the DRM driver and hardware, and the renderer used. Using Pixman-renderer, DRM-backend supports xrgb8888, xrgb2101010, rgb565 and some of their permutations. The formats supported with GL-renderer depend on the EGL and OpenGL ES 2 or 3 implementations. The names are case-insensitive. This setting applies only to outputs in SDR mode, see eotf-mode in weston.ini(5). If the hardware platform supports hardware planes placed under the DRM primary plane type (underlays), specifying argb8888 would be needed for Weston to display content lifted into such hardware planes. If not specified, xrgb8888 is used. See also gbm-format in output section.

pageflip-timeout=milliseconds

sets Weston's pageflip timeout in milliseconds. This sets a timer to exit gracefully with a log message and an exit code of 1 in case the DRM driver is non-responsive. Setting it to 0 disables this feature.

### Section output
name=connector

The KMS connector name identifying the output, for instance LVDS1.

mode=mode

Specify the video mode for the output. The argument mode can be one of the words off to turn the output off, preferred to use the monitor's preferred video mode, or current to use the current video mode and avoid a mode switch. It can also be a resolution as:

mode=widthxheight

mode=widthxheight@refresh_rate

Specify a mode with a given refresh-rate measured in Hz.

mode=widthxheight@refresh_rate ratio

Here ratio is Picture Aspect-Ratio which can have values as 4:3, 16:9, 64:27, and 256:135. This resolution-format helps to select a CEA mode, if such a video mode is present in the mode-list of the output. CEA defines the timing of a video mode, which is considered as a standard for HDMI spcification and compliance testing. It defines each and every parameter of a video mode, like hactive, vactive, vfront, vback etc., including aspect-ratio information. For CEA modes, the drm layer, stores this aspect-ratio information in user-mode (drmModeModeInfo) flag bits 19-22. For the non-CEA modes a value of 0 is stored in the aspect-ratio flag bits.

Each CEA-mode is identified by a unique, Video Identification Code (VIC). For example, VIC=4 is 1280x720@60 aspect-ratio 16:9. This mode will be different than a non-CEA mode 1280x720@60 0:0. When the video mode 1280x720@60 0:0 is applied, since its timing doesn't exactly match with the CEA information for VIC=4, it would be treated as a non-CEA mode. Also, while setting the HDMI-AVI-Inforframe, VIC parameter will be given as '0'. If video mode 1280x720@60 16:9 is applied, its CEA timimgs matches with that of video mode with VIC=4, so the VIC parameter in HDMI-AVI-Infoframe will be set to 4.

Many a times, an output may have both CEA and non-CEA modes, which are similar in all resepct, differing only in the aspect-ratio. A user can select a CEA mode by giving the aspect-ratio, along with the other arguments for the mode. By omitting the aspect-ratio, user can specify the non-CEA modes. This helps when certification testing is done, in tests like 7-27, the HDMI-analyzer applies a particular CEA mode, and expects the applied mode to be with exactly same timings, including the aspect-ratio and VIC field.

The resolution can also be a detailed mode line as below.

mode=dotclock hdisp hsyncstart hsyncend htotal vdisp vsyncstart vsyncend vtotal hflag vflag

Use the given detailed mode line as the video mode for this output. The definition is the same as in xorg.conf(5), and cvt(1) can generate detailed mode lines.

transform=transform

Transform for the output, which can be rotated in 90-degree steps and possibly flipped. Possible values are normal, rotate-90, rotate-180, rotate-270, flipped, flipped-rotate-90, flipped-rotate-180, and flipped-rotate-270.

gbm-format=format

Set the DRM KMS framebuffer format for this specific output. If not set, the value from gbm-format option in core section is used for SDR mode outputs and xrgb2101010 for other modes. For the possible values for format see gbm-format option in core section. For SDR mode, see eotf-mode in weston.ini(7).

pixman-shadow=boolean

If using the Pixman-renderer, use shadow framebuffers. Defaults to true.

clone-of=name

Make this output (connector) a clone of another. The argument name is the name value of another output section. The referred to output section must exist. When this key is present in an output section, all other keys have no effect on the configuration.

force-on=true

Force the output to be enabled even if the connector is disconnected. Defaults to false. Note that mode=off will override force-on=true. When a connector is disconnected, there is no EDID information to provide a list of video modes. Therefore a forced output should also have a detailed mode line specified.

max-bpc=N

Set "max bpc" KMS property to value N, silently clamped to the hardware driver supported range. This artificially limits the driver chosen link bits-per-channel which may be useful for working around sink hardware (e.g. monitor) limitations. The default is 16 which is practically unlimited. If you need to work around hardware issues, try a lower value like 8. A value of 0 means that the current max bpc will be reprogrammed.

### Section remote-output
name=name

Specify unique name for the output.

mode=mode

Specify the video mode for the output. The argument mode is a resolution setting, such as:

mode=widthxheight

mode=widthxheight@refresh_rate

If refresh_rate is not specified it will default to a 60Hz.

host=host

Specify the host name or IP Address that the remote output will be transmitted to.

port=port

Specify the port number to transmit the remote output to. Usable port range is 1-65533.

gst-pipeline=pipeline

Specify the gstreamer pipeline. It is necessary that source is appsrc, its name is "src", and sink name is "sink" in pipeline. Ignore port and host configuration if the gst-pipeline is specified.

## OPTIONS
When the DRM backend is loaded, weston will understand the following additional command line options.

--current-mode

By default, use the current video mode of all outputs, instead of switching to the monitor preferred mode.

--drm-device=cardN

Use the DRM device cardN for rendering and output instead of the default heuristics based on seat assignments and boot VGA status. For example, use card0.

--additional-devices=cardN

Comma separated list of secondary DRM devices cardM,cardN that will only be used as outputs, but not for rendering. For example, use card1,card2.

--seat=seatid

Use graphics and input devices designated for seat seatid instead of the seat defined in the environment variable XDG_SEAT. If neither is specified, seat0 will be assumed.

--continue-without-input

Allow Weston to start without input devices. Used for testing purposes.

## ENVIRONMENT
WESTON_LIBINPUT_LOG_PRIORITY

The minimum libinput verbosity level to be printed to Weston's log. Valid values are debug, info, and error. Default is info.

XDG_SEAT

The seat Weston will start on, unless overridden on the command line.

## SEE ALSO
weston(1)


weston-rdp

title: weston-rdp(7)

summary: the RDP backend for Weston

text:
# weston-rdp(7)

## NAME
weston-rdp - the RDP backend for Weston

## SYNOPSIS
weston --backend=rdp

## DESCRIPTION
The RDP backend allows to run a weston environment without the need of specific graphic hardware, or input devices. Users can interact with weston only by connecting using the RDP protocol.

The RDP backend uses FreeRDP to implement the RDP part, it acts as a RDP server listening for incoming connections. It supports different codecs for encoding the graphical content. Depending on what is supported by the RDP client, the backend will encode images using remoteFx codec, NS codec or will fallback to raw bitmapUpdate.

On the security part, the backend supports RDP security or TLS, keys and certificates must be provided to the backend depending on which kind of security is requested. The RDP backend will announce security options based on which files have been given.

The RDP backend is multi-seat aware, so if two clients connect on the backend, they will get their own seat.

## CONFIGURATION
The RDP backend uses the following entries from weston.ini.

### Section rdp
refresh-rate=rate

Specifies the desktop redraw rate in Hz. If unspecified, the default is 60Hz. Changing this may be useful if you have a faster than 60Hz display, or if you want to reduce updates to reduce network traffic.

tls-key=file

The file containing the key for doing TLS security. To have TLS security you also need to ship a file containing a certificate.

tls-cert=file

The file containing the certificate for doing TLS security. To have TLS security you also need to ship a key file.

## OPTIONS
When the RDP backend is loaded, weston will understand the following additional command line options.

--address=address

The IP address on which the RDP backend will listen for RDP connections. By default it listens on 0.0.0.0.

--port=port

The TCP port to listen on for connections, it defaults to 3389.

--no-clients-resize

By default when a client connects on the RDP backend, it will instruct weston to resize to the dimensions of the client's announced resolution. When this option is set, weston will force the client to resize to its own resolution.

--no-remotefx-codec

The RemoteFX compression codec is enabled by default, but it may be necessary to disable it to work around incompatibilities between implementations. This option may be removed in the future when all known issues are resolved.

--rdp4-key=file

The file containing the RSA key for doing RDP security. As RDP security is known to be insecure, this option should be avoided in production.

--rdp-tls-key=file

The file containing the key for doing TLS security. To have TLS security you also need to ship a file containing a certificate.

--rdp-tls-cert=file

The file containing the certificate for doing TLS security. To have TLS security you also need to ship a key file.

--external-listener-fd=fd

Specifies a file descriptor inherited from the process that launched weston to be listened on for client connections. Only local (such as AF_VSOCK) sockets should be used, as this will be considered to be a local connection by the RDP backend, and TLS and RDP security will be bypassed.

## Generating cryptographic material for the RDP backend
To generate a key file to use for RDP security, you need the winpr-makecert utility shipped with FreeRDP:

```
$ winpr-makecert -rdp -silent -n rdp-security
```

This will create a rdp-security.key file.

You can generate a key and certificate file to use with TLS security using a typical openssl invocations:

```
$ openssl genrsa -out tls.key 2048
Generating RSA private key, 2048 bit long modulus
[...]
$ openssl req -new -key tls.key -out tls.csr
[...]
$ openssl x509 -req -days 365 -signkey tls.key -in tls.csr -out tls.crt
[...]
```

You will get the tls.key and tls.crt files to use with the RDP backend.

## SEE ALSO
weston(1)


weston-vnc

title: weston-vnc(7)

summary: the VNC backend for Weston

text:
# weston-vnc(7)

## NAME
weston-vnc - the VNC backend for Weston

## SYNOPSIS
weston --backend=vnc

## DESCRIPTION
The VNC backend allows to run a weston environment without the need of specific graphic hardware, or input devices. Users can interact with weston only by connecting using the remote framebuffer protocol (RFB).

The VNC backend uses Neat VNC to implement the VNC part, it acts as a VNC server listening for incoming connections. It supports different encodings for encoding the graphical content, depending on what is supported by the VNC client.

The VNC backend is not multi-seat aware, so if a second client connects to the backend, the first client will be disconnected.

The VNC client has to authenticate as the user running weston. This requires a PAM configuration file /etc/pam.d/weston-remote-access.

## CONFIGURATION
The VNC backend uses the following entries from weston.ini.

### Section vnc
refresh-rate=rate

Specifies the desktop redraw rate in Hz. If unspecified, the default is 60Hz. Changing this may be useful if you have a faster than 60Hz display, or if you want to reduce updates to reduce network traffic.

tls-key=file

The file containing the key for doing TLS security. To have TLS security you also need to ship a file containing a certificate.

tls-cert=file

The file containing the certificate for doing TLS security. To have TLS security you also need to ship a key file.

### Section output
name=vnc

The name vnc is used to identify the VNC output.

mode=widthxheight

Specifies the (initial) size for the output.

resizeable=boolean

Specifies whether the VNC client is allowed to resize the output.

## OPTIONS
When the VNC backend is loaded, weston will understand the following additional command line options.

--address=address

The IP address on which the VNC backend will listen for VNC connections. By default it listens on 0.0.0.0.

--width=width

The width of the framebuffer. It defaults to 640.

--height=height

The height of the framebuffer. It defaults to 480.

--port=port

The TCP port to listen on for connections. It defaults to 5900.

--vnc-tls-key=file

The file containing the key for doing TLS security. To have TLS security you also need to ship a file containing a certificate.

--vnc-tls-cert=file

The file containing the certificate for doing TLS security. To have TLS security you also need to ship a key file.

--disable-transport-layer-security

Disable Transport Layer Security. If specified, VNC will be enabled with password-only authentication. This option is not recommended, as it creates security risk.

## Generating cryptographic material for the VNC backend
You can generate a key and certificate file to use with TLS security using typical openssl invocations:

```
$ openssl genrsa -out tls.key 2048
Generating RSA private key, 2048 bit long modulus
[...]
$ openssl req -new -key tls.key -out tls.csr
[...]
$ openssl x509 -req -days 365 -signkey tls.key -in tls.csr -out tls.crt
[...]
```

You will get the tls.key and tls.crt files to use with the VNC backend.

## SEE ALSO
weston(1)


wireless

package: wireless-tools

title: wireless(7)

summary: Wireless Tools and Wireless Extensions

text:
# wireless(7)

## NAME
wireless - Wireless Tools and Wireless Extensions

## SYNOPSIS
iwconfig

iwpriv -a

## DESCRIPTION
The Wireless Extensions is an API allowing you manipulate Wireless LAN networking interfaces. It is composed of a variety of tools and configuration files. It is documented in more detail in the Linux Wireless LAN Howto.

The Wireless Tools are used to change the configuration of wireless LAN networking interfaces on the fly, to get their current configuration, to get statistics and diagnose them. They are described in their own man page, see below for references.

Wireless configuration is specific to each Linux distribution. This man page will contain in the future the configuration procedure for a few common distributions. For the time being, check the file DISTRIBUTIONS.txt included with the Wireless Tools package.

## DEBIAN 3.0
In Debian 3.0 (and later) you can configure wireless LAN networking devices using the network configuration tool ifupdown(8).

File :

/etc/network/interfaces

Form :

wireless-<function> <value>

wireless-essid Home

wireless-mode Ad-Hoc

See also :

/etc/network/if-pre-up.d/wireless-tools

/usr/share/doc/wireless-tools/README.Debian

## SuSE 8.0
SuSE 8.0 (and later) has integrated wireless configuration in their network scripts.

Tool :

Yast2

File :

/etc/sysconfig/network/wireless

/etc/sysconfig/network/ifcfg-*

Form :

WIRELESS_<function>=<value>

WIRELESS_ESSID="Home"

WIRELESS_MODE=Ad-Hoc

See also :

man ifup

info scpm

## ORIGINAL PCMCIA SCRIPTS
If you are using the original configuration scripts from the Pcmcia package, you can use this method.

File :

/etc/pcmcia/wireless.opts

Form :

*,*,*,*)

ESSID="Home"

MODE="Ad-Hoc"

;;

See also :

/etc/pcmcia/wireless

File PCMCIA.txt part of Wireless Tools package

## AUTHOR
Jean Tourrilhes - jt@hpl.hp.com

http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/

## SEE ALSO
iwconfig(8), iwlist(8), iwspy(8), iwpriv(8), iwevent(8).


wofi

package: wofi

title: wofi(7)

summary: Built in modes and other features

text:
# wofi(7)

## NAME
wofi - Built in modes and other features

## DESCRIPTION
Wofi contains several built in modes as well as a lot of other features including combi which are documented here.

The config options documented here are stripped of mode names. Mode specific config options are placed in the config file in the format mode-example_opt=val. For example dmenu has an option called parse_action which would be placed in the config as dmenu-parse_action=true.

## MODES
Currently wofi has 3 built in modes

1.

run - searches $PATH for executables and allows them to be run by selecting them.

2.

drun - searches $XDG_DATA_HOME/applications and $XDG_DATA_DIRS/applications for desktop files and allows them to be run by selecting them.

3.

dmenu - reads from stdin and displays options which when selected will be output to stdout.

In the event $XDG_DATA_HOME is not specified it defaults to ~/.local/share. If $XDG_DATA_DIRS is not specified it defaults to /usr/local/share:/usr/share.

Combi is not a mode however it does exist as a feature. You can use it by doing --show mode1,mode2,mode3,etc. You can mix and match any number of modes however each mode can only be loaded once so doing something like --show run,drun,run is not supported although I'm not sure why you'd do that in the first place.

## DMENU CONFIG OPTIONS
parse_action=BOOL

If true the result returned by dmenu will be stripped of image escape sequences and pango markup, default is false.

separator=CHAR

The character used to separate dmenu entries, default is \n.

print_line_num=BOOL

When an entry is selected the number of the line the entry was on is printed instead of the entry itself. This disables caching as it's fundamentally incompatible with it.

## RUN
In run mode holding ctrl while running an entry will cause arguments to be parsed even if always_parse_args=false. Holding shift will cause the entry to be run in a terminal.

## RUN CONFIG OPTIONS
always_parse_args=BOOL

If true spaces will not be treated as part of the executable name but rather as an argument separator equivalent to holding control while pressing enter, default is false.

show_all=BOOL

If true shows all the entries in path, this will show entries that have the same executable name, for example /bin/bash and /usr/bin/bash will be shown separately as bash instead of having one bash entry for the first one encountered, default is true.

print_command=BOOL

If true the executable that would be run will be printed to stdout instead of executing it, default is false.

## DRUN CONFIG OPTIONS
print_command=BOOL

If true the command used to launch the desktop file will be printed to stdout instead of invoking it, default is false.

display_generic=BOOL

If true then generic names will be displayed in () next to the application name, default is false.

## DRUN
When images are enabled drun mode will pull icon themes however being a GTK app it's possible you'll need to run gtk-update-icon-cache to get them to apply.

## LOCATIONS
There are 9 possible locations which can be specified either by name or by number, the number scheme is the same as in rofi and the corresponding number is listed next to the names below, the default is center.

1.

center 0

2.

top_left 1

3.

top 2

4.

top_right 3

5.

right 4

6.

bottom_right 5

7.

bottom 6

8.

bottom_left 7

9.

left 8

The x and y offsets are applied based on layer-shell anchors which means an x offset can only be applied if wofi is anchored on the x axis, i.e. you can only use an x offset with the top_left, top_right, right, bottom_right, bottom_left, and left locations. center, top, and bottom can't have x offsets as they're not anchored on the x axis. Likewise y offsets can only be applied to top_left, top, top_right, bottom_right, bottom, and bottom_left locations. center, left, and right can't have y offsets because they're not anchored to the y axis. Since center can't have offsets on either as it's not anchored to any axis any x or y offset applied while using center will override the location to top_left for backwards compatibility reasons seeing as not doing so would simply ignore the offsets anyway.

## ORDER
There are 2 order options currently, default and alphabetical. Default means the entries are displayed in the order they are added by the mode, for all built in modes this is cached items first, followed by other entries in no specific order. Alphabetical means entries are alphabetical sorted period. These orders only affect the order when no search has been entered. Once a search is entered the order is re-arranged based on the current matching preference and this order is ignored.

## CACHING
Caching cannot be disabled however the cache file can be set to /dev/null to effectively disable it.

## WINDOW SWITCHER
Wofi does not have the ability to do window switching on its own as there is no way to do this with wayland/wlroots protocols however if you're using sway you can use swaymsg with dmenu mode to accomplish it. The following script can be used to do window switching:

swaymsg -t get_tree |

jq -r '.nodes[].nodes[] | if .nodes then [recurse(.nodes[])] else [] end + .floating_nodes | .[] | select(.nodes==[]) | ((.id | tostring) + " " + .name)' |

wofi --show dmenu | {

read -r id name

swaymsg "[con_id=$id]" focus

}

## WIDGET LAYOUT
This section is for advanced CSS which needs more control than the built in wofi CSS names/classes allow for. This widget layout is subject to change at any time and without warning so your CSS might very well break if you rely on this. Widgets have their corresponding names next to them if they have one.

window - #window

box - #outer-box entry - #input scrolledwindow - #scroll

viewport box flowbox - #inner-box flowboxchild - #entry .entry - #unselected or #selected

This only exists if there's ONLY 1 action. This is a WofiPropertyBox which has no CSS node and should probably not be used, the name is dependent on whether or not the entry is selected. See wofi(5) on #selected and #unselected for info.

image

This is only present if an image is present in the entry and might occur multiple times if multiple images are present. label

This is only present if text is present in the entry and might occur multiple times if there are multiple text objects in a single entry.

expander

This and its children only exist if there are multiple actions on the entry

.entry - #unselected or #selected

The main action. This is a WofiPropertyBox which has no CSS node and should probably not be used, the name is dependent on whether or not the entry is selected. See wofi(5) on #selected and #unselected for info.

image

This is only present if an image is present in the entry and might occur multiple times if multiple images are present. label

This is only present if text is present in the entry and might occur multiple times if there are multiple text objects in a single entry.

list

This contains all the secondary actions

row - #entry .entry - #unselected or #selected

This is a WofiPropertyBox which has no CSS node and should probably not be used, the name is dependent on whether or not the entry is selected. See wofi(5) on #selected and #unselected for info.

image

This is only present if an image is present in the entry and might occur multiple times if multiple images are present. label

This is only present if text is present in the entry and might occur multiple times if there are multiple text objects in a single entry.

scrollbar