external processes interaction v2

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

external processes interaction v2

pkt-2

Unfortunately the previous thread I saw about this issue seemed to
have degraded to a programming language debate for LISP, FORTH and so
on, intermingled with some comments about the spell checking
functionality.

I 'd like to present my point of view as a vim user. IMHO, it is a
fact that users would really like a reasonable, official way for
external processes to call vim.

Note that this is nothing new, the "netbeans" interface already exists
but the big problem with it is that it won't work with console vim and
console vim is the most useful from its flavors.

(In fact I practically never use gvim, it only adds menus which is an
irrelevant feature if you already have muscle memory for the commands
contained in them. So it is just a waste of precious vertical screen
real estate)

Also note, that adding this facility doesn't really require anything
as dramatic as rearchitecting vim to be thread-safe / multithreaded
or Model View Controller or the like (such a refactoring would be
equivalent to a rewrite anyway - clearly impractical and the
usefulness is also debatable).

The "only" thing needed is the equivalent of the X netbeans mechanism,
i.e., an input multiplexing layer "in front" of the
current input handling code in the console. Pretty much
everything in vim can be done if you just send the right
input characters to it and from what I 've seen the plugin
authors would be really happy with just having that functionality.

(I.e., not having to use screen for console, netbeans/server gvim for
X, something else for windows, you get the picture).

There will be a need for the app that integrates with vim  to maintain
a copy of some of vim state for such a way of
communication to work, but I think many people could live
with that compromise.

It was asked what would be the "killer app" for such functionality.
Let's list some:

        * Debugger integration (having the debugger instruct vim to
          "step through" for example.

        * REPL integration: communicating with bash, ipython,  irb,
           the lisp repl, firefox through mozrepl, ...

        * Background compilation / static analysis / running test
           suites.

        * Code Suggestions in the IDE sense

        * Integration to existing IDEs would be more feasible.

        * Shared editing (ggobi / Eclipse style), very useful for
           teaching programming remotely.

        * Even spell checking (integrating with custom spell-checkers
           for uncommon languages).

         * Several more.

Note that for some (lots?) of vim users these may not be exactly
"killer applications" and that is perfectly understandable. But
then again, almost nobody uses even all the *existing* features,
so this should be no reason to deny the new ones from the users
that do think they are valuable.

Also, there is already at least one useful user who changed camp to
emacs out of frustration from lack of this functionality and as
a result we missed some nice debian packaging work for vim plugins ;)

Just my 0.02 euro,
Pantelis

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

GUI and real estate (Was: external processes interaction v2)

Tony Mechelynck

On 19/04/09 10:09, pkt wrote:
[...]
> (In fact I practically never use gvim, it only adds menus which is an
> irrelevant feature if you already have muscle memory for the commands
> contained in them. So it is just a waste of precious vertical screen
> real estate)
[...]

That's an unsubstantiated slur:
- The menubar and toolbar can be removed via an option setting (two
flags in 'guioptions'). Not so for the menubar on any "modern" terminal
emulator.
- gvim isn't constrained by a terminal for its choice of fonts,
encodings, and keystrokes. If something goes wrong in its keyboard or
display interface, it's usually easier to find and fix, since only Vim
can be responsible, and it has first-quality help.
- Even if you (or I) keep the menu & toolbar displayed, any "precious
real estate" they take up is easily reclaimed by tweaking the 'guifont',
'lines' and 'columns' (with my usual settings, gvim has lines=63
columns=199 while a typical terminal would, at most, use 60 lines by 80
columns).

Regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
11. You find yourself typing "com" after every period when using a word
     processor.com

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: GUI and real estate (Was: external processes interaction v2)

pkt-2

> That's an unsubstantiated slur:

Heh, this part was not meant to be objective, it is only my
personal experience.

> - The menubar and toolbar can be removed via an option setting (two
> flags in 'guioptions'). Not so for the menubar on any "modern" terminal
> emulator.

It works for konsole and mxterm at least, no idea what terminal
emulators
you use. The only extra vertical space I typically keep is for the
different
terminal tabs in the lowest row (and this can be made pretty small).

