Thank you all for your feedback!
Ben Schmidt wrote: > It might be nice in some situations, but it really wouldn't work in Vim [...] > I'm not sure if Bram would be willing to include such a change if > someone wrote a patch for it, either I agree that it's not in line with the Vim philosophy, and I wouldn't ask to have it included in the upstream Vim. I was thinking more of a derivative project, a fork of MacVim, available only for OS X and with several Vim features disabled. That's what would happen for example to vertical splits, block selection, and so on... at least until I find the time to write proper replacements. Björn wrote: > I don't think it is feasible to get proportional editing working > properly with Vim. [...] > Don't let me stop you from trying though! In fact I think I will, starting from your hack! Timothy Grant wrote: > I'm curious how the OP would like to see visual block mode work with > proportional fonts. Existing proportional font editors with the equivalent of visual block mode (there are a few) usually base it on screen pixels, rounded to the nearest character cell, instead of character position. I agree that it wouldn't be terribly useful. I would probably just disable the feature. My aim is *not* that of replacing Vim, which is possibly the most useful piece of software I've ever known, but to make a hybrid between a proportional font editor and Vim, for those who might want to use it. I would, for some tasks. Steven Michalske wrote: > your not crazy, as long as leading white space is somewhat fixed for > us programmers that want pretty fonts. some fonts will adjust the > space based upon the next letter... we may not want that I had already given it quite a bit of thought. Here is my solution. Leading space would be composed of tab characters entirely (noexpandtabs) and each tab position (in pixels) would be computed in different ways, depending on what is being edited. For example, while editing ALGOL-like languages (C, C++, Java, Python, Perl, Ruby, VimScript... and a million others, plus HTML and XML) every tab position would be fixed to tabwidth (or shiftwidth) times the width of a 'x' character. While editing LISP-like languages (:set lisp) the tab positions would be content-dependant and computed separately for each line. They would be equal to the starting positions of all enclosing lists, optionally shifted to the right by (tabwidth times 'x') if the enclosing list has a body, as defined by :set lispwords. Here is an illustration of this wacky concept: http://img80.imageshack.us/img80/9869/tabsro6.png If you don't speak Lisp, believe me that this makes sense. Finally, there could be a table-editing mode, or "tab separated values" editing mode, where the tab positions would be content-dependant but computed once for the whole file: they would be equal to the max width of the respective column of data, plus some space. They could be recomputed on the fly, at the end of every edit operation. The aim is to make the table occupy the least space on the screen, while keeping all columns aligned and non-overlapping. It would be very much like classical HTML table rendering, where the width of every column depends on its widest content, plus some cell spacing. All the while keeping Vim editing modes, mappings, syntax highlighting, plugins, and all the shebang. Yes, I'm insane ;-) Tobia --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_mac" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
