vim narrowing to region like emacs
CharlesM
Narrowing plugins, but they do not work.
They all seem to think narrowing has something to do with folds - it
does not! Narrowing is like cutting
out the region, putting it into its own buffer, editing it, then
placing it back in the original buffer -
but without actually doing all that. It totally prevent any edits,
searches, replaces, etc from affecting the rest of
the buffer (but it doesn't actually remove the region first). For
instance, say I realize a variable name in
a function cannot be the same as the rest of the program. With
narrowing I can do a global replace of that
variable without worrying that I'll mess up the rest of the program.
CMM
Rui Maciel
You can do that with ranges. For example, let's say you want to replace all instances of
the keyword "foo" with the keyword "bar", but you only want to do that in a particular
function. In order to do that you only need to do the following:
a) check where the function starts and ends (i.e., the document range where to perform the
replacing)
b) replace all instances of "foo" with "bar" in that region.
That means that if you happen to have a function that's located in a specific source file
between lines 1023 and 1145, you only need to run the following command:
1023,1145s/foo/bar/g
It's also possible to set a range by specifying relative positions. For example, if your
cursor is placed in line 1023, you will get the same result by running the following
command:
.,.+22s/foo/bar/g
On a side note, to be extra safe and avoid replacing keywords which also contain the
keyword "foo" (i.e., to avoid changing "foobie" into "barbie") then you need to mark the
begining and end of a keyword, such as:
1023,1145s/\<foo\>/bar/g
Hope this helps,
Rui Maciel
charlesm
I've thought of that but it's not exactly what I meant. Suppose you've
got a lot of edits to do. Maybe searches as well.
Perhaps some confirm replaces mixed in as well. I don't have to give
ranges each time with narrowing (I'm not even sure if
everything you might do can have a range) . I never have to worry
about affecting things outside the region until I widen
the buffer to the whole file. It sort of fixes the range up front
(although it's actually more complicated and thorough ),
as opposed to you giving it a range each time (and perhaps slipping
up).
CMM
Gary Johnson
> On Apr 25, 11:29 am, Rui Maciel <rui.mac...@gmail.com> wrote:
> > CharlesM wrote:
> > > Has vim got anything that restricts editing to a region? I've tried
> > > Narrowing plugins, but they do not work.
> > > They all seem to think narrowing has something to do with folds - it
> > > does not! Narrowing is like cutting
> > > out the region, putting it into its own buffer, editing it, then
> > > placing it back in the original buffer -
> > > but without actually doing all that. It totally prevent any edits,
> > > searches, replaces, etc from affecting the rest of
> > > the buffer (but it doesn't actually remove the region first). For
> > > instance, say I realize a variable name in
> > > a function cannot be the same as the rest of the program. With
> > > narrowing I can do a global replace of that
> > > variable without worrying that I'll mess up the rest of the program.
> >
> > You can do that with ranges.
> I've thought of that but it's not exactly what I meant. Suppose you've
> got a lot of edits to do. Maybe searches as well.
> Perhaps some confirm replaces mixed in as well. I don't have to give
> ranges each time with narrowing (I'm not even sure if
> everything you might do can have a range) . I never have to worry
> about affecting things outside the region until I widen
> the buffer to the whole file. It sort of fixes the range up front
> (although it's actually more complicated and thorough ),
> as opposed to you giving it a range each time (and perhaps slipping
> up).
That's a neat feature but Vim doesn't have that. I use visual blocks a
lot to set those sorts of limits. With those I don't have to keep track
of numbers or marks; I just execute 'gv' to restore the visual
selection. Nevertheless, it does require that the user take some action
before each edit, so it is subject to the sort of slip-ups that emacs's
narrowing avoids.
--
Gary Johnson
Rui Maciel
> I've thought of that but it's not exactly what I meant. Suppose you've
> got a lot of edits to do. Maybe searches as well.
> Perhaps some confirm replaces mixed in as well. I don't have to give
> ranges each time with narrowing (I'm not even sure if
> everything you might do can have a range) . I never have to worry
> about affecting things outside the region until I widen
> the buffer to the whole file. It sort of fixes the range up front
> (although it's actually more complicated and thorough ),
> as opposed to you giving it a range each time (and perhaps slipping
> up).
I am not a emacs user, which means that it's quite possible I may not completely understand
the mechanics of this narrowing feature. Nonetheless, with vim you aren't forced to
explicitly define a range by providing line numbers. You may use position marks to define the
start and the end marker for a region and then perform whatever task you'd like, such as
search and replace, in the region defined by those markers.
Rui Maciel
AK
The closest you can get is to make a visual selection; then make a very
easy shortcut that does 'gv:'. For example, you can map spacebar to do
that if you're not using it for anything else. Or alt-j or something.
Obviously this emacs feature sounds nicer but in my experience doing a
visual selection and then using gv is more than enough 99 times out of a
hundred. ymmv.
Christian Brabandt
> I've thought of that but it's not exactly what I meant. Suppose you've
> got a lot of edits to do. Maybe searches as well.
> Perhaps some confirm replaces mixed in as well. I don't have to give
> ranges each time with narrowing (I'm not even sure if
> everything you might do can have a range) . I never have to worry
> about affecting things outside the region until I widen
> the buffer to the whole file. It sort of fixes the range up front
> (although it's actually more complicated and thorough ),
> as opposed to you giving it a range each time (and perhaps slipping
> up).
Well you could yank your region to a scratch buffer, perform your edits
there and when you are finished, replace that part with the one in your
file. You could probably set this up via a plugin.
regards,
Christian
Kenny McCormack
I think that's the essence of the question: Why hasn't someone (on the
VIM team) done this (yet) ?
--
> No, I haven't, that's why I'm asking questions. If you won't help me,
> why don't you just go find your lost manhood elsewhere.
CLC in a nutshell.
Rui Maciel
> I think that's the essence of the question: Why hasn't someone (on the
> VIM team) done this (yet) ?
This feature may be useful to some people but it isn't exactly desperately in demand.
Rui Maciel
Christian Brabandt
Here we go, a very basic version:
http://www.256bit.org/~chrisbra/Nrrwrgn.vim
it only works with a line based region (so you can't use rectangles and
narrow them). I am not sure, if this is really useful, but I might
upload it to www.vim.org
regards,
Christian
Christian Brabandt
> On 2010-04-27, Rui Maciel <rui.m...@gmail.com> wrote:
>> Kenny McCormack wrote:
>>
>>> I think that's the essence of the question: Why hasn't someone (on the
>>> VIM team) done this (yet) ?
>>
>> This feature may be useful to some people but it isn't exactly desperately in demand.
Well, there are already 3 similar plugins available. That does not sound
too bad. And now there is a fourth (see below).
>
> Here we go, a very basic version:
> http://www.256bit.org/~chrisbra/Nrrwrgn.vim
>
> it only works with a line based region (so you can't use rectangles and
> narrow them). I am not sure, if this is really useful, but I might
> upload it to www.vim.org
An improved version, that allows arbitrarily selections has been
uploaded to vim.org at
http://www.vim.org/scripts/script.php?script_id=3075
regards,
Christian
CharlesM
> On 2010-04-27, Christian Brabandt <cb-n...@256bit.org> wrote:
>
> > On 2010-04-27, Rui Maciel <rui.mac...@gmail.com> wrote:
> >> Kenny McCormack wrote:
>
> >>> I think that's the essence of the question: Why hasn't someone (on the
> >>> VIM team) done this (yet) ?
>
> >> This feature may be useful to some people but it isn't exactly desperately in demand.
>
> Well, there are already 3 similar plugins available. That does not sound
> too bad. And now there is a fourth (see below).
>
>
>
> > Here we go, a very basic version:
> >http://www.256bit.org/~chrisbra/Nrrwrgn.vim
>
> > it only works with a line based region (so you can't use rectangles and
> > narrow them). I am not sure, if this is really useful, but I might
> > upload it towww.vim.org
>
> An improved version, that allows arbitrarily selections has been
> uploaded to vim.org athttp://www.vim.org/scripts/script.php?script_id=3075
>
> regards,
> Christian
Tried it and seems to be working. Didn't change things outside the
narrowed part when I did a global replace - some of the
other narrowing plugins do. I did notice that my search term was
highlighted outside when I widened though. (emacs narrowing would
have left that alone). The widening was confusing at first (didn't
notice that there were two screens). Have to test a bit further, but
all and
all, a good job!
CMM
Christian Brabandt
> On Apr 28, 6:19 am, Christian Brabandt <cb-n...@256bit.org> wrote:
>> An improved version, that allows arbitrarily selections has been
>> uploaded to vim.org athttp://www.vim.org/scripts/script.php?script_id=3075
>
> narrowed part when I did a global replace - some of the
> other narrowing plugins do. I did notice that my search term was
> highlighted outside when I widened though. (emacs narrowing would
> have left that alone). The widening was confusing at first (didn't
> notice that there were two screens). Have to test a bit further, but
> all and
> all, a good job!
Well, regarding the search highlighting that is not possible. If you
have enabled to highlight search terms (:set hls), then vim will always
highlight your current search term in every window. There is no way to
prevent that. But you can save the current search-register and restore
it later (which I have now enabled in the plugin, but that version is
yet only available at github, not yet uploaded to vim.org).
Additionally, that version contains a bugfix, that recalculates the
narrowed region, after widening (so that several Widenings won't change
your original buffer (I hope it is clear, what I mean)
I'll try to write a documentation and include it into the plugin in the
next time. So make sure, to watch the github or vim.org site for the
next time ;)
Anything else, that this plugin should do? (Highlight in the original
buffer the narrowed region, for example?)
regards,
Christian
Rui Maciel
> Here we go, a very basic version:
> http://www.256bit.org/~chrisbra/Nrrwrgn.vim
>
> it only works with a line based region (so you can't use rectangles and
> narrow them). I am not sure, if this is really useful, but I might
> upload it to www.vim.org
Sounds good, Christian. Kudos for contributing to vim. Great stuff.
Rui Maciel
Gary Johnson
> On 2010-04-28, CharlesM <char...@rocketmail.com> wrote:
> > On Apr 28, 6:19�am, Christian Brabandt <cb-n...@256bit.org> wrote:
> >> An improved version, that allows arbitrarily selections has been
> >> uploaded to vim.org athttp://www.vim.org/scripts/script.php?script_id=3075
> >
> > Tried it and seems to be working. Didn't change things outside the
> > narrowed part when I did a global replace - some of the
> > other narrowing plugins do. I did notice that my search term was
> > highlighted outside when I widened though. (emacs narrowing would
> > have left that alone). The widening was confusing at first (didn't
> > notice that there were two screens). Have to test a bit further, but
> > all and
> > all, a good job!
>
> Well, regarding the search highlighting that is not possible. If you
> have enabled to highlight search terms (:set hls), then vim will always
> highlight your current search term in every window. There is no way to
> prevent that.
That's not entirely true, if you allow for modifying the search term
appropriately. For example,
/\%>3l\%<8lfoo
will find and highlight the word "foo", but only on lines numbered
greater than 3 and less than 8. See
:help /\%l
--
Gary Johnson
Christian Brabandt
> Christian Brabandt <cb-...@256bit.org> wrote:
>> Well, regarding the search highlighting that is not possible. If you
>> have enabled to highlight search terms (:set hls), then vim will always
>> highlight your current search term in every window. There is no way to
>> prevent that.
>
> That's not entirely true, if you allow for modifying the search term
> appropriately. For example,
>
> /\%>3l\%<8lfoo
>
> will find and highlight the word "foo", but only on lines numbered
> greater than 3 and less than 8. See
>
> :help /\%l
I am not sure I understand. Of course you can restrict the search to a
certain column or a line, but how does it relate to the fact, that vim
will always highlight a match in /every/ window, where the search term
applies?
You cannot restrict a match to a certain buffer or even a window. Well,
you could if you would be using :match, but that is something different.
regards,
Christian
Gary Johnson
> On 2010-04-29, Gary Johnson <gary...@eskimo.com> wrote:
> > Christian Brabandt <cb-...@256bit.org> wrote:
> >> Well, regarding the search highlighting that is not possible. If you
> >> have enabled to highlight search terms (:set hls), then vim will always
> >> highlight your current search term in every window. There is no way to
> >> prevent that.
> >
> > That's not entirely true, if you allow for modifying the search term
> > appropriately. For example,
> >
> > /\%>3l\%<8lfoo
> >
> > will find and highlight the word "foo", but only on lines numbered
> > greater than 3 and less than 8. See
> >
> > :help /\%l
>
> I am not sure I understand. Of course you can restrict the search to a
> certain column or a line, but how does it relate to the fact, that vim
> will always highlight a match in /every/ window, where the search term
> applies?
The comment from Charles was:
> > I did notice that my search term was highlighted outside when I
> > widened though. (emacs narrowing would have left that alone).
I understood that to mean that he observed the search term to be
highlighted in the same buffer as the narrowed region but outside the
narrowed region.
You replied:
> Well, regarding the search highlighting that is not possible.
You went on to say that the search term will be highlighted in every
window. However, the "that" to which your first sentence referred
appeared to be Charles's statement that the search term was highlighted
outside the narrowed region.
My reply was intended to address the first part of your reply, the "that
is not possible" part. It _is_ possible to restrict the search
highlighting to a narrowed region, with some caveats. I didn't say
anything about highlighting in other windows. I thought that by saying
your reply was not "entirely true" and addressing the line numbers that
that would have been more clear.
Also, I wasn't trying to contradict you as much as I was trying to show
the use of the \%>#l and \%<#l pattern atoms, which I don't think are
known to many users.
> You cannot restrict a match to a certain buffer or even a window. Well,
> you could if you would be using :match, but that is something different.
Agreed.
--
Gary Johnson
esquifit
> Anything else, that this plugin should do? (Highlight in the original
> buffer the narrowed region, for example?)
Thanks for this nice piece of code. Two comments:
1) You're using the following to delete the contents of the scratch
buffer
:%d_
I suppose you meant %d _ (aka "black hole register". Without the
space between d and _ you are not using the _ register, check
out :registers).
2) I was searching for something like that because I wanted to edit
tables 'inline' and make use of the csv plugin in
http://vim.wikia.com/wiki/Working_with_CSV_files.
I've seen that you have also worked based on that tip to produce
http://www.vim.org/scripts/script.php?script_id=2830
Maybe you want to consider merging both scripts into a new "edit
inline tables" script? With "inline table" I mean a 'csv fragment'
surrounded by 'normal' (non-structured) text.
Christian Brabandt
> On 28 Abr, 16:26, Christian Brabandt <cb-n...@256bit.org> wrote:
>
>> Anything else, that this plugin should do? (Highlight in the original
>> buffer the narrowed region, for example?)
>
> Thanks for this nice piece of code. Two comments:
>
> 1) You're using the following to delete the contents of the scratch
> buffer
>:%d_
Thanks. I'll uploaded an improved version.
> I suppose you meant %d _ (aka "black hole register". Without the
> space between d and _ you are not using the _ register, check
> out :registers).
>
> 2) I was searching for something like that because I wanted to edit
> tables 'inline' and make use of the csv plugin in
>
> http://vim.wikia.com/wiki/Working_with_CSV_files.
>
> I've seen that you have also worked based on that tip to produce
>
> http://www.vim.org/scripts/script.php?script_id=2830
>
> Maybe you want to consider merging both scripts into a new "edit
> inline tables" script? With "inline table" I mean a 'csv fragment'
> surrounded by 'normal' (non-structured) text.
Nice idea. That could be really useful, especially for columnizing the
output. Unfortunally the csv.vim plugin is not really in a good shape.
I'll have to put more work into this one. (The RE is really messy and
does not always work reliably, especially with spaces and quotations).
regards,
Christian