> - gvim isn't constrained by a terminal for its choice of fonts,
> encodings, and keystrokes. If something goes wrong in its keyboard or
> display interface, it's usually easier to find and fix, since only Vim
> can be responsible, and it has first-quality help.

Konsole "just works" too (at least here it does). And since console
vim
is so useful for working over ssh anyway, I don't see any reason to
have
different font settings for vim and gvim. Liberation Sans is good
enough
for me (at least for now).

> - Even if you (or I) keep the menu & toolbar displayed, any "precious
> real estate" they take up is easily reclaimed by tweaking the 'guifont',
> 'lines' and 'columns' (with my usual settings, gvim has lines=63
> columns=199 while a typical terminal would, at most, use 60 lines by 80
> columns).

Vertical real estate is more valuable than the horizontal one since
more
and more monitors are "wide". Unless you like to rotate it of course.
I didn't get the part about the size. Konsole is arbitrarily
resizable.
I can get > 200 columns even without X using kernel mode setting
or the framebuffer driver with the 1920x1200 monitor resolution.

In any case, this is off-topic and I really shouldn't have ranted
about gvim.
The only point I 'm trying to make is that console vim is at least as
useful
(more useful imho) and deserves to get support for asynchronous
input /
netbeans interface too :)

Regards,
Pantelis


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: GUI and real estate (Was: external processes interaction v2)

Raúl Núñez de Arenas Coronado-2
In reply to this post by Tony Mechelynck

Saluton Tony :)

On Sun 19 Apr 2009 18:06 +0200, Tony Mechelynck <[hidden email]> dixit:
> On 19/04/09 10:09, pkt wrote:
> [...]
>> (In fact I practically never use gvim, it only adds menus which is an
>> irrelevant feature if you already have muscle memory for the commands
>> contained in them. So it is just a waste of precious vertical screen
>> real estate)
> [...]
>
> That's an unsubstantiated slur:

Regarding the "menubar stealing screen real state", I agree, but...

> - The menubar and toolbar can be removed via an option setting (two
> flags in 'guioptions'). Not so for the menubar on any "modern" terminal
> emulator.

...xcfe4-terminal and gnome-terminal can hide the menubar, for example.

> - gvim isn't constrained by a terminal for its choice of fonts,
> encodings, and keystrokes.

...but font rendering is suboptimal at least under Linux, where fonts
are not aliased with the GTK+ GUI. Vim running under a terminal emulator
is, for me, much more readable and much faster than gvim. I've read
reports of other people telling than gvim was, for them, much faster
than console vim, but for me it is just the opposite.

> - Even if you (or I) keep the menu & toolbar displayed, any "precious
> real estate" they take up is easily reclaimed by tweaking the 'guifont',
> 'lines' and 'columns' (with my usual settings, gvim has lines=63
> columns=199 while a typical terminal would, at most, use 60 lines by 80
> columns).

...but any terminal emulator allows you to adjust the font size (and
family, of course) and the size of the terminal.

Gvim has many advantages over console-vim-on-a-real-console, but when
using a terminal emulator it has, for me, only disadvantages.

--
Raúl "DervishD" Núñez de Arenas Coronado
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: GUI and real estate (Was: external processes interaction v2)

Tony Mechelynck

On 19/04/09 18:53, Raúl Núñez de Arenas Coronado wrote:

>
> Saluton Tony :)
>
> On Sun 19 Apr 2009 18:06 +0200, Tony Mechelynck<[hidden email]>  dixit:
>> On 19/04/09 10:09, pkt wrote:
>> [...]
>>> (In fact I practically never use gvim, it only adds menus which is an
>>> irrelevant feature if you already have muscle memory for the commands
>>> contained in them. So it is just a waste of precious vertical screen
>>> real estate)
>> [...]
>>
>> That's an unsubstantiated slur:
>
> Regarding the "menubar stealing screen real state", I agree, but...
>
>> - The menubar and toolbar can be removed via an option setting (two
>> flags in 'guioptions'). Not so for the menubar on any "modern" terminal
>> emulator.
>
> ...xcfe4-terminal and gnome-terminal can hide the menubar, for example.

OK, if you can hide the menubar my "not so" argument falls.

