Re: [Nano-devel] merged patch

[Dwayne Rightler]

Ok, so I feel somewhat silly submitting patches to nano and I cant even
get the cvs tree to compile...


When I run autogen.sh, I get:

autoheader: error: AC_CONFIG_HEADERS not found in configure.in
automake: configure.in: installing `./install-sh'
automake: configure.in: installing `./mkinstalldirs'
automake: configure.in: installing `./missing'
automake: configure.in: installing `./config.guess'
automake: configure.in: installing `./config.sub'
configure.in: 5: required file `./config.h.in' not found
./aclocal.m4:220: error: m4_defn: undefined macro: _m4_divert_diversion
acfunctions.m4:386: AC_FUNC_FSEEKO is expanded from...
./aclocal.m4:220: the top level




On Thu, 21 Feb 2002, David Lawrence Ramsey wrote:

> Attached is the patch you sent, with the following
> modifications (aside from the patch name change):
>
> Multibuffer tweaks:
>
> * When inserting a nonexistent file or a blank buffer in
> multibuffer mode, both of which result in a new blank
> buffer, 'New File' is now displayed on the statusbar instead
> of '"" not found' or '[filename] not found.'
>
> * All duplicate handling code has been removed, and the
> resulting changes merged with your patch.
>
> getnextfn() tweaks:
>
> * Cosmetic alterations have been mode to make your added
> code match the style of the rest of nano's code (just so
> it's a little easier to read).
>
> * I moved getnextfn() has been moved from the absolute end
> of files.c, so it is closer to related functions, and
> renamed it to get_next_filename(), as that name is slightly
> more descriptive.
>
> * I changed it to use charalloc() to allocate string space,
> instead of malloc(), to match the rest of nano.
>
> * Instead of going by the assumption that the maximum int
> vlue has 10 digits, as your original code did, there is now
> a function in utils.c (num_of_digits()) that calculates the
> maximum number of digits (not counting the sign) in an int.
> The number of digits in the maximum int value (INT_MAX) is
> calculated using this function, and used to allocate the
> proper maximum amount of string space in die_save_file() and
> get_next_filename().  If get_next_filename() runs up to
> INT_MAX without finding a match (filename.save,
> filename.save.1 ... filename.save.2147283627; nothing like
> over 2 billion files in a directory :), it will break out
> just as it does when it finds a match, to avoid a negative
> overflow), but ret will be left set at the NULL value it was
> initialized to when allocated by charalloc(), which uses
> calloc()
>
> * Your saving of the calculated filename in die_save_file()
> using strcpy() would cause a segfault if ret was longer than
> name; name is now just set to point to ret, and ret is
> free()d at the end of die_save_file().
>
> * The context-sensitive help now explains how to insert a
> blank buffer in multibuffer mode: just press enter at the
> prompt without typing in a filename, or, as before, type in
> a nonexistent filename at the prompt and press Enter.  Since
> Enter is a little easier to hit than Ctrl-N, as in your
> next-to-last patch, your Ctrl-N shortcut may not be needed.
>
> Miscellaneous:
>
> * My nanobits.patch has also been merged with your patch,
> since the current nano-1.1.6-cvs will not always read files
> correctly without one ofits fixes (I needed it fixed in
> order to do proper testing); the nanobits.patch also now
> removes a few more unneeded blank lines, and it should be
> noted that it, and the previous version of it, sets the
> replace_list_2 shortcut to NULL, as one of the pieces of
> Steven Kneizys' patches also does.  (I hope that it
> won't be too much trouble to merge with SPK's patch.)
>
> * One thing I forgot about in this patch and just remembered
> as I was typing this: maybe the char *name argument of
> get_next_filename() can be a const char* instead of a char*,
> since it isn't modified in the function at all?  (I don't
> have any more time to recreate it and repost it today, so
> could you possibly look into it, if you don't mind?)
>
> * One caveat about this patch: Could you also test it on
> your end, so I can be sure I haven't inadvertently missed or
> screwed up anything?  Thanks.
>
> * One last item unrelated to this patch: I've been testing
> this by running it in an rxvt (version 2.6.4), creating
> unsaved files, and then shrinking the window to too small a
> size.  However, when I do this, the terminal settings don't
> seem to be properly reset (i. e. the lines indicating the
> names of the files saved are only ended with the cursor's
> moving down and not back to the beginning of the line, and
> any text I type at the prompt is invisible until I do a
> "stty sane"; (a) does this happen to anyone else, and (b)
> do I need to provide more information?
>
>
> _____________________________________________________________
> Sluggy.Net: The Sluggy Freelance Community!
>