headers
Michael Henry | 1 Nov 2008 13:05

Bug: :echo output missing with QuickFix and Command-line windows


All,

It appears that the output from :echo and :echomsg does not
show up properly when used from the Command-line window
while a QuickFix window is open.

Steps to reproduce:

- Startup Vim clean:

    vim -u NONE -N

- Test regular :echo command:

    :echo "Hello"<CR>

  This works properly.

- Open command-line window:

    q:

- Cursor up to :echo "Hello", press Enter to execute.

  This works properly.

- Open the QuickFix window:

    :copen<CR>
(Continue reading)

Permalink | Reply | 4 comments |
headers
Bram Moolenaar | 1 Nov 2008 14:21
Picon

Patch 7.2.026


Patch 7.2.026 (after 7.2.010)
Problem:    "K" doesn't use the length of the identifier but uses the rest of
	    the line.
Solution:   Copy the desired number of characters first.
Files:	    src/normal.c

*** ../vim-7.2.025/src/normal.c	Thu Oct  2 22:55:17 2008
--- src/normal.c	Sat Nov  1 13:41:03 2008
***************
*** 183,188 ****
--- 183,190 ----
  static void	nv_cursorhold __ARGS((cmdarg_T *cap));
  #endif

+ static char *e_noident = N_("E349: No identifier under cursor");
+ 
  /*
   * Function to be called for a Normal or Visual mode command.
   * The argument is a cmdarg_T.
***************
*** 3510,3516 ****
  	if (find_type & FIND_STRING)
  	    EMSG(_("E348: No string under cursor"));
  	else
! 	    EMSG(_("E349: No identifier under cursor"));
  	return 0;
      }
      ptr += col;
--- 3512,3518 ----
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bram Moolenaar | 1 Nov 2008 17:12
Picon

Re: Drupal .module proper support (fwd)


Alexis Wilke wrote:

> I'm developing on Drupal now a days and find it annoying that gvim cannot 
> detect that the .module are PHP files. So I added a few lines of code to 
> my filetype.vim to paliate. I would imagine some other vi lovers will run 
> in this one too. We could also support the .install files I guess. Also 
> that I do not have much of a problem with.

Makes sense.

You use this statement:

	if getline(1) =~ '<\?php'

That backslash should probably not be there, since this matches "php" by
itself.  This might work better:

	if getline(1) =~ '<?php'

--

-- 
hundred-and-one symptoms of being an internet addict:
163. You go outside for the fresh air (at -30 degrees) but open the
     window first to hear new mail arrive.

 /// Bram Moolenaar -- Bram <at> Moolenaar.net -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bram Moolenaar | 1 Nov 2008 17:12
Picon

Re: Bug: :echo output missing with QuickFix and Command-line windows


Michael Henry wrote:

> It appears that the output from :echo and :echomsg does not
> show up properly when used from the Command-line window
> while a QuickFix window is open.
> 
> Steps to reproduce:
> 
> - Startup Vim clean:
> 
>     vim -u NONE -N
> 
> - Test regular :echo command:
> 
>     :echo "Hello"<CR>
>  
>   This works properly.
> 
> - Open command-line window:
> 
>     q:
> 
> - Cursor up to :echo "Hello", press Enter to execute.
> 
>   This works properly.
> 
> - Open the QuickFix window:
> 
>     :copen<CR>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bram Moolenaar | 1 Nov 2008 17:12
Picon

Re: Encoding recognizing problem with 2 byte BOM "FF FE"


Yanwei wrote:

> For a 2 byte BOM "FF FE", "ucs-2le" is used, which doesn't work for
> little-endian UTF-16 text. Like the patch 7.1.261, the only difference
> is the byte order.  And I have also writen a patch for Vim-7.2.025:

Looks good, thanks.  I'll include it.

--

-- 
hundred-and-one symptoms of being an internet addict:
164. You got out to buy software, instead of going out for a beer.

 /// Bram Moolenaar -- Bram <at> Moolenaar.net -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 0 comments |
headers
Vladimir A. Pavlov | 2 Nov 2008 12:13
Picon

Re: New feature: cursor at the beginning of tab character in normal mode


Hi!

I made a patch to the documentation to mention the way to
display the cursor where most popular editors do.

I mention the cursor positioning behaviour in 'list' help node,
put the command in question there and made a link from 'listchars'
node to 'list' one.

I think it's better to put the command in question to 'list'
help node since it's 'list' (not, 'listchars') option's issue
that allows us to do what we want.

P.S. Sorry for being so late, I've been busy this month :(

--
Vladimir

The patch follows (should be applied to just unpacked
vim-7.2.tar.bz2):

diff -Naur vim72.orig/runtime/doc/options.txt vim72/runtime/doc/options.txt
--- vim72.orig/runtime/doc/options.txt  2008-08-09 18:22:59.000000000 +0400
+++ vim72/runtime/doc/options.txt       2008-11-02 13:45:41.000000000 +0300
 <at>  <at>  -4331,6 +4331,18  <at>  <at> 
        'wrapmargin') when 'cpoptions' includes 'L'.  See 'listchars' for
        changing the way tabs are displayed.

+       In Normal mode the cursor is displayed at the end of the space a tab
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Henry | 2 Nov 2008 13:52

Re: Bug: :echo output missing with QuickFix and Command-line windows


Bram Moolenaar wrote:
> Michael Henry wrote:
>
>   
>> It appears that the output from :echo and :echomsg does not
>> show up properly when used from the Command-line window
>> while a QuickFix window is open.
>>     
[...]

> If you use:
> 	:echo "hello\nthere"
>
> You get the hit-enter prompt before redrawing te display.  So it's
> indeed that closing the command-line window causes a redraw and that
> clears the message.
>
> Forcing the hit-enter prompt would be a solution, but at the same time
> may annoy quite a few users.
>   
Yes, that would be annoying :-)
> I'll make a remark in the todo list if it's possible to redraw without
> erasing the message.  Don't expect this soon though.
>   
Intuitively, I'd imagined that forcing a redraw when the command-line 
window closes but before the command is executed might fix the problem.  
I poked around a little bit this morning and made the following two-line 
patch against Vim 7.2.25:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bram Moolenaar | 2 Nov 2008 20:47
Picon

Re: Bug: :echo output missing with QuickFix and Command-line windows


Michael Henry wrote:

> >> It appears that the output from :echo and :echomsg does not
> >> show up properly when used from the Command-line window
> >> while a QuickFix window is open.
> >>     
> [...]
> 
> > If you use:
> > 	:echo "hello\nthere"
> >
> > You get the hit-enter prompt before redrawing te display.  So it's
> > indeed that closing the command-line window causes a redraw and that
> > clears the message.
> >
> > Forcing the hit-enter prompt would be a solution, but at the same time
> > may annoy quite a few users.
> >   
> Yes, that would be annoying :-)
> > I'll make a remark in the todo list if it's possible to redraw without
> > erasing the message.  Don't expect this soon though.
> >   
> Intuitively, I'd imagined that forcing a redraw when the command-line 
> window closes but before the command is executed might fix the problem.  
> I poked around a little bit this morning and made the following two-line 
> patch against Vim 7.2.25:
> 
> --- vim72/src/ex_getln.c.orig   2008-11-02 07:34:57.000000000 -0500
> +++ vim72/src/ex_getln.c        2008-11-02 07:30:20.000000000 -0500
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andy Wokula | 2 Nov 2008 21:34
Picon
Favicon

Re: Bug: :echo output missing with QuickFix and Command-line windows


Michael Henry schrieb:
> All,
> 
> It appears that the output from :echo and :echomsg does not
> show up properly when used from the Command-line window
> while a QuickFix window is open.
> 
> Steps to reproduce:
> 
> - Startup Vim clean:
> 
>     vim -u NONE -N
> 
> - Test regular :echo command:
> 
>     :echo "Hello"<CR>
>  
>   This works properly.
> 
> - Open command-line window:
> 
>     q:
> 
> - Cursor up to :echo "Hello", press Enter to execute.
> 
>   This works properly.
> 
> - Open the QuickFix window:
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bram Moolenaar | 2 Nov 2008 14:56
Picon

Re: Gvim for Windows doesn't handle non-BMP characters when interchanging data with Windows OS


Yanwei wrote:

> When interchanging data with Windows such as clipboard operation, gvim will 
> convert the text into UCS-2 encoding, but different from UTF-16, UCS-2 can't 
> encode non-BMP characters. 
> 
> For example, when paste a non-BMP character U+248BB from Windows clipboard, 
> it will insert two separated characters <d852> <dcbb>. It is caused by the 
> function ucs2_to_utf8() in src/os_mswin.c, which treates the surrogate pairs 
> as separated unicode characters, and convert it into bad UTF-8 sequence 
> 0xED 0xA1 0x92 0xED 0xB2 0xBB -- the correct UTF-8 sequence should be 
> 0xF0 0xA4 0xA2 0xBB.
> 
> Similarly, when copy a non-BMP character U+248BB into Windows clipboard, the 
> content of clipboard will be U+48BB, because the function utf8_to_ucs2() 
> in src/os_mswin.c will cast the integer 0x248BB into a short integer 0x48BB.
> 
> The attachment is a patch. The surrogate pairs handling has been add into the 
> two functions mentioned above. This make the non-BMP characters can be 
> correctly interchanged with Windows clipboard as I had tested:
> 	Non-BMP character paste from/copy into Windows clipboard
> 	+----------+--------------------------------+------------------------+
> 	|          | WindowsXP with GB18030 support |  Windows 98            |
> 	+----------+--------------------------------+------------------------+
>         | editing  | before patch works bad         | before patch works bad |
> 	| UTF-* or | after patch works OK           | after patch works OK   |
> 	| UCS-4*   |                                |                        |
> 	| text     |                                |                        |
> 	+----------+--------------------------------+------------------------+
(Continue reading)

Permalink | Reply | 1 comment |

Gmane