headers
Tim Chase | 30 Jul 01:24

Re: CTRL-X CTRL-N in command line?

> It might be possible to write a script to do that, but the 
> best solution is to switch to the command-line window and 
> complete the word. Take a look at the help on cmdline-window.

I too have wished that ^N/^P (or ^X ^N/^P) worked in command-line
mode--particularly in the ":s/.../" portion of things.

In addition to Hari's good suggestion of using "q:" or "q/" to
edit the command-line history much like any other buffer, if your
cursor is on the word in question, you can also use ^R^W (that's
control+R followed by control+W) on the command line to insert
the word over which you're cursor is currently positioned.  There
are some funky edge cases in which this doesn't work quite as
expected (such as when coming through line-wise visual mode) but
for most of your usual cases, it works like a charm.

	:help c_CTRL-R_CTRL-W

for more on this too.

HTH,

-tim
Permalink | Reply | 0 comments |
headers
M.K. | 30 Jul 01:38
Picon
Favicon

Re: CTRL-X CTRL-N in command line?

--On Friday, July 29, 2005 18:18:17 -0400 Hari Krishna Dara
<hari_vim <at> yahoo.com> wrote:
> It might be possible to write a script to do that, but the best solution
> is to switch to the command-line window and complete the word. Take a
> look at the help on cmdline-window.

Hmm, good idea, never thought of that.  But now I have a second problem:
the 'cedit' key doesn't seem to work for me.  From what I understand, after
I type ":%s/", I should be able to just hit C-F, and the cmdline  window
should pop up.  For me, nothing happens.  To make sure, I did ":set
cedit=<C-F>", and still nothing.  I have no problems reaching that window
from normal mode though, using "q:".  What could be the problem??
Permalink | Reply | 0 comments |
headers
M.K. | 30 Jul 07:26
Picon
Favicon

editing ChangeLogs with Vim?

Is there any special handling for editing ChangeLog files in Vim?  If not,
can anyone who does use Vim to maintain ChangeLogs share any effective tips
& tricks they use?
Permalink | Reply | 1 comment |
headers
Hari Krishna Dara | 30 Jul 07:40
Picon
Favicon

Re: CTRL-X CTRL-N in command line?


On Fri, 29 Jul 2005 at 7:38pm, M.K. wrote:

> --On Friday, July 29, 2005 18:18:17 -0400 Hari Krishna Dara
> <hari_vim <at> yahoo.com> wrote:
> > It might be possible to write a script to do that, but the best solution
> > is to switch to the command-line window and complete the word. Take a
> > look at the help on cmdline-window.
>
> Hmm, good idea, never thought of that.  But now I have a second problem:
> the 'cedit' key doesn't seem to work for me.  From what I understand, after
> I type ":%s/", I should be able to just hit C-F, and the cmdline  window
> should pop up.  For me, nothing happens.  To make sure, I did ":set
> cedit=<C-F>", and still nothing.  I have no problems reaching that window
> from normal mode though, using "q:".  What could be the problem??
>

I think I had some problem with setting 'cedit' too, but <C-F> I think
is the default, so it should work with no configuration. I use <C-F> to
move forward, so I wanted to change it to <A-S-F>, and here is what I
have in my vimrc:

" To open the command window.
cnoremap <A-S-F> <C-F>
"set cedit=<A-S-F>

I think 'cedit' didn't work, which is why I had it commented and used an
alterntaive.

Another alternative I many times use is to use <C-R><C-W> in combination
(Continue reading)

Permalink | Reply | 0 comments |
headers
François Pinard | 30 Jul 13:25
Picon
Gravatar

Re: is vim putting the right bytes for utf-8 ?

[Mike Williams]

> The Unicode codespace is 21-bit only

Roughly, but not exactly.  You have to exclude surrogates from the
codespace.

> ISO646 has a 32-bit codespace range,

It's (or was?) ISO 10646-1.  ISO 646 is something else :-).

I think that ISO 10646 is (was) defined over 31 bits, not 32.

--

-- 
François Pinard   http://pinard.progiciels-bpi.ca
Permalink | Reply | 3 comments |
headers
François Pinard | 30 Jul 13:58
Picon
Gravatar

Re: is vim putting the right bytes for utf-8 ?

[Bram Moolenar]

> Both UCS-2 and UCS-4 depend on byte order, thus are only useful inside
> a program.  Unfortunately, some people do use them for files, that's
> why the BOM (Byte Order Mark) was invented (helps, but makes file
> manipulation complicated).

I heard that "UCS-2" files are often seen on Windows, but do not really
know, not being a Windows user.

> I never heard about Unicode limiting to 0x10FFFF, I think that's a
> limit of UTF-16.

UTF-16 has been integrated and made "official" in more recent Unicode.
Unicode has long lost the original purity it had in the beginnings,
it became a fairly complex thing.  But do not read my opinion as
definitive, as I should be following standard evolution much more
closely than I did in the recent years.

> As mentioned before UTF-16 is a bad hack for people who used 16 bit
> characters and discovered later that it's not sufficient for all
> characters (most notably MS-Windows).  There's a lot of politics going
> on for this standard...

