Re: VIM and NTFS streams

On 31 Jan., 19:57, Alexei Alexandrov <alexei.alexand... <at> gmail.com>
wrote:

> 2 notes here:

> 1. I think NTFS streams is useless feature.

NTFS Streams can be used for the very same stuff resource streams on
MacOS or extended attributes on OS/2 / Linux are used. And in fact
they are used for precisely that. Also note that extended attributes
on NTFS are implemented as streams as well. And Unix file attributes
(at least on Windows Server).

In fact I very much miss all the features OS/2 had to offer by the use
of extended attributes. For example I could attach a custom made icon
to important files (like cmd files) which would then be stored in the
extended attributes.

Or Rexx would store a pre-compiled version of all scripts inside the
extended attributes. And here streams would even excel since extended
attributes are limited in size while streams are not.

> I've never seen any
> practical example of the usefulness of this.

You might want to get yourself the demo version of 4NT (http://
www.jpsoft.com/) and then use "DIR /:" a bit - you might be surprised
how many streams are already used on your system. Most notably:

Re: VIM and NTFS streams

Re: VIM and NTFS streams

On 1 Feb., 09:15, "George V. Reilly" <geo... <at> reilly.org> wrote:
> On 31/01/2008, krischik <krisc... <at> users.sourceforge.net> wrote:

> > You might want to get yourself the demo version of 4NT (http://
> >www.jpsoft.com/) and then use "DIR /:" a bit - you might be surprised
> > how many streams are already used on your system. Most notably:
>
> > 12.12.2007  14:03           1'670  _H_A_________  .vimrc
> >                                               0
> > {4c8cc155-6c1e-11d1-8e41-00c04fb9386d}:$DATA
>
> Every NTFS file is implemented as one or more streams, and the default
> stream is called $DATA. It's a bit like finding a directory named . in every
> directory.

You misinterpreted the output. Lets try "dir /A /F /:"

C:\Documents and Settings\...\.vimrc
C:\Documents and Settings\...\.vimrc:
{4c8cc155-6c1e-11d1-8e41-00c04fb9386d}

The stream is called "{4c8cc155-6c1e-11d1-8e41-00c04fb9386d}". But
speaking of the directory "." - How about:

>dir /:

 Datenträger in Laufwerk C ist SYSTEM         Seriennummer ist
5cb9:81be
 Verzeichnis von  C:\Media\*

11.10.2007  12:28         <DIR>    .
11.10.2007  12:28         <DIR>    ..
                              646    $MountMgrRemoteDatabase:$DATA
28.09.2007  14:43    <JUNCTION>    MEDIASAVE
[Volume{543aeb10-6dbe-11dc-b33a-001a73660515}\]
11.10.2007  12:28    <JUNCTION>    TITANIUM [Volume{95a63aac-7702-11dc-
b340-001a73660515}\]
            646 Bytes in 0 Dateien und 4 Verzeichnisse
 28'062'420'992 Bytes frei

or

>dir /: /F
C:\Media\.
C:\Media\..
C:\Media\..:$MountMgrRemoteDatabase
C:\Media\MEDIASAVE
C:\Media\TITANIUM

Yep - a tream on directory ".." .

Of course for all the "DIR" commands mentioned you need a command
interpreter which actually supports streams.

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

[bugreport] pastetoggle does not update statusline

Hi,

I set the following options to see the current status of paste:

set pastetoggle=<F11>
set statusline=%{&paste}

It works perfectly except that a single press of <F11> in normal/visual
*all*/select *all*-mode doesn't update the statusline until I do
something else, i.e. move the cursor.

Cheers.
--

-- 
Jan Christoph Ebersbach
Fear God and keep his commandments, for this is the whole duty of man.
Eccl 12,13

Gtk-X11, gui.num_rows, window height and font height

Hi,

This is in regards to an old bug report from 2004:

http://tech.groups.yahoo.com/group/vimdev/message/34562

At the time, the problem was dismissed as the window manager's
(metacity) fault, but I don't think this is the case. The code in
question is this part of src/gui.c, ~line 1296 (from vim-7.1.tar.bz,
downloaded from the website)

    gui.num_rows = (pixel_height - gui_get_base_height()
#if !defined(FEAT_GUI_PHOTON) && !defined(FEAT_GUI_MSWIN)
				    + (gui.char_height / 2)
#endif
					) / gui.char_height;

