Re: [Nano-devel] [poll] which features would you like to see in nano?
Trevor Brown <[email protected]> Sun, 12 Jul 2015 07:27:12 -0600
| Newsgroups | gmane.editors.nano.announce |
|---|---|
| Message-ID | <CAM7n+D=TmoWd6KzZsNoWwfVc1107gvK4GDFdn+ERaq9dYQ=8Uw__37324.8858530589$1436714253$gmane$org@mail.gmail.com> |
--===============5490618482684320594== Content-Type: multipart/alternative; boundary=089e0149bbb0109560051aad904a --089e0149bbb0109560051aad904a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 26 June 2015 at 03:20, Benno Schulenberg <[email protected]> wrote: > > On Fri, Jun 26, 2015, at 06:59, Eitan Adler wrote: > > On 21 June 2015 at 03:28, Benno Schulenberg <[email protected]> > wrote: > > > c) Find next occurrence backward / find next occurrence forward. > > > (So you don't have to toggle the search direction with ^W M-B first.) > > > > +0 I have no opinion on this other than to be concerned about an > > explosion of complexity. > > I understand. It's just something that I really would like to have. > All other command-line editors have a find-forward and find-backward. > What nano has feels like what graphical editors have: check boxes that > one can click to toggle Direction, Case Sensitivity and Regular > Expressions. > > An alternative would be to have a bindable WhereWas function: the same as > WhereIs but with the Backward direction toggled always on. > +1 for this. I can't tell you how many times I've wanted to be able to use both while searching without having to toggle an option. > > > > d) Save the current file without any prompting (if it has a name). > > > > +1. I'd also be okay with this being an option to default save to the > > same name as previously asked. > > Hm. The option you're suggesting is how --tempfile should behave, > but it doesn't. In Pico the -t option will save the file straightaway > upon a ^O or ^X. But nano will do that only for the latter. (Bug > has been filed as https://savannah.gnu.org/bugs/index.php?45415.) > > > > e) An option to consider underscores to be part of a word. > > > > -1 as is. I'd be +0 if it were "an option to list characters to be > > considered part of a word". In particular I don't like how specific > > this option is. > > You're right, it was too specific. And being able to define which > characters should also be considered parts of words nicely fits > with nano's other options like 'set brackets' and 'set punct'. > +1 in this form, especially when programming > > By the way, Pico always considers hyphens and underscores to be > parts of words (but also all brackets and other things, which is > not good). So we could also consider nano's current behaviour > as a bug. The -W (--wordbounds) option makes nano behave more > like Pico, but worse: it will also put the cursor on an opening > bracket, something that Pico never does. > > Thanks for the detailed response. > > Benno > > -- > http://www.fastmail.com - Access all of your messages and folders > wherever you are > > > _______________________________________________ > Nano-devel mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/nano-devel > > --=20 Mit freundlichen Gr=C3=BC=C3=9Fen and 73s, Trevor Brown KE7RTO --089e0149bbb0109560051aad904a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo= te">On 26 June 2015 at 03:20, Benno Schulenberg <span dir=3D"ltr"><<a hr= ef=3D"mailto:[email protected]" target=3D"_blank">[email protected]= et</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg= in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D""= ><br> On Fri, Jun 26, 2015, at 06:59, Eitan Adler wrote:<br> > On 21 June 2015 at 03:28, Benno Schulenberg <<a href=3D"mailto:bens= [email protected]">[email protected]</a>> wrote:<br> </span><span class=3D"">> > c)=C2=A0 Find next occurrence backward / = find next occurrence forward.<br> > > (So you don't have to toggle the search direction with ^W M-B= first.)<br> ><br> > +0 I have no opinion on this other than to be concerned about an<br> > explosion of complexity.<br> <br> </span>I understand.=C2=A0 It's just something that I really would like= to have.<br> All other command-line editors have a find-forward and find-backward.<br> What nano has feels like what graphical editors have: check boxes that<br> one can click to toggle Direction, Case Sensitivity and Regular Expressions= .<br> <br> An alternative would be to have a bindable WhereWas function: the same as<b= r> WhereIs but with the Backward direction toggled always on.<br></blockquote>= <div><br></div><div>+1 for this. I can't tell you how many times I'= ve wanted to be able to use both while searching without having to toggle a= n option.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"= margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <span class=3D""><br> > > d)=C2=A0 Save the current file without any prompting (if it has a= name).<br> ><br> > +1.=C2=A0 I'd also be okay with this being an option to default sa= ve to the<br> > same name as previously asked.<br> <br> </span>Hm.=C2=A0 The option you're suggesting is how --tempfile should = behave,<br> but it doesn't.=C2=A0 In Pico the -t option will save the file straight= away<br> upon a ^O or ^X.=C2=A0 But nano will do that only for the latter.=C2=A0 (Bu= g<br> has been filed as <a href=3D"https://savannah.gnu.org/bugs/index.php?45415"= rel=3D"noreferrer" target=3D"_blank">https://savannah.gnu.org/bugs/index.p= hp?45415</a>.)<br> <span class=3D""><br> > > e)=C2=A0 An option to consider underscores to be part of a word.<= br> ><br> > -1 as is.=C2=A0 I'd be +0 if it were "an option to list chara= cters to be<br> > considered part of a word".=C2=A0 In particular I don't like = how specific<br> > this option is.<br> <br> </span>You're right, it was too specific.=C2=A0 And being able to defin= e which<br> characters should also be considered parts of words nicely fits<br> with nano's other options like 'set brackets' and 'set punc= t'.<br></blockquote><div><br></div><div>+1 in this form, especially whe= n programming</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> By the way, Pico always considers hyphens and underscores to be<br> parts of words (but also all brackets and other things, which is<br> not good).=C2=A0 So we could also consider nano's current behaviour<br> as a bug.=C2=A0 The -W (--wordbounds) option makes nano behave more<br> like Pico, but worse: it will also put the cursor on an opening<br> bracket, something that Pico never does.<br> <br> Thanks for the detailed response.<br> <span class=3D"HOEnZb"><font color=3D"#888888"><br> Benno<br> <br> --<br> <a href=3D"http://www.fastmail.com" rel=3D"noreferrer" target=3D"_blank">ht= tp://www.fastmail.com</a> - Access all of your messages and folders<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 wherever you are<br> </font></span><div class=3D"HOEnZb"><div class=3D"h5"><br> <br> _______________________________________________<br> Nano-devel mailing list<br> <a href=3D"mailto:[email protected]">[email protected]</a><br> <a href=3D"https://lists.gnu.org/mailman/listinfo/nano-devel" rel=3D"norefe= rrer" target=3D"_blank">https://lists.gnu.org/mailman/listinfo/nano-devel</= a><br> <br> </div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>= <div class=3D"gmail_signature">Mit freundlichen Gr=C3=BC=C3=9Fen and 73s,<b= r>Trevor Brown<br>KE7RTO</div> </div></div> --089e0149bbb0109560051aad904a-- --===============5490618482684320594== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Info-nano mailing list [email protected] https://lists.gnu.org/mailman/listinfo/info-nano --===============5490618482684320594==--