Re: [Nano-devel] definition of filestruct with ENABLE_MULTIBUFFER

[David Lawrence Ramsey]

--- David Benbennick <address@hidden> wrote:

>I realized last night that if we have an
>openfilestruct->lineno variable (holding the line number of
>the current cursor position in this file), then we don't
>need filestruct->lineno.  Whenever the cursor changes
>lines, we would need to change openfilestruct->lineno, but
>on the other hand we would never need to call renumber().

That sounds as though it'd work.

>Also, we would save 4 bytes per line.

Only on a 32-bit system, but yes, we'd definitely save
space.

>So your first "minor bug", about where
open_file_sync_fileage() must be called.  It only needs to
be called in close_open_file(), but before the
open_nextfile().  The reason is that open_nextfile()
discards the current value of fileage without storing it to
open_files->fileage.  As far as I know, there is nowhere
else that discards the value of fileage, so
open_file_sync_fileage() need not be called when cutting or
uncutting, and also isn't necessary in do_exit() [which
calls close_open_file()].

Yes, that definitely works; thanks.  However, I just
thought of something: if we only have to sync it in one
place, and that place is inside one of the multibuffer
functions, we don't need the open_file_sync_fileage()
wrapper function anymore; we can just use
"open_files->fileage = fileage;" explicitly there.

>Your second minor bug: I don't see that
>open_files->file_lineno is mis-initialized.

I don't either, now; for some reason the problem disappeared
after I updated my CVS snapshot recently (I forget exactly
when).

>Alas, I didn't make any progress this weekend on actually
>coding the switch to openfilestruct.  If I ever do, I will
>send you back a patch.  But first, there are about 3 other
>bugs I want to work on.

I'll try and do some work on it soon, too; I'll keep you
updated and send you back patches as necessary.  We should
probably make sure we're using the same version of the patch
on both ends before we do anything, though; assuming the
last patch you sent gets applied, there will be more
breakage in the original nanopieces.patch, in which case it
should probably be updated before anything else is done. 

>You talked a while ago about making nano handle NULL
>characters correctly in the input file.  I would like nano
>to have that feature, too.  We should work on the
>openfilestruct thing first, but when that is done: I think
>the cleanest solution, though much harder than your idea of
>using \n, would be to actually record the line length in
>each line, and convert string operations to their
>non-NULL-terminated equivalents.

That definitely would be cleaner, but the reason I discarded
the idea was because of the difficulty; with it, we'd have
to write wrappers for every string function that references
fileage->data, which would make things much more
complicated.  For example, we'd have to modify the searching
code, and considering that (a) it is very delicate, as
demonstrated by some of the searching bugs in previous
versions of nano, and (b) I don't fully understand it, I
don't want to screw around with it unless I know exactly
what I'm doing.  (Maybe you understand it better than I do;
let me know if that's the case.)

Also, there's the issue of binary size.  From the February
'02 mailing list archives:

[Nano-devel] nano and binary files 
Chris Allegretta address@hidden 
Mon, 18 Feb 2002 12:36:26 -0500 

On Mon, Feb 18, 2002 at 09:28:14AM -0800, David Lawrence Ramsey wrote:
> 
> I'll at least make an attempt at this, so you can see what I
> have in mind.

Sounds good.  I am genuinely interested in what this would take, but I
admit I may not want to accept it into the tree depending on the code
size increase.  Once we get these recent patches reconciled, I need to
take a look at binary size again.

Chris A
-- 
Chris Allegretta        http://www.asty.org

"Share and Enjoy" - Douglas Adams, 1952 - 2001

As you can see, the code size increase brought on by all the
string wrapper functions might be a problem.  (Sure, the
openfilestruct stuff will increase code size, too, but after
nano's been completely ported to it, some functionality
currently in nano will no longer be needed; e. g.
add_open_file() will not have to save all the values it does
now.)  For that reason, I'm a bit leery of them.  How about
if I take a stab at the \n idea eventually (especially since
I was planning to make it my priority until the
openfilestruct issue came up; my apologies to any I'm
keeping waiting), and I let you see what I have in mind,
before we try to do another major overhaul, since the
openfilestruct stuff is probably going to be complicated
enough as it is?


_____________________________________________________________
Sluggy.Net: The Sluggy Freelance Community!

_____________________________________________________________
Run a small business? Then you need professional email like address@hidden from 
Everyone.net  http://www.everyone.net?tag