nano-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nano-devel] how Alt+6 should behave


From: Rishabh Dave
Subject: Re: [Nano-devel] how Alt+6 should behave
Date: Fri, 5 Feb 2016 16:53:37 +0530



On Fri, Feb 5, 2016 at 1:54 AM, Benno Schulenberg <address@hidden> wrote:
> About progress in patch,
>
> I achieved the effect - cursor doesn't move while selecting and copying
> text - for all movements while selecting text i.e. up, down, left and
> right. However, they are little unstable.

What do you mean with unstable?  That it crashes now and then?


Downward selection works right. But in case of marking/selecting upwards, cursor jumps to end of marking on pressing M-6. Left and right sometimes works well sometimes, other time led to segfault, (highlighting works on only left that too irregularly) and today pressing M-A launched Search icon over the launcher. This never happened before (maybe, I haven't tested enough).
 
On Thu, Feb 4, 2016, at 18:55, Rishabh Dave wrote:
> Code in patch I sent -
>
> +>  if.(!copy_text)
> +>  ....openfile->current.=.openfile->filebot;
>
> Code in patch you sent -
>
> +....if.(put_cursor)
> +>  openfile->current.=.openfile->filebot;
>
> Could you please point me to the mistake

You see, you have a tab (represented by a >) before the if,
and I have four spaces.  And before the openfile you have
a tab plus four spaces, and I just a tab.  Nano's code
assumes a tab size of eight (yes, sorry, but that's how it
is).  So your fragment is indented too much by four positions.


Oh... so... we leave 4 spaces generally from left border of editor window and when we want to indent inside a code block (like in case of if, for, etc.) we leave one tab, correct? I was actually changing tab-size to 4 by looking gap of 4 spaces in code.
 
> Also highlighting text while
> selecting the effect is remaining (I have figured where is that under our
> source code) and --cut and --wrap are unstable; it will take some time. I
> wanted to send a patch to confirm things are what we want but I keep
> repeating that whitespace-mistake.

Well, for just judging whether the behaviour is the intended one,
the whitespace doesn't matter.  But you wanted me to comment
immediately.


I know whitespace does't matter but I did not want to keep repeating that mistake, that is why I did not attach a patch. :(
 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]