headers
David Lawrence Ramsey | 6 Aug 2005 05:47
Picon

Re: Translating nano

Jean-Philippe Guérard wrote:

<snip>

 >I would like to suggest the following change to the nano release
 >process that would enable a much better integration of the translation
 >process with the development process.
 >
 >Instead of directly releasing a new unstable version of nano (e.g.
 >1.3.9), release a 1.3.9-rc, and send the corresponding .pot file to the
 >translation teams.
 >
 >Then, one week after that, release the official 1.3.9 version,
 >including all the new updated translations.

Sounds good to me.  Jordi?
Permalink | Reply | 0 comments |
headers
David Lawrence Ramsey | 6 Aug 2005 06:02
Picon

Re: justify in nano 1.3.7.

Ken Tyler wrote:
 >
 > On of my pet hates is trailing spaces and tabs on the ends of lines.
 > Imagine my absolute horror when I noticed that justifying a paragraph
 > leaves a trailing space on every line. I had to lie down for the rest of
 > the day. I am appalled at the thought of all those reduntant spaces I 
have
 > inadvertantly released into the world.
 >
 > I don't recall earlier versions of nano doing this.

It's been doing this since 1.3.3, although it's only been really doing
it properly since 1.3.6.  Before that, and in 1.2.x, it would leave one
space at the end of a line if it ended with two before justification. 
(By the way, it shouldn't be leaving a space at the end of the last
line.  If it is, that's a bug.)

As for why the behavior changed, (a) later versions of Pico do this
(apparently, some RFC dealing with flowed text in email requires it; a
line ending in a space is flowed into the next one, so all lines except
for the last one in a paragraph have to end in spaces), and (b) it's
consistent with wrapping, which leaves spaces at the end of wrapped
lines.

Sorry for any inconvenience, though.  If it bothers you that much, I
suppose you could always do a complete regex replace of "( )+$" with ""
just before saving...
Permalink | Reply | 2 comments |
headers
David Lawrence Ramsey | 6 Aug 2005 08:04
Picon

Re: spell check

Ken Tyler wrote:
 >
 > nano 1.3.7
 >
 > if spell check is run on an unmodified file and finds no errors it
 > says "Modified" in the status bar and offers up save menu when
 > exiting.
 >
 > I have
 >     set speller "ispell"
 > in .nanorc

The short of it is that it doesn't seem to be worth it in terms of
effort to determine whether a file run through the alternate spell
checker has changed or not.  For the same reason, replacing all
instances of a string with itself will still set the "Modified" flag.

This is not to say that I haven't thought about it, but getting, say,
MD5 sums or SHA1 sums of the files before and after spell checking seems
like overkill if it's added to nano (and will make it less portable,
since methods like them depend on numbers' having particular bit widths,
and there's no clean way to ensure that and still remain completely
compatible with C89), and introduces another unnecessary dependency on
an external program if it isn't added to nano.  And doing a straight
comparison of both files will take even longer, and make things more
complicated in a different way.

Of course, I'm open to suggestions (or patches) if you have any ideas as
to how to do it well.  Thanks for the report, in any case.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ken Tyler | 7 Aug 2005 09:19
Picon
Picon

Re: justify and spell check


The spell check setting the modified flag is not a problem, I thought it 
was a simple oversight type bug, I've never examined hot that bit of code 
works.

The trailing space bizo is an irritation but I'll cope, it looks untidy to 
me to have a file with trailing tabs and garbage on the ends of lines, 
does the standard .nanorc have

# trailing rubbish
color brightgreen,green "(( )+)$"

or is it one of mine?

It occurs to nano is and editor not a mail client though.

Ken.
Permalink | Reply | 1 comment |
headers
Simon Strandman | 10 Aug 2005 14:43
Picon

Nano 1.3.8 and 1.3.8-cvs crashes on suse 9.3 x86_64

Hi!

Nano 1.3.8 and 1.3.8-cvs crashes on suse 9.3 x86_64 when I search in a 
document. Version 1.2.5 however is stable.