>
>> - gvim isn't constrained by a terminal for its choice of fonts,
>> encodings, and keystrokes.
>
> ...but font rendering is suboptimal at least under Linux, where fonts
> are not aliased with the GTK+ GUI. Vim running under a terminal emulator
> is, for me, much more readable and much faster than gvim. I've read
> reports of other people telling than gvim was, for them, much faster
> than console vim, but for me it is just the opposite.

I'm not sure whether aliasing makes fonts easier or harder to read
(IIUC, it can make fonts less crisp while at the same time making them
better shaped). In my GTK2 gvim, the 'guifont' I have chosen (Bitstream
Vera Sans Mono 7) is perfectly readable at my reading distance (arm's
length) with my eyes and (slightly convergent) eyeglasses despite its
small size. I also use Vim in konsole and in the Linux console but there
seems to be a termcap problem there -- many special keys (and not the
same ones in both) don't work. At least it responds to the mouse.

>
>> - Even if you (or I) keep the menu&  toolbar displayed, any "precious
>> real estate" they take up is easily reclaimed by tweaking the 'guifont',
>> 'lines' and 'columns' (with my usual settings, gvim has lines=63
>> columns=199 while a typical terminal would, at most, use 60 lines by 80
>> columns).
>
> ...but any terminal emulator allows you to adjust the font size (and
> family, of course) and the size of the terminal.

The problem with adjusting the size of the terminal, according to the
Vim help, is that some _other_ programs will be disturbed, or even
crash, if they don't get a standard-size terminal (meaning 80 columns
and one of the "typical" heights). I haven't run tests to see whether
this information is still up-to-date.

>
> Gvim has many advantages over console-vim-on-a-real-console, but when
> using a terminal emulator it has, for me, only disadvantages.
>

Preferences are subjective, and therefore not to be disputed. What made
me react was the assertion that "gvim menus take up valuable real
estate", which by itself was regarded (IIUC) as enough reason to choose
a terminal instead. When I first came to Vim several years ago, I
preferred Console Vim; now it isn't so anymore, and has been so for
quite some time. I think one of the reasons was the "screen real estate"
question, not as "space for other programs on the same desktop" but as
"space for more text in the same window", because I was on Windows then,
and IIRC cmd.exe isn't as flexible as xterm or konsole what concerns
lines & columns. Anyway, on Linux the question of "seeing more windows
on the same desktop" isn't as severe as on Windows, because with KDE3 I
can have up to 20 virtual desktops (more than I need) and switch between
them at the click of a mouse: so I keep most of my apps maximized unless
there is a reason (internal to the application) tu use a smaller window.
For instance I keep my konsole at 80x43 (EGA size) which is almost
full-height and about three-fifths of the width.


Best regards,
Tony.
--
"God is as real as I am," the old man said.  My faith was restored, for
I knew that Santa would never lie.

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: GUI and real estate (Was: external processes interaction v2)

Raúl Núñez de Arenas Coronado-2

Saluton Tony :)

On Sun 19 Apr 2009 19:47 +0200, Tony Mechelynck <[hidden email]> dixit:

>>> On 19/04/09 10:09, pkt wrote:
>>> [...]
>>>> (In fact I practically never use gvim, it only adds menus which is an
>>>> irrelevant feature if you already have muscle memory for the commands
>>>> contained in them. So it is just a waste of precious vertical screen
>>>> real estate)
>>> [...]
>>>
>>> That's an unsubstantiated slur:
>>
>> Regarding the "menubar stealing screen real state", I agree, but...
>>> - gvim isn't constrained by a terminal for its choice of fonts,
>>> encodings, and keystrokes.
>>
>> ...but font rendering is suboptimal at least under Linux, where fonts
>> are not aliased with the GTK+ GUI. Vim running under a terminal emulator
>> is, for me, much more readable and much faster than gvim. I've read
>> reports of other people telling than gvim was, for them, much faster
>> than console vim, but for me it is just the opposite.
>
> I'm not sure whether aliasing makes fonts easier or harder to read
> (IIUC, it can make fonts less crisp while at the same time making them
> better shaped).

