Ctrl+Left and Ctrl+Right revisited

Hi,

A year ago I tried to get Ctrl+Left to go to the preceding word and 
Ctrl+Right to the next, but didn't succeed.  Even with David's help 
it didn't work.

This time around I put some print statements into the code, and saw 
that Ctrl+Left and Right never even reach get_escape_seq_kbinput().  
With an 'fprintf(stderr, "BAD KEY: 0x%x ", input);' stuck in after 
the "Unknown command" message in nano.c, those two key combinations 
print 'BAD KEY: 0x203' and 'BAD KEY: 0x205' when running on an 
xterm or a Konsole.  When simply running 'cat' those combinations 
produce the normal '^[[1;5D' and '^[[1;5C' sequences, but when 
'nano' is running they apparently produce different codes.

So with attached patch applied, finally Ctrl+Left and Ctrl+Right do 
what I want them to do (except that Ctrl+Left doesn't work on the 
status line.)  This is of course not a proper addition: it simply 
replaces the existing two key combinations instead of adding two 
alternative ones, but this latter change is beyond me.

Regards,

Benno

_______________________________________________
Nano-devel mailing list

how about merge with alpine-pico?

Dear all

I am sure I am not the first one got this idea: WU had decided to use an
non-Free license. They did it in such a way that they lost reputation of
pico and pine and use of both are declined in Free software world. Now
they had learned their lesson and their new license for alpine is fine
with Debian Free Software Guidelines.

It is Chris' own wish that one day UW would change their license, as
written in the FAQ many many year ago, that he accepts the project merge
with pine if UW changes their license. Do we need two pico-style editors
because one of them is not free? Yes. Now both are free, does the world
need two free software pico-style editors? No. A very small percentage
people might need a GPL version of pico, these are people who might
think every software should have a GPL version if it didn't born that
way.

So did anyone consider a merge with pine, after so many years? This is a
happy ending for both projects, as nano now is no longer actively
maintained and alpine just started a new life with a new license, at the
right direction.

It can be a merge that pico simply joins the alpine project (could be
difficult because of copyright issue, both organization in history
showed their strength in not easily compromise), or alpine abandon the
idea of having their own editor, in turn depends on gnu nano (not a
shame! There are far too many software depends on gnu stuff) and provide
patch to nano to cope with their new requirements.

I am not faimiliar with both projects, but I remembered it very well

Re: Ctrl+Left and Ctrl+Right revisited

Benno Schulenberg wrote:
> So with attached patch applied, finally Ctrl+Left and Ctrl+Right
> do what I want them to do

Here's a better version of the patch, where Ctrl+Left also works on 
the status line, the Ctrl+Up and Down combinations jump to start and 
end of paragraph, and the Ctrl+cursor keys get printed correctly in 
the help text.  The new keys of course work only on a Konsole or 
xterm, not on a VT.  Any feedback will be appreciated.

Benno

_______________________________________________
Nano-devel mailing list
Nano-devel <at> gnu.org
http://lists.gnu.org/mailman/listinfo/nano-devel

Re: how about merge with alpine-pico?

On Sun, Jan 13, 2008 at 12:35:54AM +0800, ????????? wrote:
> It is Chris' own wish that one day UW would change their license, as
> written in the FAQ many many year ago, that he accepts the project merge
> with pine if UW changes their license. Do we need two pico-style editors
> because one of them is not free? Yes. Now both are free, does the world
> need two free software pico-style editors? No. 

I think the argument isn't quite this simple.  Do we need innumerable 
GNU/Linux distributions, or 3+ separate forks of BSD Unix?  Strictly, 
speaking, no; in fact there is not even usually a license change in 
these variants.  Practically speaking though, yes.  End users are very 
picky, and the ones with ambition and development skill do not 
hesitate to build something that better meets their needs.  There is no 
harm in that; if anything I think all Free Software projects are 
stronger because of that.

Your argument assumes there are not substantial code differences in the 
projects.  Since Nano was written fron scratch using the Pico interface 
as a black box to emulate it (and some cases breaking compatibility with 
it anyway), it's highly unlikely there are modifications which could be 
made to one code base to make it compatible with the other.

> A very small percentage
> people might need a GPL version of pico, these are people who might
> think every software should have a GPL version if it didn't born that
> way.

I think this is a pretty odd argument, since you are talking to a group 
of developers who implemented an entirely new  editor simply primarily 
because of the license of the original.  The GPL and Apache license are 

Re: how about merge with alpine-pico?

Chris Allegretta wrote:
> It's not like the PINE developers could not reimplement what nano was 
> doing in the equivalent method for their own editor; they chose not to 
> do so.  I think there is likely a bigger issue here.  Do talk to the 
> alpine team, but I would not expect a sudden 'all changes welcome' 
> attitude in the response .  U of W was notorious for ignoring patches 
> and end user feature requests, and just changing the license will not 
> change that.  Maybe that's change along with the license; I certainly 
> hope it has.
>   
> Anyway, I think the PINE and nano project havs had, and still do have 
> different end goals for their software.  PINE aims to be an MUA (and 
> succeeds at that) and it happens to have a text editor which goes along 
> with it.  Nano's end to end goal is to be a text editor with a hopefully
> broader appear due to its feature set.  I think both are successes, and 
> merging may not make sense in either the short or long term.
>
> In closing, if the license issue could be resolved, and somehow 
> codebases cold be merged or (even more unlikely) if U of W wanted to 
> throw out pico and maintain and integrate nano, I think there might be 
> some interest in assisting with that project.  But I'm not holding my 
> breath, 8+ years of waiting will do that for you :)
Thanks for still visiting the list and give suggestions and commends
(after so many years).