I experience this behavior, where the bottom line of text is cut-off,
because gui.num_rows is over-estimated. But my window manager
(metacity, gnome 2.18.1) is correctly reporting the window height.
When I put gvim in fullscreen mode, pixel_height has the correct value
of 1024. The function gui_get_base_height() gives a value of 4,
because in src/gui_gtk_x11.c, line 3437, the field gui.border_width is
initialized to 2, and gui_get_base_height() doubles this. Why is that?
What is the "border width"? When I run gvim in full screen, I can't
see any border -- gvim has use of all 1280x1024 pixels. But setting
this initial value to 0 still does not solve the problem. The only
other value affecting this expression in gui.char_height, which
appears to be set using information from pango, not metacity. So I
don't think this is metacity's fault.

In between the #if..#endif you add half a character's worth of height.
Why is that?  If I take this out, as Tony Houghton did originally, the
problem is fixed. It seems to me that you want the quotient (pixels /
char_height) to be consistently rounded down, to take the floor of it.
Rounding to the nearest integer is not the right thing to do.

I realize this is something of a heisenbug. It will or will not happen
depending on your screen resolution, and which font you use. But I'm
just wondering about these things: Why is gui.border_width initialized
to 2, why is a half-character of height added to the expression, and
what role does the window manager play in all this? Also I don't
really know the vim sources inside and out, so if I'm missing
something please let me know.

Thanks,
Scott

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

Re: VIM and NTFS streams

krischik wrote:
> On 31 Jan., 19:57, Alexei Alexandrov <alexei.alexand... <at> gmail.com>
> wrote:
> 
>> 2 notes here:
> 
>> 1. I think NTFS streams is useless feature.
> 
> NTFS Streams can be used for the very same stuff resource streams on
> MacOS or extended attributes on OS/2 / Linux are used.

I'm not aware well of Linux mechanisms for storing extended attributes 
inside files on Linux. Word "Linux" looks strange to me here in fact - 
it might a property of extX filesystem, but it doesn't have to do 
anything with Linux I think since I may use other systems for root mount 
point - reiserfs, for example. Do you have exact answers to the 
following questions:
* Which mechanism is used on Linux to store these extended attributes on 
Linux? Is it filesystem-based? If yes, which filesystems currently have 
it implemented?
* Which applications use this feature on Linux? Are they OS-specific? 
Are there application programs that use this? Are those programs 
portable? If yes, how they deal with absence of this feature on other 
file systems?

These are exactly questions which I would ask myself if I would be 
designing something new and would be considering using NTFS file 
streams. Will there be FAT32 file system clients? Would I care to port 
the program to other system some time later? Et cetera. And most (if not 
all) programs choose to use simple abstractions (files/directories) 
available on all modern systems because it works well, because you'd 
better keep it simple and because there are more important things to 
focus on.

> 
>> I've never seen any
>> practical example of the usefulness of this.
> 
> You might want to get yourself the demo version of 4NT (http://
> www.jpsoft.com/) and then use "DIR /:" a bit - you might be surprised
> how many streams are already used on your system. Most notably:
> 
> 12.12.2007  14:03           1'670  _H_A_________  .vimrc
>                                               0
> {4c8cc155-6c1e-11d1-8e41-00c04fb9386d}:$DATA
> 

This looks like a default data stream in this file. I don't see that 
there are 2 streams here - am I overlooking something?

P.S. I do see some cases where the data streams feature might be useful. 
For example, anti-virus program might store some information about the 
scanned file in a separate stream. But when I think of it more I realize 
that even in these cases data streams approach would be questionable and 
that there other ways to implement it with potentially better 
performance and less limitations. For example, you cannot attach a new 
data stream to a file which is available to you as read-only.

P.P.S. Thanks for reading to this point! :) Sorry for a long post and 
somewhat clumsy English.

--

-- 
Alexei Alexandrov

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

Re: patch 7.1.240 breaks "non block mode"

Adri Verhoef wrote:

> In "non block mode", i.e. after typing 'V' or 'v', not all text is
> converted to upper/lower/rot13.
> 
> To reproduce:
> 
> Start Vim (vim -u NONE).
> Type aThis is an example.<CR>Second line.<CR>Last line.<ESC>
> Now type VHU (or vHU) and watch the error: only a part of the first
> two lines gets changed:
> 
> THIS IS AN example.
> SECOND LINe.
> LAST LINE.
> 
> 
> So, a part of patch 7.1.240 doesn't work the way it was meant, but the
> Visual block mode part does work well.

Thanks for reporting this.  I'll fix it as soon as I have some time.

--

-- 
Back off man, I'm a scientist.
              -- Peter, Ghostbusters

 /// 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
-~----------~----~----~----~------~----~------~--~---

syntax: reusing nested expressions

Re: syntax: reusing nested expressions

