Re: Patch 8.1.0578
On Wed, Dec 12, 2018 at 10:31 PM Bram Moolenaar wrote: > It appears some terminals have bidi support, and it works to use Vim in > it without left-right support. Arabic shaping might still work then. I > don't use these languages, thus I wouldn't know how well that works. Ah, right, I had forgotten about that. I occasionally use mlterm, a full-bidi replacement to xterm (but I use it in a Vim built with features=big +rightleft +arabic) and AFAICT the result (in Latin-script text with here and there an Arabic or Hebrew word) is quite nice, with LTR and RTL being applied to each word as it needs them; but of course it means running Console Vim in that particular full-bidi terminal. What I can't use is the "native OSX terminal" of which there was talk recently, because I'm not on OSX but on Linux. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.1.0578
On Wed, Dec 12, 2018 at 8:36 PM Bram Moolenaar wrote: > > > Patch 8.1.0578 > Problem:Cannot disable arabic, rightleft and farsi in configure. > Solution: Add configur flags. (Diego Fernando Carrión, closes #1867) > Files: src/configure.ac, src/auto/configure, src/config.h.in, > src/feature.h, src/Makefile IMHO --disable-rightleft should imply --disable-arabic and --disable-farsi (since both Arabic and Farsi, and BTW even Hebrew support would be rather pointless without RTL support) but it is not clear to me that it does. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: wrong highlight for *floating-point-precision* in help
On Mon, Dec 10, 2018 at 10:59 PM Bram Moolenaar wrote: > Tony: It was highlighted like an example, which only stops at a > non-blank in the first column. "<" can be used to stop it with an > invisible character. Thanks for explaining. I wasn't conscious of that when I wrote the patch about using functions for π and e. Happily Dominique provided the correct fix. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
wrong highlight for *floating-point-precision* in help
In the eval.txt helpfile (last change 2018 Dec 09) at line 1108, with default GUI colors, the helptag *floating-point-precision* is highlighted in blue rather than pink. I suppose that some hidden control character is missing after the example functions to compute pi and e. This tag is correctly found by ":h floating-point-precision" after so this is not a severe bug. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] New search is horrible and difficult to disable (MINT19) (#3663)
On Fri, Dec 7, 2018 at 5:28 AM James McCoy wrote: > Setting aside the actual details of what options/settings are provided > by defaults.vim, the mechanism used to provide newer defaults to users > is faulty. > > The fairly standard precedence for configuration at large is: > > user config overrides system config overrides baked-in defaults > > The mechanism of using defaults.vim changes that to be > > (defaults.vim or user config) overrides system config overrides baked-in > defaults > > Cheers, > -- > James Long before defaults.vim even existed, my vimrc has had runtime vimrc_example.vim near its beginning; then I overrode the settings which I didn't like. Nowadays, most or all of what used to be in vimrc_example.vim has been moved to defaults.vim, and the vimrc_example.vim merely sources that, so on that point there has been no change for me. OTOH, the openSUSE admins' /etc/vimrc contains a lot of stuff about whose utility I have a lot of doubts, here is an example: " Changed default required by SuSE security team--be aware if enabling this " that it potentially can open for malicious users to do harmful things. set nomodeline I don't agree with the SUSE admins' theory that Vim's sandbox mechanism is insufficient everywhere including on a single-user installation like mine. However, my own-compiled Vim looks for its system vimrc at the default location which is $VIM/vimrc so that does not disturb me either. BTW, "SuSE" with lowercase u isn't the company's name anymore since 2003 so maybe this policy isn't up-to-date anymore. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.1.0565
On Wed, Dec 5, 2018 at 7:46 PM Bram Moolenaar wrote: > > > Patch 8.1.0565 > Problem:Asan complains about reading before allocated block. > Solution: Workaround: Avoid offset from becoming negative. > Files: src/gui.c [...] > ! // FIXME: how can the first character ever be zero? > ! if (col1 > 0 && ScreenLines[off + col1] == 0) > --col1; [...] Experiment shows that after yanking a block from an empty buffer (i.e. the ruler says "0,0-1") with 'virtualedit' defaulted to empty, the register yanked to is empty. Doesn't that mean that the string-terminating null byte is found at character zero of the block? Of course, one would normally not yank from an empty buffer — except, maybe, to test that the program logic is working properly, even in the most absurd circumstances. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Question] Stripping of Vim binaries
On Wed, Dec 5, 2018 at 6:28 PM wrote: > > Hi, > > I looked into Vim's Makefile and I found out binary stripping happens during > the built, which causes missing debuginfo data in the end of the build. > Would someone mind telling me if there a reason why stripping is done? Is > there a way how to disable stripping during build? I didn't find any > configure option to do that, only by setting STRIP=/bin/true in Makefile. > If there will be an interest for such configure option, I can create the > patch for it... > > Thank you in advance, > > Zdenek Stripping is done to make the Vim executable significantly smaller and marginally faster. You don't need to disable stripping during build because the unstripped executable is not deleted: it can still be found in the parent of your objects directory — i.e. in your shadow directory if you use one, or else in the src/ subdirectory of your source (git or Mercurial) clone. If you need to debug Vim "with symbols", just invoke it from there with a full path — on my system, where I use shadow directories, that would be ~/.build/vim/vim-hg/src/shadow-big/vim but on yours it is probably something else. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Invalid locale example at the end of :help digraphs-use
On Mon, Dec 3, 2018 at 8:50 PM Bram Moolenaar wrote: > > > Tony wrote: > > > The example locale at line 118 of helpfile digraph.txt is invalid. I > > suggest the attached patch. > > Thanks, I'll include it. > > Hmm, I think the remark about "fmt" is outdated. And it confuses me. > So let's just drop that part. Since I didn't understand the part about fmt myself either, I tried to change the doc as little as possible (though I changed Latin1 to the nowadays more fashionable UTF-8 [more fashionable, that is, on Unix-like systems which are those where $LC_CTYPE is defined] and I explained where to look for valid values). If the whole part about needing to set $LC_CTYPE to some value other than 7-bit US-ASCII is now obsolete, the whole paragraph can of course be dropped, and then my whole change becomes moot. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Invalid locale example at the end of :help digraphs-use
The example locale at line 118 of helpfile digraph.txt is invalid. I suggest the attached patch. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. # HG changeset patch # User Tony Mechelynck # Parent bb2696c9ed5eecf995dd51d383ea3b6f585e558c Correct invalid locale example in digraph.txt diff --git a/runtime/doc/digraph.txt b/runtime/doc/digraph.txt --- a/runtime/doc/digraph.txt +++ b/runtime/doc/digraph.txt @@ -110,17 +110,21 @@ this, you will have to type e again 'digraph' option and use CTRL-K to enter digraphs. You may have problems using Vim with characters which have a value above 128. For example: You insert ue (u-umlaut) and the editor echoes \334 in Insert mode. After leaving the Insert mode everything is fine. Note that fmt removes all characters with a value above 128 from the text being formatted. On some Unix systems this means you have to define the environment-variable LC_CTYPE. If you are using csh, then put the following line in your .cshrc: > - setenv LC_CTYPE iso_8859_1 + setenv LC_CTYPE en_US.utf8 +(or similar for a different language or country). The value must be a valid +locale on your system, i.e. on Unix-like systems it must be present in the +output of > + locale -a == 3. Default digraphs *digraphs-default* Vim comes with a set of default digraphs. Check the output of ":digraphs" to see them. On most systems Vim uses the same digraphs. They work for the Unicode and
Re: RFE: Help about computing e and pi by functions rather than literals
Oops, d/dx(atan x) is slightly less than 1 for x=1 but it is still much better-behaved than "infinity". Best regards, Tony. On Mon, Nov 26, 2018 at 3:30 AM Tony Mechelynck wrote: > > On Mon, Nov 26, 2018 at 2:10 AM Bram Moolenaar wrote: > > Makes sense. It is probably also more precise. However, I think we > > only need to give one alternative for "pi", let's use the shortest one. > > If the compiler (or the floating-point hardware) specialcases acos(-1) > — as IMHO every scientific compiler or coprocessor ought to do — then > acos(-1) is easier to write and remember, and just as precise as 4 * > atan(1). However, if the compiler compiles all inverse trigonometric > functions without specialcasing anything, then 4 * atan(1) is > inherently more precise because d/dx (atan x) = 1 for x = 1 while d/dx > (acos x) → ∞ when x → -1, which is why I had included both variants. > > This said, I would use acos(-1) myself, at least with a "modern" > compiler and after checking that, on this compiler, acos(-1) == 4 * > atan(1) so I suppose that it is OK to omit the longer formula. > > Best regards, > Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: RFE: Help about computing e and pi by functions rather than literals
On Mon, Nov 26, 2018 at 2:10 AM Bram Moolenaar wrote: > Makes sense. It is probably also more precise. However, I think we > only need to give one alternative for "pi", let's use the shortest one. If the compiler (or the floating-point hardware) specialcases acos(-1) — as IMHO every scientific compiler or coprocessor ought to do — then acos(-1) is easier to write and remember, and just as precise as 4 * atan(1). However, if the compiler compiles all inverse trigonometric functions without specialcasing anything, then 4 * atan(1) is inherently more precise because d/dx (atan x) = 1 for x = 1 while d/dx (acos x) → ∞ when x → -1, which is why I had included both variants. This said, I would use acos(-1) myself, at least with a "modern" compiler and after checking that, on this compiler, acos(-1) == 4 * atan(1) so I suppose that it is OK to omit the longer formula. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RFE: Help about computing e and pi by functions rather than literals
See the attached diff. Bram, this is an RFE, if you don't like it,
don't take it (these are formulas I would use to compute e and pi).
This also moves |float-pi| and |float-e| down by a few lines to put
the paragraph headed "Rationale" where IMHO it belongs.
Best regards,
Tony.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
# HG changeset patch
# Parent 3062856b8dc63bc586760800ce3ca90b84749dd5
RFE: alternative ways to compute pi and e
diff --git a/runtime/doc/eval.txt b/runtime/doc/eval.txt
--- a/runtime/doc/eval.txt
+++ b/runtime/doc/eval.txt
@@ -1083,29 +1083,34 @@ Examples:
1.234e03
1.0E-6
-3.1416e+88
These are INVALID:
3. empty {M}
1e40 missing .{M}
- *float-pi* *float-e*
-A few useful values to copy: >
- :let pi = 3.14159265359
- :let e = 2.71828182846
-
Rationale:
Before floating point was introduced, the text "123.456" was interpreted as
the two numbers "123" and "456", both converted to a string and concatenated,
resulting in the string "123456". Since this was considered pointless, and we
could not find it intentionally being used in Vim scripts, this backwards
incompatibility was accepted in favor of being able to use the normal notation
for floating point numbers.
+ *float-pi* *float-e*
+A few useful values to copy: >
+ :let pi = 3.14159265359
+ :let e = 2.71828182846
+Or, if you don't want to write them in as floating-point literals, you can
+also use functions like the following (several choices are possible): >
+ :let pi = acos(-1.0)
+ :let pi = 4.0 * atan(1.0)
+ :let e = exp(1.0)
+
*floating-point-precision*
The precision and range of floating points numbers depends on what "double"
means in the library Vim was compiled with. There is no way to change this at
runtime.
The default for displaying a |Float| is to use 6 decimal places, like using
printf("%g", f). You can select something else when using the |printf()|
function. Example: >
Re: Gdk-CRITICAL when I use -geometry with offset
On Wed, Nov 14, 2018 at 9:34 PM Mun wrote: > > Hi all, > > I'm not sure when this started, but it was sometime after v8.1 patch > 119 . I'm on v8.1 patch 524 now, and when I start vim thusly (e.g.): > $ vim -u NONE -U NONE --noplugin -g -geometry 80x40+100 .vimrc > > I get the following error on my console (although, vim seems to work just > fine): > > (gvim:5756): Gdk-CRITICAL **: IA__gdk_window_get_origin: assertion > `GDK_IS_WINDOW (window)' failed > > If instead I execute the following: > $ vim -geometry 80x40 .vimrc > > All is well; no error. The only real difference is that I am not > placing the window at an offset. > > I get the same results on the following systems: > 1. Red Hat Enterprise Linux v6.8 > 2. Ubuntu 16.04.5 LTS > > In both cases I am using GTK2. > > Is this a vim issue? Or did I miss something that would require > action on my part? > > Best regards, Have you tried specifying not one but two values (Δx and Δy, as shown at ":help -geometry-example")? E.g. -geometry 80x40+100+0 for a horizontal offset, or -geometry 80x40+0+10 for a vertical offset? Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.1.0519
On Linux64, even with that #ifdef in place, evalfunc.c compiles with no error, even in my Tiny and Small builds compiled with -quickfix and -eval (using gcc 7.3.1). All my other builds (Normal, Big and Huge) have +quickfix and +eval. Here are my configure options for the Normal build: export CONF_OPT_GUI='--enable-gui=gtk2' export CONF_OPT_MULTIBYTE='--enable-multibyte' export CONF_OPT_AUTOSERVE='--enable-autoservername' export CONF_OPT_FEAT='--with-features=normal' export CONF_ARGS='--with-vim-name=vim-normal' export CONF_OPT_COMPBY='"--with-compiledby=antoine.mechely...@gmail.com"' According to doc/various.txt line 426, Normal and higher builds are with +quickfix. Did you try to override that and build a Normal build without the quickfix feature? Have you tried replacing evalfunc.c line 32 with #ifdef FEAT_NORMAL rather than removing it altogether along with line 34? Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.1.0512
On Thu, Nov 8, 2018 at 6:22 AM Nazri Ramliy wrote:
>
> On Tue, Nov 6, 2018 at 3:26 AM Bram Moolenaar wrote:
> > + static int
> > + is_valid_mess_lang(char_u *lang)
> > + {
> > + return lang != NULL && ASCII_ISALPHA(lang[0]) &&
> > ASCII_ISALPHA(lang[1]);
>
> Any chance of segfault due to strlen(lang) < 1 here?
>
> nazri
IIUC, lang is an ASCIIZ string; hence, if strleng(lang) == 0 then
either lang == NULL or lang[0] == 0 (which is not ASCII_ISALPHA) and
shortcut evaluation should prevent looking at lang[1].
Best regards,
Tony.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Documentation bug report - "j" format option
On Mon, Nov 5, 2018 at 4:50 PM Edward McGuire wrote: > > This is a documentation bug report. The "j" format option is missing from the > table *fo-table* of the current HTML documentation, retrieved 5 November 2018. > > URL: > > http://vimdoc.sourceforge.net/htmldoc/change.html#fo-table > > Cheers > Edward Thanks. I suppose a new version of the HTML help should be uploaded (by whoever maintains it). That HTML documentation is "for Vim 7.3". Since then, 7.4 and 8.0 have come and gone, and the latest version asof this writing is 8.1.511. In case of doubt, the authoritative documentation is the online help distributed together with Vim. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.1.0510
>if (lang == NULL || STRLEN(lang) < 2)/* safety check */
>return;
...
>// any C like setting, such as C.UTF-8, becomes "en"
>else if (STRLEN(p_hlg) >= 1 && *p_hlg == 'C')
>{
>p_hlg[0] = 'e';
>p_hlg[1] = 'n';
>}
This sets 'helplang' to empty for just C but to "en" for C.UTF-8. A
little weird, maybe, but I suppose it's OK.
Best regards,
Tony.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] Hard-coded 2 pixel border in GTK gVim (#3575)
On Tue, Oct 30, 2018 at 11:58 AM John Little wrote: > > On Tuesday, October 30, 2018 at 2:05:04 PM UTC+13, Kazunobu Kuriyama wrote: > > Vim on xterm has the 2px-width border > > Not on my xterm on KDE. ovk's mod now makes gvim consistent with vim in an > xterm, and vim in a konsole, when I use the same font as gvim. In konsole I still see a faint margin but thinner, 1px I think. In xterm the font is different, yet I think I see a wider margin on the left side of Vim's status line (inside xterm's greyish margin of which I don't understand the /raison d'être/) than on the right, maybe 2px and 1px respectively. This is in konsole 17.12.3 and xterm 330. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Can gvim take up the whole GUI screen (with no window decorations)
On Mon, Oct 29, 2018 at 4:31 AM Kazunobu Kuriyama wrote: > > On Mon, Oct 29, 2018 at 11:25 AM Tony Mechelynck > wrote: >> >> On Mon, Oct 29, 2018 at 2:26 AM Kazunobu Kuriyama >> wrote: >> > As far as X11 is concerned, whether or not attaching the task bar or the >> > title window to the window dedicated to gvim proper is determined by the >> > window manager in use with that gvim. Accordingly, if the window manager >> > is able to distinguish maximization from full screen, and if, by the user, >> > it is configured or set up properly to work differently for each >> > enlargement mode, gvim will/should behave as expected. Gvim itself >> > doesn't know about task bars or title windows which are to be used with it >> > at all, thus having no control over them, though it can provide some >> > information such as the file name in the current buffer to the window >> > manager when asked. >> > >> > Best regards, >> > Kazunobu >> >> Well, in my current window manager (I think it is kdm but I'm not >> sure) when I hit F11 (or when I use the menuitem View→Full Screen) in >> a maximized SeaMonkey (which still has a titlebar, a menubar and a >> statusbar) it becomes even bigger, taking up the whole screen, even >> covering the clock topbar, the virtual desktops sidebar and the >> applications footer bar normally provided by the window manager (or >> something) and which "normally" maximized windows reach but don't >> cover. (In that mode I can still change virtual desktops by hitting >> Ctrl-Alt-Up, Ctrl-Alt-Down, or Ctrl-F1 to Ctrl-F8.) The above is what I think @prabirshrestha is asking for. What I mentioned below is, as you noted under it, a different issue which is covered in gvim by 'guioptions'. But the fact that it is triggered by hitting F11 or selecting a certain menuitem shows (IIUC) that the change is initiated by the browser. >> At the same time >> the window decorations (titlebar etc.) disappear, and the whole >> browser chrome becomes reduced to just a URL bar with a few buttons at >> its right end to go back to normal operation. Menu bar, toolbars, etc. >> disappear but the tab bar is still shown. The "different isue" ends here. The paragraph below is about the browser's compiled-in libraries. >> This browser is compiled >> with GTK3 GUI (its configure settings include >> --enable-default-toolkit=cairo-gtk3 as shown on its about:buildconfig >> page). So it is possible to program it, at least in a GTK3 program in >> this particular window manager. I won't bet about other GUIs and/or >> other WMs. > > > I think this is another issue different from the maximize/fullscreen issue > we've been discussing. Rather, it's asking for a new feature that has gvim > modify 'guioptions' automatically in accordance with a given enlargement mode > at runtime, e.g., while keeping 'go' unchanged for maximization, do :set > go-=m automatically for full screen, and revert to the normal user settings > when it gets back to normal. > > Note that all gvim can control is those GUI components that are listed in :h > 'go'. For them, I bet it is possible to add such a new feature with a > programming on our side if the GUI toolkit used with gvim notifies the latter > of the current enlargement mode via a GUI event. For other components, we > definitely need the help of WMs. > > Best regards, > Kazunobu > >> >> I still have no idea about the quantity of programming necessary to >> make such a capability available in as many as possible of the GUIs I >> mentioned in my previous post (when running in a WM that can do it). I >> expect it to be a huge lot of work but I would be happy to be proved >> false in this matter. >> Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Can gvim take up the whole GUI screen (with no window decorations)
On Mon, Oct 29, 2018 at 2:26 AM Kazunobu Kuriyama wrote: > As far as X11 is concerned, whether or not attaching the task bar or the > title window to the window dedicated to gvim proper is determined by the > window manager in use with that gvim. Accordingly, if the window manager is > able to distinguish maximization from full screen, and if, by the user, it is > configured or set up properly to work differently for each enlargement mode, > gvim will/should behave as expected. Gvim itself doesn't know about task > bars or title windows which are to be used with it at all, thus having no > control over them, though it can provide some information such as the file > name in the current buffer to the window manager when asked. > > Best regards, > Kazunobu Well, in my current window manager (I think it is kdm but I'm not sure) when I hit F11 (or when I use the menuitem View→Full Screen) in a maximized SeaMonkey (which still has a titlebar, a menubar and a statusbar) it becomes even bigger, taking up the whole screen, even covering the clock topbar, the virtual desktops sidebar and the applications footer bar normally provided by the window manager (or something) and which "normally" maximized windows reach but don't cover. (In that mode I can still change virtual desktops by hitting Ctrl-Alt-Up, Ctrl-Alt-Down, or Ctrl-F1 to Ctrl-F8.) At the same time the window decorations (titlebar etc.) disappear, and the whole browser chrome becomes reduced to just a URL bar with a few buttons at its right end to go back to normal operation. Menu bar, toolbars, etc. disappear but the tab bar is still shown. This browser is compiled with GTK3 GUI (its configure settings include --enable-default-toolkit=cairo-gtk3 as shown on its about:buildconfig page). So it is possible to program it, at least in a GTK3 program in this particular window manager. I won't bet about other GUIs and/or other WMs. I still have no idea about the quantity of programming necessary to make such a capability available in as many as possible of the GUIs I mentioned in my previous post (when running in a WM that can do it). I expect it to be a huge lot of work but I would be happy to be proved false in this matter. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Can gvim take up the whole GUI screen (with no window decorations)
>From github issue 3573: @prabirshrestha said: > @tonymec by full screen I don’t mean maximize. Full screen as in no task bar > and title window. I want my vim to be in one monitor and take all the pixels > there similar to watching a movie. This kind of thing would (I expect) have to be programmed separately for each different GUI, viz.: • Windows • MacVim • X11: ○ Motif ○ Athena ○ NeXtaw ○ Photon ○ GTK2 ○ GTK3 (and I'm not counting the Mac-Carbon GUI which I think is obsoleted by MacVim). That's a bunch. I'm not saying it would be impossible, but it would mean a lot of separate changes (in the separate GUI C, C++ [Windows] or Objective-C [MacVim] sources used by Vim) to be debugged and maintained separately. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: linebreak, showbreak, and visual block yank problem
On Wed, Oct 24, 2018 at 1:57 PM John Little wrote: > > I noticed a problem today when editing a paragraph that was wrapped to > several lines on screen. To reproduce, use a file with a line with normal > prose text that wraps to several screen lines, say x.txt, then > > vim -u NONE -c "set linebreak showbreak=>" x.txt > > Move to the end of the long line, start a block selection with ctrl-V, press > y to yank it. The yanked text will be from an earlier part of the line, not > the text in the block selection. The offset increases with the amount of > space showing on the right of the text, space that without the 'linebreak' > option would not be blank. It doesn't happen with v for a character > selection. > > I bisected my .vimrc to find the settings triggering the problem, then used > git bisect to find the problem was introduced with v7.4.576: > > Date: Wed Jan 14 17:52:30 2015 +0100 > > updated for version 7.4.576 > Problem:Redrawing problem with 'relativenumber' and 'linebreak'. > Solution: Temporarily reset 'linebreak' and restore it in more places. > (Christian Brabandt) > > I could give a more detailed example, but Google groups might wrap it into a > confusing mess. > > I suppose that using a block selection for part of a line that is wrapped > with 'linebreak' is marginally useful so this problem is very minor. > > Regards, John Little I confirm the problem, and in addition, when yanking a visual block extending over the common part (near, but not after, the end) of several successive long lines all wrapped with 'linebreak', the value that appears in the register after the yank is not only from an earlier part of the lines but of a different width than the highlight (which is displayed at the same visual abscissa, and thus not at the same distance from start-of-line, in all the lines over which it extends). If the selected block is shortly after a 'linebreak' wrap, the yanked text may even include some "virtual spaces" generated by 'linebreak' to wrap the line at a 'breakat' character. The difference in width is not explained by the difference in bytes for different UTF-8 characters: for instance in one file, after ":set lbr sbr=---\|" (not my usual setting) I see two consecutive file lines whose second screen lines start as: ---|href="#sryvatj">срыва́ть ---|cou, un(e) risque-tout. including the ---| 'showbreak' value. By block-selecting the /a together with the /p (a 2x2 block, all in ASCII) then yanking, I get atj">срыва́т^Jrisque-tout (which is rectangular in terms of characters, not bytes; but much longer) into the register. The excess length corresponds approximately AFAICT to the sum amount of virtual whitespace added by 'linebreak' at the end of both previous screen lines. (That file is online as part of my "Russian-French dictionary" project; the lines in question are lines 3131-3132 of http://users.skynet.be/antoine.mechelynck/slovarj/ru-fr.18.html as displayed in a full-screen gvim with encoding=utf-8 lines=68 columns=174 guifont=Bitstream Vera Sans Mono 8 linebreak showbreak=---| ). Try it, it is easier to see than to explain. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.1.0487
On Fri, Oct 19, 2018 at 10:37 PM Bram Moolenaar wrote: > > > Patch 8.1.0487 > Problem:No menus specifically for the terminal window. > Solution: Add :tlmenu. (Yee Cheng Chin, closes #3439) Add a menu test. > Files: runtime/delmenu.vim, runtime/doc/autocmd.txt, runtime/doc/gui.txt, > runtime/doc/index.txt, runtime/doc/terminal.txt, > runtime/doc/usr_42.txt, runtime/menu.vim, src/ex_cmdidxs.h, > src/ex_cmds.h, src/ex_docmd.c, src/menu.c, src/proto/menu.pro, > src/popupmnu.c, src/structs.h, src/testdir/test_menu.vim I don't know why this patch got sent to the list as "Patch 8.1.04" but at least the patch number is correct in the message text. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: MATLAB indent script
On Wed, Oct 17, 2018 at 9:08 PM Axel Forsman wrote: > > Hello everyone: > > I wrote to Christophe Poucet at christophe.pou...@pandora.be, the > listed maintainer on the MATLAB language indent file about an improved > indent script I made. Unfortunately, I got back that the email was not > listed on the server. Nevertheless the new script fixes many of the > issues of the script present in upstream Vim, and is available on > GitHub > (https://github.com/axelf4/dotfiles/blob/master/.vim/indent/matlab.vim). > Not sure on how to do with a patch since it is a complete rewrite. > > Some of the particular code patterns that this script indent better > than the current one include (where better is measured as closer to > MATLAB R2018b smart indent): > > if true, ... > if true > disp hello; > end > end > (where line continuations mean you have to explicitly line up if/end pairs) > > switch a > case 1 > if true, foo; end > case 3 > disp hello; > end > (where end of switch statement has to be dedented twice and a one-line > if is used) > > if true > A(1:end - 1) > disp hello; > end > (where end is used in array indexing) > > Additionally the Function indenting format is configurable just like in > MATLAB. > > I hope for the sake of us all that, if not this, then something else > gets merged because touching MATLAB is frustrating as is. Not a single > man should be subjected to that amount of suffering. > > Well met, > Axel Forsman At present, the Matlab indent, syntax and ftplugin scripts are each listed as maintained by a different person. The indent script (unchanged since 2001) is by far the longest-unchanged one of three. If Christophe Poucet has gone AWOL and does not reappear, I suppose that Bram (who reads this list) will let you become the new maintainer of the Matlab indent script — if you are willing, of course. That would mean listening to Matlab users' complaints about indenting, fixing problems as best you can, and centralizing patches (if any) supplied by other people, then sending any changes to Bram. What would you think of that? Yes, as you say in your other email, if Christophe Poucet's email address has become invalid it needs changing, but even if he (in Belgium where he and I live, "Christophe" is a masculline given name) is still connected to the Internet, it is quite possible that no one on this list knows his new address, so it's anyone's guess by what that invalid address should be replaced. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [patch][win32] MinGW makefile deletes too much .exe files
On Wed, Oct 17, 2018 at 1:48 AM Ken Takata wrote: > > Hi, > > When running make clean with the MinGW makefile, it deletes all *.exe files. > It's too much. It should delete only created files like Make_mvc.mak does. > Please check the attached patch. > > Regards, > Ken Takata After the recent changes, shouldn't the last context line (3rd line after your changes) be changed to -$(DEL) auto/if_perl.c ? Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.1.0474
On Mon, Oct 15, 2018 at 8:11 PM Bram Moolenaar wrote: > Ken Takata wrote: > > Is it better to remove -I. from CFLAGS in Make_mvc.mak and add it only where > > needed like Make_cyg_ming.mak? > > I think it doesn't hurt. Perhaps it's also needed for the xdiff files? On Linux, at least (where if_perl.c has lived for ages in the auto subdirectory) the compiler command-line starts with gcc -c -I. -Iproto (sometimes with additional whitespace in between) for _all_ modules (not only Perl) AFAICT and for (at least) all five featuresets, and GUI configured as Gnome2 (with several interpreters including Perl), GTK2 without Gnome, Motif or none (the latter three with no interpreters); and I don't see any harm caused by it. The xdiff sources have needed recompilation a few days ago but not this time. Let me see... not later than (and soon before) Mon 15 Oct 01:25:34 CEST 2018 (where CEST = UTC+0200) Now let's get the source repo log grouped by my downloads... 8.1.474 to 8.1.477 AFAICT • 5110 8.1.0474 directory where if_perl.c is written is inconsistent • 15480 8.1.0475 memory not freed on exit when quit in autocmd • 3035 8.1.0476 memory leaks in test_escaped_glob • 1255 8.1.0477 tiny build fails • 1704 8.1.0478 cannot build with perl using MinGW • 4319 8.1.0479 failure when setting 'varsofttabstop' to end in a comma Hm, maybe it's not needed for xdiff if no MinGW user has complained (I'm not sure: hard to test when on a different OS with a different makefile). But could it hurt? Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Testing the GUI code
On Sat, Oct 13, 2018 at 8:06 PM Bram Moolenaar wrote: > > > We have made great progress increasing test coverage, thanks for > everybody helping out! > > There is one big gap: The GUI code. We usually test by putting text in > the input buffer, which means we totally bypass all the GUI event > handling. > > For GTK we could inject events at the level of the callback functions. > E.g., invoke key_press_event() with a specific key event. And I suppose > call key_release_event() later to make everything work. > > We would need to do this for every callback function, and fill in the > event. I wonder if there is a more generic approach. > > For MS-Windows we can probably synthesise Windows messages, since they > are all handled in process_message(). Can we send ourselves a message? > > Which leaves two kinds of holes: - MacVim - Linux GUIs other than GTK (Athena, Motif, ...) - and in addition, can we be sure that GTK2 and GTK3 can be tested the same way? Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: When started as "vim-huge --clean -? |less" the Gnome version tries (and fails) to start a GUI, then seems to hang
On Thu, Oct 11, 2018 at 5:25 PM Bram Moolenaar wrote:
>
>
> Christ van Willegen wrote:
>
> > On Wed, Oct 10, 2018 at 12:44 AM Tony Mechelynck
> > wrote:
> > > Could it be because the g near the end of "vim-huge" is mistakenly
> > > interpreted as meaning that I want to invoke gvim?
> >
> > I was in the source and accidentally bumped into the code that does
> > this. Here is the comment above that function:
> >
> > /*
> > * Check for: [r][e][g][vi|vim|view][diff][ex[im]]
> > * If the executable name starts with "r" we disable shell commands.
> > * If the next character is "e" we run in Easy mode.
> > * If the next character is "g" we run the GUI version.
> > * If the next characters are "view" we start in readonly mode.
> > * If the next characters are "diff" or "vimdiff" we start in diff mode.
> > * If the next characters are "ex" we start in Ex mode. If it's followed
> > * by "im" use improved Ex mode.
> > */
> >
> > The code walks through the command name that invoked vim, and the [g]
> > is indeed only checked at that point. So, the 'g' in huge does not
> > automatically trigger a GUI, or at least, should not...
> >
> > Not sure where your problem comes from, but not from this part of the
> > code...
> >
> > I see that the comment does not specify what it does with the [vi] and
> > [vim] parts of the command name, but these are implied, I guess.
> >
> > Hey, weird... according to the spec above, I _should_ be able to start
> > with 'viex' or 'viexim', but that is not caught at all!
> >
> > if (STRNICMP(initstr, "view", 4) == 0)
> > {
> > readonlymode = TRUE;
> > curbuf->b_p_ro = TRUE;
> > p_uc = 1; /* don't update very often */
> > initstr += 4;
> > }
> > else if (STRNICMP(initstr, "vim", 3) == 0)
> > initstr += 3;
> >
> > (I would expect to have a check for "vi" and an "initstr += 2;" as wel...)
> >
> > Bram, should the pattern at the top of this function be changed to
> > note that these names for the executable are not recognized? Not sure
> > if 'viex' or 'viexim' would make sense...
>
> It just lists the general pattern, not every exception. e.g. the 'e'
> for "evim" or "egvim" doesn't always get recognized.
>
> I don't think there is an actual problem to fix here, right?
Well, IMHO when invoked with -? Vim ought never to start a GUI, it
should display the help text then exit, and that's what the GTK2
version without Gnome does, even when invoked as "gvim -?"; OTOH the
Gnome2 version invoked as "vim-huge -?" displays the help text, tries
to start the GUI, fails, and then (if I hit Enter at the
|hit-enter-prompt|), displays the intro screen and waits for console
input. IMHO it should have exited after displaying the help text.
Best regards,
Tony.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
When started as "vim-huge --clean -? |less" the Gnome version tries (and fails) to start a GUI, then seems to hang
Invoke "vim --clean -? |less" at bash prompt in konsole. Yes, vim, not gvim; or as qualified to get to the proper binary (on my system, vim-huge for Gnome2, vim for Big GTK2 without Gnome, vim-small for Motif, or vi for no GUI; all these are the names of ELF executables [not symlinks] in /usr/local/bin/) Results are OK when compiled with GTK2 without Gnome, with Motif, or without GUI. When compiled with GTK2 with Gnome, the display ends (after a short but noticeable wait near the end) in GNOME GUI Library --disable-crash-dialog Disable Crash Dialogue E852: The child process failed to start the GUI Press ENTER or type command to continue It is then necessary to blind-type :q in Vim (which displays garbage at the bottom of the screen) then type q in less in order to come back to the bash prompt. Could it be because the g near the end of "vim-huge" is mistakenly interpreted as meaning that I want to invoke gvim? Adding -v anywhere before the |less redirection gives "Warning: Output is not to a terminal" then what looks like a garbled version of the :intro screen, as if the -? switch had been disregarded. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [win32][patch] executable() may fail on very long filename
On Mon, Oct 8, 2018 at 3:50 AM Ken Takata wrote: > [...] > I have updated the patch for 8.1.0453: > > * Fixed conflicts. > * Fixed a typo in a comment which was added in 8.1.0453. > > Regards, > Ken Takata In UTF-8, characters outside the BMP (i.e. characters in the range U+1 to U+10FFFD), including some "CJK Extension" characters in plane 2, use 4 bytes each, not 3. However, in UTF-16le as used by Windows, each of those non-BMP characters takes up 2 words (one high surrogate and one low surrogate) instead of 1, so maybe (I don't know) they might "count double" towards the allowed _MAX_PATH characters. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Convert C style comments into C++ style comments in quickfix.c
On Sun, Oct 7, 2018 at 7:39 PM Yegappan Lakshmanan wrote: > > Hi, > > The attached patch changes all the C style comments (except for > the function/data type headers) into C++ style comments in > the quickfix.c file. > > - Yegappan > Are all these changes really useful? Isn't it a little like "tickling oneself to make oneself laugh" as we say in French? C-style comments still work after all (and, AFAIK, they are guaranteed to go on working for all future versions of C). Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Fwd: CLA for contributing to Vim
-- Forwarded message - From: Tony Mechelynck Date: Sat, Oct 6, 2018 at 7:24 PM Subject: Re: CLA for contributing to Vim To: Cc: On Sat, Oct 6, 2018 at 7:12 PM wrote: > > Bram: > > As I understand it, Vim doesn't require a CLA—that is, a document that > any given contributor must sign before you will accept any of their > contributions (sent to the development list, etc.). I'm fairly sure > that this is true, so that's not what I'm here to ask. > > My question is more specific than that: has Vim at any point *ever* had > a CLA process? I believe that it hasn't, but I just want to do some > fact-checking before I go off making claims without verifying them. > > Thanks. > > -- > Colby Russell On the contrary, the philosophy of Vim has always been that any changes you make to the Vim source SHOULD (and I think that at some point in the past it was MUST) be made available to Bram. For the present state of things, see section III under ":help license". Bram will then accept those changes into the "official" Vim source, or not, depending on the changes' own merit, and not on any administrative red tape or paperwork: he is the "enlightened despot" of the Vim realm, but he governs with a light hand. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [patch] Fix modeline of some documents
On Fri, Oct 5, 2018 at 6:58 AM h_east wrote: > > Hi Bram and list, > > The following documents sets 'formatoptions' in modeline. > > runtime/doc/help.txt > runtime/doc/os_390.txt > runtime/doc/os_win32.txt > > "fo=tcq2:" > > Even if write "set fo+=mM" in my .vimrc, it will be overwritten with this > modeline. > When I apply this modeline to a doc/*.txt translated file (e.g. *.jax), It > will not work well for editing. > So I currently applied the exclude "fo=tcq2:" from modeline. > If possible, I want to prevent the difference of modeline between .txt and > .jax. > > Could you change "fo=tcq2:" to "fo+=2:" ? > Please include an attached patch. > Options set by modeline are always set as if by :setlocal, and since 'formatoptions' is a buffer-local option, it will not override whatever you set for other files. (Modelines, or the :setlocal command, will only override your global options if they mention a global-only option.) Now none of the mentioned helpfiles is in CJK hanzi/kanji/hanja - kana - hangeul so ":selocal fo+=mM" is, for them, not necessary and even IMHO possibly harmful. OTOH for translations of the same helpfiles it is IMHO the translator's business to adapt the modelines as needed by the target language and writing system, and for instance to add mM to the formatoptions in the modelines of CJK translated helpfiles. There is absolutely no requirement that the modelines for Japanese, Korean, Chinese-Simplified or Chinese-Traditional helpfiles be exactly identical to those for the English-US ones; and in particular if Russian or Hebrew translators reasoned the way you do, they would want to set fo-=mM on _their_ translated helpfiles to make sure that separate words are kept separate when anyone edits their Russian or Hebrew text even if they do it in UTF-8 (where Russian and Hebrew use multibyte characters above U+00FF) rather than some 8-bit 'encoding' targeting their specific language. ;-) BTW, Esperanto uses Latin script, but with the letters Ĉĉ Ĝĝ Ĥĥ Ĵĵ Ŝŝ Ŭŭ which are above U+00FF, and even though those same letters also exist in ISO-8859-3, AFAIK most Esperantists prefer "universal" Unicode, which can also encode their native language whatever it might be, over that "Turkish - Maltese - Esperanto" 8-bit charset, which possibly cannot. (Proportionately more Russians might still prefer 8-bit charsets cp866, KOI8-R or ISO/IEC 8859-5, and similarly mutatis mutandis for Hebrew; but Unicode's "market share" is rising together with the globalization of EDP.) Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Proposal] Updated defaults.vim. (Add "mM" to 'formatoptions')
On Fri, Oct 5, 2018 at 4:19 AM h_east wrote: > > Hi Bram, > > By default, 'm' is not contained in 'formatoptions', so automatic wrapping > not work when multi-byte characters are continuously input. > Of course, I should set it up with my .vimrc, but I saw some people in > trouble with this case. > I am very happy if you can include an attached patch. > I think this change does not affect non-multi-byte-inputting people. In UTF-8, anything above U+007F is multibyte, and Cyrillic, Greek, Hebrew, Arabic, IPA, or some "extra" Latin glyphs such as the French œ (oe) ligature, are not only multibyte but also above U+00FF i.e. above 255. Adding m would allow breaking Cyrillic, Greek, Hebrew or Arabic anywhere in the middle of a word, and such common French words as "bœuf" (ox or beef), "œil" (eye), "clin d'œil" (wink), "œuf" (egg), "jaune d'œuf" (yolk), "sœur" (sister), etc. immediately before or after the œ. Similarly, adding M would IIUC glue together any Cyrillic, Greek, Hebrew or Arabic words, as well as French words the second of which starts in œ as in "un œil" (an eye) or "un œuf" (an egg). This is definitely unwanted and breaks upwards compatibility. Adding mM to 'formatoptions' should IMHO be restricted to files in CJK scripts, and since it is buffer-local it could very well be set in the modelines of said files. *Please* do NOT make fo+=mM the Vim default. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Fwd: potential user interface issue with Swap file dialog
Google blocked my previous post, saying it was "spam", so I'm posting it again with a different "To:" list. -- Forwarded message - From: Tony Mechelynck Date: Thu, Oct 4, 2018 at 10:35 PM Subject: Re: potential user interface issue with Swap file dialog To: (censored) On Thu, Oct 4, 2018 at 8:51 PM Christian Brabandt wrote: > [...] > -- > Mit jedem Tag den ich älter werde steigt die Zahl derer, > die jünger sind als ich. (Translation out of the German): Every day as I get older, the number of those younger than me increases. Whether this is true or not depends on the "universe of discourse": who are the "those" qualified by "(who are) younger than me" in the above statement? For "all human beings" or "all German-speaking people" or even maybe "all Germans" I think that, at the moment at least, the given statement is true (or is it?); but with different "universes of discourse" such as an extended family, or the people speaking a particular endangered language, there may be days where no "one" is born, or even days where the number of deaths of people younger than the speaker exceeds the number of births; such days would then, for such restricted "universes of discourse", provide counterexamples to the statement quoted above. Abstract logic has long been one of my hobbies :-P Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: potential user interface issue with Swap file dialog
On Thu, Oct 4, 2018 at 8:51 PM Christian Brabandt wrote: > [...] > -- > Mit jedem Tag den ich älter werde steigt die Zahl derer, > die jünger sind als ich. (Translation out of the German): Every day as I get older, the number of those younger than me increases. Whether this is true or not depends on the "universe of discourse": who are the "those" qualified by "(who are) younger than me" in the above statement? For "all human beings" or "all German-speaking people" or even maybe "all Germans" I think that, at the moment at least, the given statement is true (or is it?); but with different "universes of discourse" such as an extended family, or the people speaking a particular endangered language, there may be days where no "one" is born, or even days where the number of deaths of people younger than the speaker exceeds the number of births; such days would then, for such restricted "universes of discourse", provide counterexamples to the statement quoted above. Abstract logic has long been one of my hobbies :-P Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Remove function prototypes for static functions
On Mon, Oct 1, 2018 at 7:17 AM Dominique Pellé wrote: > > Tony Mechelynck wrote: > > > Oh, I thought we had (automatically generated) prototypes in > > src/proto/*.pro for all functions in src/*. > > No. The *pro files are not meant to declare static functions, > since static functions can only be used in the compilation > unit that defines them. > > Dominique Yeah, I found that out yesterday after posting by looking up the meaning of "static" in C, which shows how spottily I know C. I come from a world where (e.g. in assembly language) any linksymbol, i.e. any symbol visible in more than one source file (one "compilation unit") had to be specially labeled, both as "extern" where used but not defined, and as "entry" where defined for use by others. I see that in C it's the opposite: anything defined at top level is assumed to be globally visible unless restricted to the current compilation unit by means of the "static" keyword. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Remove function prototypes for static functions
On Sun, Sep 30, 2018 at 7:03 PM Yegappan Lakshmanan wrote: > > Hi Bram, > > On Sun, Sep 30, 2018 at 8:12 AM Bram Moolenaar wrote: > > > > Yegappan wrote: > > > > > The quickfix.c file uses several function prototypes for static > > > functions in the file. The attached patch removes these > > > prototypes by moving the functions around. Even though the > > > diff is large, no new functionality is introduced in this diff > > > and the contents of the functions are not changed. > > > > I'm not a fan of moving functions around just to remove the function > > prototype. It's better to keep functions in an order that makes it easy > > to overview their relation. > > > > Even though some of the functions are moved, I kept the related > functions together by functionality. > > > > > There is a conflict in this: It's natural to first start with the main > > entry point, and have lower level functions below it. But to avoid > > prototypes one has to do it the other way around. > > > > Yes. Currently some static functions have prototypes and others don't. > > > > > I know some people who write C put main() at the bottom and everything > > it needs above it, but that does feel like it's upside down. Especially > > if you have worked with a language that doesn't have this requirement > > (or function prototypes at all). > > > > I thought removing the static function prototypes will reduce the clutter. > But I will leave it up to you to decide whether to merge it or not. > > Regards, > Yegappan > > > > > I've been thinking of generating the prototypes automatically, like we > > do for the files in src/proto. But never got around getting all the > > details right (e.g., need some way to skip certain functions, recognize > > #ifdefs, etc.). > > Oh, I thought we had (automatically generated) prototypes in src/proto/*.pro for all functions in src/*.c — and BTW I thought it rather neat; no "clutter" at all since those prototypes are in different source files after all. Well, one learns something new every day. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.1.0400
On Sun, Sep 16, 2018 at 6:11 PM Bram Moolenaar wrote: > Q: How many legs does a giraffe have? > A: Eight: two in front, two behind, two on the left and two on the right Q.: Prove that horses have an odd number of legs. A.: Two in front, two at the rear, two on the left and two on the right, that makes eight, which sure is an odd number of legs for a horse. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: When using diff I am getting "E959: Invalid diff format" in master gVim on Windows
On Thu, Sep 13, 2018 at 10:25 AM Tony Mechelynck wrote: > > On Thu, Sep 13, 2018 at 10:13 AM Igor Forca wrote: > > > > 1. QUESTION > > copy c:\aaa\a.txt C:\Users\igor\AppData\Local\Temp\file1.txt > > copy c:\aaa\b.txt C:\Users\igor\AppData\Local\Temp\file2.txt > > > > > > C:\cygwin\bin>diff -a --binary C:\Users\igor\AppData\Local\Temp\file1.txt > > diff -a --binary C:\Users\igor\AppData\Local\Temp\file2.txt 2>&1 > > diff: extra operand `C:\Users\igor\AppData\Local\Temp\file2.txt' > > diff: Try `diff --help' for more information. > > > > C:\Programs\Vim\vim81>diff -a --binary > > C:\Users\igor\AppData\Local\Temp\file1.txt diff -a --binary > > C:\Users\igor\AppData\Local\Temp\file2.txt 2>&1 > > diff: extra operand > > diff: Try `diff --help' for more information. > > > > C:\Programs\Vim\vim81>diff -a --binary > > C:\Users\igor\AppData\Local\Temp\file1.txt > > diff: missing operand > > diff: Try `diff --help' for more information. > > > > > > Should this be one or two commands? I tired both and getting error. > [...] > > Try > > diff -a --binary C:\Users\igor\AppData\Local\Temp\file1.txt > C:\Users\igor\AppData\Local\Temp\file2.txt >..\difftest.log 2>&1 P.S. all on one line > > then look at the contents of both difftest.log files (one in > c:\cygwin\ and one in C:\Programs\Vim\) > > Best regards, > Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: When using diff I am getting "E959: Invalid diff format" in master gVim on Windows
On Thu, Sep 13, 2018 at 10:13 AM Igor Forca wrote: > > 1. QUESTION > copy c:\aaa\a.txt C:\Users\igor\AppData\Local\Temp\file1.txt > copy c:\aaa\b.txt C:\Users\igor\AppData\Local\Temp\file2.txt > > > C:\cygwin\bin>diff -a --binary C:\Users\igor\AppData\Local\Temp\file1.txt > diff -a --binary C:\Users\igor\AppData\Local\Temp\file2.txt 2>&1 > diff: extra operand `C:\Users\igor\AppData\Local\Temp\file2.txt' > diff: Try `diff --help' for more information. > > C:\Programs\Vim\vim81>diff -a --binary > C:\Users\igor\AppData\Local\Temp\file1.txt diff -a --binary > C:\Users\igor\AppData\Local\Temp\file2.txt 2>&1 > diff: extra operand > diff: Try `diff --help' for more information. > > C:\Programs\Vim\vim81>diff -a --binary > C:\Users\igor\AppData\Local\Temp\file1.txt > diff: missing operand > diff: Try `diff --help' for more information. > > > Should this be one or two commands? I tired both and getting error. [...] Try diff -a --binary C:\Users\igor\AppData\Local\Temp\file1.txt C:\Users\igor\AppData\Local\Temp\file2.txt >..\difftest.log 2>&1 then look at the contents of both difftest.log files (one in c:\cygwin\ and one in C:\Programs\Vim\) Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [patch] has('patch-8.1.0') returns 0
On Thu, Sep 13, 2018 at 7:32 AM Tony Mechelynck
wrote:
>
> On Thu, Sep 13, 2018 at 6:42 AM h_east wrote:
> >
> > Hi Bram and developers,
> >
> > :echo has('patch-8.1.0')
> > 0
> >
> > This should return 1.
> > A patch attached.
> >
> > NOTE:
> > This issue was reported by Takuya Fujiwara.
> >
> > --
> > Best regards,
> > Hirohito Higashi (h_east)
>
> I disagree.
>
> There never was a patch 0, certainly not in release 8.1, see
> http://ftp.vim.org/pub/vim/patches/8.1/
>
> To know if Vim is at patchlevel 8.1.0 or later, use
> if version >= 810
oops, if version >= 801
>
> Remember that has('patch8.1.1') returns 0, not 1, if by some chance
> you have a Vim 8.1.10 in whose source patch 8.1.1 was omitted (or
> reverted). So has('patch8.1.0') should always return 0 in Vim 8.1,
> because there never was a patch zero. IOW, it is always omitted, the
> first included patch is patch 1. For has('patch8.1.0') to return 1,
> you might need Vim 8.2 or later (which hasn't yet been released)
> because patchnumbers ('sub-minor versions') of major-minor versions
> other than the current one are never tested. This explains why
> has('patch8.0.0') returns 1 in Vim 8.1.
>
> Best regards,
> Tony.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [patch] has('patch-8.1.0') returns 0
On Thu, Sep 13, 2018 at 6:42 AM h_east wrote:
>
> Hi Bram and developers,
>
> :echo has('patch-8.1.0')
> 0
>
> This should return 1.
> A patch attached.
>
> NOTE:
> This issue was reported by Takuya Fujiwara.
>
> --
> Best regards,
> Hirohito Higashi (h_east)
I disagree.
There never was a patch 0, certainly not in release 8.1, see
http://ftp.vim.org/pub/vim/patches/8.1/
To know if Vim is at patchlevel 8.1.0 or later, use
if version >= 810
Remember that has('patch8.1.1') returns 0, not 1, if by some chance
you have a Vim 8.1.10 in whose source patch 8.1.1 was omitted (or
reverted). So has('patch8.1.0') should always return 0 in Vim 8.1,
because there never was a patch zero. IOW, it is always omitted, the
first included patch is patch 1. For has('patch8.1.0') to return 1,
you might need Vim 8.2 or later (which hasn't yet been released)
because patchnumbers ('sub-minor versions') of major-minor versions
other than the current one are never tested. This explains why
has('patch8.0.0') returns 1 in Vim 8.1.
Best regards,
Tony.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.1.0374
On Wed, Sep 12, 2018 at 11:16 PM Bram Moolenaar wrote: > > > Patch 8.1.0374 > Problem:Moving the cursor is slow when 'relativenumber' is set. > Solution: Only redraw the number column, not all lines. > Files: src/screen.c, src/move.c I just noticed the following message in Huge, Big and Normal Vim with GTK2 GUI. Not in Small with Motif GUI and not in Tiny with no GUI. This is new in 8.1.374. Best regards, Tony. gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -pthread -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libdrm -I/usr/include/libpng16 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/freetype2 -O2 -fno-strength-reduce -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1-o objects/screen.o screen.c screen.c: In function ‘win_line’: screen.c:4604:9: warning: ‘extra_check’ may be used uninitialized in this function [-Wmaybe-uninitialized] if (extra_check) ^ -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: When using diff I am getting "E959: Invalid diff format" in master gVim on Windows
On Wed, Sep 12, 2018 at 11:19 AM Igor Forca wrote: > > Now I set > :set diffopt+=internal diffexpr= > in $VIMRC file, > restarted the gVim and now it works fine. > > Still it is interesting gVim v8.1.0359 works fine without above setting, > but v8.1.0366 only works if above setting is set. Until 8.1.359, there was no diff code inside Vim, do :vimdiff had to rely on some external diff. On Unix-like systems (including Cygwin) an external diff program can be expected to exist and Vim used that. IIUC, on Windows systems an external diff could not be expected to be part of the OS so Vim came with its own diff.exe. Starting at Vim 8.1.360, the diff code is compiled inside Vim (for speed, and for cross-platform uniformity) so no diff executable needs to be published with Vim anymore: it uses its internal diff code by default (the new default for 'diffopt' is "filler,internal"). It is possible to disable this internal diff code though, by ":set diffopt-=internal", and it is not used if the 'diffexpr' option has been set (because the latter can bypass the standard diff executable altogether). If you use a 'diffexpr', and Cygwin diff.exe doesn't work for you, you might need to get some diff executable that does (possibly, but not necessarily, from a Vim 8.1.359 or earlier distribution) and copy that somewhere in your $PATH before Cygwin diff bout outside the $VIMRUNTIME tree. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.1.0369
On Tue, Sep 11, 2018 at 10:37 PM Bram Moolenaar wrote: > > > Patch 8.1.0369 > Problem:Continuation lines cannot contain comments. > Solution: Support using "\ . > Files: src/ex_cmds2.c, src/testdir/test_eval_stuff.vim, > runtime/indent/vim.vim, runtime/doc/repeat.txt Typo in helpfile runtime/doc/repeat.txt, new lines 470-471. These lines disagree with the rest of the text below them. I'm attaching a patch. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. # HG changeset patch # User Tony Mechelynck # Parent 8014307a918820085ed49a07995c3c4c10373ba1 Fix typo in comment continuation documentation diff --git a/runtime/doc/repeat.txt b/runtime/doc/repeat.txt --- a/runtime/doc/repeat.txt +++ b/runtime/doc/repeat.txt @@ -462,18 +462,18 @@ flag when defining the function, it is n :function Foo() :1append \asdf . :endfunction :set cpo-=C < *line-continuation-comment* -To add a comment in between the lines start with '\" '. Notice the space -after the double quote. Example: > +To add a comment in between the lines start with '"\ '. Notice the space +after the backslash. Example: > let array = [ "\ first entry comment \ 'first', "\ second entry comment \ 'second', \ ] Rationale:
Re: Highlighting in the quickfix list
On Thu, Aug 30, 2018 at 7:38 AM Christian Brabandt wrote: > > > On Mi, 29 Aug 2018, Jason Franklin wrote: > > > Greetings, > > > > Just throwing this out there to see if it's possible. > > > > I'd like some improved highlighting when I'm browsing the quickfix list. To > > see what I mean, take a look at the attached screenshot. > > > > To get this image, I ran: > > > > :vimgrep/test/j *.c > > :match Title /\ctest/ > > > > in the "vim/src/" directory. > > > > Is something like this behavior attainable? I would guess we could only do > > it > > for :vimgrep because we need to be using Vim's internal patterns to do the > > matching. > > Can't you do this with a syntax plugin for the quickfix filetype? If > this is possible, it might make sense to ship a quickfix syntax script > There already is one, it's rather short: `$VIMRUNTIME/syntax/qf.vim` Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Leveraging the new 'incsearch' functionality from a Vim plugin
On Thu, Aug 30, 2018 at 5:33 AM Yegappan Lakshmanan wrote: > > Hi, > > Is it possible for a Vim plugin use the new 'incsearch' functionality > in a custom command? For example, I would like to enable this > functionality for the new cfilter plugin. The cfilter plugin adds a > command ":Cfilter" that accepts a search pattern. When the user > types the search pattern, it would be useful to get the 'incsearch' > functionality. > > Thanks, > Yegappan Maybe by defining a new |:command-completion|, complete=pattern ? Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Link error if eval feature not included after patches 8.1. 311-313
Ha! Brenton Horne beat me to the ball. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Link error if eval feature not included after patches 8.1. 311-313
After applying patches 8.1.311 to 8.1.311, I get a link error in the Tiny build (shown below) and also in Small (the same error, not shown). These two builds are without expression evaluation, which makes me think that an #ifdef was forgotten in src/memline.c around the "dictionary" operations about which the linker complains. Best regards, Tony. link.sh: $LINK_AS_NEEDED set to 'yes': invoking linker directly. gcc -L/usr/local/lib -Wl,--as-needed-o vi objects/arabic.o objects/beval.o objects/buffer.o objects/blowfish.o objects/crypt.o objects/crypt_zip.o objects/dict.o objects/diff.o objects/digraph.o objects/edit.o objects/eval.o objects/evalfunc.o objects/ex_cmds.o objects/ex_cmds2.o objects/ex_docmd.o objects/ex_eval.o objects/ex_getln.o objects/farsi.o objects/fileio.o objects/fold.o objects/getchar.o objects/hardcopy.o objects/hashtab.o objects/if_cscope.o objects/if_xcmdsrv.o objects/list.o objects/mark.o objects/memline.o objects/menu.o objects/misc1.o objects/misc2.o objects/move.o objects/mbyte.o objects/normal.o objects/ops.o objects/option.o objects/os_unix.o objects/pathdef.o objects/popupmnu.o objects/pty.o objects/quickfix.o objects/regexp.o objects/screen.o objects/search.o objects/sha256.o objects/spell.o objects/spellfile.o objects/syntax.o objects/tag.o objects/term.o objects/terminal.o objects/ui.o objects/undo.o objects/userfunc.o objects/version.o objects/window.o objects/charset.o objects/json.o objects/main.o objects/memfile.o objects/message.o -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE -lm -ltinfo -lelf -lgpm -ldl objects/memline.o: In function `get_b0_dict': memline.c:(.text+0x26d9): undefined reference to `dict_add_string' memline.c:(.text+0x26f3): undefined reference to `dict_add_string' memline.c:(.text+0x270d): undefined reference to `dict_add_string' memline.c:(.text+0x2727): undefined reference to `dict_add_string' memline.c:(.text+0x2738): undefined reference to `dict_add_number' memline.c:(.text+0x2749): undefined reference to `dict_add_number' memline.c:(.text+0x275a): undefined reference to `dict_add_number' memline.c:(.text+0x2776): undefined reference to `dict_add_string' memline.c:(.text+0x27b6): undefined reference to `dict_add_string' collect2: error: ld returned 1 exit status link.sh: Linking failed make: *** [Makefile:1959: vi] Error 1 exit status 2 Tue 21 Aug 21:01:25 CEST 2018 -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: ATTENTION message with spurious (still running) warning
On Tue, Aug 21, 2018 at 3:57 PM, Bram Moolenaar wrote: > > Tony wrote: > >> If Vim is reloaded after a crash there will usually be one or more >> ATTENTION (E325) messages. This is usually no problem for me as I save >> my work at regular intervals, which means that I can usually delete >> the swapfiles left standing after the crash (they will have "modified: >> no"). However (especially after a system crash and a reboot) sometimes >> the PID of the previous Vim has been reused, the ATTENTION message >> says "(still running)" and the "delete" option is not available, even >> though the program currently using that PID is not the Vim which >> created the swapfile (and then crashed, or was involved in a system >> crash). I'm not sure if (and how) it is possible to get over this >> problem. Maybe in the (still running) case the ATTENTION message could >> list the name of the program currently using that PID, and still offer >> the "delete" option (possibly with an "are you sure" confirmation) if >> that name isn't one of those (vim, gvim, view, etc.; even vi nowadays) >> usually associated with a Vim executable? > > This is a corner case that is difficult to deal with. > There is no standard way to get the name of a process from the pid. Under Linux, on systems where the /proc filesystem is in use (which IIUC is the general case), and if I represent the PID by $PID, /proc/$PID/exe is a symlink to the executable, and /proc/$PID/cmdline is a text file containing the $0, $1, etc. (the invoked executable name and any command-line arguments), each of them null-terminated. I'm not sure whether or not the /proc filesystem is in use on other Unix-like systems (but I wouldn't bet against it), and of course on Windows I suppose that even the existence of a given PID (the "(still running)" part) must be got in a different way. See "man 5 proc" and search (with less's regexps, very similar to Vim's) for /proc/[pid]/cmdline and /proc/[pid]/exe Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.1.0306
On Tue, Aug 21, 2018 at 3:12 PM, Bram Moolenaar wrote: > > Patch 8.1.0306 > Problem:Plural messages are not translated properly. > Solution: Add more usage of NGETTEXT(). (Sergey Alyoshin) > Files: src/vim.h, src/buffer.c, src/ex_cmds.c, src/ex_docmd.c, > src/fileio.c, src/misc1.c, src/ops.c There are still more. (Big gvim 8.1.306 with GTK2 GUI) I just noticed that when hitting u (Undo), if the previous change happened just 1 second ago, the message displayed at the bottom of the screen says "1 change" (which is correct) but also "1 seconds ago" (which is not). Hitting u that fast doesn't happen much, but we shouldn't forget the possibility that languages other than English form their plural differently: for instance Russian has "agreement by proximity" after a numeral, so that the singular is used not only with 1 but also with 21, 31, 41, etc. (and the dual with 2-4, 22-24, 32-34, 42-44, etc.). (Russian cardinal numbers are constructed in a mannar parallel to those of English, French, etc., where 11-19 have their own single-word names not ending in 1-9.) Не правда ли, Сережа? ;-) Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
ATTENTION message with spurious (still running) warning
If Vim is reloaded after a crash there will usually be one or more ATTENTION (E325) messages. This is usually no problem for me as I save my work at regular intervals, which means that I can usually delete the swapfiles left standing after the crash (they will have "modified: no"). However (especially after a system crash and a reboot) sometimes the PID of the previous Vim has been reused, the ATTENTION message says "(still running)" and the "delete" option is not available, even though the program currently using that PID is not the Vim which created the swapfile (and then crashed, or was involved in a system crash). I'm not sure if (and how) it is possible to get over this problem. Maybe in the (still running) case the ATTENTION message could list the name of the program currently using that PID, and still offer the "delete" option (possibly with an "are you sure" confirmation) if that name isn't one of those (vim, gvim, view, etc.; even vi nowadays) usually associated with a Vim executable? Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Comments halfway continuation lines
P.S. Inside a single-quoted string, \c means "backslash followed by c" and we want to keep that; so I propose the following three constructs: '\c ... some comment ... \c '\c ... some comment ... \c' '\c ... some comment ... \c'' (all inside an already-started single-quoted comment) to mean (I'm not sure in what sequence): - the single-quoted string ends at the comment - the single-quoted string is interrupted by a comment and continues thereafter - the single-quoted string is interrupted by a comment and continues thereafter with an embedded single-quote character. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Comments halfway continuation lines
On Mon, Aug 20, 2018 at 1:18 PM, Bram Moolenaar wrote:
>
> Tony Mechelynck wrote:
>> [...]
>> Fixed-form COBOL (the only kind I knew), where comments had to be on
>> their own lines (with an asterisk in column 7 IIRC), and continuation
>> lines had a dash in the otherwise unused column 7, had strict rules
>> about how to represent quoted strings (which could be up to 120
>> characters long) on punched cards where the useful part of unlabeled
>> lines was 61 characters including the starting quote (from column 12
>> to column 72 inclusive) but these are not germane to Vim and I do not
>> propose to introduce anything similar into Vim script language.
>
> Well, the special character sequence to put in front of a comment in
> between continuation lines is something like that.
>
Hm. This would be hard to decide, because inside a double-quoted
string about anything can be used and becomes part of the string, with
the proviso that a backslash can be used to escape certain special
characters. Repeating the opening quote COBOL-like immediately after
the continuation backslash is of course excluded, as it would break
compatibility. Maybe we need some new syntax for comments which end
before the end of the line, but how to define that without changing
the meaning of some already useful syntax construct, especially inside
a double-quoted string? Maybe \c (which at the moment means nothing
AFAIK) and end the comment with another \c (but \\c would mean, as it
already does, "backslash followed by c"). There might be a problem
with Windows pathnames. Then maybe start with "\c and end with \c. No,
that would clash with existing end-of-line comments. Well, then \c but
precede it with a space if it would otherwise be interpreted as part
of a pathname (since on Windows, a top-level path is not indicated by
a starting backslash but by a drive letter followed by a colon).
Inside double-quoted strings, backslashes are "special" anyway and I
would (even with no change to the existing code) strongly recommend
_not_ to use single backslashes to represent a Windows path inside a
double-quoted string: so
if has('win32' || has('win64'))
let filepathname = "%USERPROFILE%\\this\\and\\that\\filename.ext"
endif
or the same with _single_ quotes and single backslashes, but not
double quotes and single backslashes (other than when intentionally
using them for their "special" meanings as under ":help expr-quote"),
as this would already produce unexpected results if the character
following the backslash is any of X x U u b e f n r t
Best regards,
Tony.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Comments halfway continuation lines
On Mon, Aug 20, 2018 at 10:06 AM, Bram Moolenaar wrote: > >> On Monday, August 20, 2018 at 1:37:53 AM UTC+9, Bram Moolenaar wrote: >> > Currently, when making a list with continuation lines, it is not >> > possible to add a comment somewhere: >> > >> > let array = [ >> > \ item, >> > \ item, >> > \ item, >> > \] >> > >> > Adding a comment after the comma causes all the rest to be included in >> > the comment: >> > >> > let array = [ >> > \ item, >> > \ item, " comment >> > \ item, >> > \] >> > >> > Since this is equivalent to: >> > >> > let array = [ item, item, " comment item, ] >> > >> > Simple solutions will such as using \" fail, because just about anything >> > following the backslash is valid if we are inside a string: >> > >> > echo "some >> > \ word >> > \" comment >> > \ word >> > >> > Is equivalent to the valid command: >> > >> > echo "some word" comment word >> > >> > So, a line starting with a backslash can't be used for a comment. >> > Thinking about what would work (that is, currently it is an error), I >> > thought of using |\": >> > >> > let array = [ >> > \ item, >> > |\" comment >> > \ item, >> > \] >> > >> > It looks a bit weird, but it would work. Any thoughts? >> > >> > -- >> > Mynd you, m00se bites Kan be pretty nasti ... >> > "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES >> > LTD >> > >> > /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ >> > ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ >> > \\\ >> > \\\ an exciting new programming language -- http://www.Zimbu.org >> > /// >> > \\\help me help AIDS victims -- http://ICCF-Holland.org/// >> >> I like this. >> >> https://go-gyazo.appspot.com/04e22439cfdc859e.png >> >> Most of people expect comments can be written as syntax is. > > Unfortunately, that currently is valid syntax, especially when the line > continuation is used for a long string. The parsing happens after all > the continuation lines are joined, it's not really possible before that. > > -- > ARTHUR: It is I, Arthur, son of Uther Pendragon, from the castle of Camelot. > King of all Britons, defeator of the Saxons, sovereign of all England! >[Pause] > SOLDIER: Get away! > "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD > > /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ > ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ > \\\ an exciting new programming language -- http://www.Zimbu.org/// > \\\help me help AIDS victims -- http://ICCF-Holland.org/// It is indeed is valid syntax, but is it used anywhere? When floating-point numbers were introduced into Vim, it was decided that using 1.5 to mean "the floating number one and a half" rather than, as before, "the string form of the integer 1 concatenated to the string form of the integer 5", i.e. the string "15" wasn't harmful. Would it be harmful to require than long strings be represented as "aaa" \. "bbb" \. "ccc" with both quotation marks on the same physical line and concatenation by . if necessary, and not "aaa \bbb \ccc" with a long string expanding over two or more continued lines? If it wouldn"t, then I suppose it would be possible to add to the parser a "preprocessor" whose sole task would be to remove comments (from the unpaired double-quote to the end of the physical line regardless of a possible continuation line). There would be an ambiguity in the case of more than one double quote on a single line, but that is already handled in the case of strings vs. comments in expressions, or when using registers in the operand of :normal, or anywhere in the case of @" which does not _have_ to be represented by @@ Fixed-form COBOL (the only kind I knew), where comments had to be on their own lines (with an asterisk in column 7 IIRC), and continuation lines had a dash in the otherwise unused column 7, had strict rules about how to represent quoted strings (which could be up to 120 characters long) on punched cards where the useful part of unlabeled lines was 61 characters including the starting quote (from column 12 to column 72 inclusive) but these are not germane to Vim and I do not propose to introduce anything similar into Vim script language. The alternative to Yatsuhiro's proposal, which is elegant and which I endorse despite its break with backward compatibility, is to break expressions over comments, which can already be done with the current code, and would remain valid
Re: Comments halfway continuation lines
On Sun, Aug 19, 2018 at 6:37 PM, Bram Moolenaar wrote: > > Currently, when making a list with continuation lines, it is not > possible to add a comment somewhere: > > let array = [ > \ item, > \ item, > \ item, > \] > > Adding a comment after the comma causes all the rest to be included in > the comment: > > let array = [ > \ item, > \ item, " comment > \ item, > \] > > Since this is equivalent to: > > let array = [ item, item, " comment item, ] > > Simple solutions will such as using \" fail, because just about anything > following the backslash is valid if we are inside a string: > > echo "some > \ word > \" comment > \ word > > Is equivalent to the valid command: > > echo "some word" comment word > > So, a line starting with a backslash can't be used for a comment. > Thinking about what would work (that is, currently it is an error), I > thought of using |\": > > let array = [ > \ item, > |\" comment > \ item, > \] > > It looks a bit weird, but it would work. Any thoughts? > > -- > Mynd you, m00se bites Kan be pretty nasti ... > "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD > > /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ > ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ > \\\ an exciting new programming language -- http://www.Zimbu.org/// > \\\help me help AIDS victims -- http://ICCF-Holland.org/// In the case of a List, you can construct it by concatenation, though it might be a little slower at run-time, depending on how densely you want to comment: let array = [ \ "one", \ "two", \ ] " three is intentionally omitted call extend(array, [ \ "four", \ "five", \ "six", \ ]) Similarly I suppose for other arithmetic operations: hold the temporary results in one or more variables, insert the comment after temporarily ending the computation, and go on from there. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.1.0294
On Sun, Aug 19, 2018 at 10:38 AM, Axel Bender wrote: > Probably correlated with this patch (did not bisect, but must have happened > between 292 and 296 inclusively), but the following command stopped to work > for me on Windows: > > gvim.exe --servername GVX --remote-silent +"silent! bwipeout 1" "" > > The command fails silently... > What does it say if you make it less silent? gvim --servername GVX --remote +"bwipeout 1" "" Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: current version funny
On Mon, Aug 13, 2018 at 12:13 AM, tooth pik wrote: > i see a patch 279 in the list, but my vim is 278 and git is telling me > i have current > source Mercurial tells me the same thing. Apparently the latest patch, «'incsearch' highlighting does not skip white space.», did not make it to the repository. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Uganda visit report
On Fri, Aug 10, 2018 at 4:45 PM, Bram Moolenaar wrote: > > Hello Vimmers, > > I have visited Vim's charity project in June. I finally had time to > finish writing my report and organise the pictures. You can find it > here: http://www.iccf.nl/news.html > > It has links to the photo album and a short video. Good news, on the average, though "not everyone can afford to boil water" and "the solar [electricity] system is too expensive to fix" distress me a little. I hope access to cooking heat will improve once the new electric installation is approved and electricity from outside (less expensive than running a generator) can be brought even to the existing generator shed. Two thousand pupils in one high school is quite a lot: I'm told the one where I went in Brussels in 1961-1967 had (at the time) something like one thousand, and it was not a small one; though I'm told attendance has increased now that it is coeducational (in my time it was a "boys only" school, except at both ends of the curriculum: in kindergarten and in the "special math" class for students having completed Latin-Greek humanities who wanted –or whose parents wanted them– to enter some "scientific" university faculty) (The Head was at that time a hellenist, which explains why Latin-Greek was regarded as tops). Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.1.0256
> If "R" is Reverse, how come "D" is FORWARD? because scanning "forward" toward the D does it forward while scanning "reverse" toward the R does it backward. :-P -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RFE: Need a plural form?
When I hit u immediately after a chage has happened (the change may have needed a bit of computation, e.g. after triggering the CloseTag plugin at the end of a long HTML file to check that there are no stray unpaired tags) I sometimes see (if I do it very fast after the change) "1 seconds ago" which hurts my sense of grammar. Maybe a "plural form" would be better here but I'm not sure how well this meshes with Vim messages' internationalization: e.g. Russian uses the nominative singular of the noun after 1, 21, 31, ... (but not 11), the genitive singular after 2-4, 22-24, 32-34, ... (but not 12-14) (all the foregoing modulo 100) and the genitive plural everywhere else (3 forms rather than the 2 of Germanic and Romance languages). (This is a leftover of the Indo-European "dual number", which Slavic languages kept longer than Germanic and Latin, together with "agreement by proximity" with the last word of the numeral.) Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.1.0245
On Tue, Aug 7, 2018 at 11:00 PM, Christ van Willegen
wrote:
> Hi,
>
>
>
> Op di 7 aug. 2018 19:05 schreef Bram Moolenaar :
>>
>>
>> Patch 8.1.0245
>> Problem:Calling setline() in TextChangedI autocmd breaks undo. (Jason
>> Felice)
>> Solution: Don't save lines for undo when already saved. (closes #3291)
>> Files: src/edit.c, src/testdir/test_autocmd.vim
>>
>>
>> *** ../vim-8.1.0244/src/edit.c 2018-08-07 14:55:04.905259782 +0200
>> --- src/edit.c 2018-08-07 18:26:35.026760346 +0200
>> ***
>> *** 1722,1732
>> --- 1722,1740
>> {
>> aco_save_T aco;
>>
>> + // Sync undo when the autocommand calls setline() or append(), so
>> that
>> + // it can be undone separately.
>> + u_sync_once = 2;
>> +
>> // save and restore curwin and curbuf, in case the autocmd changes
>> them
>> aucmd_prepbuf(, curbuf);
>> apply_autocmds(EVENT_TEXTCHANGEDI, NULL, NULL, FALSE, curbuf);
>> aucmd_restbuf();
>> curbuf->b_last_changedtick = CHANGEDTICK(curbuf);
>> +
>> + if (u_sync_once == 1)
>> + ins_need_undo = TRUE;
>> + u_sync_once = 0;
>> }
>
>
> The "if" condition looks weird. It looks as if the variable u_sync_once is
> set to 2 unconditionally, and then tested if it is == 1. I'm probably wrong,
> though...
>
> Christ van Willegen
Three functions are called in between. What do you bet that one or
more of them has access by reference to that variable?
Best regards,
Tony.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Deleting the A-A-P recipe
On Tue, Aug 7, 2018 at 2:55 PM, Bram Moolenaar wrote: > > Is anyone building Vim using src/main.aap? I can't talk for other people, but I can guess. I think the most "popular" ways of getting Vim (in no particular order) are the following: * Find a precompiled executable with its runtime files, and use that. * git and make * hg and make Maybe some people are still keeping up the source the old hard way, by downloading a source archive and then using patch and make; but the patches don't include runtime files, so even these ought to set up either a git clone or a Mercurial clone, and then use make in it, IMHO it is less error-prone, and in particular it keeps the runtime files up-to-date. If anyone is using AAP to build Vim (I never did), please speak up. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Allow clicking away from cmdline
On Sun, Aug 5, 2018 at 3:26 PM, Jason Franklin wrote: > I noticed that while editing the command line, I can't click away to focus on > a window. This is mildly annoying to me for whatever reason, so I fixed it. > > 1. Open a bunch of windows. > 2. Edit the cmdline with ":test" > 3. Try to left click on any window, you stay in the command line. > > My patch leaves the command line as if you'd pressed Ctrl_C, but adjusts your > window focus based on where you click. > > It needs some review to make sure I'm using the mouse facilities properly. > > Also, how can I test this? I'm not qualified to review your code or to say whether changing windows while staying in command-lline mode is acceptable, but shouldn't this code be qualified by #ifdef lines for FEAT_MOUSE? Or are those changes already within such a conditional-assembly region? (All builds are compiled with +windows nowadays, otherwise I'd have asked the same about FEAT_WINDOWS or whatever it used to be.) Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: autochdir feature not seen by has() and :version
On Fri, Jul 27, 2018 at 5:40 PM, wrote:
> On Friday, July 27, 2018 at 12:50:44 AM UTC-4, Tony Mechelynck wrote:
>> On Fri, Jul 27, 2018 at 3:41 AM, wrote:
>> > If Vim is built with the 'autochdir' feature defined, it is not reported
>> > as such by the ":version" command and has('autochdir') returns zero.
>>
>> Maybe this is only a documentation error under :help 'autochdir' ?
>> Such a feature is also not mentioned under :h feature-list and :h
>> +feature-list.
>
> However, AUTOCHDIR is listed as a "feature" in feature.h so I would think it
> should included in feature-list and therefore should be recognized by has()
> and :version. Why should some "features" be recognized and not others?
>
>>
>> AFAICT, Huge, Big and Normal builds return 1 as the value of
>> exists('+autochdir'), and neither exists() nor has() can be tested in
>> Small and Tiny builds, which lack expression evaluation.
>
> My experience is different. Here's the full disclosure.
>
> I always build Vim under Windows using mingw and specify FEATURES=NORMAL. I
> wanted to have the 'autochdir' feature but did not want to build with BIG
> features because I have no use for 'rightleft', 'farsi', and others. So I
> added -DFEAT_AUTOCHDIR to the make variable DEFINES in Make_cyg_ming.mak. I
> was able to build without error and all tests passed. To make sure that the
> 'autochdir' feature was included, I tried has() and :version and saw that it
> was not listed. An investigation into why then lead to my proposed patches.
>
> -mike
Well, I build all 5 featuresets of Vim on Linux64; here are the
environment variables defining my configure settings for the Normal
build:
export CONF_OPT_GUI='--enable-gui=gtk2'
export CONF_OPT_MULTIBYTE='--enable-multibyte'
export CONF_OPT_AUTOSERVE='--enable-autoservername'
export CONF_OPT_FEAT='--with-features=normal'
export CONF_ARGS='--with-vim-name=vim-normal'
export CONF_OPT_COMPBY='"--with-compiledby=antoine.mechely...@gmail.com"'
As you can see, the 'autochdir' feature (which I personally don't use)
is defaulted; but when I invoke the "vim-normal" executable in konsole
and ask it
:echo exists('+autochdir')
it answers 1, meaning (according to ":help exists()") that the
'autochdir' option not only is known, but works in this executable.
Note also that neither :help 'autochdir', :help feature-list nor :help
+feature-list mention any +autochdir feature; what is said under :help
'autochdir' about it is
{only available when compiled with it, use
exists("+autochdir") to check}
IOW, IMHO trying to use has('autochdir'), and expecting it to return 1
if the option works, is unsupported behaviour.
Best regards,
Tony.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: autochdir feature not seen by has() and :version
On Fri, Jul 27, 2018 at 3:41 AM, wrote:
> If Vim is built with the 'autochdir' feature defined, it is not reported as
> such by the ":version" command and has('autochdir') returns zero.
Maybe this is only a documentation error under :help 'autochdir' ?
Such a feature is also not mentioned under :h feature-list and :h
+feature-list.
AFAICT, Huge, Big and Normal builds return 1 as the value of
exists('+autochdir'), and neither exists() nor has() can be tested in
Small and Tiny builds, which lack expression evaluation.
Best regards,
Tony.
>
> The following diffs show my proposed patches:
>
> $ git diff evalfunc.c
> diff --git a/src/evalfunc.c b/src/evalfunc.c
> index a9f6c5b8a..ae849be2f 100644
> --- a/src/evalfunc.c
> +++ b/src/evalfunc.c
> @@ -6045,6 +6045,9 @@ f_has(typval_T *argvars, typval_T *rettv)
> "arabic",
> #endif
> "autocmd",
> +#ifdef FEAT_AUTOCHDIR
> + "autochdir",
> +#endif
> #ifdef FEAT_AUTOSERVERNAME
> "autoservername",
> #endif
> $
> $ git diff version.c
> diff --git a/src/version.c b/src/version.c
> index 830de26fc..abc7bf8df 100644
> --- a/src/version.c
> +++ b/src/version.c
> @@ -101,6 +101,11 @@ static char *(features[]) =
> "-arabic",
> #endif
> "+autocmd",
> +#ifdef FEAT_AUTOCHDIR
> + "+autochdir",
> +#else
> + "-autochdir",
> +#endif
> #ifdef FEAT_AUTOSERVERNAME
> "+autoservername",
> #else
>
> --
> --
> You received this message from the "vim_dev" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups
> "vim_dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to vim_dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Warning in Tiny and Small at ex_docmd.c line 10657 after applying patches 210 to 213
After applying patches (8.1.)210 to 213 I get the following message in Tiny and Small (shown here for Small) but not for the other featuresets: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MOTIF -O2 -fno-strength-reduce -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -o objects/ex_docmd.o ex_docmd.c ex_docmd.c: In function ‘eval_vars’: ex_docmd.c:10657:10: warning: variable ‘tilde_file’ set but not used [-Wunused-but-set-variable] int tilde_file = FALSE; ^~ Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Configure script should fail when --with-x=yes and --enable-gui are set but needed dependencies are missing
On Fri, Jul 20, 2018 at 12:39 PM, wrote: > Hi, > > I was trying to compile Vim with GUI on Fedora Server. I used configure > options: > > ./configure --with-x=yes --with-tlib=ncurses --with-features=huge > --enable-gui=gtk3 > > and compilation went smoothly, but when I ran created binary, it ends with > error: > > E25: GUI cannot be used: Not enabled at compile time > > so I checked build log, where I found: > > checking for X... (cached) no > checking if X11 header files can be found... no > checking --enable-gui argument... no GUI support > > , then I remembered the server doesn't have X11 installed. It works correctly > after X devel packages installation, but IMHO configure script should fail > when the option, which is explicitly set, cannot be satisfied. > It would require patch for configure.ac, but I'm not strong with autoconf... > would someone mind looking into it? It is not a bug, it is a feature. Whenever the arguments to configure request a certain feature, and it doesn't find the necessary software, it falls back on disabling it. Both the console output from configure and the more verbose config.log will mention what was looked for and not found. If you log the console output (e.g. by adding «2>&1 |tee make.log» at the end of the "make config" or "make reconfig" command-line, you can find out there what went wrong; and if you don't, you can still find out what went wrong by inspecting the src/auto/config.log (or the src/shadow/auto/config.log if you use a shadow directory). Also, before running "make install", it is a good idea (especially the first time) to run ./vim --version in your src (or shadow) directory to check if you got all the features you wanted. Having the necessary libraries to _run_ a program using a certain feature is usually not enough to _compile_ such a program: for that, you need the corresponding "development" package(s), where the required source header files are to be found. Such packages usually (depending on your distro) have -dev or -devel at the end of their names; the way to find them may also vary according to the package management software used by your distro. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: problem about refresh screen of vim
On Mon, Jul 16, 2018 at 3:45 AM, 许建 <17120...@bjtu.edu.cn> wrote:
> Dear developers,
> Iam a beginner of Linux programming. In amiga.c, source code of vim1.14, I
> found this:
>
> 75 flushbuf()
> 76 {
> 77 if (bpos != 0)
> 78 Write(raw_out, (char *)outbuf, (long)bpos);
> 79 bpos = 0;
> 80 }
>
> So I am confused by the function "Write" for I didn't find the function
> prototype of it.
> is it the "write" function in unistd.h?
>
> in fact I am trying to understand that how vim display chars in the terminal.
> I have tried to write /dev/tty, but the result is not satisfactory.
>
> Thanks!
>
> Jian XU
Vim 1.14? When was that released? Unless you made a typo in that
version number, the source you have is really very old. FYI, the
current Vim code is at revision 8.1.191 and AFAIK its source doesn't
include an "amiga.c" module anymore.
Nowadays, the Vim source is kept on github at
https://github.com/vim/vim (as a git repository, of course) and there
is a Mercurial mirror at https://bitbucket.org/vim-mirror/vim . Both
of them contain the same files arranged in the same directory
structure, the difference is in how you get them (so whether you
prefer git over Mercurial, or the opposite, there is a Vim source
repository for you).
Best regards,
Tony.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: How to determine the x and y position of the Vim text window on screen
On Sat, Jul 14, 2018 at 1:30 AM, tooth pik wrote: > are you looking for :winpos? No, according to earllier posts in this thread he doesn't want to know the pixel position of the Vim screen relative to the desktop, but the position in character cells of the current window (containing one view on one buffer) relative to the Vim screen. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] Change in paren matching from 8.0.0386 to 8.0.1298? (#3190)
On Wed, Jul 11, 2018 at 1:31 AM, tlathm wrote: > I'll try that test with --clean however first I need to clear up some > unspeakable confusion: If I use vim --clean it appears that the paren > matching is totally disabled. I've read countless conflicting things as to > how to enable that. I'm trying ":let loaded_matchparen = 1", ":set > showmatch" and every other imaginable thing I've read and can't get it to > even work on things it was working on. > > To be honest, without the --clean I have no idea what's enabling it in the > first place...certainly nothing in my .vimrc that I'm aware of. Totally lost > at this point. What am I missing? IIUC, --clean sources only the default.vim script but not your vimrc and no plugins, not even the standard matchparen.vim plugin. OTOH, setting loaded_matchparen _disables_ further loading of that plugin. (It makes the plugin believe that it is already loaded.) To have the defaults.vim plus paren matching but nothing else, use vim --clean -c 'runtime plugin/matchparen.vim' Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.1.0177
On Tue, Jul 10, 2018 at 7:39 PM, Bram Moolenaar wrote: > > Patch 8.1.0177 > Problem:Defining function in sandbox is inconsistent, cannot use :function > but can define a lambda. > Solution: Allow defining a function in the sandbox, but also use the sandbox > when executing it. (closes #3182) > Files: src/userfunc.c, src/ex_cmds.h I suppose that something like the attached will have to be included with the next runtime files update then. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. # HG changeset patch # Parent d01478fa739949772209566738f96bb7aaf4ea7d document patch 8.1.177 diff --git a/runtime/doc/eval.txt b/runtime/doc/eval.txt --- a/runtime/doc/eval.txt +++ b/runtime/doc/eval.txt @@ -11571,17 +11571,17 @@ The 'foldexpr', 'formatexpr', 'includeex 'foldtext' options may be evaluated in a sandbox. This means that you are protected from these expressions having nasty side effects. This gives some safety for when these options are set from a modeline. It is also used when the command from a tags file is executed and for CTRL-R = in the command line. The sandbox is also used for the |:sandbox| command. These items are not allowed in the sandbox: - changing the buffer text - - defining or changing mapping, autocommands, functions, user commands + - defining or changing mapping, autocommands, user commands - setting certain options (see |option-summary|) - setting certain v: variables (see |v:var|) *E794* - executing a shell command - reading or writing a file - jumping to another buffer or editing a file - executing Python, Perl, etc. commands This is not guaranteed 100% secure, but it should block most attacks. @@ -11592,16 +11592,17 @@ This is not guaranteed 100% secure, but *sandbox-option* A few options contain an expression. When this expression is evaluated it may have to be done in the sandbox to avoid a security risk. But the sandbox is restrictive, thus this only happens when the option was set from an insecure location. Insecure in this context are: - sourcing a .vimrc or .exrc in the current directory - while executing in the sandbox +- while in a function defined in the sandbox - value coming from a modeline Note that when in the sandbox and saving an option value and restoring it, the option will still be marked as it was set in the sandbox. == 12. Textlock *textlock*
Re: Compiler warning undo.c on Windows 7
On Tue, Jul 10, 2018 at 3:07 PM, Bram Moolenaar wrote: > > Axel Bender wrote: > >> Compiling gVim 8.1 (latest) on Windows 7 64-bit with MinGW gcc 7.30 64-bit I >> receive the following compiler warning in file undo.c: >> >> gcc -c -Iproto -DWIN32 -DWINVER=0x0600 -D_WIN32_WINNT=0x0600 -DHAVE_PATHDEF >> -DFEAT_BIG -DHAVE_STDINT_H -DMS_WIN64 -DHAVE_GETTEXT -DHAVE_LOCALE_H >> -DDYNAMIC_GETTEXT -DFEAT_CSCOPE -DFEAT_MBYTE >> -DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -march=x86-64 -Wall >> -DFEAT_PYTHON3 -DDYNAMIC_PYTHON3 -DDYNAMIC_PYTHON3_DLL=\"python36.dll\" -O3 >> -fomit-frame-pointer -freg-struct-return >> -s undo.c -o objx86-64/undo.o >> undo.c: In function 'u_save_cursor': >> undo.c:270:6: warning: assuming signed overflow does not occur when assuming >> that (X - c) > X is always false [-Wstrict-overflow] >> if (top > curbuf->b_ml.ml_line_count >> >> || top >= bot >> ^ > > There is no subtraction in this code, thus that is a compiler error. > > Can we please have a C standard without "undefined behavior"? I want my > code to always behave in a defined way. > Maybe the solution would be to change the src/Make_ming.mak to invoke gcc with -O2 (like the src/Makefile does) rather than -O3 as seen above? We had recently (yesterday, or maybe the day before) another warning in perfectly legitimate code (in that case a similar "possible signed overflow" warning for a "for (i = 0; i < something; i++)" construct, which will bail out when i becomes equal to the "something"); that warning was also due to the -O3 switch in a minGW compile. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Compiler warning in userfunc.c
On Mon, Jul 9, 2018 at 9:32 AM, Dominique Pellé wrote: > Axel Bender wrote: > >> Compiling gVim 8.1 (latest) on Windows 7 64-bit with MinGW gcc 7.30 64-bit I >> receive the following compiler warning in file userfunc.c: >> >> gcc -c -Iproto -DWIN32 -DWINVER=0x0600 -D_WIN32_WINNT=0x0600 -DHAVE_PATHDEF >> -DFEAT_BIG -DHAVE_STDINT_H -DMS_WIN64 -DHAVE_GETTEXT -DHAVE_LOCALE_H >> -DDYNAMIC_GETTEXT -DFEAT_CSCOPE -DFEAT_MBYTE >> -DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -march=x86-64 -Wall >> -DFEAT_PYTHON3 -DDYNAMIC_PYTHON3 -DDYNAMIC_PYTHON3_DLL=\"python36.dll\" -O3 >> -fomit-frame-pointer -freg-struct-return >> -s userfunc.c -o objx86-64/userfunc.o >> userfunc.c: In function 'get_funccal_local_ht': >> userfunc.c:3609:2: warning: assuming signed overflow does not occur when >> assuming that (X + c) < X is always false [-Wstrict-overflow] >> for (i = 0; i < debug_backtrace_level; i++) >> ^~~ >> userfunc.c: In function 'get_funccal_local_var': >> userfunc.c:3609:2: warning: assuming signed overflow does not occur when >> assuming that (X + c) < X is always false [-Wstrict-overflow] >> for (i = 0; i < debug_backtrace_level; i++) >> ^~~ >> userfunc.c: In function 'get_funccal_args_ht': >> userfunc.c:3609:2: warning: assuming signed overflow does not occur when >> assuming that (X + c) < X is always false [-Wstrict-overflow] >> for (i = 0; i < debug_backtrace_level; i++) >> ^~~ >> userfunc.c: In function 'get_funccal_args_var': >> userfunc.c:3609:2: warning: assuming signed overflow does not occur when >> assuming that (X + c) < X is always false [-Wstrict-overflow] >> for (i = 0; i < debug_backtrace_level; i++) >> ^~~ > > > I don't think we can do much about this warning. > I consider more as an information from the compiler > rather than a warning caused by Vim code. > > It happens when building with -O3 if I recall. > It's telling you that the compiler is statically making the > assumption that a signed integer addition is never overflowing. It's > allowed to do that, because signed int overflows are undefined > behavior in C, so the compiler can do whatever it wants in > case of overflow. When optimizing with -O3, that can cause > changes to the generated code, such as removing 'if' conditions > that are deemed useless because code would be undefined > behavior anyway. > > In above cases, Vim code looks fine. You could add > -Wno-strict-overflow to avoid those warnings. > > We could also silence such warnings by using unsigned > int (since signed int overflow are well defined in C, but I > don't think it's worth. > > We can detect signed integer overflows at runtime by > using ubsan (= undefined behavior sanitizer), to be assured > that they don't happen, at least when running all Vim tests, > and when fuzzing vim. > > Dominique In this particular case, since incrementation starts at 0 and proceeds in steps of +1, and the condition is "less than", not "(not) greater than", overflow can never happen in this loop anyway, not even if debug_backtrace_level happened (as unlikely as it might seem to me) to be the maximum possible positive value for its type (assuming i has the same type): the loop exit will be triggered when i becomes equal to debug_backtrace_level, or immediately if for some reason debug_backtrace_level were negative. On Linux64, where I neither modify the makefiles (my configure arguments are set by means of environment variables) nor bother with optimization levels, the src/Makefile calls gcc with -O2 and IIUC that's why I never got this warning. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.1.0168
On Sun, Jul 8, 2018 at 5:57 PM, Bram Moolenaar wrote: > > Patch 8.1.0168 > Problem:Output of :marks is too short with multi-byte chars. (Tony > Mechelynck) > Solution: Get more bytes from the text line. > Files: src/mark.c, src/testdir/test_marks.vim I confirm that this makes the problem disappear. Now :marks truncates all long lines at the same screen column, leaving one blank column at far right and (except in the title line) one blank column before the mark name at far left. The result is quite nice. Thanks Bram! Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: :marks truncation
On Sun, Jul 8, 2018 at 3:29 PM, Bram Moolenaar wrote: > > Tony wrote: > >> When typing ":marks" in a file with long lines, I notice that the text >> of the marked lines is truncated after a number of _bytes_ (including >> line number etc.) equal to the 'columns' setting; in partly non-ASCII >> text (and for example in my Russian dictionary mixing Russian >> (Cyrillic) and French (Latin) text with occasionally UTF-8 punctuation >> marks like em-dash or horizontal ellipsis) this gives marked text of >> apparently fluctuating width, because the "column" (i.e. byte number) >> differs from the "virtual column" (i.e. screen cell number) in >> function of the number of non-ASCII characters (each "trailer byte" >> 0x80..0xBF in their UTF-8 representation shortens by one column the >> length of the displayed text). I didn't check what happens if the >> concerned text includes hard tabs, which may _increase_ the screen >> cell number by respect to the byte number. >> >> Seen in Big gvim 8.1.164 with GTK2 GUI, not tested in other builds. >> >> Bug or feature? > > I cannot reproduc it. If I add multi-byte character in a line and type > ":marks", the mark for that line spans almost to the rightmost column. > It appears to be counting screen cells, not bytes. > It could be related to ambiguous width perhaps? Try changing the > 'ambiwidth' option. > 'ambiwidth' is set to its default of "single" and I use no CJK characters; I think there are no ambiguous-width characters either; but I have a lot of Cyrillic text (this is a Russian-French dictionary, after all) and the problem is most apparent with marks in column 1 (and, of course, on lines that exceed the screen width). See for instance one of my pages, not too long but with some long lines: http://users.skynet.be/antoine.mechelynck/slovarj/ru-fr.06.html — try setting marks a, b, c, etc. at far left of some lines that exceed your screen width, then see what ":marks" displays. Most lines start with and end with which should tel you which ones were truncated. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
:marks truncation
When typing ":marks" in a file with long lines, I notice that the text of the marked lines is truncated after a number of _bytes_ (including line number etc.) equal to the 'columns' setting; in partly non-ASCII text (and for example in my Russian dictionary mixing Russian (Cyrillic) and French (Latin) text with occasionally UTF-8 punctuation marks like em-dash or horizontal ellipsis) this gives marked text of apparently fluctuating width, because the "column" (i.e. byte number) differs from the "virtual column" (i.e. screen cell number) in function of the number of non-ASCII characters (each "trailer byte" 0x80..0xBF in their UTF-8 representation shortens by one column the length of the displayed text). I didn't check what happens if the concerned text includes hard tabs, which may _increase_ the screen cell number by respect to the byte number. Seen in Big gvim 8.1.164 with GTK2 GUI, not tested in other builds. Bug or feature? Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.1.0162
P.S. I wonder why the Italian manpages, but not those in other languages, have the "executable" bit set (-rwxr-xr-x 0755 rather than -rw-r--r-- 0644 like all the others). Maybe they were originally produced on DOS/Windows, where there is no such thing as an "execute" permission? Both .info files (help.txt.info and vim.man.info) have it also. All this is in the runtime/doc/ directory. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.1.0162
On Sat, Jul 7, 2018 at 10:27 PM, Bram Moolenaar wrote: > > Patch 8.1.0162 > Problem:Danish and German man pages are not installed. (Tony Mechelynck) > Solution: Adjust the makefile > Files: src/Makefile After applying this patch, then running "make" (apparently unneeded) and "make install" I get a lot of "No such file or directory" errors from sed, cp and chmod in the first part (only) of installing the Danish and German manpages, see below. Maybe I did something wrong but I can't guess what. Oh, and the listing excerpt below is from running "make install" in my src/shadow-huge/ directory but I get the same errors from "make install-languages" in the src/ directory one step higher. Best regards, Tony. /bin/sh ./installman.sh install /usr/local/share/man/da/man1 "-da" /usr/local/share/vim /usr/local/share/vim/vim81 /usr/local/share/vim ../runtime/doc 644 vim vimdiff evim installing /usr/local/share/man/da/man1/vim.1 sed: can't read ../runtime/doc/vim-da.1: No such file or directory installing /usr/local/share/man/da/man1/vimtutor.1 sed: can't read ../runtime/doc/vimtutor-da.1: No such file or directory installing /usr/local/share/man/da/man1/vimdiff.1 cp: cannot stat '../runtime/doc/vimdiff-da.1': No such file or directory chmod: cannot access '/usr/local/share/man/da/man1/vimdiff.1': No such file or directory installing /usr/local/share/man/da/man1/evim.1 sed: can't read ../runtime/doc/evim-da.1: No such file or directory /bin/sh ./installman.sh install /usr/local/share/man/da.ISO8859-1/man1 "-da" /usr/local/share/vim /usr/local/share/vim/vim81 /usr/local/share/vim ../runtime/doc 644 vim vimdiff evim installing /usr/local/share/man/da.ISO8859-1/man1/vim.1 sed: can't read ../runtime/doc/vim-da.1: No such file or directory installing /usr/local/share/man/da.ISO8859-1/man1/vimtutor.1 sed: can't read ../runtime/doc/vimtutor-da.1: No such file or directory installing /usr/local/share/man/da.ISO8859-1/man1/vimdiff.1 cp: cannot stat '../runtime/doc/vimdiff-da.1': No such file or directory chmod: cannot access '/usr/local/share/man/da.ISO8859-1/man1/vimdiff.1': No such file or directory installing /usr/local/share/man/da.ISO8859-1/man1/evim.1 sed: can't read ../runtime/doc/evim-da.1: No such file or directory /bin/sh ./installman.sh install /usr/local/share/man/da.UTF-8/man1 "-da.UTF-8" /usr/local/share/vim /usr/local/share/vim/vim81 /usr/local/share/vim ../runtime/doc 644 vim vimdiff evim installing /usr/local/share/man/da.UTF-8/man1/vim.1 sed: can't read ../runtime/doc/vim-da.UTF-8.1: No such file or directory installing /usr/local/share/man/da.UTF-8/man1/vimtutor.1 sed: can't read ../runtime/doc/vimtutor-da.UTF-8.1: No such file or directory installing /usr/local/share/man/da.UTF-8/man1/vimdiff.1 cp: cannot stat '../runtime/doc/vimdiff-da.UTF-8.1': No such file or directory chmod: cannot access '/usr/local/share/man/da.UTF-8/man1/vimdiff.1': No such file or directory installing /usr/local/share/man/da.UTF-8/man1/evim.1 sed: can't read ../runtime/doc/evim-da.UTF-8.1: No such file or directory /bin/sh ./installman.sh install /usr/local/share/man/de/man1 "-de" /usr/local/share/vim /usr/local/share/vim/vim81 /usr/local/share/vim ../runtime/doc 644 vim vimdiff evim installing /usr/local/share/man/de/man1/vim.1 installing /usr/local/share/man/de/man1/vimtutor.1 sed: can't read ../runtime/doc/vimtutor-de.1: No such file or directory installing /usr/local/share/man/de/man1/vimdiff.1 cp: cannot stat '../runtime/doc/vimdiff-de.1': No such file or directory chmod: cannot access '/usr/local/share/man/de/man1/vimdiff.1': No such file or directory installing /usr/local/share/man/de/man1/evim.1 sed: can't read ../runtime/doc/evim-de.1: No such file or directory /bin/sh ./installman.sh install /usr/local/share/man/de.ISO8859-1/man1 "-de" /usr/local/share/vim /usr/local/share/vim/vim81 /usr/local/share/vim ../runtime/doc 644 vim vimdiff evim installing /usr/local/share/man/de.ISO8859-1/man1/vim.1 installing /usr/local/share/man/de.ISO8859-1/man1/vimtutor.1 sed: can't read ../runtime/doc/vimtutor-de.1: No such file or directory installing /usr/local/share/man/de.ISO8859-1/man1/vimdiff.1 cp: cannot stat '../runtime/doc/vimdiff-de.1': No such file or directory chmod: cannot access '/usr/local/share/man/de.ISO8859-1/man1/vimdiff.1': No such file or directory installing /usr/local/share/man/de.ISO8859-1/man1/evim.1 sed: can't read ../runtime/doc/evim-de.1: No such file or directory /bin/sh ./installman.sh install /usr/local/share/man/de.UTF-8/man1 "-de.UTF-8" /usr/local/share/vim /usr/local/share/vim/vim81 /usr/local/share/vim ../runtime/doc 644 vim vimdiff evim installing /usr/local/share/man/de.UTF-8/man1/vim.1 installing /usr/local/share/man/de.UTF-8/man1/vimtutor.1 sed: can't read ../runtime/doc/vimtutor-de.UTF-8.1: No such file or directory installing /usr/local/share/man/de.UTF-8/man1/vi
Re: Patch 8.1.0160
On Sat, Jul 7, 2018 at 5:22 PM, Bram Moolenaar wrote: > > Patch 8.1.0160 > Problem:No Danish manual translations. > Solution: Add the Danish manual translations to the file list. > Files: Filelist Shouldn't the src/Makefile also be updated? AFAICT, by both looking into the src/Makefile and at the output of (Huge) "make install", only French, Italian, Japanese, Polish and Russian manuals get installed (usually in several charsets each). (And this is not due to an outdated src/shadow-huge/Makefile because I have intentionally replaced the latter by a symlink to its namesake in the parent src directory, rather than a copy which would get outdated.) (search on /DEST_MAN_FR\>/ and look above and below it wherever it is found) Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [PATCH] Copy Make_all.mak to SHADOWDIR
On Thu, Jul 5, 2018 at 11:46 AM, Elimar Riesebieter wrote: > * Tony Mechelynck [2018-07-05 11:39 +0200]: > >> On Thu, Jul 5, 2018 at 11:30 AM, Elimar Riesebieter >> wrote: >> > * Tony Mechelynck [2018-07-05 09:49 +0200]: >> > >> > [...] >> > >> >> Since there is no reason a user would modify the Make_all.mak, a link >> >> is enough (like for most other sources) -- see attached patch. >> > >> > Shouldn't there be a slash at '..Make_all.mak .' ? >> >> Oops, yes, there should. I attach the revised patch. Proof of the >> well-known fact that every patch should be checked by at least one >> pair of eyes in addition to those of its author. > > Applying the patch and fire up a compilerun would be a good test... In this case I would need to create a new shadow directory and _then_ compile: let's say (since I already have a shadow-huge and a shadow-tiny) hg qpush cd src SHADOWDIR='shadow-normal' make -e shadow cd shadow-normal # let's build the environment for "normal" compiles, including VIM_NAME = vim-normal to tell it apart from vi (tiny) and vim (huge) vim myconfig source ./myconfig # since we haven't yet configured, make with no arguments will configure and compile make # no need to reinstall the runtime files, those of Huge are OK make installvimbin vim-normal --version cd ../.. hg qpop "make shadow" runs configure, which I don't want yet; this implies that it ran "make config" implicitly. I don't know how to avoid that. I build a "normal" gvim, with GUI but otherwise very simplified from my "huge" gvim, as follows: export CONF_OPT_GUI='--enable-gui=gnome2' export CONF_OPT_MULTIBYTE='--enable-multibyte' export CONF_OPT_AUTOSERVE='--enable-autoservername' export CONF_OPT_FEAT='--with-features=normal' export CONF_OPT_COMPBY='"--with-compiledby=antoine.mechely...@gmail.com"' export CONF_ARGS='--with-vim-name=vim-normal' Oh, and before compiling I intentionally replace config.mk.dist and Makefile by lilnks rather than copies in the shadow dir: this way they will pick up any future changes in their counterparts one level up in src/ -- as follows: ln -svft . ../config.mk.dist ../Makefile After "make", before "make install" the executable is named "vim", not "vim-normal", let's run "make reconfig" but this time with logging. configure didn't get its --with-vim-name argument! Let's swap the last two lines of the config file and source it again... it works! And yet export CONF_ARGS='--with-vim-name=vi' works as the last line of the Tiny build... Here is the output of "vim-normal --version": linux-2iyu:~ # vim-normal --version VIM - Vi IMproved 8.1 (2018 May 18, compiled Jul 5 2018 13:41:48) Included patches: 1-152 Compiled by antoine.mechely...@gmail.com Normal version with GTK2-GNOME GUI. Features included (+) or not (-): +acl -farsi -mouse_sgr -tag_any_white -arabic+file_in_path -mouse_sysmouse-tcl +autocmd +find_in_path -mouse_urxvt -termguicolors +autoservername+float +mouse_xterm -terminal +balloon_eval +folding +multi_byte+terminfo -balloon_eval_term -footer+multi_lang+termresponse +browse+fork()-mzscheme +textobjects +builtin_terms +gettext +netbeans_intg +timers +byte_offset -hangul_input +num64 +title +channel +iconv +packages +toolbar +cindent +insert_expand +path_extra+user_commands +clientserver +job -perl -vartabs +clipboard +jumplist +persistent_undo +vertsplit +cmdline_compl -keymap+postscript+virtualedit +cmdline_hist +lambda+printer +visual +cmdline_info -langmap -profile +visualextra +comments +libcall -python+viminfo -conceal +linebreak -python3 +vreplace +cryptv+lispindent+quickfix +wildignore -cscope+listcmds +reltime +wildmenu +cursorbind+localmap -rightleft +windows +cursorshape -lua -ruby +writebackup +dialog_con_gui+menu +scrollbind+X11 +diff +mksession +signs -xfontset +digraphs +modify_fname +smartindent +xim +dnd +mouse +startuptime +xpm -ebcdic+mouseshape+statusline+xsmp_interact -emacs_tags-mouse_dec -sun_workshop +xterm_clipboard +eval +mouse_gpm +syntax+xterm_save +ex_extra
Re: [PATCH] Copy Make_all.mak to SHADOWDIR
On Thu, Jul 5, 2018 at 11:30 AM, Elimar Riesebieter wrote: > * Tony Mechelynck [2018-07-05 09:49 +0200]: > > [...] > >> Since there is no reason a user would modify the Make_all.mak, a link >> is enough (like for most other sources) -- see attached patch. > > Shouldn't there be a slash at '..Make_all.mak .' ? Oops, yes, there should. I attach the revised patch. Proof of the well-known fact that every patch should be checked by at least one pair of eyes in addition to those of its author. > > Elimar Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. # HG changeset patch # Parent 5b8606d91016c548240f348191933e0e3527388e Add Make_all.mak to target "shadow" diff --git a/src/Makefile b/src/Makefile --- a/src/Makefile +++ b/src/Makefile @@ -2676,17 +2676,17 @@ clean celan: testclean fi # Make a shadow directory for compilation on another system or with different # features. SHADOWDIR = shadow shadow: runtime pixmaps $(MKDIR_P) $(SHADOWDIR) - cd $(SHADOWDIR); ln -s ../*.[chm] ../*.in ../*.sh ../*.xs ../*.xbm ../gui_gtk_res.xml ../toolcheck ../proto ../libvterm ../vimtutor ../gvimtutor ../install-sh . + cd $(SHADOWDIR); ln -s ../*.[chm] ../*.in ../*.sh ../*.xs ../*.xbm ../gui_gtk_res.xml ../toolcheck ../proto ../libvterm ../vimtutor ../gvimtutor ../install-sh ../Make_all.mak . mkdir $(SHADOWDIR)/auto cd $(SHADOWDIR)/auto; ln -s ../../auto/configure . $(MKDIR_P) $(SHADOWDIR)/po cd $(SHADOWDIR)/po; ln -s ../../po/*.po ../../po/*.mak ../../po/*.vim ../../po/Makefile . cd $(SHADOWDIR); rm -f auto/link.sed cp Makefile configure $(SHADOWDIR) rm -f $(SHADOWDIR)/auto/config.mk $(SHADOWDIR)/config.mk.dist cp config.mk.dist $(SHADOWDIR)/auto/config.mk
Re: [PATCH] Copy Make_all.mak to SHADOWDIR
On Thu, Jul 5, 2018 at 8:06 AM, Elimar Riesebieter wrote: > To build vim in SHADOWDIR we need to copy Make_all.mak as well to > $(SHADOWDIR). > > --- > src/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/Makefile b/src/Makefile > index 2c4421ee2..016046fd5 100644 > --- a/src/Makefile > +++ b/src/Makefile > @@ -2687,7 +2687,7 @@ shadow: runtime pixmaps > $(MKDIR_P) $(SHADOWDIR)/po > cd $(SHADOWDIR)/po; ln -s ../../po/*.po ../../po/*.mak ../../po/*.vim > ../../po/Makefile . > cd $(SHADOWDIR); rm -f auto/link.sed > - cp Makefile configure $(SHADOWDIR) > + cp Makefile Make_all.mak configure $(SHADOWDIR) > rm -f $(SHADOWDIR)/auto/config.mk $(SHADOWDIR)/config.mk.dist > cp config.mk.dist $(SHADOWDIR)/auto/config.mk > cp config.mk.dist $(SHADOWDIR) > -- > 2.18.0 Since there is no reason a user would modify the Make_all.mak, a link is enough (like for most other sources) -- see attached patch. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. # HG changeset patch # Parent 5b8606d91016c548240f348191933e0e3527388e Add Make_all.mak to target "shadow" diff --git a/src/Makefile b/src/Makefile --- a/src/Makefile +++ b/src/Makefile @@ -2676,17 +2676,17 @@ clean celan: testclean fi # Make a shadow directory for compilation on another system or with different # features. SHADOWDIR = shadow shadow: runtime pixmaps $(MKDIR_P) $(SHADOWDIR) - cd $(SHADOWDIR); ln -s ../*.[chm] ../*.in ../*.sh ../*.xs ../*.xbm ../gui_gtk_res.xml ../toolcheck ../proto ../libvterm ../vimtutor ../gvimtutor ../install-sh . + cd $(SHADOWDIR); ln -s ../*.[chm] ../*.in ../*.sh ../*.xs ../*.xbm ../gui_gtk_res.xml ../toolcheck ../proto ../libvterm ../vimtutor ../gvimtutor ../install-sh ..Make_all.mak . mkdir $(SHADOWDIR)/auto cd $(SHADOWDIR)/auto; ln -s ../../auto/configure . $(MKDIR_P) $(SHADOWDIR)/po cd $(SHADOWDIR)/po; ln -s ../../po/*.po ../../po/*.mak ../../po/*.vim ../../po/Makefile . cd $(SHADOWDIR); rm -f auto/link.sed cp Makefile configure $(SHADOWDIR) rm -f $(SHADOWDIR)/auto/config.mk $(SHADOWDIR)/config.mk.dist cp config.mk.dist $(SHADOWDIR)/auto/config.mk
Re: [vim/vim] Possibly missing evim.man file (#3151)
On Wed, Jul 4, 2018 at 2:33 AM, scootergrisen wrote: > How come the other files have a .man file but not evim? On my system, where there is an own-compiled Vim 8.1 (8.1.146 as of this writing) and (further down the $PATH) a Vim 8.0.1568 from my Linux distro, I see at the bottom "2006 Apr 11" in the manpage for vim but "2002 February 16" in the manpage for evim. This might be due to a missing symlink since even "man vi" displays the manpage for Vim, where evim is mentioned as an alternative executable name near the top. Both these dates, however, look suspiciously old to me. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Error when trying to compile vim with statically linked python
I don't have this problem on Linux. Is it MinGW (or MinGW-x64)-only or does it also happen on other configurations? My Huge Vim (8.1.136 as of this writing) is configured with static Python (2.7.14 as distributed with openSUSE 15.0), and my gcc version is 7.3.1 (also distributed with openSUSE 15.0). Here are my configure arguments, as set in the shell where I run 'make' and 'make install': export CONF_OPT_GUI='--enable-gui=gnome2' export CONF_OPT_PERL='--enable-perlinterp' export CONF_OPT_PYTHON='--enable-pythoninterp' export CONF_OPT_PYTHON3='--disable-python3interp' export CONF_OPT_TCL='--enable-tclinterp' # /usr/bin/tclsh (softlink) is correctly set export CONF_OPT_RUBY='--enable-rubyinterp' export CONF_OPT_LUA='--enable-luainterp' export CONF_OPT_MZSCHEME='--disable-mzschemeinterp' #export CONF_OPT_PLTHOME='--with-plthome=/usr/local/plt' export CONF_OPT_CSCOPE='--enable-cscope' export CONF_OPT_MULTIBYTE='--enable-multibyte' export CONF_OPT_TERMINAL='--enable-terminal' export CONF_OPT_AUTOSERVE='--enable-autoservername' export CONF_OPT_FEAT='--with-features=huge' export CONF_OPT_COMPBY='"--with-compiledby=antoine.mechely...@gmail.com"' No problems compiling, linking and running this Vim, both as gvim and in a konsole window. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.1.0128
On Sun, Jul 1, 2018 at 2:59 AM, John Little wrote: > On Sunday, July 1, 2018 at 2:28:04 AM UTC+12, Bram Moolenaar wrote: >> Patch 8.1.0128 > > Just noticed version.c on github doesn't have patch number 128. No effect, > other than a little confusion. > > Regards, John Little Nor does it on the Mercurial mirror: I hadn't noticed, but now that you mention it, with all patches so far I see: Included patches: 1-127, 129-133 Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Visual Studio 2017 fails to compile one of six Vims...
On Thu, Jun 28, 2018 at 11:34 PM, tux. wrote: > As some of you might know, I provide my own Windows Vim builds. My > latest hardware upgrade brought a new infrastructure though. > > I usually compile six Vims in a row: > > - x86 GVim without OLE > - x86 GVim with OLE > - x86 CLI Vim > - the same for amd64 > > Now I get these errors _exclusively_ with x86 GVim with OLE: > >>Bibliothek "gvim.lib" und Objekt "gvim.exp" werden erstellt. >> msvcrt.lib(initializers.obj) : warning LNK4098: Standardbibliothek >> "libcmt.lib" steht in Konflikt mit anderen Bibliotheken; >> /NODEFAULTLIB:Bibliothek verwenden. >> misc1.obj : error LNK2001: Nicht aufgelöstes externes Symbol >> "_default_vim_dir". >> misc1.obj : error LNK2001: Nicht aufgelöstes externes Symbol >> "_default_vimruntime_dir". >> version.obj : error LNK2001: Nicht aufgelöstes externes Symbol >> "_compiled_user". >> version.obj : error LNK2001: Nicht aufgelöstes externes Symbol >> "_compiled_sys". >> version.obj : error LNK2001: Nicht aufgelöstes externes Symbol "_all_lflags". >> version.obj : error LNK2001: Nicht aufgelöstes externes Symbol "_all_cflags". >> gvim.exe : fatal error LNK1120: 6 nicht aufgelöste Externe > > Why? - Or, more precisely, why does _only_ this build fail, the other > five don't? > > My compilation script: > https://tuxproject.de/projects/vim/_compile.bat.php > > (It is the second x86 compilation...) > > What am I missing? > > TIA! Hm, it's been a long time since I last used Windows, and a lot may have changed. However, IIUC you say you get those errors only when compiling 32-bit gvim with OLE, and not on any of your other builds, not even 64-bit gvim with OLE. So the question arises: do you have the correct software installed (including headers) to compile and link with 32-bit OLE? Is 32-bit OLE even supported by your newly upgraded system? Or does it maybe require an optional package, SDK, or something, which isn't yet installed? Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Command to get the help translations file and set language
Shouldn't the translated help files be (like the translated menu and messages files already are) part of Vim's version control system, i.e. shouldn't they live somewhere on Vim's git server (and therefore on its Mercurial mirror)? Then "make installruntime" (and therefore "make install") would install them like it already installs the .mo files and the translated menu files. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.1.0115
On Mon, Jun 25, 2018 at 12:06 AM, Bram Moolenaar wrote: > > Patch 8.1.0115 > Problem:The matchparen plugin may throw an error. > Solution: Change the skip argument from zero to "0". > Files: runtime/plugin/matchparen.vim Nit: We forgot to bump line 3, it still says «" Last Change: 2017 Sep 30». Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Error in matchparen.vim after applying patches 8.1.111 to 113 + runtime files
On Sun, Jun 24, 2018 at 11:36 PM, Christian Brabandt wrote: > > On So, 24 Jun 2018, Tony Mechelynck wrote: > >> It doesn't even apply. Here are my lines 115-130 of that script, > > I wonder why? I made the change against the repository version. The version I have is dated 2017 Sep 30 and hg annotate tells me that that particular line was last changed in changeset 0fe7765dcb8e (the first of two changesets with description «updated for version 7.0f03»; tag v7.0f03 is the next one). AFAIK it is the latest version in your Mercurial repository; other changes are more recent, e.g. line 3 (the Date Changed line) was last changed in "Long overdue runtime update" 3b26420fc639 between v8.0.1255 and v8.0.1256 Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Error in matchparen.vim after applying patches 8.1.111 to 113 + runtime files
On Sun, Jun 24, 2018 at 10:21 PM, Christian Brabandt wrote:
>
> On So, 24 Jun 2018, Tony Mechelynck wrote:
>
>> At startup from a handcoded Session.vim I get this error (which I
>> didn't get before with the same session script)
>>
>> Error detected while processing function 24_Highlight_Matching_Pair:
>> line 97:
>> E475: Invalid argument: 0
>>
>> I get this several times, including when clicking the statusline of a
>> non-current window to make it current.
>> Script 24 (as listed by :scriptnames) is
>> /usr/local/share/vim/vim81/plugin/matchparen.vim
>>
>> If I move the cursor, be it by keyboard or by mouse, I mostly don't
>> get this message, and the matching brackets are highlighted correctly.
>> However I do get it when the matched brackets are the first and last
>> characters on a line. For instance when the line is
>>
>>
>>
>> with 'matchpairs' set to (:),[:],{:},<:>
>
> Most likely patch 8.1.112.
>
> Can you try, if the following patch works for you?
>
> diff --git a/runtime/plugin/matchparen.vim b/runtime/plugin/matchparen.vim
> index 2b2392dfc..ad3113ce7 100644
> --- a/runtime/plugin/matchparen.vim
> +++ b/runtime/plugin/matchparen.vim
> @@ -116,10 +116,10 @@ function! s:Highlight_Matching_Pair()
>" outside of the syntax types and s_skip should keep its value so we skip
> any
>" matching pair inside the syntax types.
>if !has("syntax") || !exists("g:syntax_on")
> -let s:skip = 0
> +let s_skip = '0'
>else
> try
> - execute 'if' s_skip '| let s_skip = 0 | endif'
> + execute 'if' s_skip '| let s_skip = "0" | endif'
> catch /^Vim\%((\a\+)\)\=:E363/
>" We won't find anything, so skip searching, should keep Vim
> responsive.
>return
>
>
> Best,
> Christian
It doesn't even apply. Here are my lines 115-130 of that script,
_after_ applying the very latest runtime files update (which happened
just before I had the problem):
- start
" outside of the syntax types and s_skip should keep its value so we skip any
" matching pair inside the syntax types.
execute 'if' s_skip '| let s_skip = 0 | endif'
" Limit the search to lines visible in the window.
let stoplinebottom = line('w$')
let stoplinetop = line('w0')
if i % 2 == 0
let stopline = stoplinebottom
else
let stopline = stoplinetop
endif
" Limit the search time to 300 msec to avoid a hang on very long lines.
" This fails when a timeout is not supported.
- end
So let's try putting quotes around the zero on my line 117, with no
other change. Since that is inside single quotes, we'll use double
quotes there.
=> the error disappears.
I'll attach the diff.
Best regards,
Tony.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
matchpZero
Description: Binary data
Error in matchparen.vim after applying patches 8.1.111 to 113 + runtime files
At startup from a handcoded Session.vim I get this error (which I
didn't get before with the same session script)
Error detected while processing function 24_Highlight_Matching_Pair:
line 97:
E475: Invalid argument: 0
I get this several times, including when clicking the statusline of a
non-current window to make it current.
Script 24 (as listed by :scriptnames) is
/usr/local/share/vim/vim81/plugin/matchparen.vim
If I move the cursor, be it by keyboard or by mouse, I mostly don't
get this message, and the matching brackets are highlighted correctly.
However I do get it when the matched brackets are the first and last
characters on a line. For instance when the line is
with 'matchpairs' set to (:),[:],{:},<:>
Best regards,
Tony.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: i am such an ingrate, forgive me
On Sat, Jun 23, 2018 at 11:29 PM, Christ van Willegen wrote: > Do you have expandtabs set? That would explain this, I think... > > Christ van Willegen I haven't tried them yet, but I would expect :set vartabstop=4,20,10,8 to mean that hitting the tab key moves the cursor forward to the first one encountered among columns 5, 25, 35, 43, 51, 59, 67, 75, …, filling the intervening columns either with one hard tab (if 'noexpandtab') or with as many spaces as necessary (if 'expandtab'), similarly to what happened some 60 or so years ago when I set the tabs on the backside of the paper carriage guide of my Underwood typewriter, an old hand-me-down from my grandfather who had got himself a newer model. (That typewriter looked more or less like the one at https://commons.wikimedia.org/wiki/File:The_Childrens_Museum_of_Indianapolis_-_Typewriter.jpg and it had adjustable tabs.) Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.1.0104
On Sat, Jun 23, 2018 at 5:15 PM, Bram Moolenaar wrote: > > Patch 8.1.0104 > Problem:Can't build without the +eval feature. > Solution: Add #ifdef. > Files: src/regexp_nfa.c Now my Tiny build compiles again. Thanks Bram! Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.1.0102
On Sat, Jun 23, 2018 at 3:09 PM, Bram Moolenaar wrote: > > Patch 8.1.0102 > Problem:Cannot build without syntax highlighting. > Solution: Add #ifdef around using reg_do_extmatch. > Files: src/regexp.c After applying this patch, my Tiny build has two fewer errors compared with patch 98, but there is still this one: linux-2iyu:~/.build/vim/vim-hg/src/shadow-tiny # (make || echo 'exit status' $? ; date) 2>&1 |tee -a make.log gcc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -fno-strength-reduce -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1-o objects/regexp.o regexp.c In file included from regexp.c:8088:0: regexp_nfa.c: In function ‘nfa_regmatch’: regexp_nfa.c:5696:39: error: ‘nfa_fail_for_testing’ undeclared (first use in this function); did you mean ‘nfa_alt_listid’? && (nfa_listid >= NFA_MAX_STATES || nfa_fail_for_testing)) ^~~~ nfa_alt_listid regexp_nfa.c:5696:39: note: each undeclared identifier is reported only once for each function it appears in make: *** [Makefile:3285: objects/regexp.o] Error 1 exit status 2 Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.1.0098
On Sat, Jun 23, 2018 at 2:21 PM, Bram Moolenaar wrote: > > Patch 8.1.0098 > Problem:Segfault when pattern with \z() is very slow. > Solution: Check for NULL regprog. Add "nfa_fail" to test_override() to be > able to test this. Fix that 'searchhl' resets called_emsg. > Files: src/syntax.c, runtime/doc/eval.txt, src/evalfunc.c, src/vim.h, > src/testdir/test_syntax.vim, src/globals.h, src/screen.c, > src/regexp.c, src/regexp_nfa.c Compile failure for regexp_nfa.c and regexp.c in Tiny but not in Huge: gcc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -fno-strength-reduce -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1-o objects/regexp.o regexp.c In file included from regexp.c:8088:0: regexp_nfa.c: In function ‘nfa_regmatch’: regexp_nfa.c:5696:39: error: ‘nfa_fail_for_testing’ undeclared (first use in this function); did you mean ‘nfa_alt_listid’? && (nfa_listid >= NFA_MAX_STATES || nfa_fail_for_testing)) ^~~~ nfa_alt_listid regexp_nfa.c:5696:39: note: each undeclared identifier is reported only once for each function it appears in regexp.c: In function ‘vim_regexec_multi’: regexp.c:8381:6: error: ‘reg_do_extmatch’ undeclared (first use in this function); did you mean ‘ref_extmatch’? reg_do_extmatch = REX_ALL; ^~~ ref_extmatch regexp.c:8381:24: error: ‘REX_ALL’ undeclared (first use in this function); did you mean ‘HL_ALL’? reg_do_extmatch = REX_ALL; ^~~ HL_ALL make: *** [Makefile:3285: objects/regexp.o] Error 1 exit status 2 -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Warning when compiling 8.1.89 os_unix.c
On Thu, Jun 21, 2018 at 10:37 AM, Gary Johnson wrote: > On 2018-06-20, Gary Johnson wrote: >> On 2018-06-20, Bram Moolenaar wrote: >> > Gary Johnson wrote: >> > >> > > When compiling Vim 8.1.89 on an Ubuntu Linux system, I get the >> > > following warning. >> > > >> > > os_unix.c: In function ‘mch_signal_job’: >> > > os_unix.c:5851: warning: implicit declaration of function ‘getpgid’ >> > > >> > > I think that means that os_unixx.h should include something like >> > > this: >> > > >> > > #ifdef HAVE_GETPGID >> > > # include >> > > #endif >> > > >> > > but I'm not familiar enough with Vim's include strategy to know for >> > > sure. >> > >> > We already have this in os_unix.h: >> > >> > #ifdef HAVE_UNISTD_H >> > # include >> > #endif >> > >> > Perhaps you can check src/auto/config.log why unistd.h wasn't found. >> > Mine contains: >> > >> > configure:11078: checking unistd.h usability >> > configure:11078: gcc -c -g -Wall -Wextra -Wshadow -Wmissing-prototypes >> > -Wunreachable-code -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 conftest.c >&5 >> > configure:11078: $? = 0 >> > configure:11078: result: yes >> > configure:11078: checking unistd.h presence >> > configure:11078: gcc -E conftest.c >> > configure:11078: $? = 0 >> > configure:11078: result: yes >> > configure:11078: checking for unistd.h >> > configure:11078: result: yes >> >> Mine contains this, which, except for the gcc arguments, looks the same to >> me. >> >> configure:11078: checking unistd.h usability >> configure:11078: gcc -std=gnu99 -c -g -DFEAT_CONCEAL -DFEAT_MOUSE_SGR >> -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 conftest.c >&5 >> configure:11078: $? = 0 >> configure:11078: result: yes >> configure:11078: checking unistd.h presence >> configure:11078: gcc -std=gnu99 -E conftest.c >> configure:11078: $? = 0 >> configure:11078: result: yes >> configure:11078: checking for unistd.h >> configure:11078: result: yes >> >> I don't have an explanation at the moment. I'll try to look at it >> more this evening. > > For /usr/include/unistd.h to include a prototype for getpgid(), > __USE_XOPEN_EXTENDED must be defined, and in this system of mine, > it isn't. > > The man page for getpgid() says that _XOPEN_SOURCE >= 500 for > getpgid() to be declared. In my system, _XOPEN_SOURCE isn't > defined, either. > > My gcc version is 4.4.3, if that matters. > > Regards, > Gary Hm, the gcc command-line arguments produced by src/auto/configure seem highly variable: I have configure:11078: checking unistd.h usability configure:11078: gcc -c -O2 -fno-strength-reduce -Wall conftest.c >&5 configure:11078: $? = 0 configure:11078: result: yes configure:11078: checking unistd.h presence configure:11078: gcc -E conftest.c configure:11078: $? = 0 configure:11078: result: yes configure:11078: checking for unistd.h configure:11078: result: yes with gcc 7.3.1 and (as shown at the top of auto/config.log) Gnu Autoconf 2.69 IIUC, that _XOPEN_SOURCE number is a question of C dialect; and older gcc versions (as yours seem to be) didn't know about newer dialects. According to https://en.wikipedia.org/wiki/GNU_Compiler_Collection the current stable gcc version is 8.1 released 48 days ago, and 6.x is also supported (which IIUC means that 6.0 to 8.1 are supposed to be supported). Maybe you ought to find a newer gcc version. Or (depending on your OS release) maybe even a newer Ubuntu version: the current release is supposed to be Ubuntu 18.04 LTS "Bionic Beaver" released 56 days ago, and older versions 14.04 LTS "Trusty Tahr", 16.04 LTS "Xenial Xerus" and 17.10 "Artful Aardvark" are supposed still to be supported. Best regards, Tony. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.1.0078
On Wed, Jun 20, 2018 at 5:59 AM, Ken Takata wrote:
> Hi Bram,
>
> 2018/6/19 Tue 21:24:20 UTC+9 Bram Moolenaar wrote:
>> Patch 8.1.0078
>> Problem:"..." used inconsistently in messages.
>> Solution: Drop the space before " ...".
>> Files:src/spellfile.c, src/regexp_nfa.c
>
> One more fix is needed:
>
> --- a/src/regexp_nfa.c
> +++ b/src/regexp_nfa.c
> @@ -5620,7 +5620,7 @@ nfa_regmatch(
> }
> else
> {
> - EMSG(_("Could not open temporary log file for writing, displaying on
> stderr ... "));
> + EMSG(_("Could not open temporary log file for writing, displaying on
> stderr... "));
> log_fd = stderr;
> }
> #endif
>
>
> Regards,
> Ken Takata
HM, IIUC this implies a reissue of all .po files, which have just been
updated, because one more "from-string" has changed?
Best regards,
Tony.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [vim/vim] langremap doesn't work for Cyrillic letters (#3018)
On Tue, Jun 19, 2018 at 11:42 AM, Christian Brabandt
wrote:
> Hm, the macro that is responsible for the langmap feature is LANGMAP_ADJUST.
> I noticed it works on single bytes, e.g. what is in the input queue buffer.
> However the cyrillic character о ('о' U+043E Dec:1086 CYRILLIC SMALL LETTER
> O (o=) о) is stored inside the input buffer as the two bytes 0xd0 0xbe. And
> then the macro LANGMAP_ADJUST is called for each of that byte, however it
> won't find anything, since the code that parses and stores the langmap
> option, stores the unicode value 1086.
>
> It's a bit tricky to make this work, since the macro is called all over the
> code base and the getchar.c code is a bit fragile.
>
…And yet the very example about 'langmap' in
$VIMRUNTIME/doc/options.txt is in Unicode with Greek letters
represented in UTF-8 (Alpha 0xCE 0x91, Beta 0xCE 0x92, Psi 0xCE 0xA8,
etc.). I bet that a Greek user with a Greek keyboard would have the
same problems as Maxim if he tried to use the example in the help.
Best regards,
Tony.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