As you described there are reasons not to become alpine and no interest
to move to alpine, which I understood. I am not an user with ambition to
do something around any C source code, but I see both nano and pine
development almost stalled for years, and if alpine is moving, I hope
nano can move more lively too, in one way or another. Another option is

Nano - Segmentation fault

Hi mates,

I'm a Yoper (http://www.yoper.com) packager. We have nano in our reposotiories and, what's more, it's our
default editor. Besides, we are about to release Yoper 3.1 and to achieve this we have upgraded a lot of
packages including nano. It's exactly because of this why I'm writing to you, nano causes segmentation
fault under certain circumstances. If you set the LANG variable to "es_ES <at> euro" and launch nano, it
crashes. However, if you set the varible to es_ES <at> utf8 it works out great. Although this happens with nano
2.0.7, it doesn't on nano 1.3.8, which used to be the version of Yoper 3.0.

To test the bug please do any of the following lines:

export LANG=es_ES <at> euro && nano
export LANG=es_ES && nano

Although nano works out with any of the next lines:

unset LANG && nano
export LANG=es_ES <at> utf8 && nano
export LANG=es && nano
export LANG=de && nano
...etc

Do you know what's going on?
How could I solve it?
Is it a nano's bug or simply a problem of my system?

I'm looking forward to having news from you soon.

Best regards! 

Re: Nano - Segmentation fault

Carlos López wrote:
> To test the bug please do any of the following lines:
>
> export LANG=es_ES <at> euro && nano
> export LANG=es_ES && nano

For what it's worth, those commands don't crash here.

  GNU nano 2.0.7               Nuevo Búfer

What happens if you start nano with --ignorercfiles ?  What happens 
if you move the relevant nano.mo file out of the way?

Benno

RE: Nano - Segmentation fault

Hey Benno, it works! 

I have launch it with the switch you said (--ignorercfiles) and it works. However, I wonder what's wrong and
how I could fix it?

I have found out the our previous nano RPM release didn't have any /etc/nanorc file while the current one
does. I have send it to you attched in this mail so you can have a look at it. Please, let me know if you find
someting wrong in it. I would really appreciate any help here., because honestly, I'm quite loss here...

Thanks a million for your quick reply. I'm looking forward to having more new about you soon!

Cheers! 

----------------------------------------
> Date: Wed, 23 Jan 2008 22:58:45 +0100
> From: bensberg <at> justemail.net
> Subject: Re: [Nano-devel] Nano - Segmentation fault
> To: nano-devel <at> gnu.org
> CC: musikolo <at> hotmail.com
>
> Carlos López wrote:
>> To test the bug please do any of the following lines:
>>
>> export LANG=es_ES <at> euro && nano
>> export LANG=es_ES && nano
>
> For what it's worth, those commands don't crash here.
>
>   GNU nano 2.0.7               Nuevo Búfer

RE: Nano - Segmentation fault

Hi guys,

I've keept on working on this issue and I have found the exact reason why nano is crashing in my PC. The
following two lines are the culprits:

line 242: syntax "c" "\.(c|C|cc|cpp|cxx|h|H|hh|hpp|hxx)$"

line 281: syntax "groff" "\.ms$" "\.mm$" "\.me$" "\.tmac$" "^tmac." ".rof"

Don't know what's wrong in them. Thus, if you could tell me, I would really appreciate it. Besides, I have
attached the file prefixed with "###---- CRASH" where having a line causing crashes.

I'm looking forward having news from you soon.

Best regards! 

PD: Please, ignore the previous attached file it isn't the right one. The attached this time is the true one.
----------------------------------------
> From: musikolo <at> hotmail.com
> To: bensberg <at> justemail.net; nano-devel <at> gnu.org
> Subject: RE: [Nano-devel] Nano - Segmentation fault
> Date: Wed, 23 Jan 2008 22:18:38 +0000
> CC:
>
>
> Hey Benno, it works!
>
> I have launch it with the switch you said (--ignorercfiles) and it works. However, I wonder what's wrong
and how I could fix it?

Re: Nano - Segmentation fault

Carlos López wrote:
> Don't know what's wrong in them. Thus, if you could tell me, I
> would really appreciate it. Besides, I have attached the file
> prefixed with "###---- CRASH" where having a line causing
> crashes.

Your nanorc file contains multiple definitions of the same syntax.
Running 'grep ^syntax nanorc' gives:

syntax "asm" "\.(S|s|asm)$"
syntax "c" "\.(c(c|pp|xx)?|C)$" "\.(h(h|pp|xx)?|H)$" "\.ii?$"
syntax "groff" "\.m[ems]$" "\.rof" "\.tmac$" "^tmac."
syntax "html" "\.html$"
syntax "java" "\.java$"
syntax "man" "\.[1-9]x?$"
syntax "mutt"
syntax "nanorc" "\.?nanorc$"
syntax "patch" "\.(patch|diff)$"
syntax "perl" "\.p[lm]$"
syntax "pov" "\.(pov|POV|povray|POVRAY)$"
syntax "python" "\.py$"
syntax "ruby" "\.rb$"
syntax "sh" "\.sh$"
syntax "tex" "\.tex$"
syntax "*"
syntax "php" "\.php[2345s~]?$"
syntax "python" "\.py$"
syntax "HTML" "\.html$"
syntax "TeX" "\.tex$"
syntax "perl" "\.p[lm]$"