#------------------#
# This is Todo.txt #
#------------------#

#option -bw means that only user defined colors are used not that the output is bw
	- make bw option bw only
	- add no-auto-color option

column order can be decided by user as well as if the column is displayed or not

compact vertical mode where the hexdump is always aligned to the left

! bitfield padding character '-', should be replaced by a character that disturbs the display less and maybe in a different color.

give start offset on the command line (may be done)

2/4/6/8 byte offset display depending on the offset of the actual data
	- also depends on start offset when the input data is a fragment for which we know the start offset
	- user can specify minimum with for offset display
	! - dimm offset to grey from white
	! - user offset color
	- may interfere on bitfield display that requires 8 character display
		- bit field is max 32 bits but can start at any offset in source data, how is the offset displayed
		if the offset is more than 0xff? 
		there an error in the way it is dsplayed today, it shifts te colums to the right after oxff


bitfield ruler
	- relevant only if the offset is less than 32

bitfiels offset should be writen the other way around when bit zero is on the right (default case)

bitfield with width value zero (0), still displays one bit

bitfields to ranges with zero data are displayed even when display_zero_byte_range is set to 0
	- should not be displayed
	- error is displayed correctly, even if nothing should be displayed

when display_zero_size_range_warning is set to 0, bitfields warning are still displayed
	Warning: bitfield description 'all bits' can't be applied to empty source

zero size range displays a warning instead for an empty data dump
	- currently quotes the range name with <>, as it should, but is not helpful enough

range name width auto calculated
	- length can be forced by user

make range separator, in string mode, user definable  a,12 : b,15 : c,3  vs   a,12 | b,15 | c,3 

align range fields in documentation examples

csv export, another format like ANSI, HTML, ...

error in documentation MYDATA should be BITMAp

# replace "oxff oxff ... skiped" with "skipped 0xff 0xff bytes"

# Do not show cumulative offset which is zero, first cumulative offset

Do not show extra zeroes in cumulative offset only the part that is necessary
	 means that all the ranges cumulative offset must be knows before deciding on format

! when displaying more than 2 lines of dump for the same range only the start on the last range name are displayed
	- continuation signs in the same color provide a clue

! color the offset as the data in vertical mode

make data split by _gather available through the API so user can use it in own code

!range has color attributes for the comment
	=> uses range color

range has a visibility field, a name
	- name  is used to decide if the range is is to e displayed or skipped
	this allows for a data dump definition with all the details but lets the user decide how much of the details are displayed
	- visibility can be set, by name, on the command line
	- multiple ranges can have the same visibility field name
	
	- applies to data ranges and bitfields
	- applies to comment, skip, and other ranges

	- when a range is made not visible, a message is optionaly displayed, log entry is added

	- if a data range is silenced, its corrsponding itfields are also silence

	- ranges are extracted and presented to the user and the ranges that can be made not visible showed

	- visibility field contains a default value, visible/not visible
		- lets the user defining the range setup a default display

	- multiple names can be assigned to the same range

full name for comment, skip and header ranges as well as shortcuts #, X, @

! ASCII ruler is always decimal and should be hexadecimal
	=> already hex

ruler and column name are displayed in a user definable color, today color is fixed to white

decimal and hexadecimal dump can co-exist but offset is in hexadecimal, should the co-existance be forbidden?

!previous_field_ color as a valid color name
	allows the user to define blocks of data colors, specially useful in bitmaps
	=> type the color

#error displayed when giving, eg, -r 'a,1:b3' is not clear enough
	- colorize the fields that are erroneous 
	- give example of valid definitions

option to display the ranges definitions in color and well aligned, with  field names instead for positon

hdr accepts multiple -r options
	-r can be of mixed types, string and file
	- skip fields can be used to synch between the -r ranges
		- skip fields can be hidden, visibily, default to 0
	- comment range to inform about the next data dump
	- skip range via perl sub can do dynamic synch
		- may need to push back data
	- range definition sub can, base on context, decide what the next data dump is 
 	
	- is offset cumulative or reset between data dumps?
		- offset reset range type can let the user decide when it is reset and to which values
	
cyclic ranges
	- given a user option is set, the ranges are applied on all the data available, if there is more data, the ranges are used again till the data is consumed

hdr accepts a stream of data instead for a set amount of data
	- need to rework the internals

in code, in documentation of sub, $container refers to real variable name $collected_data

in code, comment eeek! is to be replaced with code ... and @array == 1

option to show stats on dumped data
	- amount of data consummed
	- total fields displayed
	- total data per field name , since names can be reused
	- data skipped
	- data hidden

range object creation steps
	range array and string is first parsed and error are displayed if any, only then the ranges can be dumped. It would be
	preferable to handle the parsing of the ranges one by one and be able to dump the range information till an error is found
	this makes it easier for the user to find which range description is wrong

range warnings and errors
	- if a range detects an error (eg comment about size in examples), the range is displayed in a warning color, a warning is logged, all warning can be displayed after the dump is done


	- if an error is detected by a range sub, we must still display some information, offset, data, ... and the error

hdr provides a LOG that can be used by ranges, as it does INFO, DIE, ...

data gathered in chunks should be reference to the data and an offset
	- when stream mode is implemented, we may not have the data left

	- DUMP RANGE DESCRIPTION uses DTD and a reference to data could mean a very long dump for every field
		- this is already a problem if the range is long
		- dump of range should go through a method and the amount of data displayed controlled

in code $last_data should be a reference not a copy

range type 'recurrent header' 
	- displayed every x lines, defined by user, useful when a single range has many lines
	- may need a comment, or a recurrent comment type
	- the type is also named so multiple headers can be recurrent
	- setting a recurrent header to zero stops it

comments can be multi line

comment range can be implemented with sub which gets context information so it can generate text dynamically

in code, split.pm: 193
	range_source is a reference.

DUMP RANGE DESCRIPTION only displays relevant fields
	- or structure can be replaced by different types and have their own dumpers
	- make truncated ranges obvious

spacing column type to add space between column
	- or separator colum that can be any string, allowing '|' to be used to make it look more column like

Column can be repeated, eg, offset at beginin and end of line

#mixed hexadecimal and ascii dump
	63:c 6f:o

ranged defined in file can defined options to hdr
	- or options can be defined in separate file (what is the difference with a bash/perl file?)



	


vocabulary list
	field
	range
	data dump
	...


 



	- user can force color




make t/test_color.pl work, allows default color and user colors to co-exist

range error location is not very helpful as the location is the line where the object is defined not the line where the array is defined. It also doesn't help much to know that a structure with tens of lines failed, it would be good to pinpoint a location in the array.

	do not accept '::' as a valid range

	dump the whole range definition with DTD
		colorize the failing range
		colorize all ranges that would fail ?

	Text::Context
	PBS::Output::GetLineWithContext
	Carp::source

	# display the error range elements

tests
	#Can we get to Error: too few elements in range description 
	\&parser vs [\&parser]


refactoring
	do not cary a copy of the data in the ranges
	split should use $self->{FIELD_LENGTH}
	author tests
	spelling
	skip range code
	bitfield column display code
		cleaner
		more effective
	data flow and architectural overview
		specially for complex ranges
	remove ugly goto
