Re: [PATCH] compile fix when DEBUG is defined

--- Jon Oberheide <jon <at> oberheide.org> wrote:
>Looks like a simple mistake that was overlooked.  Please apply and CC 
>me as I am not subscribed.

Applied; thanks.

nano-1.3.x disregards umask when saving files

i kind of noticed this behavior myself when using 1.3 but i didnt notice that 
it only happened when working with nano ;)

http://bugs.gentoo.org/show_bug.cgi?id=55780

seems that when creating files, they always start with 600 instead of working 
off of the umask ...
-mike

Re: nano-1.3.x disregards umask when saving files

--- Mike Frysinger <vapier <at> gentoo.org> wrote:
>i kind of noticed this behavior myself when using 1.3 but i didnt 
>notice that it only happened when working with nano ;)
>
>http://bugs.gentoo.org/show_bug.cgi?id=55780
>
>seems that when creating files, they always start with 600 instead of 
>working off of the umask ...

Fixed in CVS.  The problem isn't actually with the umask; it's with the 
default permissions as modified by the umask.  It seems to have gotten 
in when I was merging DB's changes to write_file(), which included a 
change to the default file-creation permissions to make them 600 instead 
of 666.  600 with a umask of 022 applied is still 600, while 666 with a 
umask of 022 applied is the expected 644.  The attached patch fixes it 
for 1.3.3.

diff -ur nano-1.3.3/src/files.c nano-1.3.3-fixed/src/files.c
--- nano-1.3.3/src/files.c	2004-06-21 23:03:00.000000000 -0400
+++ nano-1.3.3-fixed/src/files.c	2004-07-06 09:58:56.000000000 -0400
 <at>  <at>  -1619,7 +1619,7  <at>  <at> 
      * is now copied from joe, because wiggy says so *shrug*. */
     fd = open(realname, O_WRONLY | O_CREAT |
 	(append == 1 ? O_APPEND : (tmp ? O_EXCL : O_TRUNC)),
-	S_IRUSR | S_IWUSR);
+	S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH);

     /* Put the umask back to the user's original value. */
     umask(original_umask);

Re: nanorc example for colorizing patches / shell scripts

--- Mike Frysinger <vapier <at> gentoo.org> wrote:
>find attached a few nanorc's i made a while back to:
>(1) colorize all those .diff and .patch files
>(2) colorize .sh scripts ... i think this one could use some polishing 
>;
>feedback welcome :)

I'll check these out; they certainly look useful.

Re: additions to example c-file nanorc

--- Mike Frysinger <vapier <at> gentoo.org> wrote:
>while i'm here, i figured i'd add my 2 cents to the example c-file 
>syntax in the nanorc ...
>(1) it'd be nice if the default match pattern was "\.(c|h|cpp|cc|cxx)"

>(2) double, typedef, extern, union, unsigned, inline, and long were 
>added to the 'green' list ... if you dont mind GNU extensions, you 
>could also handle volatile ...

Maybe.  Incidentally, if I remember correctly, volatile was also used in 
Borland's Turbo C/C++.

>(3) add undef to the brightcyan list
>(4) add for and break to the brightyellow list

These sound good.  Maybe enum should be added to the brightyellow list 
too?

>i'm not much of a C++ guy, but maybe someone would like friend, 
>namespace, etc... added somewhere too ?

Neither am I.  However, bool at least has been added to C99, so this 
might be needed.  A few sample C++ regexes were posted to help-nano 
awhile back, and they might be useful here as a base:

http://lists.gnu.org/archive/html/help-nano/2004-01/msg00002.html

Invalid address: finn.hakansson

The addresses <finn <at> axis.com> and <finn.hakansson <at> axis.com> are not valid.
Finn Håkansson can be reached at finn_haakansson <at> hotmail.com.

do_para_begin bug

Hi DLR, et. al.

