headers
Luis A. Florit | 1 Mar 2006 01:11

Re: vim question

* El 28/02/06 a las 15:22, Gerald Lai chamullaba:

> >>>    2) how to select text with Shift-cursorkey.
> [snip]
> >>>For (2), I put
> >>>
> >>>    set keymodel=startsel
> >>>
> >>>in my .vimrc file, but the screen just blinks and does nothing.
> >>>I even deleted my .vim and .vimrc stuff and give this command
> >>>alone, with no results. I also tried mixing it with 'selectmode'
> >>>with no results either.
> >>
> >>     First guess:
> >>
> >>:help xterm-cursor-keys
> >
> >Didn't work, but it explains a loooong wired
> >behaviour of the cursor keys that I used to
> >have, specially in UNIX.
> [snip]
> 
> If you don't mind, you could manually define mappings that would do
> that. I have mappings that would visually select words when doing a
> Ctrl-Shift-arrow key combination in GVim.
> 
> "down/up selection
> nmap <C-S-Down> v<Down>
> nmap <C-S-Up>   v<Up>
> imap <C-S-Down> <Esc>vg`^og`^<Down><Right><BS><BS>
(Continue reading)

Permalink | Reply | 1 comment |
headers
panshizhu | 1 Mar 2006 01:38

Re: GVim 7.0aa Segfaulting in font dialog

Bram <at> moolenaar.net wrote on 2006.02.28 00:30:04:
> > Console.  If I choose Lucida Console, as soon as I click the name of
> > the font, gvim crashes with:
> >
> > Vim: Caught deadly signal SEGV
> > Vim: Finished.
> > Segmentation fault
> >
> > I've tried this with "gvim -u NONE" as the command line, but it makes
> > no difference at all.
> >
> > As for me, I'm going to stick with Bitstream Vera Sans Mono for now!
>
> I don't have this font.  The other Lucida fonts I have work fine.
>
> Can you try compiling with "-g" instead of "-O2" and use gdb to find out
> where the crash occurs?  If it still happens without optimizer...
>
> You may have to disable Perl and Python to get sensible debugging info,
> multi-threading makes this difficult.

"Lucida Console" is provided with all Windows distributions, If he
mentioned the font "Lucida Console", I think he is running Windows, so, gdb
may not be available.
Permalink | Reply | 4 comments |
headers
Luis A. Florit | 1 Mar 2006 01:40

Re: vim question

* El 28/02/06 a las 21:48, Chris Allen chamullaba:

> On 2/28/06, Luis A. Florit <vim <at> luisflorit.endjunk.com> wrote:
> > > Syntax is one big area of vim where I am pretty ignorant.
> > > There seems to be a lot of folding in the default
> > > syntax/tex.vim file already, but not for comments.
> >
> > I found no folds there.
> > A lot of syntax, but no fold option.
> > I have vim version 6.3.86.
> 
> Folding for LaTeX was introduced by Dr Chip last summer, which makes
> it a bit too new for 6.3.  It is present in the Vim 6.4 distribution
> and Vim 7. 

I see. Perhaps if I replace the syntax/tex.vim in vim6.3...
I installed vim6.4 in a Sun, and see how that works.

> Comment folding is not supported by the plugin, however.

Strange. Comments would be the very first thing I would fold.

> I personally find it much nicer to use marker folding in TeX -- the
> added ugliness doesn't hurt it much (LaTeX just isn't pretty, anyway)

Certainly it's not.

> and the added flexibility helps a lot with documents.

Mmmmm... Interesting.
(Continue reading)

Permalink | Reply | 1 comment |
headers
A. J. Mechelynck | 1 Mar 2006 02:03
Picon

Re: GVim 7.0aa Segfaulting in font dialog

panshizhu <at> routon.com wrote:
> Bram <at> moolenaar.net wrote on 2006.02.28 00:30:04:
>>> Console.  If I choose Lucida Console, as soon as I click the name of
>>> the font, gvim crashes with:
>>>
>>> Vim: Caught deadly signal SEGV
>>> Vim: Finished.
>>> Segmentation fault
>>>
>>> I've tried this with "gvim -u NONE" as the command line, but it makes
>>> no difference at all.
>>>
>>> As for me, I'm going to stick with Bitstream Vera Sans Mono for now!
>> I don't have this font.  The other Lucida fonts I have work fine.
>>
>> Can you try compiling with "-g" instead of "-O2" and use gdb to find out
>> where the crash occurs?  If it still happens without optimizer...
>>
>> You may have to disable Perl and Python to get sensible debugging info,
>> multi-threading makes this difficult.
> 
> 
> "Lucida Console" is provided with all Windows distributions, If he
> mentioned the font "Lucida Console", I think he is running Windows, so, gdb
> may not be available.
> 
> 
> 
> 
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
antoine | 1 Mar 2006 06:35

undo and buffers

hello,

I'm using multiple buffers switching between them with :bn! like
commands. My issue is when I save a buffer (:w) I can still go back to
the pre-save state but not if I switch to another buffer and back.

ie. with more than one buffer loaded:
itest<ESC>:w<ENTER>u -> gives me the same state
but
itest<ESC>:w<ENTER>:bn!<ENTER>:bp!<ENTER>u -> undo does not work, the
"test" stay there.

this is a bit of a pain for me and I was wondering if there was a way
to circumvent this behaviour?

--
Antoine
http://delaunay.org/antoine
Permalink | Reply | 1 comment |
headers
A. J. Mechelynck | 1 Mar 2006 07:45
Picon

Re: undo and buffers