This is the backtrace:
#0  renumber (fileptr=0x0) at nano.c:171
#1  0x000000000040da90 in update_history (h=0x51f6e8, s=0x71f4f0 "fsd") 
at search.c:1214
#2  0x000000000040f010 in do_search () at search.c:449
#3  0x000000000040c817 in do_input (meta_key=<value optimized out>, 
func_key=0x7fffffffde4c, s_or_t=0x7fffffffde4d, ran_func=0x7fffffffde4e, 
finished=0x7fffffffde4f, allow_funcs=true) at nano.c:1671
#4  0x000000000040ccc2 in main (argc=1, argv=0x7fffffffe348) at nano.c:2407

I believe this is because suse patches their glibc with a patch that 
adds amd64 optimized strings. Adding the same patch to gentoo's glibc 
makes nano crash the same way there too.

More info about the amd64 patch and the problem:
http://bugs.gentoo.org/show_bug.cgi?id=100289

--

-- 
Simon Strandman <simon.strandman <at> telia.com>
Permalink | Reply | 5 comments |
headers
David Lawrence Ramsey | 11 Aug 2005 06:50
Picon

Re: justify and spell check

Ken Tyler wrote:

 > The spell check setting the modified flag is not a problem, I thought
 > it was a simple oversight type bug, I've never examined hot that bit
 > of code works.

Okay.  No problem.

 > The trailing space bizo is an irritation but I'll cope, it looks
 > untidy to me to have a file with trailing tabs and garbage on the ends
 > of lines

Justifying turns all blank characters, including tabs, to spaces, so
there should only be trailing spaces on all but the last line of a
justified paragraph.  That should make things easier, I hope.

 > does the standard .nanorc have
 >
 > # trailing rubbish
 > color brightgreen,green "(( )+)$"
 >
 > or is it one of mine?

There's a line like that in the "Java source" regexes, which David
Benbennick contributed a few years ago, IIRC.  You could probably just
copy it into the regexes you use.  Alternatively, you could use
whitespace display mode to see where any trailing spaces are.

 > It occurs to nano is and editor not a mail client though.
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Lawrence Ramsey | 11 Aug 2005 07:05
Picon

Re: Nano 1.3.8 and 1.3.8-cvs crashes on suse 9.3 x86_64

Simon Strandman wrote:
 > Hi!
 >
 > Nano 1.3.8 and 1.3.8-cvs crashes on suse 9.3 x86_64 when I search in a
 > document. Version 1.2.5 however is stable.
 >
 > This is the backtrace:

<snip>

 > I believe this is because suse patches their glibc with a patch that
 > adds amd64 optimized strings. Adding the same patch to gentoo's glibc
 > makes nano crash the same way there too.
 >
 > More info about the amd64 patch and the problem:
 > http://bugs.gentoo.org/show_bug.cgi?id=100289

Actually, there is a case in 1.3.8-cvs where the parameter passed to
that particular renumber() could be NULL (if s is equal to "", and the
match for it is the blank line at the bottom of the history list), so
I've added a NULL guard to it.  Thanks for indirectly catching it, by
the way.

However, I don't believe that that parameter should be NULL in the case
your backtrace is showing.  If "fsd" exists in the history when
update_history() is called, the entry after it, which is passed to
renumber(), should either be another string or the blank line at the
bottom of the history list.  In short, the entry after "fsd" should
never be NULL if "fsd" exists in the history.  And if "fsd" doesn't
exist in the history, find_history() should return NULL, and that
(Continue reading)

Permalink | Reply | 4 comments |
headers
David Lawrence Ramsey | 11 Aug 2005 08:28
Picon

Re: [patch][rfc] reenable wrapping

Alexey Toptygin wrote:

 > I've gotten exactly zero replies about the previous incarnation of
 > this patch, but I love you anyway, so here's an updated version. It is
 > cleaned up some, doesn't patch the generated nano.1.html and nano.info
 > files, and now exists for both 1.2.5 and 1.3.8. You can find it
 > attached, or at:
 >
 > http://alexeyt.freeshell.org/code/patch-nano-1.2.5-reenable-wrap
 > http://alexeyt.freeshell.org/code/patch-nano-1.3.8-reenable-wrap
 >
 >             Alexey

