viewer / quick view mode



Hello.

I can see what you meant when you said the hex viewer is just one big
hack.  It looks like one of those cool after-thoughts, that kept getting
more and more features ("I just need to fix two bytes!  Can you make it
edit?").  I've always felt that it deserves its own subdir like the editor.

So, I've been beating on the viewer a bit.

Some more stuff for your Hex Editor Fixit List:)
If I have the right panel set to 80 columns, quick view/hex mode won't
do 16 byte rows, I have to go up to 82 columns.  I see that's because of
the 2 columns used by the border. It bumps down to 12 byte rows even
though there's still plenty of room.  Perhaps we can get rid of the
vertical bars separating the 4 byte groups, and it would do 16 byte rows
even at 76 columns, with just a double space between 4 byte columns.  Of
course, then it doesn't look as good on standard 80 column displays,
with a big gap between the hex and text areas, so we leave them alone
unless view->widget.cols < 80.

The attached patch does the job for that.
hunk1: fixes bytes per line when cols < 80.
hunk2: stops printing vline when cols < 80
hunk3: fixes missing space between addresses and hexdump when
view->have_frame.

Another mention is that the hex mode of the viewer grabs the TAB key for
flipping between hex and text fields.  It means you have to use your
mouse to get into the other panel in quick view/hex mode, and you can't
TAB back into the hex editor either or even use the mouse to get back
in, so you're stuck in hex mode.  The TAB key just seems to stop
working. I have to exit mc and restart it to get it back.

If I switch the panel to info mode, then back to hex view mode, the hex
output is all on just one line, running right off the edge of the
screen, or sometimes just a single column of bytes.  If you do a
sigwinch a few columns to where it would have to recalculate
bytes_per_line anyway, it fixes itself.  It seems to miss
view_update_bytes_per_line() under some situations, or view->widget.cols
is not set properly.  I'm not at all sure where that one comes from.

One other thing about the viewer: if you resize your window badly while
in the viewer (either mode) or editor and return it to its original
size, when you leave the viewer, the left panel has been resized (much
smaller). It seems the sigwinch handler fixes the panels even when in
the viewer/editor and doesn't try to return them to their original
values (as per ini).  It almost calls for the ability to pull the panel
divider back and forth with the mouse.


Cheers,
Mr.Picky :)




--- mc-cvs-4.6.0-pre1-021003/mc/src/view.c	Thu Sep 26 16:13:47 2002
+++ mc-draft-4.6.0-pre1-021003/src/view.c	Sun Oct  6 11:01:42 2002
@@ -646,7 +646,10 @@
 	cols = view->widget.cols;
 
     view->bottom_first = -1;
-    view->bytes_per_line = ((2 * (cols - 8) / 9) & 0xfffc);
+    if ( cols < 80 )
+        view->bytes_per_line = ((cols - 8) / 17) * 4;
+    else
+        view->bytes_per_line = ((cols - 8) / 18) * 4;
     
     if (view->bytes_per_line == 0)
 	view->bytes_per_line++;		/* To avoid division by 0 */
@@ -853,7 +856,8 @@
 	    attrset (NORMAL_COLOR);
 
 	    /* Hex dump starts from column nine */
-	    col = 9;
+	    if ( view->have_frame) col=10;
+	    else col = 9;
 
 	    /* Each hex number is two digits */
 	    hex_buff[2] = 0;
@@ -908,8 +912,13 @@
 		    view_gotoyx (view, row, col - 1);
 		    view_add_character (view, ' ');
 		    view_gotoyx (view, row, col);
-		    view_add_one_vline ();
-		    col += 2;
+		    if ( (view->have_frame && view->widget.cols < 82) || 
+			view->widget.cols < 80 )
+    			col += 1;
+		    else {
+			view_add_one_vline ();
+			col += 2;
+		    }
 
 		    if (boldflag != MARK_NORMAL
 			&& from ==



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]