antoine wrote:
> hello,
> 
> I'm using multiple buffers switching between them with :bn! like
> commands. My issue is when I save a buffer (:w) I can still go back to
> the pre-save state but not if I switch to another buffer and back.
> 
> ie. with more than one buffer loaded:
> itest<ESC>:w<ENTER>u -> gives me the same state
> but
> itest<ESC>:w<ENTER>:bn!<ENTER>:bp!<ENTER>u -> undo does not work, the
> "test" stay there.
> 
> this is a bit of a pain for me and I was wondering if there was a way
> to circumvent this behaviour?
> 
> --
> Antoine
> http://delaunay.org/antoine
> 
> 
> 

I think you can get it with ":set hidden", but it's a setting I don't
use myself and I know that it has side-effects. Read its help
attentively (and follow the links to other options or help tags) before
using it.

Best regards,
Tony
(Continue reading)

Permalink | Reply | 0 comments |
headers
A. S. Budden | 1 Mar 2006 10:56
Picon
Gravatar

Re: GVim 7.0aa Segfaulting in font dialog

On 01/03/06, A. J. Mechelynck <antoine.mechelynck <at> skynet.be> wrote:
> panshizhu <at> routon.com wrote:
> > Bram <at> moolenaar.net wrote on 2006.02.28 00:30:04:
> >>> Console.  If I choose Lucida Console, as soon as I click the name of
> >>> the font, gvim crashes with:
> >>>
> >>> Vim: Caught deadly signal SEGV
> >>> Vim: Finished.
> >>> Segmentation fault
> >>>
> >>> I've tried this with "gvim -u NONE" as the command line, but it makes
> >>> no difference at all.
> >>>
> >>> As for me, I'm going to stick with Bitstream Vera Sans Mono for now!
> >> I don't have this font.  The other Lucida fonts I have work fine.
> >>
> >> Can you try compiling with "-g" instead of "-O2" and use gdb to find out
> >> where the crash occurs?  If it still happens without optimizer...
> >>
> >> You may have to disable Perl and Python to get sensible debugging info,
> >> multi-threading makes this difficult.
> >
> >
> > "Lucida Console" is provided with all Windows distributions, If he
> > mentioned the font "Lucida Console", I think he is running Windows, so, gdb
> > may not be available.
> >
> >
> >
> >
(Continue reading)

Permalink | Reply | 2 comments |
headers
Chris Allen | 1 Mar 2006 10:59
Picon

Re: vim question

On 3/1/06, Luis A. Florit <vim <at> luisflorit.endjunk.com> wrote:
> I see. Perhaps if I replace the syntax/tex.vim in vim6.3...
> I installed vim6.4 in a Sun, and see how that works.

That should certainly work, I think.

> Strange. Comments would be the very first thing I would fold.

Well, I think it depends on what you're doing and on your tastes.  In
most of my longer report-style documents I have no folding, but lots
of sections, subsections, etc deeply nested.  I don't like the
multiple file approach (much easier to just / from within Vim when I
need to see something), which means that section folding works very
nicely for me and makes the document much easier to navigate.  I don't
tend to have any comments at all.

In documents where formatting is much more of an issue I do have
comments, and lots of complicated trickery.  I find it useful to fold
using markers on the start of the comment and extend it throughout the
whole following section of trickery.  Makes things look much tidier.

HTH,
Chris Allen
Permalink | Reply | 0 comments |
headers
A. J. Mechelynck | 1 Mar 2006 11:05
Picon

Re: GVim 7.0aa Segfaulting in font dialog

A. S. Budden wrote:
[...]
> Sorry for the confusion everyone: I use Arch Linux, but have a dual
> boot to Windows and always kinda liked the Lucida Console font, so I
> copied it across to the other partition.
> 
> Al
> 
> 
> 

So it's a Windows font on a Linux system. Maybe that's the problem. Try
using the "lucidatypewriter" (or maybe Lucida Typewriter) font instead,
it's often available out-of-the-box on Linux, and it is almost identical
to what Windows calls Lucida Console. If you don't already have it
installed, try to find it on your Linux install disks (or whatever your
Linux distro came on).

Best regards,
Tony.
Permalink | Reply | 1 comment |
headers
Bram Moolenaar | 1 Mar 2006 11:17
Picon

Re: Filetype detect for *.tex


Benji Fisher wrote:

>      I have been thinking about this.  In vim 6.x, the default
> ftplugin/tex.vim tried to determine whether the file is latex or not.
> In vim 7, filetype.vim does pretty much the same.  So we have some
> duplication here, which might make opening a .tex file a little slow;
> worse, it will be harder to maintain.  (Maybe there are other flavors of
> TeX out there, gaining popularity.)  I suggest two options:
> 
> 1. Keep the vim 6.x way.  Treat context as another flavor of tex.  For
> ConTeXt files, set ft=tex and b:tex_flavor = context .  Merge the syntax
> and ftplugin files for tex and context, with lots of "if b:tex_flavor ="
> switches.
> 
> 2. Forget this "flavor" (or is it "flavour"?) business and have separate
> file types for plain TeX, LaTeX, and ConTeXt (and any others that come
> along).  Remove the flavor-detection code from ftplugin/tex.vim .  Two
> sub-options:  use ft=tex for plain TeX and ft=latex for LaTeX (more
> logical) or ft=plaintex for plain TeX and ft=tex for LaTeX (more
> backwards compatible, since not many vim scripts have been written with
> plain TeX in mind).

So far there was one tex syntax file for both TeX and LaTeX.  Splitting
it up in separate syntax files has advantages and disadvantages.  I
think the main issue is maintenance.  If there are separate people
taking care of each flavor then it's probably simpler to split them up.
If there is one person doing multiple flavors, or more people working
closely together, then it's easier to use one file and avoid duplication
of the common parts.
(Continue reading)

Permalink | Reply | 5 comments |

Gmane