I've used non aliased fonts for years, and I must confess that I prefer
aliased fonts. While certainly aliasing can make fonts less crisp, the
better shaping makes the letters more readable, specially on LCDs. On
CRTs I don't notice a great difference, and probably I prefer non
aliased fonts, but on LCDs I find aliased fonts much easier to read and
my eyes are less tired after reading text for a long while, specially if
I must use smaller font sizes to fit more information on the screen.

> In my GTK2 gvim, the 'guifont' I have chosen (Bitstream Vera Sans Mono
> 7) is perfectly readable at my reading distance (arm's length) with my
> eyes and (slightly convergent) eyeglasses despite its small size.

I can read BVSM 7 at arm's length, even with aliasing O:) On my new
laptop with Ubuntu Jaunty I can use Vim on a terminal emulator at font
size 8 because of the increased resolution of the laptop's LCD and the
improved subpixel smoothing (although I prefer a bigger font, let's say
9-10 points), but in my "big" PC I must use at least 11 points with
DejaVu Sans Mono or Bitstream Vera Sans Mono, and with aliasing. Without
aliasing I need a bigger font to keep my eyes from tiredness...

In my case, aliasing helps a lot, because being myopic I don't get
"crispy" fonts without aliasing for a start, so getting better shapes
helps a lot in my case.

> I also use Vim in konsole and in the Linux console but there
> seems to be a termcap problem there -- many special keys (and not the
> same ones in both) don't work. At least it responds to the mouse.

I can't help here because I don't use konsole. Any other terminal
emulator I've tried (gnome-terminal, xfce4-terminal, sakura) works
perfectly with Vim, at least in my daily usage. I don't use Vim as
proficiently as you, though, so maybe you will encounter problems with
the terminals I've mentioned, too. All of them are libvte based, so if
one of them has problems with some keys, is almost a sure thing that the
others will have the same problems.

>>> - Even if you (or I) keep the menu&  toolbar displayed, any
>>> "precious real estate" they take up is easily reclaimed by tweaking
>>> the 'guifont', 'lines' and 'columns' (with my usual settings, gvim
>>> has lines=63 columns=199 while a typical terminal would, at most,
>>> use 60 lines by 80 columns).
>>
>> ...but any terminal emulator allows you to adjust the font size (and
>> family, of course) and the size of the terminal.
>
> The problem with adjusting the size of the terminal, according to the
> Vim help, is that some _other_ programs will be disturbed, or even
> crash, if they don't get a standard-size terminal (meaning 80 columns
> and one of the "typical" heights). I haven't run tests to see whether
> this information is still up-to-date.

All the applications I use on the terminal don't care about terminal
size, but I remember having used apps that acted "weird" when the
terminal was not 80 or 132 columns wide, certainly. Even with "modern"
terminal applications, some of them may act strange if the terminal has
*less* than 80 columns, depending on the assumptions about size.

I don't use as many console applications as I used just a couple of
years ago, so I don't know the current state of affairs. But yes, I've
seen apps crashing after changing the window size on the terminal
emulator. Vim is not one of them, fortunately :)

>> Gvim has many advantages over console-vim-on-a-real-console, but when
>> using a terminal emulator it has, for me, only disadvantages.
>>
> Preferences are subjective, and therefore not to be disputed. What
> made me react was the assertion that "gvim menus take up valuable real
> estate", which by itself was regarded (IIUC) as enough reason to
> choose a terminal instead.

Certainly I agree here with you: I would NEVER use a terminal program
(which have their own problems, specially if not used in a terminal
emulator) just because its GUI counterpart has a menu bar. In fact, if I
couldn't use Vim on a terminal emulator I would use gvim without doubts
because I sometimes use characters not in the latin1 plane, so they
won't show at all in a real console without switching fonts. Gvim has no
problems dealing with that, or console Vim on a terminal emulator, but
you can't use console Vim on a real console to edit, let's say, an
arabic text. In the best case if you are already using an arabic font in
your text terminal, you will get the letters but not their proper forms
(they will be all initial, probably, with no medial or final forms).
Gvim can deal with it much easier.