On Feb 3, 7:04 am, "George V. Reilly" <geo... <at> reilly.org> wrote:
> I'm trying to write some syntax highlighting for PBwiki, and I'd like to
> reuse some complex regexps.

Hi,

I asked the same question recently and got this answer:
http://groups.google.com/group/vim_use/browse_thread/thread/84f1fa50633c6c50
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Patch to fix access to freed memory in spelling checker feature

Hi

Valgrind memory checker detects that Vim is using freed memory
in the spelling checker code:

==8692== Invalid read of size 1
==8692==    at 0x8199D87: spell_to_word_end (spell.c:15854)
==8692==    by 0x8166424: win_line (screen.c:3054)
==8692==    by 0x8163AD5: win_update (screen.c:1765)
==8692==    by 0x8161C34: update_screen (screen.c:522)
==8692==    by 0x8064F1B: ins_redraw (edit.c:1474)
==8692==    by 0x8063B96: edit (edit.c:688)
==8692==    by 0x812322A: normal_cmd (normal.c:1327)
==8692==    by 0x80E5D2D: main_loop (main.c:1181)
==8692==    by 0x80E587D: main (main.c:940)
==8692==  Address 0x50615F0 is 40 bytes inside a block of size 96 free'd
==8692==    at 0x402237F: free (vg_replace_malloc.c:233)
==8692==    by 0x8113F55: vim_free (misc2.c:1580)
==8692==    by 0x80F864A: ml_flush_line (memline.c:3149)
==8692==    by 0x80F69FE: ml_get_buf (memline.c:2111)
==8692==    by 0x80F68BB: ml_get (memline.c:2034)
==8692==    by 0x818D567: check_need_cap (spell.c:10271)
==8692==    by 0x817C828: spell_move_to (spell.c:2098)
==8692==    by 0x81663D0: win_line (screen.c:3048)
==8692==    by 0x8163AD5: win_update (screen.c:1765)
==8692==    by 0x8161C34: update_screen (screen.c:522)
==8692==    by 0x8064F1B: ins_redraw (edit.c:1474)
==8692==    by 0x8063B96: edit (edit.c:688)
==8692==    by 0x812322A: normal_cmd (normal.c:1327)
==8692==    by 0x80E5D2D: main_loop (main.c:1181)
==8692==    by 0x80E587D: main (main.c:940)

(and then follows several more errors)

Here is the relevant code in screen.c:

  2927     line = ml_get_buf(wp->w_buffer, lnum, FALSE);
  2928     ptr = line;
  ....
  ....
  3037 #ifdef FEAT_SPELL
  3038         /* When spell checking a word we need to figure out the
start of the
  3039          * word and if it's badly spelled or not. */
  3040         if (has_spell)
  3041         {
  3042             int         len;
  3043             hlf_T       spell_hlf = HLF_COUNT;
  3044
  3045             pos = wp->w_cursor;
  3046             wp->w_cursor.lnum = lnum;
  3047             wp->w_cursor.col = (colnr_T)(ptr - line);
!!3048             len = spell_move_to(wp, FORWARD, TRUE, TRUE, &spell_hlf);
  3049             if (len == 0 || (int)wp->w_cursor.col > ptr - line)
  3050             {
  3051                 /* no bad word found at line start, don't check
until end of a
  3052                  * word */
  3053                 spell_hlf = HLF_COUNT;
!!3054                 word_end = (int)(spell_to_word_end(ptr,
wp->w_buffer) - line + 1);
  3055             }

Error happens inside call of spell_to_word_end() at screen.c:3054
because ptr is dereferenced inside spell_to_word_end() but is pointing
to memory which has already been freed (bug!).

ptr was previously freed just a few lines above, as a side effect
of calling spell_move_to(...) 6 lines above at screen.c:3048, because
spell_move_to(...) may in some cases call ml_get(...) which invalidates
previous pointer returned by previous call of ml_get(...).  So call
to spell_move_to invalidates line and ptr which were initialized at
line 2927/2928 in screen.c.

Here is how I can reproduce the bug:

$ valgrind vim -u NONE -c 'set nowrap|set spell|start' -s
spell-access-freed-mem.vim  2> valgrind.log

spell-testcase is a small file generated randomly which triggers this bug:
  http://dominique.pelle.free.fr/spell-access-freed-mem.vim

But happens only if terminal is small enough (80x25 or smaller)

I attach a patch which fixes the bug but please review it.  Maybe there
is a better solution.

I'm using vim-7.1 (Patches 1-242) on Linux x86 in a gnome-terminal, built
with "configure --with-feature=huge", without optimizations (-O0 -g).

-- Dominique

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