Re: elastic tabstops implemented for GTK

On 29/08/2007, Gustavo J. A. M. Carneiro <gjc inescporto pt> wrote:
> On Qua, 2007-08-29 at 07:42 +0200, Nick Gravgaard wrote:
> > On 29/08/2007, Alex Jones <alex weej com> wrote:
> > >
> > >  Hi again, Nick
> > >
> > >  On Fri, 2007-07-13 at 10:46 +0200, Nick Gravgaard wrote:
> > >  Thanks Alex,
> > >
> > > The proportional font stuff is really just a nice side effect - this
> > > idea has all sorts of nice implications. Off the top of my head,
> > > imagine a program like ls that outputs a list of directories and
> > > files. At the moment ls needs to be aware of the number of columns of
> > > the console to which it is writing, and then it inserts spaces and
> > > newlines to make things line up. Resizing the console has no effect on
> > > the layout. Now, I haven't gotten round to implementing word wrap yet,
> > > but imagine if ls output a simple tab delimited list of directories
> > > and files instead, and the console undertood elastic tabstops (with
> > > word wrap implemented). Resizing the console would work, as would
> > > proportional fonts. Also, imagine how much easier piping between
> > > programs becomes when simple tab delimited text streams works like
> > > this!
> > >
> > > There are many other potential uses too :)
> > >
> > > Nick
> > >
> > >
> > >  How is this coming along? Have you opened bugzilla issues on this yet? I
> > > really want to start using this!
> >
> > I've been busy recently with other stuff, so at the moment I'm still
> > hacking my gedit patch to turn it into a plugin. Paolo Maggi (main
> > gedit developer) told me on the gedit list:
> >
> > "In this way it will be easier for other people to experiment with your
> > idea and may be we could start including your plugin in gedit-plugins if
> > the other members of the gedit team agree."
> >
> > See:
> >
> >
> > Does anyone know the process for getting the elastic tabstop
> > functionality into the official GTK branch?
> Personally I think this is a terrible idea because it breaks
> compatibility with other editors.  If each editor interprets tabs in its
> own way, then when you save a file from one editor and open in another
> one it will appear all wrong.

The problem is that indenting is already broken regardless of whether
you use tabs or spaces. Tabs are broken because if you don't get the
size right things won't line up ("appear all wrong"), and spaces are
broken because you're forcing everyone to use your indentation size.
My approach fixes these problems. Watch the video on my site:

If I add this to anything it will always be an option, so if people
don't like it they won't be forced to use it.

> And how will this look e.g. to Python, which generally doesn't even like
> tabs?  Variable width tabs will likely cause havoc in Python programs...

Well, if they aren't using tabs it won't affect them at all. Also, if
tabs are being used, the only ones that Python cares about are those
at the beginning of the line so we shouldn't have a problem.

> Now, if you did the exact same thing, but behind the scenes inserted
> spaces instead of tab characters, then it would be nice.

If you look at the plugin I made for gedit (watch the video at the
link I mentioned above) you can see that it is possible to convert
between elastic tabstops and spaces. You lose some of the advantages
this way (you can't manipulate the files using tools like sed and
still have everything line up when you load it in the editor), but can
work on projects that mandate the use of spaces for


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]