And talking about fonts, changing the font under Gvim is much easier
than changing the font under a terminal emulator, unless the terminal
emulator has a keybinding or some kind of fast way of changing the font.
Otherwise, even if you know in advance the name of the font, you will
have to choose a menu entry and deal with the font choosing dialog. In
Gvim it is a matter of using ":set gf=whatever".

And BTW, when I'm programming I use "fullscreen" windows for editing
(140x50, more or less, with my current LCD and current font size on the
virtual terminal) too, and virtual desktops on my Ubuntu ;) For
answering emails I usually don't need so much context and go with a
terminal size of 80x25 or 100x30 sometimes. I usually don't even notice
because Vim works like a charm no matter the resolution ;)

--
Raúl "DervishD" Núñez de Arenas Coronado
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: GUI and real estate (Was: external processes interaction v2)

Michael Henry-5

All,

One advantage of GUI Vim not yet mentioned (if I've not
missed anything) is the ability to resize via Vim script.
In Gvim, I can execute the following:

:set columns=161

and the GUI window resizes to accommodate the 161
columns (which makes room for a pair of 80-column
vertical splits and the separating column between them).

I don't know how to make the equivalent behavior work
in console Vim.  Is there a way to configure either Vim or
the terminal emulator (or both) so that Vim can cause a
resize of the terminal emulator's number of columns or lines?

Michael Henry


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: GUI and real estate (Was: external processes interaction v2)

Raúl Núñez de Arenas Coronado-2

Saluton Michael :)

On Sun 19 Apr 2009 20:52 +0200, Michael Henry <[hidden email]> dixit:
> One advantage of GUI Vim not yet mentioned (if I've not
> missed anything) is the ability to resize via Vim script.
> In Gvim, I can execute the following:
>
> :set columns=161
>
> and the GUI window resizes to accommodate the 161
> columns (which makes room for a pair of 80-column
> vertical splits and the separating column between them).

Yes, I haven't thought about that!.

> I don't know how to make the equivalent behavior work
> in console Vim.  Is there a way to configure either Vim or
> the terminal emulator (or both) so that Vim can cause a
> resize of the terminal emulator's number of columns or lines?

I don't know of any way. The fastest way of resizing a console Vim
(under a terminal emulator, of course), is to use the mouse or any
keybinding the terminal emulator or the window manager (under X Window
System, I mean) has for such tasks.

--
Raúl "DervishD" Núñez de Arenas Coronado
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: GUI and real estate (Was: external processes interaction v2)

Tony Mechelynck
In reply to this post by Raúl Núñez de Arenas Coronado-2

On 19/04/09 20:35, Raúl Núñez de Arenas Coronado wrote:
>
> Saluton Tony :)
>
> On Sun 19 Apr 2009 19:47 +0200, Tony Mechelynck<[hidden email]>  dixit:
[...]
> I've used non aliased fonts for years, and I must confess that I prefer
> aliased fonts. While certainly aliasing can make fonts less crisp, the
> better shaping makes the letters more readable, specially on LCDs. On
> CRTs I don't notice a great difference, and probably I prefer non
> aliased fonts, but on LCDs I find aliased fonts much easier to read and
> my eyes are less tired after reading text for a long while, specially if
> I must use smaller font sizes to fit more information on the screen.

