:e handles one file
Tom
you explicitly make :e only handle one, then complain if there's more
then one argument and create other commands to do what you're trying
to prevent with the first command? That seems a bit illogical...
Would it be a good idea to have vim handle multiple files with :e in
the future, and if not why?
Tim Chase
Because :e replaces the contents of the current window with the
contents of the specified file, asking for multiple files makes
for an undefined result: should the first file be put in the
current window, and the other files added to the args? Should the
first file be put in the current window, and the other files
split into other windows? How about each in its own tab? Should
the last file in the resulting filespec override the others (as
if ":e f[12].txt" did the same thing as ":e f1.txt" followed by
":e f2.txt")?
So I can see clear reasons for not letting ":e" take a file-glob.
However the two that do surprise me are that :badd and
:split/:vsplit don't let you specify a file-glob. There have
been plenty of times I'd like to issue something like
:sp att*.txt
to open each "att*.txt" file in its own split window. I've seen
(as well as built) some simple functions/commands to assist in
doing that, but those seem less constrained than ":e" and thus
better candidates for accepting a glob, IMHO.
-tim
AK
> On 08/22/2011 12:09 PM, Tom wrote:
>> I know :args can load multiple files in multiple buffers but why would
>> you explicitly make :e only handle one, then complain if there's more
>> then one argument and create other commands to do what you're trying
>> to prevent with the first command? That seems a bit illogical...
>>
>> Would it be a good idea to have vim handle multiple files with :e in
>> the future, and if not why?
>
> Because :e replaces the contents of the current window with the contents
> of the specified file, asking for multiple files makes for an undefined
> result: should the first file be put in the current window, and the
> other files added to the args? Should the first file be put in the
> current window, and the other files split into other windows? How about
> each in its own tab?
> Should the last file in the resulting filespec
> override the others (as if ":e f[12].txt" did the same thing as ":e
> f1.txt" followed by ":e f2.txt")?
My guess is that if you asked 100 vim users, 90-95 would be fine with
either leaving first or last file in current window and loading the
rest in buffer list.
I have to say this is an odd argument.. Vim has maybe on the order of
five thousand commands and options that might conceivably work one way
or another, one way is chosen as a more reasonable default and the
other ways are available via a setting or some workaround.
But for this command, out of thousands, it can't be done!
-ak
Tim Chase
> On 08/22/2011 01:47 PM, Tim Chase wrote:
>> Should the last file in the resulting filespec
>> override the others (as if ":e f[12].txt" did the same thing as ":e
>> f1.txt" followed by ":e f2.txt")?
>
> My guess is that if you asked 100 vim users, 90-95 would be fine with
> either leaving first or last file in current window and loading the
> rest in buffer list.
>
Not too hard to throw together something that will end up editing
all of them:
function! Edit(really, ...)
if len(a:000)
for globspec in a:000
let l:files = split(glob(globspec), "\n")
for fname in l:files
exec 'e'.(a:really).' '.(fname)
endfor
endfor
else
exec 'e'.(a:really)
endif
endfunction
command! -nargs=* -complete=file -bang E call Edit("<bang>",
<f-args>)
which should give you an ":E" command that works like ":e" except
that if you give it one or more filespecs, it loads them all and
leaves you on the last one. E.g.
:E
:E!
:E *.txt
:E! *.txt
:E *.txt *.html
:E! *.txt *.html
So, while I wouldn't use, it's a pretty simple function to make
use of.
-tim
AK
Thanks, I for one will use it. I don't see any harm if vim could do this
with :e command though. -ak
Tim Chase
> On 08/22/2011 05:15 PM, Tim Chase wrote:
>> function! Edit(really, ...)
>> if len(a:000)
>> for globspec in a:000
>> let l:files = split(glob(globspec), "\n")
>> for fname in l:files
>> exec 'e'.(a:really).' '.(fname)
>> endfor
>> endfor
>> else
>> exec 'e'.(a:really)
>> endif
>> endfunction
>>
>> command! -nargs=* -complete=file -bang E call Edit("<bang>",<f-args>)
>>
>> which should give you an ":E" command that works like ":e" except that
>> if you give it one or more filespecs, it loads them all and leaves you
>> on the last one.
>
> with :e command though.
This was almost a cut-n-paste from one of my variants--the
original using ":badd" instead of ":e". If I want to load a file
in the current window, I use :e whereas if I wanted to stock up
the buffer list with a filespec, I used my :badd variant of this
function.
-tim
ZyX
sent 01:15:56 23 August 2011, Tuesday
by Tim Chase:
> which should give you an ":E" command that works like ":e" except
> that if you give it one or more filespecs, it loads them all and
> leaves you on the last one. E.g.
Try :E %, it does not work. You should use expand(...) instead of glob(...)
because expand(...) expands % and some other specials and also globs. You also
definitely forgot fnameescape() and use `len(...)' where you can write either
`!empty(...)' or just `a:0'.
// Not very important, but you can't :E filename with newlines.
Original message:
Tom
place to talk with developers of vim (or policy makers) on their view
on this. Do they post here?
Christian Brabandt
> Scripting solutions aside, I thought the mailinglist would be a good
> place to talk with developers of vim (or policy makers) on their view
> on this. Do they post here?
In the end, you need to talk to Bram about it. He decides.
My guess is, that this is some vi compatibility thing and since vi- and
backwards compatibility is very important to Bram, I think it is very
unlikely to change. Especially, since alternative solutions have been
mentioned.
regards,
Christian
Tom
You can patch and update the old software, not changing behaviour, and
change the new software (progression!). If you keep updating the new
to be compatible with all the old while adding new features, you're
going to end up with a big heap of .. lots of stuff most people don't
need anymore..
If other systems rely on old software, then just dont use the new
version (maybe update the systems?)..
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
George Dinwiddie
On 8/23/11 7:17 AM, Tom wrote:
> I've never understood this type of software policy..
>
> You can patch and update the old software, not changing behaviour, and
> change the new software (progression!). If you keep updating the new
> to be compatible with all the old while adding new features, you're
> going to end up with a big heap of .. lots of stuff most people don't
> need anymore..
>
> If other systems rely on old software, then just dont use the new
> version (maybe update the systems?)..
The "system" consists of people who have used vi for so long that the
knowledge of the commands is in the fingers rather than the brain. The
great popularity of vim is built on the popularity and ubiquity of vi.
If vim were to break compatibility with vi, there would be little reason
to stick with it. It would become "just another editor."
- George
--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------
Tim Chase
> Scripting solutions aside, I thought the mailinglist would be
> a good place to talk with developers of vim (or policy makers)
> on their view on this. Do they post here?
There are a number of Vim devs on this list, though many just
lurk and pop up as needed. Given my gut feeling after a decade
or so on the vim-ml, I'm guessing that your chances of getting
the behavior of :e modified is close to nil. Especially since a
fairly easy scripting solution is readily available and it
changes the semantic meaning of ":edit" (from "I want to edit
this file" to "I want to add this list of files to the
buffer-list and then edit the first/last of them"). You might
have a stronger argument for getting :badd to take a glob-spec as
the purpose of :badd is to add buffers to the buffer-list, but
short of scripting, there's no current mechanism for adding a
glob-spec to the buffer-list.
And as for "policy makers", while Bram mostly (short of forking)
has final say, he's pretty in-tune with the consensus as defined
by some internal weighted sum of his own opinions, mailing-list
member opinion, and TODO items detailed at
:help vote-for-changes
-tim'
Tim Chase
> Reply to message �Re: :e handles one file�,
> sent 01:15:56 23 August 2011, Tuesday
> by Tim Chase:
>
>> which should give you an ":E" command that works like ":e" except
>> that if you give it one or more filespecs, it loads them all and
>> leaves you on the last one. E.g.
> Try :E %, it does not work. You should use expand(...) instead of glob(...)
> because expand(...) expands % and some other specials and also globs. You also
> definitely forgot fnameescape() and use `len(...)' where you can write either
> `!empty(...)' or just `a:0'.
All three are nice modifications. I'm partial to the simplicity
of a:0 and just didn't have the time/inclination to investigate
whether that was JUST the number of varargs, or whether it was
the number of args in total, when len() worked when I reached for
it. I think !empty() reads the most cleanly for future maint.
purposes.
> // Not very important, but you can't :E filename with newlines.
Yeah, I noticed that, since POSIX filenames seem to allow for
that head-scratcher. However since glob() returned things with
newlines separators instead of as a List, there wasn't much to do
about that except shrug and accept it as an "if you choose to do
something stupid like put newlines in your filenames, then this
breaks and it's part of the price you pay for doing that. Do it
manually"
-tim
ZyX
by Tim Chase:
> Yeah, I noticed that, since POSIX filenames seem to allow for
> that head-scratcher. However since glob() returned things with
> newlines separators instead of as a List, there wasn't much to do
> about that except shrug and accept it as an "if you choose to do
> something stupid like put newlines in your filenames, then this
> breaks and it's part of the price you pay for doing that. Do it
> manually"
It is possible to write Expand() :: String -> [Path]. I already have
os.listdir[1] function which cares about possible newlines in filenames* and
also about some other glob limitations/inconvenienses[2].
* Though it assumes that there is no smart-ass who is trying to open such file
on windows: I don't even want to know whether it is going it work: NTFS allows
to create them, but Windows does not.
[1]https://bitbucket.org/ZyX_I/frawor/src/release-0.1.13/plugin/frawor/os.vim#cl-161
[2] http://stackoverflow.com/questions/6411496/6426638#6426638
Original message:
Bram Moolenaar
Christian Brabandt wrote:
Yep. :e is used everywhere, we don't want to change its behavior.
You can just get used to :n instead. Or write a user command if that
isn't exactly what you want.
--
TERRY GILLIAM PLAYED: PATSY (ARTHUR'S TRUSTY STEED), THE GREEN KNIGHT
SOOTHSAYER, BRIDGEKEEPER, SIR GAWAIN (THE FIRST TO BE
KILLED BY THE RABBIT)
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///