I felt like hacking again, so I took a look at the new justify code.  
There's a bug in do_para_begin().  The attached file consists of 3 
paragraphs (have autoindent turned off!).  From the third line, do ^W^W.  
The cursor moves up two lines, not one.  Add a character to the end of the 
second line, and it works correctly.

The code for do_para_begin and do_para_end was too complicated for me to 
understand (a static local variable and a goto in do_para_search didn't 
help), so I just rewrote them.  They're now stand-alone, and pretty 
simple.  I also simplified do_para_search, since it is now only called 
from do_justify.

Finally, the attached patch makes the quote string regular expression be 
compiled once, globally.  That simplifies the justify code a bit.

Next, I intend to rework do_justify.  It's currently quadratic runtime; I 
think I can make it linear.

By the way: can we use the "bool" data type instead of "int" for boolean 
values?  If it'll get applied, I'll be happy to make a patch that does 
that change globally.

David

	    first
	y
  third

Copy Text feature?

Hey everyone,

One thing I think might be a useful addition is a Copy Text feature to
copy a line into the cut buffer without deleting it.  I often want to
copy a line and change the new one without deleting the current line.

AFAIK, you have to Cut a line, then UnCut it twice to accomplish this. 
If there is another way to do this with the keyboard, please let me
know.

I know I can copy/paste using the mouse and X, but I was looking for a
way to do it with just the keyboard.

It could be done by duplicating the do_cut_text function in cut.h, just
leaving out the code that removes the text.  It seems like M-K would be
the right key for this, but that is already taken by the "Cut to end
enable/disable".

I would be interested in opinions on a Copy Text feature.

Best Regards,
Keith

updates

Been busy the past few weeks.  When I've had time, I've been focusing on 
mainly fixing the bugs that cropped up in 1.3.3 and cleaning up some of 
nano's internals to cut down on the bloat that the new features added to 
1.3.3.  Among other things:

* added a fix for erroneously allowing tab completion in restricted mode 
when the filename can't be changed

* added a fix for justifying's taking spaces off a line more than once 
when part of the next line was added to it

* added a fix for a segfault when trying to do full-justify on a file 
with no paragraphs, and changed its shortcut to ^W^U as the current 
version of Pico has

* for more Pico compatibility, nano no longer cuts text on the statusbar 
when Ctrl-U is pressed

* properly added delayed string translation, ported from DB's patch, 
which allows the xlcredits[] strings to be translated properly again 
(they weren't in 1.3.3)

* moved the setlocale() call out of the NLS #ifdef, as Debian does, in 
preparation for UTF-8 support, since the wide character functions it'll 
need won't works properly without that setlocale() call, and just 
because the strings aren't translated doesn't mean that UTF-8 
interpretation should be disabled

* fixed a problem where the terminal settings weren't always being 
properly restored after running the alternative spell checker

Re: do_para_begin bug

--- David Benbennick <dbenbenn <at> cam.cornell.edu> wrote:
>Hi DLR, et. al.
>
>I felt like hacking again, so I took a look at the new justify code.  
>There's a bug in do_para_begin().  The attached file consists of 3 
>paragraphs (have autoindent turned off!).  From the third line, do 
>^W^W.
>  
>The cursor moves up two lines, not one.  Add a character to the end of 
>the second line, and it works correctly.

That's definitely odd.

>The code for do_para_begin and do_para_end was too complicated for me 
>to understand (a static local variable and a goto in do_para_search 
>didn't help), so I just rewrote them.

That static/goto was my attempt at dealing with the case of the user's 
pressing ^W^W on the furst line of a paragraph.  It was supposed to 
restart the search from the previous line in that case; without it, the 
cursor wouldn't move at all.  But you're right, it definitely isn't the 
easiest to understand in its current form.

>They're now stand-alone, and pretty simple.  I also simplified 
>do_para_search, since it is now only called from do_justify.

Yes, the new versions of do_para_start() and do_para_end() are much more 
understandable.  I have one quick question, though: why is old_place set 
to the value of xplustabs() instead of just placewewant?  I figure that 
they should be equivalent at that point.  Or am I missing something?