My desktop computer's screen is a CRT run at 1024 x 768 x 16777216. Its
diagonal is (now where's my ruler? Ah, here) 38 cm, which means (let's
use Vim's new floating-point feature to compute that) 38/2.54 = 15 in,
give or take 1/25 in. (about 1 mm) which is within the limits of
experimental error.

>
>> In my GTK2 gvim, the 'guifont' I have chosen (Bitstream Vera Sans Mono
>> 7) is perfectly readable at my reading distance (arm's length) with my
>> eyes and (slightly convergent) eyeglasses despite its small size.
>
> I can read BVSM 7 at arm's length, even with aliasing O:) On my new
> laptop with Ubuntu Jaunty I can use Vim on a terminal emulator at font
> size 8 because of the increased resolution of the laptop's LCD and the
> improved subpixel smoothing (although I prefer a bigger font, let's say
> 9-10 points), but in my "big" PC I must use at least 11 points with
> DejaVu Sans Mono or Bitstream Vera Sans Mono, and with aliasing. Without
> aliasing I need a bigger font to keep my eyes from tiredness...

I've had excellent eyesight most of my life, but now (with old age, at
not even 60, ah lala) I need glasses to read. The ones I'm wearing at
the moment seem excellent for my sight, no fatigue at all.

>
> In my case, aliasing helps a lot, because being myopic I don't get
> "crispy" fonts without aliasing for a start, so getting better shapes
> helps a lot in my case.
[...]

IIUC, aliasing gives better curves at large sizes while non-aliasing
gives crispier fonts at small sizes.


Best regards,
Tony.
--
How doth the VAX's C-compiler
Improve its object code.
And even as we speak does it
Increase the system load.

How patiently it seems to run
And spit out error flags,
While users, with frustration, all
Tear all their clothes to rags.

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: GUI and real estate (Was: external processes interaction v2)

Tony Mechelynck
In reply to this post by Michael Henry-5

On 19/04/09 20:52, Michael Henry wrote:

>
> All,
>
> One advantage of GUI Vim not yet mentioned (if I've not
> missed anything) is the ability to resize via Vim script.
> In Gvim, I can execute the following:
>
> :set columns=161
>
> and the GUI window resizes to accommodate the 161
> columns (which makes room for a pair of 80-column
> vertical splits and the separating column between them).
>
> I don't know how to make the equivalent behavior work
> in console Vim.  Is there a way to configure either Vim or
> the terminal emulator (or both) so that Vim can cause a
> resize of the terminal emulator's number of columns or lines?
>
> Michael Henry

That depends on the console. In the Linux (true-text) console, in xterm
and (I think) in Windows, Vim can't resize the terminal AFAIK. OTOH, in
konsole, setting 'lines' and 'columns' does resize the terminal. In the
Mac's Terminal.app console, I don't know.


Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
12. You turn off your modem and get this awful empty feeling, like you just
     pulled the plug on a loved one.

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: GUI and real estate (Was: external processes interaction v2)

Matt Wozniski-2

On Sun, Apr 19, 2009 at 3:30 PM, Tony Mechelynck wrote:

>
> On 19/04/09 20:52, Michael Henry wrote:
>> In Gvim, I can execute the following:
>>
>> I don't know how to make the equivalent behavior work
>> in console Vim.  Is there a way to configure either Vim or
>> the terminal emulator (or both) so that Vim can cause a
>> resize of the terminal emulator's number of columns or lines?
>
> That depends on the console. In the Linux (true-text) console, in xterm
> and (I think) in Windows, Vim can't resize the terminal AFAIK. OTOH, in
> konsole, setting 'lines' and 'columns' does resize the terminal. In the
> Mac's Terminal.app console, I don't know.

In xterm it can.  But, even so, don't do this.  It will cause very bad
behavior when interacting with, say, Gnu Screen - in an xterm that
isn't running screen, it would resize the window, and in one that is
running screen, it would cause redrawing problems that would render
the session unusable.

~Matt

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: GUI and real estate (Was: external processes interaction v2)

Raúl Núñez de Arenas Coronado-2
In reply to this post by Tony Mechelynck

Saluton Tony :)

On Sun 19 Apr 2009 21:30 +0200, Tony Mechelynck <[hidden email]> dixit:

> On 19/04/09 20:52, Michael Henry wrote:
>> One advantage of GUI Vim not yet mentioned (if I've not missed
>> anything) is the ability to resize via Vim script. In Gvim, I can
>> execute the following:
>>
>> :set columns=161
>
> That depends on the console. In the Linux (true-text) console, in
> xterm and (I think) in Windows, Vim can't resize the terminal AFAIK.
> OTOH, in konsole, setting 'lines' and 'columns' does resize the
> terminal. In the Mac's Terminal.app console, I don't know.

Under Linux, libvte-based terminals doesn't seem to be able to resize
after doing ":set columns=whatever". I haven't tested under sakura, but
I've tested with gnome-terminal and xfce4-terminal.

--
Raúl "DervishD" Núñez de Arenas Coronado
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: GUI and real estate (Was: external processes interaction v2)

Tony Mechelynck
In reply to this post by Matt Wozniski-2

On 19/04/09 21:47, Matt Wozniski wrote:

