shabble / irssi Goto Github PK

Per title.

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

As above. Edit here to add proposed functionality

have /help look into scripts for a

sub HELP {
 ...
}

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

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.

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.

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

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.

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.

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)

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

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

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

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)

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, ...)

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.

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.

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.)