They always knew 16 bits is not sufficient, but thought they could
force Asian people into simplifications that would well fit Americans.
Some countries ferociously resisted, and Unicode progressively relaxed
its rules, while the political damage being slow to repair.  Even in
the recent years, Unicode (and W3C) are making hardening moves which
hurt poorer countries (I particularly studied this for a few African
(Continue reading)

Permalink | Reply | 12 comments |
headers
Tony Mechelynck | 30 Jul 15:44
Picon

Re: is vim putting the right bytes for utf-8 ?

----- Original Message ----- 
From: "François Pinard" <pinard <at> iro.umontreal.ca>
To: "Bram Moolenaar" <Bram <at> moolenaar.net>
Cc: <mike.williams <at> globalgraphics.com>; "vim list" <vim <at> vim.org>
Sent: Saturday, July 30, 2005 1:58 PM
Subject: Re: is vim putting the right bytes for utf-8 ?

> [Bram Moolenar]
>
>> Both UCS-2 and UCS-4 depend on byte order, thus are only useful inside
>> a program.  Unfortunately, some people do use them for files, that's
>> why the BOM (Byte Order Mark) was invented (helps, but makes file
>> manipulation complicated).
>
> I heard that "UCS-2" files are often seen on Windows, but do not really
> know, not being a Windows user.

I'm a Windows user. "Long file names" on Windows are encoded in 16-bit 
little-endian Unicode (whether UCS-2 or UTF-16 I'm not sure); WordPad (a 
watered-down version of Word or a deluxe Notepad, depending on point of 
view) can read any Unicode file if it has a BOM, but when saving its only 
choices are the current "locale" encoding or 16-bit little-endian Unicode 
with BOM (again, I'm not sure whether UTF-16 or UCS-2).
>
>> I never heard about Unicode limiting to 0x10FFFF, I think that's a
>> limit of UTF-16.
>
> UTF-16 has been integrated and made "official" in more recent Unicode.
> Unicode has long lost the original purity it had in the beginnings,
> it became a fairly complex thing.  But do not read my opinion as
(Continue reading)

Permalink | Reply | 9 comments |
headers
Bram Moolenaar | 30 Jul 16:29
Picon

Re: is vim putting the right bytes for utf-8 ?


François Pinard wrote:

> [Bram Moolenar]
> 
> > Both UCS-2 and UCS-4 depend on byte order, thus are only useful inside
> > a program.  Unfortunately, some people do use them for files, that's
> > why the BOM (Byte Order Mark) was invented (helps, but makes file
> > manipulation complicated).
> 
> I heard that "UCS-2" files are often seen on Windows, but do not really
> know, not being a Windows user.

Before UTF-8 was invented UCS-2 was used.  It was good to avoid all
kinds of multi-byte and double-byte encodings, but UTF-8 is better (no
byte order problems, backwards compatible with ASCII, etc.).  I don't
think UCS-2 has become very popular for text files, it is used for
MS-Windows files, such as a dump of the registry.

These days you probably should call it UTF-16 (which is upwards
compatible with UCS-2).  Although it would be hard to find a real-life
UTF-16 file that is not valid UCS-2.

--

-- 
BLACK KNIGHT: The Black Knight always triumphs. Have at you!
   ARTHUR takes his last leg off.  The BLACK KNIGHT's body lands upright.
BLACK KNIGHT: All right, we'll call it a draw.
                 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 /// Bram Moolenaar -- Bram <at> Moolenaar.net -- http://www.Moolenaar.net   \\\
(Continue reading)

Permalink | Reply | 1 comment |
headers
François Pinard | 30 Jul 16:55
Picon
Gravatar

Re: is vim putting the right bytes for utf-8 ?

> I'm a Windows user. "Long file names" on Windows are encoded [...]

Thanks for this information.

> [...] IMHO Unicode is irreplaceable when it comes to multilingual
> texts with several different writing systems on the same page.

ISO 2022 offers extension mechanisms for such a mix, and it has
been popular in many countries, each its way of using it, making
inter-operation rather difficult.  Unicode is more successful at
inter-operability, and while not being simple, is technically simpler.

> I have doubts about any contraption's capability [...]

[contraption] You're teaching me new English words, thanks! :-)

> UTF-8 multibyte sequences are perfectly valid (if often meaningless)
> Latin-1 strings and there would arise a need for disambiguation.

You are right of course.  While an UTF-8 string could be checked for
UTF-8'ness, hardly a Latin-1 string could be checked for Latin-1'ness.
Yet, rxvt-Unicode is pretty successful at it.  I'm not sure how it does
it, but I would guess that any 0x80-0xFF byte which is not part of a
valid UTF-8 sequence is then interpreted as Latin-1.  Despite confusion
is theoretically possible, this works pretty well in practice, and
especially well for French!

I would like if Vim had an option for doing something similar while
reading an UTF-8 file, because it sometimes happen, especially with
email, that a file (or a message) contains a mix of UTF-8 and Latin-1.
(Continue reading)

Permalink | Reply | 8 comments |
headers
François Pinard | 30 Jul 17:36
Picon
Gravatar

Re: is vim putting the right bytes for utf-8 ?

[Bram Moolenar]

> Before UTF-8 was invented UCS-2 was used.

The first time I heard about UTF-8 was while reading addendum N. of
a draft of ISO 10646-1.  If I remember well, UTF-8 was only later
introduced into Unicode, which was the UCS-2 proponent, while ISO
10646-1 was more on the UCS-4 side.  So, from this perspective, UTF-8
and UCS-2 may be chronologically unrelated.

On the other hand, the experimental AT&T's Plan9 was rune (UCS-2)
oriented, and their UTF-FSS was not far from the actual UTF-8.  I do not
remember Plan9 dates, relative to standards, however.

But all this is fairly fuzzy in my memory, read me with a grain of salt.

--

-- 
François Pinard   http://pinard.progiciels-bpi.ca
Permalink | Reply | 0 comments |

Gmane