[Top][All Lists]

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

Re: [Nano-devel] the difficulties of behaving similar

From: Benno Schulenberg
Subject: Re: [Nano-devel] the difficulties of behaving similar
Date: Sat, 21 Jun 2014 11:26:07 +0200

Hi Mark,

On Thu, Jun 19, 2014, at 18:07, Mark Majeres wrote:
> I haven't looked to see if this makes sense for all of the current
> assignments, but maybe something like this:
>     lineno --> end_lineno
>     begin_x --> end_x
>     mark_begin_lineno --> begin_lineno
>     mark_begin_x --> begin_x

Renaming 'begin' to 'end' looks like a recipe for confusion to
me, and begin and end are overused anyway, so I would opt for
'head' and 'tail'.  When things quiet down, I will make that

> > Hmmm...  When the mark is not set, and some command key did not
> > reset the cutbuffer when it should have, then the add_undo() item
> > for CUT will not be reached because keeping_cutbuffer() wil be true.
> > No?  Like I said before, the call to cutbuffer_reset() in CUT ever
> > only has an effect when the mark is set or the action is CUT_EOF.
> The conditional also requires that the current line is the next contiguous 
> line:
>    u->mark_begin_lineno == fs->current->lineno

Contiguous?  I understand this to mean that the line where the
cutting started is still the current line -- and this will automatically
be the case when using ^K.  And when the mark is set, any cursor
movement that moved off this line will have reset the cutbuffer

> Right now, the call(s) to cutbuffer_reset() in nano.c do
> make the call in add_undo redundant for *most* cases.  If you remove
> those calls, then it will matter for *all* cases.

Hmm.  Strange, I cannot get my head around this, but it works
-- except that any horizontal movement within the current line
will not reset the cutbuffer.  Maybe the x coordinate needs to be
added to the above condition as well?

> BTW, the entire mechanism for copy/cut/paste is not very efficient
> IMO.  For example, when copying, the text is cut, then pasted back in.
> Why not just paste it to the cutbuffer instead, without cutting it
> from the document?  I always thought this was strange, maybe I
> overlooked something?  No really a big deal though, it functions fine.

I think it was done that way because it was cheaper: there is no
separate function needed for copying.  And incidentally it mimics
what I've always done when wanting to copy something: ^X ^V, and
now in nano: ^K ^U -- I never could remember what the shortcut for
Copy is.  :)


-- - A no graphics, no pop-ups email service

reply via email to

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