Sorry about the wait.  I've been a bit busy with 1.3.8-cvs lately.  Just
so you know, the 1.2 branch of nano is in feature freeze, so this
feature can't go into it, but the 1.3 branch is still open.

Given that, however, the inability to unset --nowrap from the command
line is just a symptom of a larger problem: *any* flag set inside nano
or the .nanorc cannot be unset from the command line.  Adding a single
command line option for one case of this isn't quite enough, and adding
one for each case is overkill.

Don't get me wrong; I certainly appreciate the attempt you've made, but
I'd prefer a solution that fixes the problem as a whole.  Pico's
solution of apparently toggling flags (i.e, "pico -w -w" leaves wrapping
turned on) is probably the direction nano needs to go, but I'm not sure
how it should interact with the rcfile options or those options that set
other options (e.g. --restricted).  If you have any ideas how, or a
better solution, let me know.  Thanks.
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Lawrence Ramsey | 11 Aug 2005 09:20
Picon

massive updates...

Sorry I didn't get to this before, but I just recently got current CVS
to a state approximating "stable".  Here are the (massive) changes in
it:

* at long last, merged Mike Frysinger's old sample regexes for Bourne
shell scripts

* overhauled buffer and multibuffer support to remove longstanding
design problems; instead of periodically setting the globals to match
the current openfilestruct and dealing separately with cases that left
them out of sync, every buffer now gets its own openfilestruct and
changes its values directly; the openfilestruct structure now contains
all data set on an individual-file basis, including the modification
flag, the marking flag and position, and the current color strings

* other buffer/multibuffer changes: totlines no longer exists in either
global or openfilestruct form, as filebot->lineno is now used in its
place due to its being equivalent when the file's lines are properly
numbered; there are now functions that work on a per-buffer basis in
files.c; the hblank global has been removed, and its functionality
replaced with the function blank_line(); global_init() no longer exists,
and the tiny bit of resizing logic left in it has been moved into
window_init(); renumber_all() has also been removed, since it was
unnecessarily coupled to the main filestruct, and replaced with
renumber(); various functions have also been renamed

* fixed a few minor kinks in the previously overhauled history code: the
current position in the history list is now properly set to the bottom
if we cancel out of the prompt, and magichistory is now properly updated
when we change it and then move up
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Strandman | 11 Aug 2005 11:44
Picon

Re: Nano 1.3.8 and 1.3.8-cvs crashes on suse 9.3 x86_64

David Lawrence Ramsey skrev:

>
> Thanks for the report and the link, in any case.  How does current CVS
> behave?  I imagine that renumbering won't be done properly in all cases
> due to the above problem, but at least it shouldn't segfault.
>

It still segfaults. :( This is the new bt:

#0  0x00002aaaaad90253 in malloc_consolidate () from /lib64/tls/libc.so.6
#1  0x00002aaaaad92002 in _int_malloc () from /lib64/tls/libc.so.6
#2  0x00002aaaaad93719 in malloc () from /lib64/tls/libc.so.6
#3  0x0000000000412556 in nmalloc (howmuch=1230) at utils.c:346
#4  0x000000000041443e in statusbar (msg=0x41ac9f "Search Wrapped") at 
winio.c:2943
#5  0x000000000040e0b0 in findnextstr (can_display_wrap=true, 
wholeword=false, no_sameline=false, begin=0x710e90, begin_x=6, 
needle=0x712490 "qwerty", needle_len=0x0) at search.c:362
#6  0x000000000040efe2 in do_search () at search.c:453
#7  0x000000000040c857 in do_input (meta_key=<value optimized out>, 
func_key=0x7fffffffddbc, s_or_t=0x7fffffffddbd, ran_func=0x7fffffffddbe, 
finished=0x7fffffffddbf, allow_funcs=true) at nano.c:1679
#8  0x000000000040cd02 in main (argc=1, argv=0x7fffffffe2f8) at nano.c:2425

--

-- 
Simon Strandman <simon.strandman <at> telia.com>
Permalink | Reply | 3 comments |

Gmane