>
> On Sun, Apr 19, 2009 at 3:30 PM, Tony Mechelynck wrote:
>>
>> On 19/04/09 20:52, Michael Henry wrote:
>>> In Gvim, I can execute the following:
>>>
>>> I don't know how to make the equivalent behavior work
>>> in console Vim.  Is there a way to configure either Vim or
>>> the terminal emulator (or both) so that Vim can cause a
>>> resize of the terminal emulator's number of columns or lines?
>>
>> That depends on the console. In the Linux (true-text) console, in xterm
>> and (I think) in Windows, Vim can't resize the terminal AFAIK. OTOH, in
>> konsole, setting 'lines' and 'columns' does resize the terminal. In the
>> Mac's Terminal.app console, I don't know.
>
> In xterm it can.  But, even so, don't do this.  It will cause very bad
> behavior when interacting with, say, Gnu Screen - in an xterm that
> isn't running screen, it would resize the window, and in one that is
> running screen, it would cause redrawing problems that would render
> the session unusable.
>
> ~Matt

Well, I tried it in xterm, version X.Org 6.8.99.903(236), not running
screen, and when setting 'lines' and 'columns' in Vim 7.2.148, the
window didn't budge. Something weird happened to my status line, a
second copy of which was drawn in the command-line area, but that's all.


Best regards,
Tony.
--
One advantage of talking to yourself is that you know at least
somebody's listening.
                -- Franklin P. Jones

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: GUI and real estate (Was: external processes interaction v2)

Matt Wozniski-2

On Sun, Apr 19, 2009 at 4:06 PM, Tony Mechelynck wrote:
>
> On 19/04/09 21:47, Matt Wozniski wrote:
>>
>> In xterm it can.
>
> Well, I tried it in xterm, version X.Org 6.8.99.903(236), not running
> screen, and when setting 'lines' and 'columns' in Vim 7.2.148, the
> window didn't budge. Something weird happened to my status line, a
> second copy of which was drawn in the command-line area, but that's all.

Strange.  Works for me, with xterm 242 running in openbox.  Either
way, though, my point stands - even if your terminal emulator supports
it, programs that you run in it (like screen and dvtm) can break it,
so it's probably a bad idea to do.

~Matt

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: external processes interaction v2

StarWing
In reply to this post by pkt-2

> There will be a need for the app that integrates with vim  to maintain
> a copy of some of vim state for such a way of
> communication to work, but I think many people could live
> with that compromise.
>
> It was asked what would be the "killer app" for such functionality.
> Let's list some:
>
>         * Debugger integration (having the debugger instruct vim to
>           "step through" for example.
>
>         * REPL integration: communicating with bash, ipython,  irb,
>            the lisp repl, firefox through mozrepl, ...
>
>         * Background compilation / static analysis / running test
>            suites.
>
>         * Code Suggestions in the IDE sense
>
>         * Integration to existing IDEs would be more feasible.
>
>         * Shared editing (ggobi / Eclipse style), very useful for
>            teaching programming remotely.
>
>         * Even spell checking (integrating with custom spell-checkers
>            for uncommon languages).
>
>          * Several more.
>
> Note that for some (lots?) of vim users these may not be exactly
> "killer applications" and that is perfectly understandable. But
> then again, almost nobody uses even all the *existing* features,
> so this should be no reason to deny the new ones from the users
> that do think they are valuable.
>
> Also, there is already at least one useful user who changed camp to
> emacs out of frustration from lack of this functionality and as
> a result we missed some nice debian packaging work for vim plugins ;)
>
> Just my 0.02 euro,
> Pantelis


a standard Process Interaction interface for Vim?

yes, we have the same idea.

I'm try to implement it at Windows & Unix, but it has some trouble
when i try to read data form pipe...

has any other way to implement?
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: GUI and real estate (Was: external processes interaction v2)

Michael Henry-5
In reply to this post by Matt Wozniski-2

Matt Wozniski wrote:
>  Either way, though, my point stands - even if your terminal emulator
>  supports it, programs that you run in it (like screen and dvtm) can
>  break it, so it's probably a bad idea to do.

