Vim 8.0 Suggestion

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Vim 8.0 Suggestion

Robert Lee-7
I'd like to see an external .vimrc editor shipping with gVim and
directly accessible from within easy mode (e.g. on the tools menu). The
editor would likely be a totally separate binary though, so maybe a
separate project is called for.

What I have in mind is a tabbed dialog (depending on platform), that
behaves like any native dialog on the target platform. So under windows
you would have "OK", "Apply" and "Cancel" (assuming that applying .vimrc
changes to an active vim window is even possible). Only the most basic
settings would be provided (obviously). This is intended for users
absolutely new to gVim. Tabs might include:

 - Shortcuts (mappings), grouped by mode, sorted by keystrokes
 - Abbreviations, similar to above (a.k.a. Auto-correct or Auto-complete)
 - Per-language settings (smartindent, formatoptions, textwidth)
 - Appearance (colors, fonts, line numbering, titlebar text, tabbar
text, status bar text, window chrome features)
 - Syntax Highlighting Colors (a.k.a. a colorscheme editor)
 - Behaviors (search behavior, mouse behavior, command history, scroll
offset, foldmethod, etc)

Also, it would be nice to have native Win32 help (chm). This would annoy
most of us but new users would really like to see this I think. Again,
this can be an external project.

Also, a real built in file browser would be nice (e.g. a sidebar similar
to that in EasyEdit). Actually an optional "Browser" Tabpage showing a
Windows Explorer-like view would be killer on Win32. Oh, and the ability
to add a "New Tab" button to the tab bar. Double-clicking does not work
properly when you are using a text-mode tab bar.

Just brainstorming.

-Robert
Reply | Threaded
Open this post in threaded view
|

Re: Vim 8.0 Suggestion

dominique.pelle
My wishlist for vim-8.0:

- being able to open very large files quickly and
  without using too much memory.  This could possibly
  be achieved by not loading the entire file immediately.
  File could be loaded lazily when required.

- define spelling checker language for different
  part of the file (probably using syntax file).
  In the following example, I would like to
  let the spelling checker know that msgid
  strings are be English and msgstr are in
  French.

    msgid "Any authenticated user"
    msgstr "Tout utilisateur authentifié"

- option to ignore accent differences when searching
  for strings (a bit like ":set ignorecase")
  ex: searching for "cafe" could find "café"

Thanks
-- Dominique
Reply | Threaded
Open this post in threaded view
|

Re: Vim 8.0 Suggestion

Martin Krischik
Am Dienstag 30 Januar 2007 schrieb [hidden email]:

> - being able to open very large files quickly and
>   without using too much memory.  This could possibly
>   be achieved by not loading the entire file immediately.
>   File could be loaded lazily when required.

The last (and only) editor to have that feature was The Atari Editor which run
on 8 bit Atari computers. Was a full screen, modeing editor like vim as
well :-).

Martin

--
Martin Krischik
mailto://[hidden email]

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Vim 8.0 Suggestion

Nikolai Weibull-11
On 1/30/07, Martin Krischik <[hidden email]> wrote:

> Am Dienstag 30 Januar 2007 schrieb [hidden email]:
>
> > - being able to open very large files quickly and
> > without using too much memory. This could possibly
> > be achieved by not loading the entire file immediately.
> > File could be loaded lazily when required.
>
> The last (and only) editor to have that feature was The Atari Editor which run
> on 8 bit Atari computers. Was a full screen, modeing editor like vim as
> well :-).

How do you mean?  A lot of editors work like this.  The Atari Editor
is hardly the first, or last, editor to work this way.  Sam works this
way, Wily works this way, my editor ned works this way, James Brown's
example editor "Neatpad" [1] works this way.

It's usually down to the data structure used to manage buffer contents
that defines whether it's possible to implement this feature or not.
It's can also be down to support for various encodings that can
require preprocessing of the files.

I'm not sure to what degree Vim requires the whole file to be read
before editing can commence.  I'm, however, sure that it can be made
to load files without too much preprocessing, but I'm also pretty sure
that it would require a lot of work and I don't think it's worth the
kind of time that Bram would have to invest in such a feature.  Vim
is, when it all comes down to it, designed to be a programmers editor,
and that means that it'll mostly work with files smaller, mostly much
smaller, than a megabyte, for which preprocessing works fine.

  nikolai

  nikolai

