mrosic (Vim Github Repository) writes:
> "\a" is an alphabetic character [A-Za-z] Unfortunately that doesn't
> seem to include "ä" which makes Austrian sysadmins sad because they
> don't have syntax highlighting for Log files in January due to that
> error Note that for example echo -e "ä\na" | gr
On 2015-12-11, Bram Moolenaar wrote:
> The name user preferences was not quite right, but you can see that
> these values will remain the same no matter what command you run. As
> soon as you have something like:
>
> setenv SOME_VAR=some_value
> run command
> setenv SOME_VAR=
e
On 2015-12-11, Bram Moolenaar wrote:
> Sorry, I just do not agree with that spec. Building software using
> environment variables is brittle and is bound to go wrong. Environment
> variables can be set for various reasons, and there is hardly any
> control over them. Generally they are user pre
On 2015-12-03, h_east wrote:
> Yes and No.
> It can be switched by the 'clpum' option.
It seems like two parallel ways of implementing essentially the same
functionality. I'm particularly interested in the custom completion
functionality (your clcomplete option), and if (or if not why not) it is
On 2015-12-02, Jörn Engel wrote:
> The vim bug is to try "$TMPDIR" even though the environment variable
> isn't set. Arguably that could become a security-issue if I can create
> a "$TMPDIR" in a directory I control and trick someone else to open a
> file from that directory.
If it were possible
On 2015-12-02, h_east wrote:
> I am trying to add new feature to Vim.
> It's CLPUM(Command-line mode PopUp Menu)
Would this replace 'wildmenu'? Would it work with it, if someone
still prefers the single-line display?
--
--
You received this message from the "vim_dev" maillist.
Do not top-post!
On 2015-11-29, rdebath wrote:
> Grrr, the point of the patch is not 4k colours, it's that vim uses
> a weird set of 16 colours for *any* number of colours that isn't
> 8,16,88 or 256.
And that's wrong for *any* number. The weird order should only be
used for Sb/Sf, not AB/AF.
> The reason you mi
On 2015-11-28, rdebath wrote:
> Vim assumed that all terminals that do not have 8, 16, 88 or 256 colours
> have a particular non-ansi, non-terminfo ordering to the first 16 colours.
> Terminals that had one of those counts would only get ANSI ordering if
> the terminfo control sequence ends with a
Brian Wilson writes:
> Not sure I understand the question about \< and \> being on the same
> column.
\< and \> are zero-width regex specifiers matching the beginning and
ending of a word. For english words AAA BBB it would become ^\
\$, but for Thai words AAABBB it would be ^\\$ and I
was wonder
Luf Waffe writes:
> Is there any news on this?
> This is quite a nuisance to any windows gVim users who prefer dark themes.
> Here is a screenshot (superimposed on a dark background to highlight borders).
> http://i.imgur.com/4ENpUvP.jpg
>
> The white border can change in size (sometimes disappea
Bram Moolenaar writes:
> Can we see the start and/or end of a word by recognizing characters?
> Or do we need to recognize words?
Everything I can find online indicates that word boundary detection (and
line breaking, which requires _syllable_ boundary detection). ICU
provides algorithms for this
Tony Mechelynck writes:
> On Sun, Nov 8, 2015 at 8:47 PM, Bram Moolenaar wrote:
>> Instead of removing the documentation, we can add the options.
>> The feature actually is supported. Although it's probably only useful
>> for the GUI.
>
> They give me E846 "Key code not set" which seems to mean
John Little writes:
> On Sunday, November 8, 2015 at 4:52:26 PM UTC+13, Random832 wrote:
>
>> "U+25BD WHITE DOWN-POINTING TRIANGLE"
>
> Well done, is all I can say.
>
> How do you start an xterm in non-utf8 mode?
As far as I can tell, it's non-utf8 by
John Little writes:
> On Sunday, November 8, 2015 at 12:03:49 PM UTC+13, Random832 wrote:
>> When running in xterm (a real xterm, not any other terminal reporting
>> itself as "xterm") with TERM set to xterm, Vim puts the terminal in a
>> state where the screen cle
When running in xterm (a real xterm, not any other terminal reporting
itself as "xterm") with TERM set to xterm, Vim puts the terminal in a
state where the screen clearing commands \e[K and \e[J do not work
(resulting in many artifacts where text that Vim attempted to clear
remains on the screen).
Bram Moolenaar writes:
> Please suggest a patch. I don't have a vt52 to try it out on :-).
Many vt100 emulators (and a real vt100, should you happen to have one)
can be put in vt52 mode by echoing '\e[?2l' ('\e<' to get back).
Removing the offending codes, and doing a simple ifdef for terminfo,
I was, just for fun, writing a vt52 terminal emulator, and one of the
programs I tested was vim. I discovered that vim has a built-in terminal
description of the vt52 which has several bugs:
>{(int)KS_AL,IF_EB("\033T", ESC_STR "T")},
>{(int)KS_DL,IF_EB("\033U", ESC_STR "U")},
>...
Dominique Pellé writes:
> Having said that, a file could may contain invalid utf-8 with
> sequences longer than 4 bytes.
> It should be treated as errors and should not crash Vim.
File _contents_ can contain these, or random bytes that don't mean
anything, but file _names_, on Windows, are not en
Tony Mechelynck (Vim Github Repository)
writes:
> P.S. IMHO scrolling with the wheel should act the same as scrolling
> with the scrollbar, i.e., when used in an inactive window, "adjust"
> its offset and not move the other ones.
Scrolling with the wheel always scrolls the focused window (and
th
19 matches
Mail list logo
