shabble / irssi Goto Github PK

see:

Irssi::UI::Theme::format_expand(Irssi::UI::Theme $theme, string $format, int
    $flags)
Irssi::UI::Theme::get_format(Irssi::UI::Theme $theme, string $module, string $tag)
Irssi::abstracts_register(SVptr $abstracts)

All of which are crippled in some way (forcing perl_package() on them, etc)

Also allow access to formats similar to the /format command.

Add support for searches with / and ?.

Search begins with /<pattern> or ?<pattern> from command mode.

Internally, runs a /lastlog <pattern> <$max_matches>, and consumes the result (not printed).

Parse timestamps or do other cunning matching things to find the position of each match in the scrollback.

Jump the window-item view back to the most recent match with /sb goto ...

Each subsequent / (or n) in command-mode moves to the next match in the buffer. ? moves in the opposite direction.

Any new pattern invalidates the current jump list.

TODO

• Need a way to cancel and jump back to /sb end
• Finding the actual position of the matches might be tricky (especially without timestamps, or non-standard formats)
  • Could compare entire lines by walking the window history, but that sounds slow.
• Is it possible to highlight the matched pattern onscreen? Probably not easily, without remove/readding the line entry, or using gui_print (which is transient)

partly in progress here; https://github.com/shabble/irssi-scripts/tree/master/testing

Needs more testing (ho ho), and maybe some internal irssi support to stop it from being so horribly slow.

As above. Edit here to add proposed functionality

overlaps a bit with issue #8 regarding whether scripts are loaded.
Otherwise, access to list of all loaded scripts would be nice

• Irssi::scripts() - returns a list of Irssi::Script objects
• Irssi::script_get($name) where name is either a package or filename (apply appropriate heuristics to check which, and return object or undef
• Irssi::script_load($name)`
• Irssi::script_unload($name)

have /help look into scripts for a

sub HELP {
 ...
}

in the same way UNLOAD() is called at script destruction

Currently, Irssi only supports 8 colours (16 if you count bright ones). Buidling Ncurses with --enable-ext-colors allows for
256 foreground and background colors (assumign a supporting terminal), which would allow for much more configurability in themes, etc.

Notes from a prior conversion:
<+ferret> in src/fe-text/term-terminfo.c:set_term_colors() the colour argument is an integer with lowest 4 bits for the foreground color and 5th-8th bits for the background colour <+ferret> that would need to be changed to 1-8 and 9-16 <+ferret> or split into two vars (I mean, come on? Why compress data that way?) <+ferret> Ahh... the upper 8 bits are also used for things like blink <+ferret> So you would definitely need to either make that var bigger or add another one <+ferret> Other than that the code doesn't look too hard to implement <+shabble> think of all the extra %num special vars you'd need! <+ferret> The money shot is in src/fe-text/terminfo-core.c, where you change terminfo_setup_colors to respect 256 color term environment and config option, setting term->TI_colors to 256 <+ferret> It creates an array of strings of either 8 or 256 colour entries, either returned from the setaf tput function or force generated as \e[%dm <+ferret> As a refinement you'd probably want to come up with a way of mapping the 256 entries to the basic 8 colours in the case the terminal doesn't support it. Code for that can be ripped from screen :D <+ferret> Yeah, there is that... but the formats parsing isn't particularly critical anyway, and you can make it greedy without causing too many problems. Just create a new %X where X is a letter that has two following bytes which are interpreted as hex in the range 0..255. Another letter for background colour. <+shabble> that could work <+shabble> although I suspect many things will assume % is only followed by a single char <+ferret> Let's find out. <+shabble> looks like fe-common/core/themes.c where it gets processed <+ferret> Nah <+ferret> There's no big switch statement in there <+ferret> There should be one :> <+ferret> It's in formats.c in the same directory <+shabble> ah, formats.c

Or at least, don't mention it so obviously, and provide an alternative reversal alias (/automatic-windows)

Things like is_script_loaded(), etc.

Probably some others, like actually loading them.

Hi Shabble,

I setup a buildserver and apt repository a while ago.

I'm using it mainly to host packages of my forks to make it easier to keep them deployed across hosts. If you'd like I can maintain and host packages of your irssi fork?

Richo

Currently, although commands exist to create/destroy keyboards, only a single one is ever created and used (in gui-readline.c:init())

By moving the actual keybindings state into the KEYBOARD_REC object, it should be possible to design an API in which
there are multiple defined keyboards, each with their own set of bindings. A perl API can then create/destroy and switch between
active keybinding maps.

Rationale: Various scripts could benefit from being able to bind keys in a modal fashion, without having to resort to capturing and reparsing gui key pressed each time. Allowing a script to create a new keyboard which has hte desired bindings/functions and
a 'default keyboard' binding to activate it will eliminate most of these issues.

Currently, only signals subscribed to with signal_add('foo', 'func_name') can be unbound. It should also be possible to
unbind signal_add('foo', \&func). Ditto for command_unbind.

Statusbars are currently fairly minimally supported by the scripting API.

Proposed features:

Package Irssi::

• statusbars_get() - return a list of Irssi::TextUI::Statusbar Objects
• statusbar_find($name) - return a specific Statusbar object
• statusbar_create($name, @params) - create a new statusbar with specified paramaters.
• statusbar_remove($name) - remove/delete the named bar.

Package Irssi::TextUI::Statusbar:: methods (implicit $statusbar->func() )

• get_items() - return a list of I::T::StatusbarItems for a given bar
• get_item($name) return a specific item
• remove_item($name)
• add_item($name, @params) - add an item to an sbar
• reset() - behaves as equiv. /sbar reset does.
• accessors (getter/setters) for various sbar parameters (Position, Placement, Type, Visible, ...)

print some standard format on script load?
add a { requires => [qw/a b c/] } section which checks if dependencies are loaded and tries to load them otherwise?

Maybe shouldn't be part of Irssi core, but integrated into scriptassist (the only thing that currently uses %IRSSI.

Add a new type of variable expansion, of the form $?name.

It should work similarly to $@ or $#, but should expand to:

nothing (empty string) if $name contains only whitespace,
the value of $name, if $name actually has content.

Can be used to replace $cumode/cumode_space, and
allow optional `msgnick = "$0 $1-" user mode in messages.

look at how to use
http://www.leonerd.org.uk/code/libtermkey/ to process incoming keystrokes, allowing many more options for binding keys (such as being able to distinguish ctrl-shift-s and the like.

Some interesting info at http://groups.google.com/group/vim_dev/browse_thread/thread/626e83fa4588b32a/20d707e705da3dad as well. (Not exclusively vim-related.)

Per title.

Probably using git format-patch, and keeping features in branches as necessary. Talk to Irssi maintainers about what format is preferred.

Or at least figure out what hte hell they actually mean.

make it easier than having to go through the ->view->textbuffercache... linked list, if possible.