[1] http://www.catch22.net/
Reply | Threaded
Open this post in threaded view
|

Re: Vim 8.0 Suggestion

A.J.Mechelynck
Nikolai Weibull wrote:

> On 1/30/07, Martin Krischik <[hidden email]> wrote:
>> Am Dienstag 30 Januar 2007 schrieb [hidden email]:
>>
>> > - being able to open very large files quickly and
>> > without using too much memory. This could possibly
>> > be achieved by not loading the entire file immediately.
>> > File could be loaded lazily when required.
>>
>> The last (and only) editor to have that feature was The Atari Editor
>> which run
>> on 8 bit Atari computers. Was a full screen, modeing editor like vim as
>> well :-).
>
> How do you mean?  A lot of editors work like this.  The Atari Editor
> is hardly the first, or last, editor to work this way.  Sam works this
> way, Wily works this way, my editor ned works this way, James Brown's
> example editor "Neatpad" [1] works this way.
>
> It's usually down to the data structure used to manage buffer contents
> that defines whether it's possible to implement this feature or not.
> It's can also be down to support for various encodings that can
> require preprocessing of the files.
>
> I'm not sure to what degree Vim requires the whole file to be read
> before editing can commence.  I'm, however, sure that it can be made
> to load files without too much preprocessing, but I'm also pretty sure
> that it would require a lot of work and I don't think it's worth the
> kind of time that Bram would have to invest in such a feature.  Vim
> is, when it all comes down to it, designed to be a programmers editor,
> and that means that it'll mostly work with files smaller, mostly much
> smaller, than a megabyte, for which preprocessing works fine.
>
>  nikolai
>
>  nikolai
>
> [1] http://www.catch22.net/
>

IIUC, Vim loads the whole file in memory before starting to edit. It might be
possible (but not necessarily worth the trouble on modern computers with their
large memory and their huge virtual-memory addressing ranges) to only keep
parts of the file in memory; but:
- depending on the syn-sync setting, it may be necessary to scan part or all
of the file in front of the edit point, even repeatedly, in order to
synchronize the syntax highlighting properly.
- if many scattered changes are made without saving the file, they may have to
be written to the (Vim) swapfile, then later read from swap, causing a
performance degradation over time. (I realize that for files which are larger
than the available RAM, "reading the whole file in memory" actually always
includes some virtual memory, which is OS swap, and not necessarily better
managed than Vim swap.)
- A command such as :$ or G (goto last line) can be implemented by seeking to
EOF then scanning backwards; but for :8752 or 8752G (go to line 8752) I see no
other possibility than counting the 8751 first ends-of-lines (if there are
that many, of course), which means scanning the whole file until there. Of
course, any search also requires scanning from the current location to the
next match in the search direction (and the whole file if there is no match
and wraparound is set). Loading the whole file in memory at the start allows
building an index (or something) which will later allow lightning-fast access
to any line given by number. I see this as an advantage when line numbers are
known, e.g. when trying to evaluate a patch by looking at the parts of the
source that it will change if applied, or when using a tagfile with line
numbers (as opposed to a tagfile with search patterns). (And, yes, the index
could be built incrementally as later parts of the file are accessed, but then
a forward seek might seem to "hang" just because it goes to a part of the file
not yet read from disk.)

Vim is not only a programmer's editor (in the sense of an editor which can be
used to edit source programs: even Notepad can do that). It can do any kind of
editing, and it is particularly useful for complex editing tasks. If it is a
programmer's editor, it is most importantly an editor which can be programmed
(in five programming languages [six in version 7] including vimscript, which
is a full structured-programming language for text, string, and integer
processing). Unlike many other editors, it can handle any kind of text,
including Unicode text, even if the underlying OS has no input method usable
for arbitrary Unicode codepoints. The biggest file I'm currently using it for
is 33.8 million bytes long. That file does take some time to load, and
searching when there is no match, or no nearby match, does take a measurable
time; but IMHO it remains "bearable".


Best regards,
Tony.
Reply | Threaded
Open this post in threaded view
|

Re: Vim 8.0 Suggestion

Bram Moolenaar
In reply to this post by dominique.pelle

Dominique Pelle wrote:

> My wishlist for vim-8.0:
>
> - being able to open very large files quickly and
>   without using too much memory.  This could possibly
>   be achieved by not loading the entire file immediately.
>   File could be loaded lazily when required.

