Feature request... non-uniform tabstops

[Mark Waggoner]

I've asked Bram in the past whether he would add this to the voting list.  The best I've been able to get is "I'll think about it" :)   Perhaps if I throw the idea out to the mailing lists I can garner a little support.

When editing or viewing text files that contain data with fields separated by tab characters, I would like to be able to set non-uniform tabstops.  This would allow the text to be viewed and edited in a much more readable/understandable format than fixed tabstops can provide.   The usage model I envision is:

set tabstop=8,10,4,20,8

This would make (depending on how you are counting) the first tabstop at character 9, the second at character 19, the third at 23, the fourth at 43, and the fifth at 51.  Tabstops beyond those explicitly specified would repeat the last tabstop, making the setting backward compatible with what we have today, where only one value is allowed and it is used for all the tabstops.

 

Anyone else care to join me in voting to add this to the voting options?

Mark Waggoner
 

(I'm trying out mailing to the list with gmail for the first time.  If this ends up "ugly", my apologies.) 

[Gregory Seidman]

On Mon, Aug 27, 2007 at 10:27:02AM -0700, Mark Waggoner wrote:
> I've asked Bram in the past whether he would add this to the voting list.
> The best I've been able to get is "I'll think about it" :) Perhaps if I
> throw the idea out to the mailing lists I can garner a little support.
>
> When editing or viewing text files that contain data with fields
> separated by tab characters, I would like to be able to set non-uniform
> tabstops. This would allow the text to be viewed and edited in a much
> more readable/understandable format than fixed tabstops can provide.
> The usage model I envision is:
>
> set tabstop=8,10,4,20,8
>
> This would make (depending on how you are counting) the first tabstop at
> character 9, the second at character 19, the third at 23, the fourth at
> 43, and the fifth at 51. Tabstops beyond those explicitly specified
> would repeat the last tabstop, making the setting backward compatible
> with what we have today, where only one value is allowed and it is used
> for all the tabstops.
>
> Anyone else care to join me in voting to add this to the voting options?

I like it a lot. I usually wind up just making the window huge and making
the tabstops extra big, but variable width would be nice.

> Mark Waggoner
--Greg

[Zdenek Sekera]

> From: vim...@googlegroups.com
> [mailto:vim...@googlegroups.com] On Behalf Of Mark Waggoner
> Sent: 27 August 2007 19:27
> To: v...@vim.org; vim...@vim.org
> Subject: Feature request... non-uniform tabstops

>
> I've asked Bram in the past whether he would add this to the
> voting list.  The best I've been able to get is "I'll think
> about it" :)   Perhaps if I throw the idea out to the mailing
> lists I can garner a little support.
>
> When editing or viewing text files that contain data with
> fields separated by tab characters, I would like to be able to
> set non-uniform tabstops.  This would allow the text to be
> viewed and edited in a much more readable/understandable format
> than fixed tabstops can provide.   The usage model I envision
> is:
>
> set tabstop=8,10,4,20,8
>
> This would make (depending on how you are counting) the first
> tabstop at character 9, the second at character 19, the third
> at 23, the fourth at 43, and the fifth at 51.  Tabstops beyond
> those explicitly specified would repeat the last tabstop,
> making the setting backward compatible with what we have today,
> where only one value is allowed and it is used for all the
> tabstops.
>
> Anyone else care to join me in voting to add this to the voting
> options?

I do, because I like it very much and would find it a very
useful addition to vim features.

there has been other attempts in the past to suggest or even
to try to implement such a feature, one the most attractive (to
me) seemed to be the 'elastic tabstops' suggested in this forum
by Nick Gravgaard around Oct last year ( I CC him on this email
just in case he cares to add a comment), my last email exchange
with him on this subject dates Mar/2007, however, to my sad
surprise, I can see that his aim to implement this in vim
completely disappeared from http://nickgravgaard.com/elastictabstops/
Of course this is a more ambitious feature then one suggested
above by Mark, but I would for sure love to have at least
this one.

---Zdenek

-----------------------------------------------------
Zdenek Sekera | zdenek...@cern.ch
LHC Computing Grid Project | +41 76 487 4971 (mobile)
CERN, IT Department | +41 22 767 1068 (office)
CH-1211, Geneva 23, Switzerland

[Richard Hartmann]

On 28/08/07, Zdenek Sekera <Zdenek...@cern.ch> wrote:

> there has been other attempts in the past to suggest or even
> to try to implement such a feature, one the most attractive (to
> me) seemed to be the 'elastic tabstops' suggested in this forum
> by Nick Gravgaard around Oct last year

If I remeber that concept right it might hit the same spot as my
suggestion of 'AutoAlign'.

Back then, it was proposed as a formatting (not identing) option
which is inherently evil (set autoindent; set copyindent anyone?),
but for displaying data that just happens to have different lengths,
it would be great. That thing could then save back into the
expanded tabstop variable, offering the full experience, so to
speak.

Richard

[Ilya Sher]

Mark Waggoner wrote:

[snip]

> When editing or viewing text files that contain data with fields
> separated by tab characters, I would like to be able to set non-uniform
> tabstops.

I needed that several times too.

[snip]

--
Beating the averages: http://www.paulgraham.com/avg.html
Python paradox: http://www.paulgraham.com/pypar.html
Bad Vista: http://badvista.org/
XML sucks: http://c2.com/cgi/wiki?XmlSucks
For robots (please don't mail me there): part...@sshoverpci.com

[Nick Gravgaard]

On Aug 28, 9:52 am, "Zdenek Sekera" <Zdenek.Sek...@cern.ch> wrote:
>
> > From: vim...@googlegroups.com
> > [mailto:vim...@googlegroups.com] On Behalf Of Mark Waggoner
> >

> > When editing or viewing text files that containdata with

> > fields separated by tab characters, I would like to be able to

> > set non-uniform tabstops.This would allow the text to be

> > viewed and edited in a much more readable/understandable format
> > than fixed tabstops can provide.

This is one of the things that elastic tabstops makes possible. One of
the nice things about it is that the columns will expand (by re
setting the tabstops) to accommodate their contents as you type
without inserting whitespace, so it's perfect for editing tab
separated value files.

> there has been other attempts in the past to suggest or even
> to try to implement such a feature, one the most attractive (to
> me) seemed to be the 'elastic tabstops' suggested in this forum
> by Nick Gravgaard around Oct last year ( I CC him on this email
> just in case he cares to add a comment), my last email exchange
> with him on this subject dates Mar/2007, however, to my sad
> surprise, I can see that his aim to implement this in vim
> completely disappeared from http://nickgravgaard.com/elastictabstops/
> Of course this is a more ambitious feature then one suggested
> above by Mark, but I would for sure love to have at least
> this one.

For elastic tabstops to be implementable we need the ability to not
only set non-uniform tabstops, but also to be able to do so on
different lines. I have no idea how much work it would take to
implement this. gvim may be able to take advantage of the fact that
GTK's GtkTextView text widget supports this (I have a patched version
of gedit on the page you linked to), but it will presumably need to be
done in a different way for the console and other versions...

Nick

[Nick Gravgaard]

Nick

PS. Apologies to anyone getting this mail more than once - joining a
Google Group caused me some grief.

[Yakov Lerner]

On 8/27/07, Mark Waggoner <mark.w...@gmail.com> wrote:
>
>
> I've asked Bram in the past whether he would add this to the voting list.
> The best I've been able to get is "I'll think about it" :) Perhaps if I
> throw the idea out to the mailing lists I can garner a little support.
>
> When editing or viewing text files that contain data with fields separated
> by tab characters, I would like to be able to set non-uniform tabstops.
> This would allow the text to be viewed and edited in a much more
> readable/understandable format than fixed tabstops can provide. The usage
> model I envision is:
>
> set tabstop=8,10,4,20,8

You can make this in vimscript, as "userlevel" plugin.
By remapping the tab in i-mode an using <expr> to expand it to your
function.
Get example of simple plugin, learn vimscript, make plugin, post to
www.vim.org/scripts.

Yakov

[Charles E Campbell Jr]

Hello!

Those of you who are interested in "elastic" non-uniform tab stops may
find Align/AlignMaps/AutoAlign of interest. Its not a pure non-uniform
tab solution (that would take a modification to vim itself); however,
there's an almost-elastic-tab solution there.

If the tabstop is set to 1 (:set ts=1), then AlignMaps' \tab will do a
no-padding alignment on the tabs. Thus one gets tabs surrounded by
spaces to do the alignment.

AutoAlign now provides a new filetype: eltab . If your file has a
modeline: vim: ft=eltab
then the file will be re-aligned with \tab and tabstop=1 when you start
editing it. Furthermore, as you type, tabs will be auto-aligned with
the current insertion block of text; total file alignment can be done
with 1V$\tab (ie. select entire file, align it).

You'll need the Align/AlignMaps/AutoAlign plugins from my website:
http://mysite.verizon.net/astronaut/vim/index.html#ALIGN and
http://mysite.verizon.net/astronaut/vim/index.html#AUTOALIGN .

Regards,
Chip Campbell

[Nikolai Weibull]

> > set tabstop=8,10,4,20,8

Not in general, though. Yes, mapping <Tab> is easy, but the problem
is that one has to deal with the case when text is deleted as well.
Then, assuming we have <Tab> insert the necessary number of spaces to
the next 'tabstop', this would break.

nikolai

[Mark Waggoner]

There are two critical factors that make vimscript solutions undesirable:

 

1. This is NOT for entering text - it is for viewing/editing text that already exists.  So any mapping solutions aren't really useful.

 

2. I do not want spaces added to the file to create the alignment.  The description of the AutoAlign method sounds really close to "working" if, before re-saving, I were to replace all the "spaces followed by a tab" with a tab, (and maybe it already does this automatically - I haven't tried).  However, if there were a place where some text was SUPPOSED to have a space before a tab, it would go away.

 

I did just try installing AutoAlign - but I get errors such as:

 

E486: Pattern not found: ^(t*)(.*)
 

when I try to use \tab on a range of lines.  No doubt I am missing something, but I don't have time to debug it right now.

 

Mark

[Charles E Campbell Jr]

Mark Waggoner wrote:

>
> There are two critical factors that make vimscript solutions undesirable:
>
> 1. This is NOT for entering text - it is for viewing/editing text that
> already exists. So any mapping solutions aren't really useful.
>
> 2. I do not want spaces added to the file to create the alignment.
> The description of the AutoAlign method sounds really close to
> "working" if, before re-saving, I were to replace all the "spaces
> followed by a tab" with a tab, (and maybe it already does this
> automatically - I haven't tried). However, if there were a place
> where some text was SUPPOSED to have a space before a tab, it would go
> away.
>
> I did just try installing AutoAlign - but I get errors such as:
>
> E486: Pattern not found: ^(t*)(.*)
>
> when I try to use \tab on a range of lines. No doubt I am missing
> something, but I don't have time to debug it right now.

Did you also get an up-to-date Align/AlignMaps plugin? The new Align
plugin processes the input arguments itself, rather than depending on
<f-args> processing; the reason is that <f-args> converts \x to x unless
x is a \, in which case \\ -> \\, thereby making <f-args> difficult to
use with regexp patterns (I submitted a patch providing <p-args> which
is well-suited for pattern handling, but Bram didn't appear to care for it).

The "Pattern not found:..." message sounds like the old <f-args> trick
of removing the backslashes, so \t -> t.

I didn't put a

au BufWritePre * if &ft == "eltab"|%s/ *\t */\t/ge|endif

into eltab/eltab.vim, but obviously it'd be easy to do. I didn't do so
because its also easy to do manually, and I'm not certain that I should
force it on users. However, its a new addition to AutoAlign, and is in
beta, so this could change depending on what folks indicate should be there.

Regards,
Chip Campbell

[Mark Waggoner]

Once I investigated a little - I had some old Align files in my .vim/* directory that were conflicting.  It seems to be working better now.  I'll try it for a while.

 

When I extracted the Align.vba file (which I haven't done before), it created output files named, for example, plugin/AlignPlugin.vim<tab>[[[1  (where <tab> is an actual tab character).  I presume that the extra characters past the .vim aren't really supposed to be there, and I renamed them.

 

 

Thanks,

 

Mark Waggoner

 

[drc...@campbellfamily.biz]

Quoting Mark Waggoner <mark.w...@gmail.com>:

>
>
> When I extracted the Align.vba file (which I haven't done before), it
> created output files named, for example, plugin/AlignPlugin.vim<tab>[[[1
> (where <tab> is an actual tab character). I presume that the extra
> characters past the .vim aren't really supposed to be there, and I renamed
> them.

Hmmm -- now that sounds like you're using vim 7.0 (the vimball plugin had some
bugs which are fixed in the 7.1 release). I suggest upgrading to vim 7.1;
there's instructions at my website, however, for just upgrading vimball if you
wish.
(http://mysite.verizon.net/astronaut/vim/index.html#VIMBALL )

Regards,
Chip Campbell

[Richard Hartmann]

On 28/08/2007, Nick Gravgaard <nickgr...@gmail.com> wrote:

> For elastic tabstops to be implementable we need the ability to not
> only set non-uniform tabstops, but also to be able to do so on
> different lines. I have no idea how much work it would take to
> implement this. gvim may be able to take advantage of the fact that
> GTK's GtkTextView text widget supports this (I have a patched version
> of gedit on the page you linked to), but it will presumably need to be
> done in a different way for the console and other versions...

As someone who uses command line vim exclusively, I would be against
a GVim-only solution ;)

Richard

PS: Unrelated note: KVim will never see the light of day again, will it?
The zyk (or similar) project that aims to reimplement a feature subset is
the only living project, correct?

[Tony Mechelynck]

Richard Hartmann wrote:
[...]

> PS: Unrelated note: KVim will never see the light of day again, will it?
> The zyk (or similar) project that aims to reimplement a feature subset is
> the only living project, correct?

IIUC:
- kvim is dead. The latest version was (IIRC) 6.2.something. There may be some
(outdated, of course) versions of it in some Linux distros.
- yzis may be alive but I haven't heard much about it on this list.
- gvim with Gnome2 GUI is standard (the sources are part of Bram's
distributions), it works quite well under kde, and (among other goodies) saves
and restores its session transparently when you log out of / into the kde
winmanager. Bram says it has bugs but none of them has bitten me yet.

Best regards,
Tony.
--
Real Users know your home telephone number.

[Richard Hartmann]

On 31/08/2007, Tony Mechelynck <antoine.m...@gmail.com> wrote:

> IIUC:

iiuc?

> - yzis may be alive but I haven't heard much about it on this list.

I used to check their website regularly, but nothing on there :/

> - gvim with Gnome2 GUI is standard (the sources are part of Bram's
> distributions), it works quite well under kde, and (among other goodies) saves
> and restores its session transparently when you log out of / into the kde
> winmanager. Bram says it has bugs but none of them has bitten me yet.

Problem is that this will not integrate into KDE as an embedded editor. For
example, I normally write emails with pine & vim. Using Kontact & their editor
is extremely slow and painful (not as painful as using the GMail interface
without fixed width fonts or tw=72 which means I need to guess the
formatting..) when replying to more complex mails.

Richard

[Tony Mechelynck]

Richard Hartmann wrote:
> On 31/08/2007, Tony Mechelynck <antoine.m...@gmail.com> wrote:
>
>> IIUC:
>
> iiuc?

If I Understand Correctly. Similarly, IIRC means If I Remember Correctly.

Hm, I wouldn't know about that. I use Thunderbird as mail/news client, and
with the "External Editor" extension, I can (if I want to -- usually I don't)
compose my mail in gvim. Not embedded though -- it runs in its own window.

Best regards,
Tony.
--
New members are urgently needed in the Society for Prevention of
Cruelty to Yourself. Apply within.

[sc]

On Fri, Aug 31, 2007 at 04:31:51PM +0200, Tony Mechelynck wrote:
>
> Richard Hartmann wrote:
> > On 31/08/2007, Tony Mechelynck <antoine.m...@gmail.com> wrote:
> >
> >> IIUC:
> >
> > iiuc?
>
> If I Understand Correctly. Similarly, IIRC means If I Remember Correctly.

any time i see one of those i don't already know (more rare
all the time) i google for it

>
> >
> >
> >> - yzis may be alive but I haven't heard much about it on this list.
> >
> > I used to check their website regularly, but nothing on there :/
> >
> >
> >> - gvim with Gnome2 GUI is standard (the sources are part of Bram's
> >> distributions), it works quite well under kde, and (among other goodies) saves
> >> and restores its session transparently when you log out of / into the kde
> >> winmanager. Bram says it has bugs but none of them has bitten me yet.
> >
> > Problem is that this will not integrate into KDE as an embedded editor. For
> > example, I normally write emails with pine & vim. Using Kontact & their editor
> > is extremely slow and painful (not as painful as using the GMail interface
> > without fixed width fonts or tw=72 which means I need to guess the
> > formatting..) when replying to more complex mails.
> >
> >
> >
> > Richard
>
> Hm, I wouldn't know about that. I use Thunderbird as mail/news client, and
> with the "External Editor" extension, I can (if I want to -- usually I don't)
> compose my mail in gvim. Not embedded though -- it runs in its own window.

if you want vim embedded for email, you want mutt

--
sc

[Gary Johnson]

Not necessarily. I love mutt. I use it exclusively at work where
99% of my e-mail is plain text or can be converted to plain text
without losing any information. At home I use Thunderbird with the
External Editor extension, just as Tony does, because a lot of the
e-mail I receive there is HTML with formatting and images that I
care about.

I wish there was a way to share a common inbox between mutt and
Thunderbird and be able to choose which client to use.

Regards,
Gary

[Elimar Riesebieter]

On Fri, 31 Aug 2007 the mental interface of
Gary Johnson told:

[...]

> I wish there was a way to share a common inbox between mutt and
> Thunderbird and be able to choose which client to use.

IMAP?

Elimar

--
Obviously the human brain works like a computer.
Since there are no stupid computers humans can't be stupid.
There are just a few running with Windows or even CE ;-)

[Richard Hartmann]

On 31/08/07, sc <toot...@swbell.net> wrote:

> any time i see one of those i don't already know (more rare
> all the time) i google for it

True

> if you want vim embedded for email, you want mutt

From everything I have seen of both pine and mutt, i prefer the
former. What benevit does embedded vim have in mutt over pine?

Richard

[Gregory Seidman]

On Fri, Aug 31, 2007 at 04:18:57PM +0200, Richard Hartmann wrote:
>
> On 31/08/2007, Tony Mechelynck <antoine.m...@gmail.com> wrote:

[...]

> (not as painful as using the GMail interface without fixed width fonts or
> tw=72 which means I need to guess the formatting..) when replying to more
> complex mails.

The MozEx Firefox extension lets you edit textareas with an external editor
(e.g. vim). I'm a fan.

> Richard
--Greg

[Milan Vancura]

> The MozEx Firefox extension lets you edit textareas with an external editor
> (e.g. vim). I'm a fan.

I've found another FF extension called It's All Text - it allows the same and
it handles character encoding and cooperates nicely with FF. And it works with
FF 1.5 and 2.0

Great for editing wiki pages (for example). I can't imagine my work in wiki
without that extension.

Milan Vancura

[Tony Mechelynck]

Yeah, I use it too. It adds a small blue button labeled "edit" at the bottom
right of textareas when the mouse is over them. Click that button: plop! gvim
opens with any text already typed in. Enter :x to close gvim, plop! the edited
text appears in the browser. Works like magic (as Arthur Weasley would have
said ;-) ).

Best regards,
Tony.
--
The average woman would rather have beauty than brains, because the
average man can see better than he can think.

[Richard Hartmann]

I don't know why, but neither seem to want to work with iceweasel..
Any ideas why that could be? I tried gvim with and without full path,
neither worked.

Richard

[Tony Mechelynck]

try

gvim -f

with full path if it isn't in the $PATH.

See the second paragraph ("GUI:") under ":help -f"

Best regards,
Tony.
--
Q: Why does Helen Keller masturbate with one hand?
A: So she can moan with the other!

[Ernie Rael]

It's All Text! is nice, that's a great tip. Know of anything similar for Thunderbird?

Thanks,
-ernie

[Tony Mechelynck]

Ernie Rael wrote:
> It's All Text! is nice, that's a great tip. Know of anything similar for
> Thunderbird?
>
> Thanks,
> -ernie

In Thunderbird, there are no boxes to fill, only messages. What about the
"External Editor" extension? http://globs.org/articles.php?lng=en&pg=8

Best regards,
Tony.
--
ARTHUR: Now stand aside worthy adversary.
BLACK KNIGHT: (Glancing at his shoulder) 'Tis but a scratch.
ARTHUR: A scratch? Your arm's off.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD