Re: Patch to support horizontal mouse wheel
Hi Bjorn, On Wed, Jun 30, 2010 at 12:43 PM, björn wrote: > ... > > One comment regarding the code: since vertical movement uses > and I named the horizontal keys and > but I realize that this can be kind of confusing since > e.g. is used for clicking the left mouse button. Should I > change the names? To what? > > ... Perhaps all of those identifiers should be changed to . for scrolling upward is just as confusing to me as for scrolling left. This sounds like a nice and useful patch! - Jordan -- You received this message from the "vim_dev" 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
Re: Update on Vim 7.3 status
On Tue, May 25, 2010 at 2:27 PM, Nikolai Weibull wrote: > I figured that “That said, I think persistent undo is more or less > useless and, well, just a big pile of potential problems. Persistent > undo is in the version control system, not in the editor.” is me > stating an opinion about it, not saying “please remove it”. [...] > > I gave what I considered to be the deeper solution to a problem that > one user figured that persistent undo would bring and that was to keep > edits local. That someone chose to only focus on the fact that I said > that I thought persistent undo was a non-solution was where it > started. [...] > Strawman, much? “I think persistent undo is more or less useless” is > what I initially wrote, followed by “persistent undo is in the > version control system, not in the editor”, which I figured would > imply that my point was that persistent undo is the wrong solution to > the problem. Responding to give another perspective on where persistent undo might fit relative to all of the ways we have to keep track of the history of things. I think that persistent undo is an excellent *complement* to version control. It is not a replacement. I use git to manage revisions and history of every project I work on these days, yet persistent undo is still a great boon to my productivity. For example, pretend you're developing the ultimate novel Vim feature, but you've caused a bug, and want to trace it in gdb. You edit Vim's makefile to enable -g in CFLAGS, recompile, track down the bug, and want to compile a release version. I wouldn't have committed enabling -g in git, as it's a transient change that I don't want to make permanent. So I edit again and undo the change. As another example, pretend you're editing your Apache config in an attempt to get a new module working on your web page. The workflow here is a tight loop - edit, reload apache, test, repeat. If it's too much overhead in this tight loop to continue committing small changes to git, then it's no problem to undo the failed couple lines of new configuration and try again. Persistent undo is a good complement to revision control because it fills in a lower 'tier' of persistence, between session-limited undos and revision control. I think of this space as the realm of small, experimental changes, but of course that is open to the interpretation that works best with the user's workflow. And of course, as others have mentioned, it is an optional feature, so the user may choose to ignore it as she wishes. - Jordan -- You received this message from the "vim_dev" 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
Re: Update on Vim 7.3 status
On Mon, May 24, 2010 at 4:23 PM, James Vega wrote: > On Mon, May 24, 2010 at 10:56:59PM +0200, Bram Moolenaar wrote: > > > > Jordan Lewis wrote: > > > I suppose the argument could be made that the user who has added undo > > > persistence to her vimrc would have read enough of the documentation to > know > > > that she must also set undodir if she doesn't want a polluted current > > > working directory. I don't think that this argument is strong enough to > > > warrant using the new default behavior, though, since a less clued-in > user > > > might not understand why his working directory is suddenly full of dot > > > files. > > > > It's a bit like using backup files. The undo files are hidden (start > > with a dot), thus are less intrusive. It's also like swap files, they > > also go in the same directory as the file, by default. Still, when a > > directory is not writable swap files need to go elsewhere. Undo files > > won't be written when a file is not writable. > > Are the undo files supposed to be hidden when 'undodir' is not the > current directory? If so, that's not currently the case. > No, they should not be hidden - in the common case of a dedicated directory for undo files, this behavior would be unnecessary, and possibly lead to confusion when the directory is examined and found at first glance to be empty. - Jordan -- You received this message from the "vim_dev" 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
Re: Update on Vim 7.3 status
On Mon, May 24, 2010 at 4:39 PM, Tony Mechelynck < antoine.mechely...@gmail.com> wrote: > On 24/05/10 22:30, Jordan Lewis wrote: > [...] > > I am a bit concerned with your decision to write undo files to the >> current directory by default, though. I think that it is "impolite" to >> users to have Vim store its state (especially at the >> 1-statefile-per-file rate that undo persistence uses) directly in the >> user's working directory. It makes more sense to me to use an undo >> directory within ~/.vim by default. If that fails, then the right thing >> to do would be to go ahead and write in the file's directory since, as >> you mentioned, it is likely to succeed. >> >> I suppose the argument could be made that the user who has added undo >> persistence to her vimrc would have read enough of the documentation to >> know that she must also set undodir if she doesn't want a polluted >> current working directory. I don't think that this argument is strong >> enough to warrant using the new default behavior, though, since a less >> clued-in user might not understand why his working directory is suddenly >> full of dot files. >> >> >> >> - Jordan Lewis >> > > The default Bram chose is not the "current" directory (as of :cd or :lcd) > but the directory of the file. The advantage of this choice is that you > could quite possibly have files of the same name (e.g. Makefile) in > different directories, and with a common 'undodir', undofiles for all those > identically-named files would overwrite each other. Placing undofiles in the > directory of the file makes sure that the undofiles for vim73/Makefile, > vim73/src/Makefile, vim73/src/po/Makefile and vim73/src/testdir/Makefile > won't destroy each other. > > > Best regards, > Tony. I should have worded my post better - I did mean the directory of the file as you indicate. And the patch doesn't blindly name all undo files the same if they have the same filename - with a common undo directory, the files will be named path_to_vim73_Makefile.un~, path_to_vim73_src_Makefile.un~, etc. - Jordan -- You received this message from the "vim_dev" 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
Re: Update on Vim 7.3 status
On Mon, May 24, 2010 at 3:06 PM, Bram Moolenaar wrote: > > As you may have noticed, I have added the persistent undo patch > yesterday. The core of this was done by Jordan Lewis. > This means you can make changes to a file, quit Vim, edit that same file > and undo the previous changes. > > I have added a few things, such as computing a hash of the text to > verify it is equal to when the undo file was written. That works better > than a timestamp. > I also changed it to put the undofile with the edited file. That should > work, as writing a file usually means the undofile can be written there > as well. It's possible to change this with the 'undodir' option. > > Note that despite the checks it might still be possible that the undo > information is corruped and changes your text in unexpected ways. Be > careful. > This is excellent news! Thanks for your work. I am a bit concerned with your decision to write undo files to the current directory by default, though. I think that it is "impolite" to users to have Vim store its state (especially at the 1-statefile-per-file rate that undo persistence uses) directly in the user's working directory. It makes more sense to me to use an undo directory within ~/.vim by default. If that fails, then the right thing to do would be to go ahead and write in the file's directory since, as you mentioned, it is likely to succeed. I suppose the argument could be made that the user who has added undo persistence to her vimrc would have read enough of the documentation to know that she must also set undodir if she doesn't want a polluted current working directory. I don't think that this argument is strong enough to warrant using the new default behavior, though, since a less clued-in user might not understand why his working directory is suddenly full of dot files. - Jordan Lewis -- You received this message from the "vim_dev" 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
Re: patch for strong encryption in vim, resending patch for vim7* dev branch.
On Sun, May 16, 2010 at 6:54 PM, Tony Mechelynck < antoine.mechely...@gmail.com> wrote: > > 2. "In the public domain". > > > This looks promising; but one part has a "note" in lawyerese and the other > a "defined term" in quotes, let us see... ah, I think this clinches it, and > since there is an "or" clause, no need (I think) to check the other: > > > GTN "In the public domain" > GSN This means "technology" or "software" which has been made available > ML 22 without restrictions upon its further dissemination. >NoteCopyright restrictions do not remove "technology" or > "software" from being "in the public domain". > > > I believe that Vim is "in the public domain" within the definitions used in > that document (but of course, IANAL, nor do I play one on TV). > No, I don't think that Vim is "in the public domain" at all or even according to this document. The definition you quoted has the key phrase "without restrictions upon its further dissemination." Even the first clause of Vim's license agreement here http://vimdoc.sourceforge.net/htmldoc/uganda.html#license requires distributing the license itself alongside of any part of Vim that you choose to distribute yourself. I believe that this requirement, although trivial, constitutes a restriction upon further dissemination, which removes it from the public domain classification. I am similarly NAL, though. - Jordan Lewis -- You received this message from the "vim_dev" 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
Re: Planning Vim 7.3
On Sun, May 2, 2010 at 7:31 PM, Nazri Ramliy wrote: > With hard link it's harder (impossible?) to determine what the 'target' > is based on their file names because of ambiguity: one hardlink is no > different than another - they are all first class 'file names'. > You're right, of course. I wasn't thinking. > Using the SHA1 of the content of the target file as the unique id into > its associated undo file might solve the problem. > I had tried out using hashes instead of file mtimes to determine undo file validity in an earlier version of this patch, but gave it up after it was suggested that the potentially large time requirement for hashing large files wasn't worth it when you consider that, in the majority of cases, a different file mtime means different file contents. So I don't think hashing is an appropriate solution for dealing with hard links. Perhaps it could be available as an option, but for now I think it is OK if we can't handle matching undo files for many hard links to the same file. - Jordan -- You received this message from the "vim_dev" 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
Re: Planning Vim 7.3
On Sat, May 1, 2010 at 8:20 AM, Christian Brabandt wrote: > Thanks for letting me know. Today it's the first time I tested this > feature. This is really awesome and I have been missing it so much. I > already started testing it. There are some issues I already noticed: > > 1) This does not work very well with files that are symlinked. If >you start by editing a symlink file, the undo will be saved and >remembered only for the symlink. If you are later start editing >the symlink target, there won't be any undo-state remembered and >further you are loosing your old remembered undo points (because >even if you later again start editing the symlink file, you >won't be able to undo changes. > This should be a relatively easy fix, if the desired behavior is to have all of the symlinks associate to the same undo file as the target. Same story for hard links. > >2) What happens with old undo files? They seem to accumulate and >it seems that sooner or later you'll have in ~/.vim/undo/ a bunch >of unusable undo files. Could they be deleted automatically, >when they become unusable or is there a way to force reading the >undo-file? > This is kind of a tricky problem - the only way Vim will notice when an undo file becomes unusable is if a user edits the file its associated with. But then presumably the user will soon write another fresh undo file for the file that was just opened, so there wouldn't actually be any pruning unless the user just opens and closes the file without writing out a new undo file. I suppose it wouldn't be hard to write a cleanup function that would iterate through the whole undo directory and delete those which are out of date or whose associated file no longer exists. Would that be useful? > >3) :rundo should at least output some message, if it can't restore >the undo points from a previous session, since the file has been >modified by some other program. > When I first wrote this patch, an error message for this was printed both for explicit and implicit :rundo (implicit being when undofile is set in the vimrc, and the undo file is automatically loaded). Some testers were peeved by error messages popping up indicating outdated undo files for the automatic undo file load, so I removed them unless the verbose mode was greater than 0. But it makes sense to display the messages for explicit :rundo always; I will make that change. > I'll keep on testing it. Thanks for your work! - Jordan -- You received this message from the "vim_dev" 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
Re: Planning Vim 7.3
On Tue, Apr 13, 2010 at 10:31 AM, Ernie Rael wrote: > On 4/13/2010 5:49 AM, Bram Moolenaar wrote: > >> Jordan Lewis wrote: >> >> >> >>> Any thoughts about including persistent undo in Vim 7.3? >>> >>> >> I do like the functionality of this patch, but this is something that >> >> requires a lot of testing. You don't want your text to be changed in >> unexpected ways (lines go missing or duplicated where you aren't >> looking). >> >> >> >> > I'm unfamiliar with the internal operation of this patch. Does it verify > that the file in question, with persistent undo info, has not been modified > since last open. For example with a crc? > > -ernie It does a basic check using file modification times, which is sufficient barring a pathological user who modifies a file's mtime to match the last time Vim wrote out the file, after modifying the file itself. -- You received this message from the "vim_dev" 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 To unsubscribe, reply using "remove me" as the subject.
Re: Planning Vim 7.3
Any thoughts about including persistent undo in Vim 7.3? It's being maintained in Markus Heidelberg's vim_extended repository here http://repo.or.cz/w/vim_extended.git/shortlog/refs/heads/feat/persistent-undo. It's also the 3rd most popular new feature on the new feature voting list. - Jordan Lewis On Mon, Apr 12, 2010 at 5:45 PM, Lech Lorens wrote: > On 12-Apr-2010 Tony Mechelynck wrote: > > #10 (Variable tabstops) sounds interesting. I haven't tested it. > > Reportedly still in alpha. Probably wait some more (Vim 8.0 ?) but > > keep an eye on it. > > Pretty stable alpha, I'd say. It's of limited use for programming but > I've been using it for configuration files and it's been totally > reliable since the last update in Nov 2009. > > -- > Cheers, > Lech > > -- > You received this message from the "vim_dev" 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 > > To unsubscribe, reply using "remove me" as the subject. > -- You received this message from the "vim_dev" 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
Re: [patch] Persistent undo
2009/11/16 Dominique Pellé :
>
> Jordan Lewis wrote:
>
>> Hi,
>>
>> I've added some documentation to the patch I wrote for persistent
>> undo. It's been a while since I've posted about this, so I'll recap
>> the features:
>>
>> 1. New option 'undofile' causes Vim to automatically write out the
>> undo history for the current session to a file located in the directory
>> (ies) provided by the new 'undodir' option, and to automatically read
>> back this undo history when the same file is opened again.
>> 2. New commands :wundo and :rundo allow you to manually write and read
>> undo files, respectively.
>>
>> The attached diff was created against SVN version 1658. Once you patch
>> your source, you'll want to add 'set undofile' to your vimrc to enable
>> the functionality. Then make some edits to a file, quit Vim, and open
>> the file again - you will still be able to undo your edits.
>>
>> I've been using this patch in my Vim for close to a year now, and its
>> a real productivity booster. Working on other machines without undo
>> persistence has become fairly difficult for me, as I'm so used to
>> being able to revert changes I've made to (for example) a LaTeX file
>> after exiting Vim, creating a PDF, and noticing a mistake.
>>
>> Please try this patch! I think you all and the rest of the Vim
>> community will really like this functionality.
>>
>>
>> Thanks,
>> Jordan Lewis
>
> Hi Jordan
>
> Thanks for your work!
>
> The persistent undo feature would be very nice in my opinion.
> And I see that persistent undo is quite high on the feature voting
> page:
>
> http://www.vim.org/sponsor/vote_results.php
>
> Some remarks about your patch:
>
> - code compiles fine with huge version of Vim but fails to
> compile with tiny version of Vim:
>
> $ ./configure --with-features=tiny
> $ make
> ...
> objects/undo.o: In function `unserialize_pos':
> /tmp/vim7/src/undo.c:667: undefined reference to `get4c'
> /tmp/vim7/src/undo.c:668: undefined reference to `get4c'
> etc, etc...
>
> - It would be best to have the persistent undo code
> within something like #ifdef FEAT_PERSISTENT_UNDO
>
> - compilation warning:
> undo.c:1073: warning: unused variable ‘cur_seq’
>
> - typo in undo.c:946: strutures -> structures
>
> - Memory leak: variable munged_name allocated at undo.c:703
> is never freed:
>
> 702 name_len = STRLEN(ffname);
> 703 munged_name = alloc(name_len + 1);
> 704 mch_memmove(munged_name, ffname, name_len + 1);
>
> - Using the same coding convention of Vim may increase your chance
> of having the patch merged in the main tree. For example:
>
> if (...) {
> ...
> }
>
> ... should be...
>
> if (...)
> {
> ...
> }
>
> - serialize_uep(...) has FILE *fp as first argument whereas
> functions serialize_pos(...) & serialize_visualinfo(...) have
> FILE *fp as last argument. Consistent would be better.
>
> - According to Valgrind memory checker, line undo.c:1033
> writes an uninitialized value uep->ue_lcount in
> serialize_uep(...):
>
> put_bytes(fp, (long_u) uep->ue_lcount, 4);
>
> I will check further when I have time, maybe next weekend.
>
> Cheers
> -- Dominique
Thanks for the excellent comments, Dominique. I've incorporated most
of your feedback into the patch, and I have a few further questions.
> objects/undo.o: In function `unserialize_pos':
> /tmp/vim7/src/undo.c:667: undefined reference to `get4c'
> /tmp/vim7/src/undo.c:668: undefined reference to `get4c'
> etc, etc...
This family of functions (get[2,3,4,8]c) currently lives in spell.c,
but they are generic enough that I was able to easily reuse them.
Should they be moved to misc.c or misc2.c? This would remove the
dependency of persistent undo on the spelling feature.
> - It would be best to have the persistent undo code
> within something like #ifdef FEAT_PERSISTENT_UNDO
I've wrapped all of the persistent undo with an #ifdef like you
recommended, and set FEAT_PERSISTENT_UNDO to appear in Vims of size
normal or above. Is that a reasonable setting, or should I change it
to big or huge?
I've attached an updated patch that should address your remarks with
the exception of the uninitialized value problem that Valgrind turned
up. I'm still working on the solution to that.
This updated patch should now also build and run on Windows, thanks to
Erik Falor's helpful advice.
- Jordan
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
persistent_undo.diff
Description: Binary data
Re: Persistent undo
On Nov 16, 10:49 am, Erik Falor wrote: > I'm sorry to report that your patch does not build on Windows with > VS2008. Thanks for that input - I've only tested the patch under Linux and Mac OS X. I don't actually have a Windows development environment available to me at the moment, but I'll try to get this issue fixed. --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
[patch] Persistent undo
Hi, I've added some documentation to the patch I wrote for persistent undo. It's been a while since I've posted about this, so I'll recap the features: 1. New option 'undofile' causes Vim to automatically write out the undo history for the current session to a file located in the directory (ies) provided by the new 'undodir' option, and to automatically read back this undo history when the same file is opened again. 2. New commands :wundo and :rundo allow you to manually write and read undo files, respectively. The attached diff was created against SVN version 1658. Once you patch your source, you'll want to add 'set undofile' to your vimrc to enable the functionality. Then make some edits to a file, quit Vim, and open the file again - you will still be able to undo your edits. I've been using this patch in my Vim for close to a year now, and its a real productivity booster. Working on other machines without undo persistence has become fairly difficult for me, as I'm so used to being able to revert changes I've made to (for example) a LaTeX file after exiting Vim, creating a PDF, and noticing a mistake. Please try this patch! I think you all and the rest of the Vim community will really like this functionality. Thanks, Jordan Lewis --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- persistent_undo.diff Description: Binary data
Re: Persistent Undo
On Feb 27, 5:28 pm, Jordan Lewis wrote: > Good point, aside from some kind of rare race condition it seems like > using mtime would offer only advantages over checksumming. I'll try to > make this change sometime soon and resubmit the patch. I've replaced the checksum operation with a simple mtime check. This allowed me to remove the extra checksumming functions I wrote from misc2.c. This patch is now against SVN revision 1390. --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- persistent_undo.diff Description: Binary data
Re: Persistent Undo
On Feb 23, 4:51 am, Andreas Bernauer wrote: > > 2. Added 'undofile'/'udf' option that toggles automatic undo file > > writing and reading. If a file's checksum changed since the last time > > it had an undo file written for it, Vim will silently (or loudly, with > > verbose > 0) ignore the undo file when editing the file. > > Why do you use checksum? For large files, this could take very long. How about > mtime or some other timestamp of the filesystem? Good point, aside from some kind of rare race condition it seems like using mtime would offer only advantages over checksumming. I'll try to make this change sometime soon and resubmit the patch. > Is it possible to exclude some files from undo saving? I was thinking that there could be an option containing a list of filename patterns that would cause undo saves not to happen, a la cvsignore. > Reasoning for using a binary format? I designed the file format in an ad-hoc fashion, and it is a lot easier to simply write out numbers than to convert everything into strings, and design a nice format, etc. Some (possibly negligible) advantages to using a binary format: 1. No need to do difficult parsing or include an XML library or anything. 2. No difficulties with an 'end-of-string' marker heuristic: can just use a null byte instead of having to pick a marker and hack to make sure that no one can accidentally include it in their text file 3. Smaller files 4. Swap files and spell files are already in a binary format, so it shouldn't come as a surprise for people to see a new one. On the other hand, it would be nice to have a human-readable format. > If the undo file is shared between systems > that use different binary representation, things will probably go havoc. Yep, probably. > Without having looked into it, I guess the undo parts contain text that has > been > undone plus some extra information such as location and time, all of which > could > be represented in a text format. There's significantly more metadata than just the things that you mentioned, but yes, it would probably be possible to represent the file textually. - Jordan --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
[patch] Persistent Undo
This patch implements persistent undo. It is against SVN revision 1365. I'd like to submit it to the list to see what people think. More specifically, here are the changes: 1. Added commands :wundo and :rundo that write and read undo files respectively. An undo file is a binary file that contains an undo tree. One of these will exist for every file whose undo tree is saved. 2. Added 'undofile'/'udf' option that toggles automatic undo file writing and reading. If a file's checksum changed since the last time it had an undo file written for it, Vim will silently (or loudly, with verbose > 0) ignore the undo file when editing the file. 3. Added 'undodir'/'udir' option that defines a list of directories in which to save the undo files. I copied the per-OS default values for this option based on the swapfile 'dir' option. 4. Added simple crc32 checksum based on the crc32 crypto in misc2.c and a function to checksum a buffer. 5. Made the get2c, get3c, and get4c functions in spell.c not static since they were useful to me. Perhaps these belong in one of the misc.c files now? 6. Added calls to u_wundo and u_rundo where files get written/read if undofile is set. It seems like I had to put these calls in too many places, perhaps there is a better place for them? To test it, you'll need to: 1. set the 'undofile' or 'udf' option in your .vimrc 2. mkdir .vim/undo, or set undodir to something else and mkdir it 3. change a file, :wq, reload, and your undo tree should be loaded Things to note: 1. I have only tested this patch on Linux (32- and 64-bit) and OS X machines. 2. If the checksum of a file changes in between edits, the patch will not load the undo file. A message will get displayed about this if your verbose is greater than 0. 3. The undo files are saved in a binary format. I have put some simple safety checks in the unserialization function, but if you edit the undo file, there is a high likelihood that Vim will choke. 4. I didn't give error numbers to the new error messages I defined. I suspect that this is important, but I wasn't sure how the numbering scheme works. Known bug: If you edit a file inside of a zip archive and save changes, Vim will segfault when you re-edit it later and it tries to load the undofile. I suspect this is because Vim seems to have two different types of canonical name for files within zip archives, and the undo file mechanism somehow mismatches these representations. I am unfamiliar with the mechanics of Vim's zip file support, so I thought I would ask the list for advice on how to fix this issue. Comments and suggestions would be greatly appreciated. - Jordan Lewis --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- persistent_undo.diff Description: Binary data
Re: Summer of Code 2008
Bram Moolenaar wrote: > Jordan Lewis wrote: >>* Undo persistence - save a representation of the tree to a file on >> or before exit >> > > This would be really nice. But it's very likely too much work for the > SoC. Especially because it must work very reliably. > I have been thinking more about a possible implementation of this, and I think that the main difficulty would be coming up with a text-based (or binary) representation of the undo tree that is isomorphic to the undo tree data structure. Once that is overcome, though, I don't think that the saving/loading functionality (which comes down to converting the data structure into the file representation and back) would be too much work for me in the 2+ months that SoC consists of. There are already some hints on how this might be done in the other .viminfo data as far as I can tell, for example per-file mark history. It sounds like you know about another difficulty that I am missing, however, and I would greatly appreciate if you could explain what it is so I can revise my proposal. Thanks, Jordan Lewis --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Summer of Code 2008
Hello Vimmers, My name is Jordan Lewis, and I am applying to Vim for Google's Summer of Code this year. I am a first year student at the University of Chicago (and a Vim addict). I am planning to work on some of the items in todo.txt like the ideas page suggests, and I wanted to get some opinions on the ones that I've been looking at (I don't intend to necessarily work on all of these items, or these items exclusively). 1. Undo tree improvements * Implement visual representation suggested by Damian Conway. * Undo persistence - save a representation of the tree to a file on or before exit * Pattern search - incremental search of undo tree for full text of each operation - this could be fairly easily done by wrapping the existing search function to search the right parts of the undo file 2. Scrolling * Add scrolling that doesn't move the cursor, as in the scroll bar in GUI applications - this would serve as an automatic mark. movement would spring the view back to where the cursor was, and you could choose to move the cursor to the current view with a command. This would also be usable (and helpful) in visual mode selection * Implement Rimon Barr's suggestion of scrolling marks - save the current cursor position to '- on a scroll or jump operation if there has been editing between it and the last one. Are these good items to work on? Any and all feedback is appreciated. Thanks, Jordan Lewis --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