This could perhaps have been useful ten years ago, but computers are now
fast enough not having to do this.

Lazy file loading causes quite a few problems:

- You don't know how many lines there are, the CTRL-G command would not
  work.
- If the file changes after starting to read it you get a big mess.
- If the file is deleted after starting to edit it the user may be very
  surprised he lost the text.  Recovery will also be impossible.
- You quickly end up loading the whole file anyway if you search for a
  pattern without a match, do "G", etc.

> - define spelling checker language for different
>   part of the file (probably using syntax file).
>   In the following example, I would like to
>   let the spelling checker know that msgid
>   strings are be English and msgstr are in
>   French.
>
>     msgid "Any authenticated user"
>     msgstr "Tout utilisateur authentifié"

This is in the todo list somewhere.  It's not difficult to implement,
mostly a question of how to define what language applies where.

> - option to ignore accent differences when searching
>   for strings (a bit like ":set ignorecase")
>   ex: searching for "cafe" could find "café"

/caf[[=e=]]

I don't think we want yet another option to change the meaning of
patterns.  It's difficult enough as it is.

--
Proof techniques #2: Proof by Oddity.
        SAMPLE: To prove that horses have an infinite number of legs.
(1) Horses have an even number of legs.
(2) They have two legs in back and fore legs in front.
(3) This makes a total of six legs, which certainly is an odd number of
    legs for a horse.
(4) But the only number that is both odd and even is infinity.
(5) Therefore, horses must have an infinite number of legs.

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///
Reply | Threaded
Open this post in threaded view
|

Re: Vim 8.0 Suggestion

Nikolai Weibull-11
In reply to this post by A.J.Mechelynck
On 1/31/07, A.J.Mechelynck <[hidden email]> wrote:

> Nikolai Weibull wrote:
> > On 1/30/07, Martin Krischik <[hidden email]> wrote:
> >> Am Dienstag 30 Januar 2007 schrieb [hidden email]:
> >>
> >> > - being able to open very large files quickly and
> >> > without using too much memory. This could possibly
> >> > be achieved by not loading the entire file immediately.
> >> > File could be loaded lazily when required.
> >>
> >> The last (and only) editor to have that feature was The Atari Editor
> >> which run
> >> on 8 bit Atari computers. Was a full screen, modeing editor like vim as
> >> well :-).
> >
> > How do you mean?  A lot of editors work like this.  The Atari Editor
> > is hardly the first, or last, editor to work this way.  Sam works this
> > way, Wily works this way, my editor ned works this way, James Brown's
> > example editor "Neatpad" [1] works this way.
> >
> > It's usually down to the data structure used to manage buffer contents
> > that defines whether it's possible to implement this feature or not.
> > It's can also be down to support for various encodings that can
> > require preprocessing of the files.
> >
> > I'm not sure to what degree Vim requires the whole file to be read
> > before editing can commence.  I'm, however, sure that it can be made
> > to load files without too much preprocessing, but I'm also pretty sure
> > that it would require a lot of work and I don't think it's worth the
> > kind of time that Bram would have to invest in such a feature.  Vim
> > is, when it all comes down to it, designed to be a programmers editor,
> > and that means that it'll mostly work with files smaller, mostly much
> > smaller, than a megabyte, for which preprocessing works fine.
> >
> >  nikolai
> >
> > [1] http://www.catch22.net/
> >
>
> IIUC, Vim loads the whole file in memory before starting to edit. It might be
> possible (but not necessarily worth the trouble on modern computers with their
> large memory and their huge virtual-memory addressing ranges) to only keep
> parts of the file in memory; but:

[a list of reasons why preprocessing may be a hidden cost of commands
being run on the file at around load-time anyway.]

That is all true, but under certain conditions it may still be the
case that pre-loading the whole file is unnecessary.

> Loading the whole file in memory at the start allows
> building an index (or something) which will later allow lightning-fast access
> to any line given by number.

Considering that lightning travels at the speed of light, I'd say that
this is an overestimation of the line-lookup routines.

> Vim is not only a programmer's editor (in the sense of an editor which can be
> used to edit source programs: even Notepad can do that).

My statement was more about the size of a typical file loaded into Vim
than its specific uses.  I consider(ed) that to be obvious.

  nikolai