summary refs log tree commit diff stats
path: root/compiler/evaltempl.nim
Commit message (Expand)AuthorAgeFilesLines
* pragma for sfCallsite instead of name check + better semantics, test (#20464)metagn2022-10-031-2/+2
* fix #16993, #18054, #17835 runnableExamples now works with templates and nest...Timothee Cour2021-06-021-4/+8
* IC: next steps (#16550)Andreas Rumpf2021-01-071-1/+1
* big steps torwards an efficient, simple IC implementation (#16543)Andreas Rumpf2021-01-021-1/+1
* explicit ID generation for easier IC (#15559)Andreas Rumpf2020-10-251-1/+4
* Fix forward declaration issues in template/macro context (#15091)Clyybber2020-07-291-3/+7
* Cosmetic compiler cleanup (#12718)Clyybber2019-11-281-18/+18
* Fix spellings (#12277) [backport]Federico Ceratto2019-09-271-1/+1
* Small ast.nim cleanup (#12156)Clyybber2019-09-091-2/+2
* fixes #12121 (#12126)Andreas Rumpf2019-09-051-1/+1
* new gensym handling (#11985)Andreas Rumpf2019-08-231-3/+11
* [refactoring] remove unused imports in the compiler and in some stdlib modulesAraq2019-07-181-2/+1
* Remove immediate pragma (#11308)Arne Döring2019-05-291-1/+1
* Replace countup(x, y-1) with x ..< yClyybber2019-05-071-3/+3
* fixes #10192Araq2019-05-061-1/+1
* it's spelt callsiteAndreas Rumpf2019-02-221-1/+1
* 32 bit fixes (#10608)Arne Döring2019-02-131-4/+3
* fixes nested gensym'ed parameters; fixes #9476Araq2018-12-081-4/+10
* IC: further progressAraq2018-12-011-1/+1
* docgen: fixes #9432 [backport]Araq2018-10-311-0/+20
* baby steps for incremental compilationAndreas Rumpf2018-05-301-1/+1
* remove more global variables in the Nim compilerAndreas Rumpf2018-05-271-5/+4
* remove ast.emptyNode global; cleanup configuration.nimAraq2018-05-161-1/+1
* fixes testament compilationAraq2018-05-141-1/+1
|\
| * Better support for treating templates and macros as symbols.Zahary Karadjov2018-05-071-1/+1
* | more modules compile againAndreas Rumpf2018-05-121-1/+1
* | more modules compile againAndreas Rumpf2018-05-121-10/+18
|/
* allow setting template/macro recursive evaluation limits (#7652)jcosborn2018-04-191-2/+3
* first steps in adding template/macro calls to stack tracesAraq2017-12-211-3/+7
* Fix usage of parameters types in templates #6756 (#6768)Anatoly Galiulin2017-11-291-1/+1
* deprecated unary '<'Andreas Rumpf2017-10-291-1/+1
* Fix #4020; Better handling of templates within conceptsZahary Karadjov2017-06-201-0/+2
* lift parameter-less do block to lambdasZahary Karadjov2017-04-101-5/+1
* fix the do notation when used with procsZahary Karadjov2017-04-091-1/+5
* Fixes #5167 and related problems (#5475)zah2017-03-121-0/+5
* macros are now checked to not produce cyclic ASTsAndreas Rumpf2017-02-081-1/+0
* make tests green againAraq2016-12-181-1/+1
* fixes #4308, fixes #4905Araq2016-12-181-1/+20
* hotfix: don't crash for wrong template callsAndreas Rumpf2016-06-031-1/+1
* remove funny debug outputAndreas Rumpf2016-05-271-1/+0
* fixes #4227Andreas Rumpf2016-05-271-4/+5
* Merge pull request #3500 from nanoant/patch/fix-3498-generic-args-in-tmplAndreas Rumpf2016-01-141-1/+2
|\
| * fixes #3498Adam Strzelecki2015-10-301-1/+2
* | better nimsuggest supportAraq2015-11-031-4/+4
|/
* fixes #3359Araq2015-09-231-3/+2
* compiler: Trim .nim files trailing whitespaceAdam Strzelecki2015-09-041-3/+3
* Disable the new generic params handling for immediate template and macrosZahary Karadjov2015-08-021-1/+11
* fix #1858 again; restores the support for static macro paramsZahary Karadjov2015-08-021-16/+34
* fixes #3044Araq2015-07-021-1/+3
* fixes #1940; code breakage! stricter template evaluationAraq2015-03-071-5/+5
href='#n66'>66 67 68 69 70 71 72 73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140

            


                                                  

            
 


                                                                                 
 


                                                                                
 






                                                
                                     
















































                                                                                
 
                                 
                                 
 
                                                                                 
                                                                             
                                                                                  




                                                                                 
                                                                            
 

                







                                                                                 
                                            

                                                                              
                                                           


                                                                                
                                                                               



                                                             

                     












                                                                            

                   













                                                                                
Colorschemes
============

This text explains colorschemes and how they work.

Context Tags
------------

Context tags provide information about the context and are Boolean values (`True`
or `False`). For example, if the tag `in_titlebar` is set, you probably want to
know about the color of a part of the titlebar now.

The default context tags are specified in `/ranger/gui/context.py` in the
constant `CONTEXT_KEYS`. Custom tags can be specified in a custom plugin file in
`~/.config/ranger/plugins/`. The code to use follows.

```python
# Import the class
import ranger.gui.context

# Add your key names
ranger.gui.context.CONTEXT_KEYS.append('my_key')

# Set it to False (the default value)
ranger.gui.context.Context.my_key = False

# Or use an array for multiple names
my_keys = ['key_one', 'key_two']
ranger.gui.context.CONTEXT_KEYS.append(my_keys)

# Set them to False
for key in my_keys:
    code = 'ranger.gui.context.Context.' + key + ' = False'
    exec(code)
```

As you may or may not have guessed, this only tells ranger that they exist, not
what they mean. To do this, you'll have to dig around in the source code. As an
example, let's walk through adding a key that highlights `README.md` files
differently. All the following code will be written in a standalone plugin file.

First, from above, we'll add the key `readme` and set it to `False`.

```python
import ranger.gui.context

ranger.gui.context.CONTEXT_KEYS.append('readme')
ranger.gui.context.Context.readme = False
```

Then we'll use the hook `hook_before_drawing` to tell ranger that our key is
talking about `README.md` files.

```python
import ranger.gui.widgets.browsercolumn

OLD_HOOK_BEFORE_DRAWING = ranger.gui.widgets.browsercolumn.hook_before_drawing

def new_hook_before_drawing(fsobject, color_list):
    if fsobject.basename === 'README.md':
        color_list.append('readme')

    return OLD_HOOK_BEFORE_DRAWING(fsobject, color_list)

ranger.gui.widgets.browsercolumn.hook_before_drawing = new_hook_before_drawing
```

Notice we call the old `hook_before_drawing`. This makes sure that we don't
overwrite another plugin's code, we just append our own to it.

To highlight it a different color, just [add it to your colorscheme][1]

[1]:#adapt-a-colorscheme

Implementation in the GUI Classes
---------------------------------

The class `CursesShortcuts` in the file `/ranger/gui/curses_shortcuts.py` defines
the methods `color(*tags)`, `color_at(y, x, wid, *tags)` and `color_reset()`.
This class is a superclass of `Displayable`, so these methods are available almost
everywhere.

Something like `color("in_titlebar", "directory")` will be called to get the
color of directories in the titlebar. This creates a `ranger.gui.context.Context`
object, sets its attributes `in_titlebar` and `directory` to True, leaves the
others as `False`, and passes it to the colorscheme's `use(context)` method.

The Color Scheme
----------------

A colorscheme should be a subclass of `ranger.gui.ColorScheme` and define the
method `use(context)`. By looking at the context, this use-method has to
determine a 3-tuple of integers: `(foreground, background, attribute)` and return
it.

`foreground` and `background` are integers representing colors, `attribute` is
another integer with each bit representing one attribute. These integers are
interpreted by the terminal emulator in use.

Abbreviations for colors and attributes are defined in `ranger.gui.color`. Two
attributes can be combined via bitwise OR: `bold | reverse`

Once the color for a set of tags is determined, it will be cached by default. If
you want more dynamic colorschemes (such as a different color for very large
files), you will need to dig into the source code, perhaps add a custom tag and
modify the draw-method of the widget to use that tag.

Run `tc_colorscheme` to check if your colorschemes are valid.

Specify a Colorscheme
---------------------

Colorschemes are searched for in these directories:

- `~/.config/ranger/colorschemes/`
- `/path/to/ranger/colorschemes/`

To specify which colorscheme to use, change the option `colorscheme` in your
rc.conf: `set colorscheme default`.

This means, use the colorscheme contained in either
`~/.config/ranger/colorschemes/default.py` or
`/path/to/ranger/colorschemes/default.py`.

Adapt a colorscheme
-------------------

You may want to adapt a colorscheme to your needs without having a complete copy
of it, but rather the changes only. Say, you want the exact same colors as in
the default colorscheme, but the directories to be green rather than blue,
because you find the blue hard to read.

This is done in the jungle colorscheme `ranger/colorschemes/jungle`, check it
out for implementation details. In short, I made a subclass of the default
scheme, set the initial colors to the result of the default `use()` method and
modified the colors how I wanted.

This has the obvious advantage that you need to write less, which results in
less maintenance work and a greater chance that your colorscheme will work with
future versions of ranger.