Yes, I've seen the kind of bad behavior you are mentioning when using
the following within console Vim (even when using Konsole, though maybe
I just need to change some setting since Tony says it works for him):

set columns=161

It's true I can re-size the terminal emulator itself and Vim will nicely
re-adjust its columns and rows, but I've grown very used to a couple of
custom Vim commands I use to flip between a single 80-column window and
a pair of vertically-split windows:

    :L1      " Switches to a single 80-column window.
    :L2      " Switches to a pair of vertically split 80-column windows.

As part of these two commands I reset various other aspects of the
layout (e.g., the QuickFix window is resized to my standard size, the
windows are re-balanced via :wincmd =, etc.).

Ideally, I could find some way to have Vim script trigger the right
action in the terminal emulator, perhaps by "shelling out" to an
external command that could signal the terminal emulator to change size,
indirectly changing Vim's notion of columns and rows.  If I could
control the window layout as easily in console Vim as I can in Gvim, I
could more easily live inside GNU screen and share a single running
instance of vim from multiple computers.

Michael Henry


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: external processes interaction v2

pkt-2
In reply to this post by StarWing

Hi,

> a standard Process Interaction interface for Vim?
>
> yes, we have the same idea.

Great!
I 'd be happy even with just a solution that worked in the unix
(linux) console vim.
Extra points if it also worked in cygwin.

> I'm try to implement it at Windows & Unix, but it has some trouble
> when i try to read data form pipe...
>
> has any other way to implement?

How are you implementing it?
I think there are problems with just trying to add a pipe/socket to
the "mainloop".

There may be a need to add a layer of indirection "below" that to get
input multiplexing
to work reasonably. I think there were discussions about a failed
attempt to implement
this functionality for a vim plugin that needed to interact with a
Lisp REPL. Some of the
pitfalls are discussed there.

Thanks a lot for your efforts,
Pantelis













--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: GUI and real estate

Christian Ebert
In reply to this post by Tony Mechelynck

* Tony Mechelynck on Sunday, April 19, 2009 at 21:30:41 +0200

> On 19/04/09 20:52, Michael Henry wrote:
>> One advantage of GUI Vim not yet mentioned (if I've not
>> missed anything) is the ability to resize via Vim script.
>> In Gvim, I can execute the following:
>>
>> :set columns=161
>>
>> and the GUI window resizes to accommodate the 161
>> columns (which makes room for a pair of 80-column
>> vertical splits and the separating column between them).
>>
>> I don't know how to make the equivalent behavior work
>> in console Vim.  Is there a way to configure either Vim or
>> the terminal emulator (or both) so that Vim can cause a
>> resize of the terminal emulator's number of columns or lines?
>
> That depends on the console. In the Linux (true-text) console, in xterm
> and (I think) in Windows, Vim can't resize the terminal AFAIK. OTOH, in
> konsole, setting 'lines' and 'columns' does resize the terminal. In the
> Mac's Terminal.app console, I don't know.

Terminal.app: no
xterm:        yes

c
--
  Was heißt hier Dogma, ich bin Underdogma!
[ What the hell do you mean dogma, I am underdogma. ]
_F R E E_  _V I D E O S_  http://www.blacktrash.org/underdogma/
                          http://www.blacktrash.org/underdogma/index-en.html

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: GUI and real estate (Was: external processes interaction v2)

Tom Link-3
In reply to this post by Raúl Núñez de Arenas Coronado-2

> > - The menubar and toolbar can be removed via an option setting (two
> > flags in 'guioptions'). Not so for the menubar on any "modern" terminal
> > emulator.
>
> ...xcfe4-terminal and gnome-terminal can hide the menubar, for example.

With shymenu[1], the menu bar is shown only when pressing alt + some
accelerator key. You thus get the extra screen estate without losing
the menu bar's functionality.

One argument pro gvim is that you can easily switch between different
settings. I often switch between a view with a small font plus scroll
bars (for displaying several windows side by side) and a second view
with a larger font minus scroll bar and minus window title bar (for
writing). gvim is one of the best editors for working on a terminal
but I wouldn't want to miss the gui if I have a choice.


[1] http://www.vim.org/scripts/script.php?script_id=2437

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---