Re: gvim and ASCII glyphs

[Kazunobu Kuriyama]

2016-08-09 6:35 GMT+09:00 manuelschiller.pimail via vim_dev <
vim_dev@googlegroups.com>:

> On Monday, 8 August 2016 22:27:11 UTC+2, Bram Moolenaar  wrote:
> > Manuel Schiller wrote:
> >
> > [...]
> >
> > > Concerning your request to send a patch that just fixes the assumption
> > > about "one ascii character == one glyph": One could either get rid of
> > > that speed optimisation code altogether (in which case all ligatures
> > > will work), or rewrite most of that optimisation, doing one shaping
> > > call into pango for each of (or some of) the characters with codes <
> > > 128. The latter versoin would amount to some overhead for all those
> > > calls, and reassembling the returned data structures in a suitable
> > > way...
> >
> > I don't see how it can work with a font where it is not true that each
> > ASCII character is one display cell.  E.g., when highlighting or drawing
> > the cursor.  If you draw some combination of two ASCII characters with
> > one double-wide glyph it's not possible to highlight half of it.
> >
> > It appears pango has no way to disable ligatures.
> >
> > So the table we create should work, putting in extra spaces to avoid the
> > shaping to take place.  But I don't see why we would be doing this only
> > for alphanumeric characters, this should work for all ASCII characters.
> >
> >
>
> Hi Bram,
>
> well, it seems I upset quite a bee's nest with this (much of which may be
> my own fault ;)...
>
> Neither patch nor the current vim code will work when one ASCII character
> translates to more than one display cell.
>
> But when you have a ligature between two characters, drawing a two-cell
> glyph might be considered an improvement by some. As to what happens when
> you change highlighting, or move the cursor across such a ligature:
> Currently, the redrawn character cell gets repainted with the
> "non-ligaturised" version of that single glyph, which results in the
> ligature partially reverting back to its component glyphs. Moving the
> cursor off, and a (partial) redraw like from pressing ^L causes the
> ligature glyph to reappear. It's not perfect, but it's consistent with the
> behaviour I've seen from e.g. putty and Konsole/qterminal (the latter two
> do their own metrics calculation, and get the spacing wrong if there's
> ligatures on the line - patched gvim doesn't do that, so I'm very happy
> with it ;).


putty, konsole, qterminal, and gvim...There's a obvious difference between
the first three and the last; the former are terminals and the latter is an
editor.

If you think of the difference of their usages, you'll notice that even
small hiccups on terminals could much matter on editors, in particular for
users who must have the cursor go to and fro to view and edit files for
hours.

That's something we should not underestimate, isn't that?  Probably, some
of the users wouldn't be patient enough to put up with it and would soon
file bug reports once your patch was merged into the upstream.

You mentioned that gvim has less issues than the terminals.  But that's is
a side effect of redrawing by gvim for its own necessity, not for the sake
of ligatures.

Your patch doesn't contain any code for that.  That has no redraw mechanism
to ensure ligatures to appear on the screen as/when they should.

I'm glad to hear, "patched gvim doesn't do that, so I'm very happy with
it:)."  But you should be aware that your happiness comes to you only by
accident or fortune, not by design or code.

The reason I'm sticking to monospace fonts comes here.  If we were making a
text viewer, your patch would be sufficient.  But actually what we are
making is an editor.  We have to address other issues such as the one you
mentioned above to make vim truly and decently support ligatures.  For that
purpose, the precondition that all fonts to be used are monospace, could be
helpful and make our work much simpler and easier.  After that, we could do
something about "effectively" monospace fonts if necessary, couldn't we?

By the way, why didn't you honestly talk to the people here about the issue
you've already noticed till now?  As you guessed, I didn't install the
fonts in question on my PC nor tried your patch, because I easily predicted
from the code that your patch had such an issue you mentioned above.
That's why I'm sticking to monospace; it's for getting us ready for
addressing possible other issues your patch has.  Not a pretext for
rejecting your patch on behalf of old-school people.

That said, it's OK for me to stop talking right now if you think I'm not
qualified for a reviewer because of those.  That helps me enjoy the coming
vacation without anything bothering me.


> My assertion is that people using these programming fonts will be happy to
> see these ligatures assemble/disassemble as they edit across them.
>

Once people view ligatures on Vim, they will ask us more for the purpose of
editing them in a way each individual thinks better...

Best,
Kazunobu


> Regarding your 

Re: [vim/vim] SEGV when run gvim in ubuntu 16.04 (#851)

[John Little]

On Tuesday, August 9, 2016 at 8:16:28 AM UTC+12, gschintgen wrote:
> Hi, I think my current Ubuntu installation is suffering from the same bug. 
> I'm on 16.04 (clean install) using the distribution-provided package: version 
> 7.4.1689-3ubuntu1.1.

> Fairly often (but not always) gvim crashes as soon as I launch it.

Which distro provided GUI are you running?  Ubuntu packages vim with GTK2 and 
GTK3.  IIUC GTK2 is the default, and you get GTK3 at /usr/bin/vim.gtk3

> The error output is the same as given by @tracyone.

I suspect that doesn't mean much, the output looks generic.

Regards, John Little

-- 
-- 
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.

getcompletion() and 'wildignore' setting

[Yegappan Lakshmanan]

Hi,

The getcompletion() function applies the 'wildignore' option setting and removes
all the entries matching the file patterns in 'wildignore'. Currently,
there is no way
to disable this. Do you think we should add a 'flag' argument to getcompletion()
to ignore/support 'wildignore'?

Thanks,
Yegappan

-- 
-- 
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] SEGV when run gvim in ubuntu 14.04 (#851)

[John Little]

On Wednesday, June 8, 2016 at 6:41:47 PM UTC+12, tracyone wrote:
> OS:ubuntu 16.04 x86-64
> I build vim from source by myself,build script is:
> ./configure \
> --with-features=huge \
> --with-compiledby="tracyone" \
> --enable-multibyte \
> --enable-gui=gtk3 \
> --enable-gpm \
> --enable-cscope \
> --enable-fontset \
> --enable-sniff \
> --enable-xim \
> --enable-fail-if-missing \
> --enable-pythoninterp=dynamic \
> --enable-fail-if-missing \
> --with-python-config-dir=/usr/lib/python2.7/config-x86_64-linux-gnu \
> --enable-python3interp=dynamic \
> --with-python3-config-dir=/usr/lib/python3.5/config-3.5m-x86_64-linux-gnu
> run any command in gvim will lead to SEGV

I'm on 16.04, so I had a go compiling with your options, with patches up to 
2187. configure said:

configure: WARNING: unrecognized options: --enable-sniff

I don't understand that, but anyway I compiled with make and vim -g runs ok.  I
did run
sudo apt-get build-dep vim-gtk3
and it pulled down some packages:
  gir1.2-atspi-2.0 gir1.2-gconf-2.0 gir1.2-gnomekeyring-1.0 icu-devtools
  libart-2.0-dev libatk-bridge2.0-dev libatspi2.0-dev libavahi-client-dev
  libavahi-common-dev libavahi-glib-dev libbonobo2-dev libbonoboui2-dev
  libdbus-1-dev libdrm-dev libegl1-mesa-dev libepoxy-dev libgail-common
  libgail-dev libgconf2-dev libgmp-dev libgmpxx4ldbl libgnome-keyring-dev
  libgnome2-dev libgnomecanvas2-dev libgnomeui-dev libgnomevfs2-dev
  libgnutls-dev libgnutlsxx28 libgtk-3-dev libicu-dev libidl-2-0 libidl-dev
  libidn11-dev libmirclient-dev libmircommon-dev libmircookie-dev
  libmircookie2 liborbit2 liborbit2-dev libp11-kit-dev libpopt-dev
  libprotobuf-dev libprotobuf9v5 libtasn1-6-dev libwayland-dev libx11-xcb-dev
  libxcb-dri2-0-dev libxcb-dri3-dev libxcb-glx0-dev libxcb-present-dev
  libxcb-randr0-dev libxcb-shape0-dev libxcb-sync-dev libxcb-xfixes0-dev
  libxkbcommon-dev libxml2-dev libxshmfence-dev libxtst-dev libxxf86vm-dev
  nettle-dev orbit2 ruby-dev ruby2.3-dev x11proto-dri2-dev x11proto-gl-dev
  x11proto-record-dev x11proto-xf86vidmode-dev

I've been building fine with GTK2 without that lot.

My :ver says
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK  -pthread -I/usr/
include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/
include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/gtk
-3.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/mirclient -I/usr/include/mircom
mon -I/usr/include/mircookie -I/usr/include/cairo -I/usr/include/pango-1.0 -I/us
r/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/includ
e/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12
 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng12 -I/usr/include/glib-2.0 -
I/usr/lib/x86_64-linux-gnu/glib-2.0/include   -g -O2 -DCANBERRA -Wall -Wextra -W
missing-prototypes -Wunreachable-code -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
 -D_REENTRANT
Linking: gcc   -L/usr/local/lib -Wl,--as-needed -o vim   -lgtk-3 -lgdk-3 -lpango
cairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2
.0 -lgobject-2.0 -lglib-2.0 -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE  -lm
-ltinfo -lnsl  -lselinux   -lacl -lattr -lgpm -ldl -lcanberra

(Ignore the canberra stuff, I don't like the GTK bell so have coded in my own. 
Canberra needs -D_REENTRANT.)

HTH, and regards, John Little

-- 
-- 
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: Wish list for a more powerful search in Vim

[Yegappan Lakshmanan]

Hi Christian,

On Wed, Aug 3, 2016 at 3:58 PM, Yegappan Lakshmanan  wrote:
>>> >> >
>>> >> >> I think it should.  Most users will have 'wrapscan' on, since it is 
>>> >> >> the
>>> >> >> default.  If someone switches it off he must have a reason for it.
>>> >> >
>>> >> > okay, fixed with the latest version
>>> >> >
>>> >>
>>> >> I tested the latest patch and the confirmed that the problems I reported 
>>> >> earlier
>>> >> are fixed. I saw some new issues. Take the following text:
>>> >>
>>> >>   1
>>> >>   2 these
>>> >>   3 the
>>> >>   4 their
>>> >>   5 there
>>> >>   6 their
>>> >>   7 the
>>> >>   8 them
>>> >>   9 these
>>> >>
>>> >> The cursor is in line 1 and I have 'nowrapscan' set. I search for "the" 
>>> >> and
>>> >> press CTRL-N 7 times and "the" in "these" is highlighted. Now I press
>>> >> CTRL-L to copy "s" and then erase it. Now if I press CTRL-P, I expect
>>> >> that the cursor will move to line 8. Instead the cursor moves to line 7.
>>> >>
>>> >> Another problem: Place the cursor in line 1. Enter "/thes" and then press
>>> >> CTRL-N. The "thes" in line 9 is highlighted. Now if you press backspace,
>>> >> the cursor jumps back to line 3. I expected that the cursor will remain
>>> >> in line 9.
>>> >
>>> > Thanks, will look at these and add some tests.
>>> >
>>> >> I think, the CTRL-N and CTRL-P should respect the search direction.
>>> >> For example, if I search a pattern using "?text", pressing CTRL-N
>>> >> should search backwards. Currently CTRL-N always searches
>>> >> forward (irrespective of the search direction). Note that this is
>>> >> different from how "n" and "N" work.
>>> >
>>> > Please don't make me do this. Currently the inconsistent search
>>> > direction is one of my biggest annoyances of Vim. I really really really
>>> > hate it, that I can't rely on the fact that N searches backwards and n
>>> > forward.
>>> >
>>>
>>> I don't have any preference between the two options. I was just pointing
>>> out the deviation from the behavior of 'n' and 'N' commands.
>>
>> I attach an updated patch, which fixes all issues mentioned so far.
>> Additionally I added a test for this.
>>
>
> I can confirm that this patch fixes all the issues reported so far.
> I played around with CTRL-N and CTRL-P at the search prompt
> for some time and didn't find any issues.
>

I found a problem with searching for a pattern in a single line if
the pattern appears more than once in the line. Example:

some text some text

In the above line with the cursor at the beginning of the line,
search for "text", press  and then press .
The expected behavior is for the cursor to be placed at the
first "text". But the cursor is not moved and is still placed
at the second "text".

If the pattern appears in a different line, then the problem is
not seen. Example:

some text
some text

- Yegappan

>
>>
>> I will be away the next 2-3 weeks, so won't have time to work on this
>> further. However, I'd appreciate feedback and will work further on it
>> after I return, if there are more issues.
>>
>> Oh and before I forget to mention it. I made Ctrl-N always go further
>> down and Ctrl-P always go further up and I don't intend to change that.
>>

-- 
-- 
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: Quickfix List vs Location List

[Yegappan Lakshmanan]

Hi,

On Mon, Aug 8, 2016 at 10:04 AM, Nikolay Aleksandrovich Pavlov
 wrote:
> 2016-08-08 19:44 GMT+03:00 LCD 47 :
>> On 8 August 2016, Kent Sibilev  wrote:
>>> On Monday, August 8, 2016 at 4:03:22 AM UTC-4, LCD 47 wrote:
>>>
>>> >
>>> > Wait, isn't the title already supposed to tell you that?
>>> >
>>>
>>> What do you mean by title?
>>
>> From the manual (":h :copen"):
>>
>> : The window will have the w:quickfix_title variable set
>> : which will indicate the command that produced the
>> : quickfix list. This can be used to compose a custom
>> : status line if the value of 'statusline' is adjusted
>> : properly.
>>
>> By default the status line of the quickfix open shows "[Quickfix
>> List]" or "[Location List]", followed by the w:quickfix_title variable
>> described above.  Some of the plugins that customize status lines choose
>> to ignore that information.  I don't think this is something that needs
>> to be fixed in Vim.
>
> w:quickfix_title cannot be used: e.g. install
> https://github.com/rking/ag.vim and run `:Ag -w test` then `:LAg -w
> test`. If you use :copen and :lopen then you will see that in both
> cases `w:quickfix_title` is `:ag --vimgrep -w test`: completely
> useless.
>
> `[Quickfix List]` vs `[Location List]` can neither be used because
> they are translated as Bram said. Also parsing anything to get this
> information sounds like a bad idea.
>
> ---
>
> By the way, I remember some patches that add functions returning
> information about buffer/window/tabpage. It would be logical if
> information regarding whether given buffer contains
> quickfix/location/no list was included there.
>

I agree. The patch to get information about a buffer/window/tab page
is at:

https://github.com/vim/vim/pull/833

The information about the quickfix/location list window/buffer can be
added to this patch.

Another alternative is the patch I sent two weeks ago to extend the
getqflist() and getloclist() functions. The returned dictionary contains
the 'winid' key which has the window ID of the quickfix or location
list window.

- Yegappan

-- 
-- 
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] file encoding detection doesn't work with process substitution

[Ken Takata]

Hi,

2016/8/9 Tue 5:27:12 UTC+9 Bram Moolenaar wrote:
> Ken Takata wrote:
> 
> > 2016/8/6 Sat 22:30:05 UTC+9 Bram Moolenaar wrote:
> > > Ken Takata wrote:
> > > 
> > > > When process substitution (e.g. "<(cmd)") is used on bash (or zsh), file
> > > > encoding detection doesn't work, and an empty buffer is opened.
> > > > E.g.:
> > > > 
> > > >   $ vim -u NONE --cmd "set fencs=cp932,utf-8" <(echo テスト)
> > > >   # Assuming the system encoding is utf-8.
> > > > 
> > > > Vim will be executed with the command line like:
> > > > 
> > > >   $ vim -u NONE --cmd "set fencs=cp932,utf-8" /dev/fd/63
> > > > 
> > > > "/dev/fd/63" is a fifo and it is not seekable.
> > > > The echoed string "テスト" (utf-8) cannot be converted from cp932 to 
> > > > utf-8, so
> > > > Vim retries with utf-8, but it fails because the input is not seekable.
> > > > 
> > > > However reading from stdin can detect the encoding. E.g.:
> > > > 
> > > >   $ echo テスト | vim -u NONE --cmd "set fencs=cp932,utf-8" -
> > > > 
> > > > I think file encoding detection should also work with process 
> > > > substitution.
> > > > Attached patch fixes the problem.
> > > 
> > > Thanks.  It would be good to have a test for this.  The encoding
> > > detection is important, but I don't think there is a test for it.
> > > 
> > > Reading from stdin and fifo require starting Vim.  Test49 does this, it
> > > just uses ../vim for that.  That doesn't work on Windows though.  But
> > > the fifo won't work on Windows either.
> > 
> > I added a test for this. I also wanted to add a test for stdin on Windows,
> > but Windows' echo command cannot write Unicode characters to a pipe. So the
> > test is disabled on Windows.
> 
> Thanks.  It would be better to use "cat" instead of "echo".  Does this
> also exist on MS-Windows?  Or perhaps we can check if it exists.
> Then we can also use multiple lines in the test.

OK, "type" can be used on Windows.
Please check the attached patch.  

Regards,
Ken Takata

-- 
-- 
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  f574310bd638067986318c3d8f0ecd77dae84748

diff --git a/src/Makefile b/src/Makefile
--- a/src/Makefile
+++ b/src/Makefile
@@ -2114,6 +2114,7 @@ test_arglist \
 	test_signs \
 	test_sort \
 	test_startup \
+	test_startup_utf8 \
 	test_stat \
 	test_statusline \
 	test_syn_attr \
diff --git a/src/buffer.c b/src/buffer.c
--- a/src/buffer.c
+++ b/src/buffer.c
@@ -70,6 +70,64 @@ static char *e_auabort = N_("E855: Autoc
 /* Number of times free_buffer() was called. */
 static int	buf_free_count = 0;
 
+/* Read data from buffer for retrying. */
+static int
+read_buffer(
+int		read_stdin,	/* read file from stdin, otherwise fifo */
+exarg_T	*eap,		/* for forced 'ff' and 'fenc' or NULL */
+int		flags)		/* extra flags for readfile() */
+{
+int		retval = OK;
+linenr_T	line_count;
+
+/*
+ * Read from the buffer which the text is already filled in and append at
+ * the end.  This makes it possible to retry when 'fileformat' or
+ * 'fileencoding' was guessed wrong.
+ */
+line_count = curbuf->b_ml.ml_line_count;
+retval = readfile(
+	read_stdin ? NULL : curbuf->b_ffname,
+	read_stdin ? NULL : curbuf->b_fname,
+	(linenr_T)line_count, (linenr_T)0, (linenr_T)MAXLNUM, eap,
+	flags | READ_BUFFER);
+if (retval == OK)
+{
+	/* Delete the binary lines. */
+	while (--line_count >= 0)
+	ml_delete((linenr_T)1, FALSE);
+}
+else
+{
+	/* Delete the converted lines. */
+	while (curbuf->b_ml.ml_line_count > line_count)
+	ml_delete(line_count, FALSE);
+}
+/* Put the cursor on the first line. */
+curwin->w_cursor.lnum = 1;
+curwin->w_cursor.col = 0;
+
+if (read_stdin)
+{
+	/* Set or reset 'modified' before executing autocommands, so that
+	 * it can be changed there. */
+	if (!readonlymode && !bufempty())
+	changed();
+	else if (retval != FAIL)
+	unchanged(curbuf, FALSE);
+
+#ifdef FEAT_AUTOCMD
+# ifdef FEAT_EVAL
+	apply_autocmds_retval(EVENT_STDINREADPOST, NULL, NULL, FALSE,
+			curbuf, );
+# else
+	apply_autocmds(EVENT_STDINREADPOST, NULL, NULL, FALSE, curbuf);
+# endif
+#endif
+}
+return retval;
+}
+
 /*
  * Open current buffer, that is: open the memfile and read the file into
  * memory.
@@ -88,6 +146,7 @@ open_buffer(
 #ifdef FEAT_SYN_HL
 long	old_tw = curbuf->b_p_tw;
 #endif
+int		read_fifo = FALSE;
 
 /*
  * The 'readonly' flag is only set when BF_NEVERLOADED is being reset.
@@ -143,17 +202,42 @@ open_buffer(
)
 {
 	int old_msg_silent 

Re: gvim and ASCII glyphs

[manuelschiller.pimail via vim_dev]

On Monday, 8 August 2016 22:27:11 UTC+2, Bram Moolenaar  wrote:
> Manuel Schiller wrote:
> 
> [...]
> 
> > Concerning your request to send a patch that just fixes the assumption
> > about "one ascii character == one glyph": One could either get rid of
> > that speed optimisation code altogether (in which case all ligatures
> > will work), or rewrite most of that optimisation, doing one shaping
> > call into pango for each of (or some of) the characters with codes <
> > 128. The latter versoin would amount to some overhead for all those
> > calls, and reassembling the returned data structures in a suitable
> > way...
> 
> I don't see how it can work with a font where it is not true that each
> ASCII character is one display cell.  E.g., when highlighting or drawing
> the cursor.  If you draw some combination of two ASCII characters with
> one double-wide glyph it's not possible to highlight half of it.
> 
> It appears pango has no way to disable ligatures.
> 
> So the table we create should work, putting in extra spaces to avoid the
> shaping to take place.  But I don't see why we would be doing this only
> for alphanumeric characters, this should work for all ASCII characters.
> 
> 

Hi Bram,

well, it seems I upset quite a bee's nest with this (much of which may be my 
own fault ;)...

Neither patch nor the current vim code will work when one ASCII character 
translates to more than one display cell.

But when you have a ligature between two characters, drawing a two-cell glyph 
might be considered an improvement by some. As to what happens when you change 
highlighting, or move the cursor across such a ligature: Currently, the redrawn 
character cell gets repainted with the "non-ligaturised" version of that single 
glyph, which results in the ligature partially reverting back to its component 
glyphs. Moving the cursor off, and a (partial) redraw like from pressing ^L 
causes the ligature glyph to reappear. It's not perfect, but it's consistent 
with the behaviour I've seen from e.g. putty and Konsole/qterminal (the latter 
two do their own metrics calculation, and get the spacing wrong if there's 
ligatures on the line - patched gvim doesn't do that, so I'm very happy with it 
;). My assertion is that people using these programming fonts will be happy to 
see these ligatures assemble/disassemble as they edit across them.

Regarding your question about the range of ascii characters to which the 
tabulated cache is applied: Restricting this to subranges of [0,127] that I 
mentioned should get you most of the speed improvement that can be had from 
bypassing pango's shaping, and from what I understood, the space ' ' is 
especially important, since it's used to clear the screen.

But the restriction to those subranges also means that strings containing the 
popular "programming ligatures" like "<=", ">=", "!=", "->" etc. will be 
subject to pango's shaping, thus ligatures are displayed... In a way, we're 
selectively disabling the "shaping bypass" for less obvious character ranges 
where ligatures are more likely (and more likely to be missed by programmers).

I hope this clarifies things a bit.

Thanks for the interest,

Manuel

-- 
-- 
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: Quickfix List vs Location List

[Bram Moolenaar]

Kent Sibilev wrote:

> On Saturday, August 6, 2016 at 1:02:18 PM UTC-4, Bram Moolenaar wrote:
> > 
> > The problem with this solution is that the names are translated.
> > A more direct solution would be better.
> > 
> > The 'buftype' option is "quickfix" for both quickfix and location list.
> > We can't change that without causing problems.
> > 
> > Perhaps we should add a buftype({expr}) function, that can get the
> > buffer type of any buffer, and make a difference between "quickfix" and
> > "loclist".
> 
> I see. Even though it's quite awkward to add a new function just to
> accommodate this particular case, i'm attaching my attempt to
> implement it.

Yes, it is unexpected to have this function.  But I can see it's useful.
Would there be a better solution somehow?
Perhaps using one of the existing quickfix functions?


-- 
While it's true that many normal people whould prefer not to _date_ an
engineer, most normal people harbor an intense desire to _mate_ with them,
thus producing engineerlike children who will have high-paying jobs long
before losing their virginity.
(Scott Adams - The Dilbert principle)

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

-- 
-- 
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.

Patch 7.4.2187

[Bram Moolenaar]

Patch 7.4.2187 (after 7.4.2185)
Problem:glob2regpat test fails on Windows.
Solution:   Remove the checks that use backslashes.
Files:  src/testdir/test_glob2regpat.vim


*** ../vim-7.4.2186/src/testdir/test_glob2regpat.vim2016-08-08 
22:41:59.854993152 +0200
--- src/testdir/test_glob2regpat.vim2016-08-08 23:20:32.033357649 +0200
***
*** 9,22 
  func Test_valid()
call assert_equal('^foo\.', glob2regpat('foo.*'))
call assert_equal('^foo.$', glob2regpat('foo?'))
-   call assert_equal('^foo?$', glob2regpat('foo\?'))
call assert_equal('\.vim$', glob2regpat('*.vim'))
call assert_equal('^[abc]$', glob2regpat('[abc]'))
call assert_equal('^foo bar$', glob2regpat('foo\ bar'))
call assert_equal('^foo,bar$', glob2regpat('foo,bar'))
call assert_equal('^\(foo\|bar\)$', glob2regpat('{foo,bar}'))
-   call assert_equal('^\(foo,bar\|foobar\)$', glob2regpat('{foo\,bar,foobar}'))
-   call assert_equal('^{foo,bar}$', glob2regpat('\{foo,bar\}'))
-   call assert_equal('^\\\(foo\|bar\\\)$', glob2regpat('\\{foo,bar\\}'))
call assert_equal('.*', glob2regpat('**'))
  endfunc
--- 9,26 
  func Test_valid()
call assert_equal('^foo\.', glob2regpat('foo.*'))
call assert_equal('^foo.$', glob2regpat('foo?'))
call assert_equal('\.vim$', glob2regpat('*.vim'))
call assert_equal('^[abc]$', glob2regpat('[abc]'))
call assert_equal('^foo bar$', glob2regpat('foo\ bar'))
call assert_equal('^foo,bar$', glob2regpat('foo,bar'))
call assert_equal('^\(foo\|bar\)$', glob2regpat('{foo,bar}'))
call assert_equal('.*', glob2regpat('**'))
+ 
+   if has('unix')
+ call assert_equal('^foo?$', glob2regpat('foo\?'))
+ call assert_equal('^\(foo,bar\|foobar\)$', 
glob2regpat('{foo\,bar,foobar}'))
+ call assert_equal('^{foo,bar}$', glob2regpat('\{foo,bar\}'))
+ call assert_equal('^\\\(foo\|bar\\\)$', glob2regpat('\\{foo,bar\\}'))
+   " todo: Windows
+   endif
  endfunc
*** ../vim-7.4.2186/src/version.c   2016-08-08 22:46:10.777100339 +0200
--- src/version.c   2016-08-08 23:26:17.474635304 +0200
***
*** 765,766 
--- 765,768 
  {   /* Add new patch number below this line */
+ /**/
+ 2187,
  /**/

-- 
Engineers are widely recognized as superior marriage material: intelligent,
dependable, employed, honest, and handy around the house.
(Scott Adams - The Dilbert principle)

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

-- 
-- 
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 7.4.2183

[Dominique Pellé]

Bram Moolenaar  wrote:

> Patch 7.4.2183
> Problem:Sign tests are old style.
> Solution:   Turn them into new style tests. (Dominique Pelle)
> Files:  src/Makefile, src/testdir/Make_all.mak, src/testdir/test_signs.in,
> src/testdir/test_signs.ok, src/testdir/test_signs.vim,

Strange, this patch was meant to increase test coverage but
according to https://coveralls.io/github/vim/vim?branch=master
coverage dropped from 66.37% to 65.88% with this patch!?

I'm not sure why. The new test should test more than the old one.
Ah, I see that the new test does not test sign with split window.
I'll add that soon, but I don't think it explains loosing ~0.5% overall.

Regards
Dominique

-- 
-- 
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.

Patch 7.4.2186

[Bram Moolenaar]

Patch 7.4.2186
Problem:Timers test is flaky.
Solution:   Relax the sleep time check.
Files:  src/testdir/test_timers.vim


*** ../vim-7.4.2185/src/testdir/test_timers.vim 2016-08-07 18:22:30.426091047 
+0200
--- src/testdir/test_timers.vim 2016-08-08 22:44:45.593742704 +0200
***
*** 27,33 
let timer = timer_start(50, 'MyHandler', {'repeat': 3})
let slept = WaitFor('g:val == 3')
call assert_equal(3, g:val)
!   call assert_inrange(100, 250, slept)
  endfunc
  
  func Test_repeat_many()
--- 27,33 
let timer = timer_start(50, 'MyHandler', {'repeat': 3})
let slept = WaitFor('g:val == 3')
call assert_equal(3, g:val)
!   call assert_inrange(80, 200, slept)
  endfunc
  
  func Test_repeat_many()
*** ../vim-7.4.2185/src/version.c   2016-08-08 22:41:59.858993123 +0200
--- src/version.c   2016-08-08 22:45:33.649380292 +0200
***
*** 765,766 
--- 765,768 
  {   /* Add new patch number below this line */
+ /**/
+ 2186,
  /**/

-- 
For humans, honesty is a matter of degree.  Engineers are always honest in
matters of technology and human relationships.  That's why it's a good idea
to keep engineers away from customers, romantic interests, and other people
who can't handle the truth.
(Scott Adams - The Dilbert principle)

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

-- 
-- 
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.

Patch 7.4.2185

[Bram Moolenaar]

Patch 7.4.2185
Problem:Test glob2regpat does not test much.
Solution:   Add a few more test cases. (Dominique Pelle)
Files:  src/testdir/test_glob2regpat.vim


*** ../vim-7.4.2184/src/testdir/test_glob2regpat.vim2016-01-25 
22:20:24.056402843 +0100
--- src/testdir/test_glob2regpat.vim2016-08-08 22:35:40.837855952 +0200
***
*** 2,10 
--- 2,22 
  
  func Test_invalid()
call assert_fails('call glob2regpat(1.33)', 'E806:')
+   call assert_fails('call glob2regpat("}")', 'E219:')
+   call assert_fails('call glob2regpat("{")', 'E220:')
  endfunc
  
  func Test_valid()
call assert_equal('^foo\.', glob2regpat('foo.*'))
+   call assert_equal('^foo.$', glob2regpat('foo?'))
+   call assert_equal('^foo?$', glob2regpat('foo\?'))
call assert_equal('\.vim$', glob2regpat('*.vim'))
+   call assert_equal('^[abc]$', glob2regpat('[abc]'))
+   call assert_equal('^foo bar$', glob2regpat('foo\ bar'))
+   call assert_equal('^foo,bar$', glob2regpat('foo,bar'))
+   call assert_equal('^\(foo\|bar\)$', glob2regpat('{foo,bar}'))
+   call assert_equal('^\(foo,bar\|foobar\)$', glob2regpat('{foo\,bar,foobar}'))
+   call assert_equal('^{foo,bar}$', glob2regpat('\{foo,bar\}'))
+   call assert_equal('^\\\(foo\|bar\\\)$', glob2regpat('\\{foo,bar\\}'))
+   call assert_equal('.*', glob2regpat('**'))
  endfunc
*** ../vim-7.4.2184/src/version.c   2016-08-08 22:34:10.294536818 +0200
--- src/version.c   2016-08-08 22:37:00.253255723 +0200
***
*** 765,766 
--- 765,768 
  {   /* Add new patch number below this line */
+ /**/
+ 2185,
  /**/

-- 
Engineers are always delighted to share wisdom, even in areas in which they
have no experience whatsoever.  Their logic provides them with inherent
insight into any field of expertise.  This can be a problem when dealing with
the illogical people who believe that knowledge can only be derived through
experience.
(Scott Adams - The Dilbert principle)

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

-- 
-- 
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] test_glob2regpat.vim did not run + increased its coverage

[Bram Moolenaar]

Dominique wrote:

> > Test test_glob2regpat.vim does not run when running tests.
> > Attached patch fixes it.
> >
> > Patch also increases the coverage of test_glob2regpat.vim.
> >
> > Regards
> > Dominique
> 
> Sorry, test_glob2regpat.vim was actually part of test_alot.vim.
> So it was running.
> 
> So I update my patch to only contain the coverage increase
> of test_glob2regpat.vim

Thanks!

-- 
The fastest way to get an engineer to solve a problem is to declare that the
problem is unsolvable.  No engineer can walk away from an unsolvable problem
until it's solved.
(Scott Adams - The Dilbert principle)

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

-- 
-- 
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.

Patch 7.4.2184

[Bram Moolenaar]

Patch 7.4.2184
Problem:Tests that use RunVim() do not actually perform the test.
Solution:   Use "return" instead of "call". (Ken Takata)
Files:  src/testdir/shared.vim


*** ../vim-7.4.2183/src/testdir/shared.vim  2016-08-07 18:22:30.426091047 
+0200
--- src/testdir/shared.vim  2016-08-08 22:32:28.575298784 +0200
***
*** 130,136 
  " Plugins are not loaded, unless 'loadplugins' is set in "before".
  " Return 1 if Vim could be executed.
  func RunVim(before, after, arguments)
!   call RunVimPiped(a:before, a:after, a:arguments, '')
  endfunc
  
  func RunVimPiped(before, after, arguments, pipecmd)
--- 130,136 
  " Plugins are not loaded, unless 'loadplugins' is set in "before".
  " Return 1 if Vim could be executed.
  func RunVim(before, after, arguments)
!   return RunVimPiped(a:before, a:after, a:arguments, '')
  endfunc
  
  func RunVimPiped(before, after, arguments, pipecmd)
*** ../vim-7.4.2183/src/version.c   2016-08-08 22:26:37.993926379 +0200
--- src/version.c   2016-08-08 22:33:23.786885179 +0200
***
*** 765,766 
--- 765,768 
  {   /* Add new patch number below this line */
+ /**/
+ 2184,
  /**/

-- 
Git catch 22: "merge is not possible because you have unmerged files."

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

-- 
-- 
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] fixed typos in help files

[Bram Moolenaar]

Dominique wrote:

> Attached patch fixes several typos in help files.

Thanks!

-- 
Engineers will go without food and hygiene for days to solve a problem.
(Other times just because they forgot.)
(Scott Adams - The Dilbert principle)

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

-- 
-- 
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] file encoding detection doesn't work with process substitution

[Bram Moolenaar]

Ken Takata wrote:

> 2016/8/6 Sat 22:30:05 UTC+9 Bram Moolenaar wrote:
> > Ken Takata wrote:
> > 
> > > When process substitution (e.g. "<(cmd)") is used on bash (or zsh), file
> > > encoding detection doesn't work, and an empty buffer is opened.
> > > E.g.:
> > > 
> > >   $ vim -u NONE --cmd "set fencs=cp932,utf-8" <(echo テスト)
> > >   # Assuming the system encoding is utf-8.
> > > 
> > > Vim will be executed with the command line like:
> > > 
> > >   $ vim -u NONE --cmd "set fencs=cp932,utf-8" /dev/fd/63
> > > 
> > > "/dev/fd/63" is a fifo and it is not seekable.
> > > The echoed string "テスト" (utf-8) cannot be converted from cp932 to utf-8, 
> > > so
> > > Vim retries with utf-8, but it fails because the input is not seekable.
> > > 
> > > However reading from stdin can detect the encoding. E.g.:
> > > 
> > >   $ echo テスト | vim -u NONE --cmd "set fencs=cp932,utf-8" -
> > > 
> > > I think file encoding detection should also work with process 
> > > substitution.
> > > Attached patch fixes the problem.
> > 
> > Thanks.  It would be good to have a test for this.  The encoding
> > detection is important, but I don't think there is a test for it.
> > 
> > Reading from stdin and fifo require starting Vim.  Test49 does this, it
> > just uses ../vim for that.  That doesn't work on Windows though.  But
> > the fifo won't work on Windows either.
> 
> I added a test for this. I also wanted to add a test for stdin on Windows,
> but Windows' echo command cannot write Unicode characters to a pipe. So the
> test is disabled on Windows.

Thanks.  It would be better to use "cat" instead of "echo".  Does this
also exist on MS-Windows?  Or perhaps we can check if it exists.
Then we can also use multiple lines in the test.

> BTW, I found that RunVim() in shared.vim didn't work as expected. I also
> fixed this.

You mean the return value?  Strange that everything worked anyway...
Oh, it just skipped the actual test!

-- 
If the Universe is constantly expanding, why can't I ever find a parking space?

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

-- 
-- 
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.

Patch 7.4.2183

[Bram Moolenaar]

Patch 7.4.2183
Problem:Sign tests are old style.
Solution:   Turn them into new style tests. (Dominique Pelle)
Files:  src/Makefile, src/testdir/Make_all.mak, src/testdir/test_signs.in,
src/testdir/test_signs.ok, src/testdir/test_signs.vim,


*** ../vim-7.4.2182/src/Makefile2016-08-07 13:48:04.997106444 +0200
--- src/Makefile2016-08-08 22:14:42.367292767 +0200
***
*** 2032,2038 
test_marks \
test_nested_function \
test_search_mbyte \
-   test_signs \
test_tagcase \
test_utf8 \
test_wordcount \
--- 2032,2037 
***
*** 2110,2119 
test_regexp_utf8 \
test_reltime \
test_ruby \
-   test_startup \
test_searchpos \
test_set \
test_sort \
test_stat \
test_statusline \
test_syn_attr \
--- 2109,2119 
test_regexp_utf8 \
test_reltime \
test_ruby \
test_searchpos \
test_set \
+   test_signs \
test_sort \
+   test_startup \
test_stat \
test_statusline \
test_syn_attr \
*** ../vim-7.4.2182/src/testdir/Make_all.mak2016-08-07 13:48:05.001106411 
+0200
--- src/testdir/Make_all.mak2016-08-08 22:13:16.211937925 +0200
***
*** 102,108 
test_marks.out \
test_nested_function.out \
test_search_mbyte.out \
-   test_signs.out \
test_tagcase.out \
test_utf8.out \
test_wordcount.out \
--- 102,107 
***
*** 184,189 
--- 183,189 
test_perl.res \
test_quickfix.res \
test_ruby.res \
+   test_signs.res \
test_startup.res \
test_stat.res \
test_syntax.res \
*** ../vim-7.4.2182/src/testdir/test_signs.in   2014-10-21 20:57:11.538295006 
+0200
--- src/testdir/test_signs.in   1970-01-01 01:00:00.0 +0100
***
*** 1,22 
- Tests for signs
- STARTTEST
- :so small.vim
- :if !has("signs")
- :  e! test.ok
- :  wq! test.out
- :endif
- :"
- :sign define JumpSign text=x
- :exe 'sign place 42 line=2 name=JumpSign buffer=' . bufnr('')
- :" Split the window to the bottom to verify :sign-jump will stay in the 
current
- :" window if the buffer is displayed there
- :bot split
- :exe 'sign jump 42 buffer=' . bufnr('')
- :call append(line('$'), winnr())
- :$-1,$w! test.out
- ENDTEST
- 
- STARTTEST
- :qa!
- ENDTEST
- 
--- 0 
*** ../vim-7.4.2182/src/testdir/test_signs.ok   2014-10-21 20:57:11.538295006 
+0200
--- src/testdir/test_signs.ok   1970-01-01 01:00:00.0 +0100
***
*** 1,2 
- 
- 2
--- 0 
*** ../vim-7.4.2182/src/testdir/test_signs.vim  2016-08-08 22:25:55.058248340 
+0200
--- src/testdir/test_signs.vim  2016-08-08 22:13:16.211937925 +0200
***
*** 0 
--- 1,106 
+ " Test for signs
+ 
+ if !has('signs')
+   finish
+ endif
+ 
+ func Test_sign()
+   new
+   call setline(1, ['a', 'b', 'c', 'd'])
+ 
+   sign define Sign1 text=x
+   sign define Sign2 text=y
+ 
+   " Test listing signs.
+   let a=execute('sign list')
+   call assert_equal("\nsign Sign1 text=x \nsign Sign2 text=y ", a)
+ 
+   let a=execute('sign list Sign1')
+   call assert_equal("\nsign Sign1 text=x ", a)
+ 
+   " Place the sign at line 3,then check that we can jump to it.
+   exe 'sign place 42 line=3 name=Sign1 buffer=' . bufnr('')
+   1
+   exe 'sign jump 42 buffer=' . bufnr('')
+   call assert_equal('c', getline('.'))
+ 
+   " Can't change sign.
+   call assert_fails("exe 'sign place 43 name=Sign1 buffer=' . bufnr('')", 
'E885:')
+ 
+   let a=execute('sign place')
+   call assert_equal("\n--- Signs ---\nSigns for [NULL]:\nline=3  id=42  
name=Sign1\n", a)
+ 
+   " Unplace the sign and try jumping to it again should now fail.
+   sign unplace 42
+   1
+   call assert_fails("exe 'sign jump 42 buffer=' . bufnr('')", 'E157:')
+   call assert_equal('a', getline('.'))
+ 
+   " Unplace sign on current line.
+   exe 'sign place 43 line=4 name=Sign2 buffer=' . bufnr('')
+   4
+   sign unplace
+   let a=execute('sign place')
+   call assert_equal("\n--- Signs ---\n", a)
+   
+   " Try again to unplace sign on current line, it should fail this time.
+   call assert_fails('sign unplace', 'E159:')
+ 
+   " Unplace all signs.
+   exe 'sign place 42 line=3 name=Sign1 buffer=' . bufnr('')
+   sign unplace *
+   let a=execute('sign place')
+   call assert_equal("\n--- Signs ---\n", a)
+ 
+   " After undefining the sign, we should no longer be able to place it.
+   sign undefine Sign1
+   sign undefine Sign2
+   call assert_fails("exe 'sign place 42 line=3 name=Sign1 buffer=' . 
bufnr('')", 'E155:')
+ 
+ endfunc
+ 
+ func Test_sign_completion()
+   sign define Sign1 text=x
+   sign define Sign2 text=y
+ 
+   call feedkeys(":sign \\\"\", 'tx')
+   call assert_equal('"sign define jump list place undefine unplace', @:)
+ 
+   call feedkeys(":sign define Sign \\\"\", 'tx')
+   call 

Re: gvim and ASCII glyphs

[Bram Moolenaar]

Manuel Schiller wrote:

[...]

> Concerning your request to send a patch that just fixes the assumption
> about "one ascii character == one glyph": One could either get rid of
> that speed optimisation code altogether (in which case all ligatures
> will work), or rewrite most of that optimisation, doing one shaping
> call into pango for each of (or some of) the characters with codes <
> 128. The latter versoin would amount to some overhead for all those
> calls, and reassembling the returned data structures in a suitable
> way...

I don't see how it can work with a font where it is not true that each
ASCII character is one display cell.  E.g., when highlighting or drawing
the cursor.  If you draw some combination of two ASCII characters with
one double-wide glyph it's not possible to highlight half of it.

It appears pango has no way to disable ligatures.

So the table we create should work, putting in extra spaces to avoid the
shaping to take place.  But I don't see why we would be doing this only
for alphanumeric characters, this should work for all ASCII characters.


-- 
The only way the average employee can speak to an executive is by taking a
second job as a golf caddie.
(Scott Adams - The Dilbert principle)

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

-- 
-- 
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] new style tests for signs + increased coverage

[Bram Moolenaar]

Dominique wrote:

> Attached patch converts sign tests to new style.
> It also increases coverage of sign tests.

Thanks!

-- 
Sometimes you can protect millions of dollars in your budget simply by buying
a bag of cookies, dropping it on the budget anylyst's desk, and saying
something deeply personal such as "How was your weekend, big guy?"
(Scott Adams - The Dilbert principle)

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

-- 
-- 
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.

[patch] fixed typos in help files

[Dominique Pellé]

Hi

Attached patch fixes several typos in help files.

Regards
Dominique

-- 
-- 
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.
diff --git a/runtime/doc/channel.txt b/runtime/doc/channel.txt
index 6eec9f2..9a5d36d 100644
--- a/runtime/doc/channel.txt
+++ b/runtime/doc/channel.txt
@@ -54,7 +54,7 @@ Common combination are:
 - Using a job connected through pipes in NL mode.  E.g., to run a style
   checker and receive errors and warnings.
 - Using a deamon, connecting over a socket in JSON mode.  E.g. to lookup
-  crosss-refrences in a database.
+  cross-references in a database.
 
 ==
 2. Channel demo*channel-demo* *demoserver.py*
diff --git a/runtime/doc/eval.txt b/runtime/doc/eval.txt
index 39765d5..0506d41 100644
--- a/runtime/doc/eval.txt
+++ b/runtime/doc/eval.txt
@@ -207,7 +207,7 @@ this won't happen: >
 	let otherDict.myFunction = myDict.myFunction
 	call otherDict.myFunction()
 
-Here "self" will be "myDict", because it was bound explitly.
+Here "self" will be "myDict", because it was bound explicitly.
 
 
 1.3 Lists ~
@@ -1848,25 +1848,25 @@ v:swapcommand	Normal mode command to be executed after a file has been
 		example, when jumping to a tag the value is ":tag tagname\r".
 		For ":edit +cmd file" the value is ":cmd\r".
 
-*v:t_TYPE* *v:t_bool* *t_bool-varialble*
+*v:t_TYPE* *v:t_bool* *t_bool-variable*
 v:t_bool	Value of Boolean type.  Read-only.  See: |type()|
-	*v:t_channel* *t_channel-varialble*
+	*v:t_channel* *t_channel-variable*
 v:t_channel	Value of Channel type.  Read-only.  See: |type()|
-	*v:t_dict* *t_dict-varialble*
+	*v:t_dict* *t_dict-variable*
 v:t_dict	Value of Dictionary type.  Read-only.  See: |type()|
-	*v:t_float* *t_float-varialble*
+	*v:t_float* *t_float-variable*
 v:t_float	Value of Float type.  Read-only.  See: |type()|
-	*v:t_func* *t_func-varialble*
+	*v:t_func* *t_func-variable*
 v:t_func	Value of Funcref type.  Read-only.  See: |type()|
-	*v:t_job* *t_job-varialble*
+	*v:t_job* *t_job-variable*
 v:t_job		Value of Job type.  Read-only.  See: |type()|
-	*v:t_list* *t_list-varialble*
+	*v:t_list* *t_list-variable*
 v:t_list	Value of List type.  Read-only.  See: |type()|
-	*v:t_none* *t_none-varialble*
+	*v:t_none* *t_none-variable*
 v:t_none	Value of None type.  Read-only.  See: |type()|
-	*v:t_number* *t_number-varialble*
+	*v:t_number* *t_number-variable*
 v:t_number	Value of Number type.  Read-only.  See: |type()|
-	*v:t_string* *t_string-varialble*
+	*v:t_string* *t_string-variable*
 v:t_string	Value of String type.  Read-only.  See: |type()|
 
 *v:termresponse* *termresponse-variable*
diff --git a/runtime/doc/todo.txt b/runtime/doc/todo.txt
index cdd9eab..abc0858 100644
--- a/runtime/doc/todo.txt
+++ b/runtime/doc/todo.txt
@@ -1383,7 +1383,7 @@ https://scan.coverity.com/projects/241
 Patch to support :undo absolute jump to file save number. (Christian Brabandt,
 2010 Nov 5)
 
-Patch to use 'foldnextmax' also for "marker" foldmethod. (Arnaud Lacombe, 2011
+Patch to use 'foldnestmax' also for "marker" foldmethod. (Arnaud Lacombe, 2011
 Jan 7)
 
 Bug with 'incsearch' going to wrong line. (Wolfram Kresse, 2009 Aug 17)
diff --git a/runtime/doc/version7.txt b/runtime/doc/version7.txt
index e962c08..be95695 100644
--- a/runtime/doc/version7.txt
+++ b/runtime/doc/version7.txt
@@ -4026,7 +4026,7 @@ Solution:   Check for NULL pointer returned from mch_open().
 Files:	src/if_cscope.c
 
 Patch 7.0.154
-Problem:When 'foldnextmax' is negative Vim can hang. (James Vega)
+Problem:When 'foldnestmax' is negative Vim can hang. (James Vega)
 Solution:   Avoid the fold level becoming negative.
 Files:	src/fold.c, src/syntax.c
 
diff --git a/runtime/doc/version8.txt b/runtime/doc/version8.txt
index ec9a0db..da9c912 100644
--- a/runtime/doc/version8.txt
+++ b/runtime/doc/version8.txt
@@ -11289,7 +11289,7 @@ Solution:   Unregister the channel when there is an input error.
 Files:  src/channel.c
 
 Patch 7.4.1851
-Problem:test_syn_attr failes when using the GUI. (Dominique Pelle)
+Problem:test_syn_attr fails when using the GUI. (Dominique Pelle)
 Solution:   Escape the font name properly.
 Files:  src/testdir/test_syn_attr.vim
 

Re: gvim and ASCII glyphs

[manuelschiller.pimail via vim_dev]

On Monday, 8 August 2016 21:27:36 UTC+2, Tony Mechelynck  wrote:
> On Mon, Aug 8, 2016 at 3:16 PM, manuelschiller.pimail via vim_dev
>  wrote:
> > On Monday, 8 August 2016 14:51:01 UTC+2, Tony Mechelynck  wrote:
> >> Well, if you let Pango do glyph reshaping for U+0020 to U+007F you
> >> might end up with what you said you didn't want, i.e. fi fl st ffi ffl
> >> digraphs and trigraphs, which in my experience are actually uglier (in
> >> monospaced fonts) than just letting the individual letters stand side
> >> by side. Try the following in a gvim (even unpatched) with 'encoding'
> >> set to utf-8 to see what I mean:
> >> 1. Enter Insert mode (i or a or o or whatever)
> >> 2. Type the following sequences (with no spaces). Each sequence should
> >> output one glyph.
> >> Ctrl-V u fb00
> >> Ctrl-V u fb01
> >> Ctrl-V u fb02
> >> Ctrl-V u fb03
> >> Ctrl-V u fb04
> >> Ctrl-V u fb05
> >> Ctrl-V u fb06
> >> You should see, in that order, the glyphs for ff fi fl ft st ffi ffl.
> >> I absolutely don't like them (in the monospaced fonts that have them;
> >> in serif or sans-serif fonts it's different, especially in serif
> >> italic). OTOH, I think that expanding them to two or three character
> >> cells would be ugly the opposite way.
> >
> > Point taken, but this is not what the patch does. The sets [A-Z], [a-z], 
> > [0-9], and ' ' are still drawn without glyph shaping, when there's nothing 
> > else in the string being drawn that requires it - just as the old code did. 
> > (And the old code also fell back to full glyph shaping once you move above 
> > character code 128, i.e. into the range where you start to get UTF-8 
> > encoded characters...) So in that sense, there's no substantial change in 
> > strategy.
> >
> > Also, I'm not changing the width of any glyph drawn, so there is no 
> > expansion of glyphs going on. It's just a question of how exactly the cache 
> > works that bypasses the glyph shaping (and which strings are allowed to 
> > bypass the glyph shaping process by going through the cache...).
> >
> > Are you proposing changes to the patch, or are you more concerned about how 
> > it'll look? In the former case, maybe you could outline which changes you'd 
> > like to see? In the latter case, why not just give the patch a try (e.g by 
> > typing one of the character combinations, and see if it does what you'd 
> > like it to do), and tell me which bits you don't like (which is much more 
> > productive than discussing in the abstract)?
> 
> I'm concerned about how it will look, and I wasn't aware that you were
> intentionally short-circuiting Pango for all letters and digits.
> 
> Yes, these 6 codepoints (U+FB01 to U+FB06) are above the ASCII range
> but they show examples of what one could get by replacing some
> particular pairs of letters. Similarly, the Arabic subsystem of Vim
> fetches its glyphs by (IIUC) altering their codepoint numbers
> depending on whether they're joined to a preceding character, or to a
> following character, or whether a lam and an alif are found together
> in that order, thus implementing the rules for Arabic character
> shaping by means of "presentation form" codepoints.
> 
> >
> > Kind regards,
> >
> > Manuel
> 
> Best regards,
> Tony.

Okay, now I understand - thanks for the clarification. Well, current vim code 
(and my patch) bypasses pango's glyph shaping completely in some cases. Current 
vim code does this if the string only contains code points <= 127. My patch 
restricts the range somewhat, so that glyph shaping occurs in more cases as 
with vanilla vim code. As far as I can tell, strings containing code points of 
128 and above are left alone with or without my patch, and pango deals with 
them the usual way by shaping, and then drawing the resulting glyphs...

Thanks,

Manuel

-- 
-- 
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: E254: Cannot allocate color Grey40

[Tony Mechelynck]

On Mon, Aug 8, 2016 at 8:43 PM, Bram Moolenaar  wrote:
>
> Frantisek Holop wrote:
>
>> i succesfully compiled vim 7.4.2181 on openbsd
>> but i am getting these "Cannot allocate color"
>> errors after startup:
>>
>> $ gvim -u NONE -U NONE
>> E254: Cannot allocate color Grey40
>> E254: Cannot allocate color Grey40
>>
>> E254: Cannot allocate color Grey40
>> E254: Cannot allocate color Grey40
>>
>> there has been some recent work on guicolors,
>> any ideas where these are coming from?
>>
>> i use the darkburn colorscheme, and when i start gvim using my .vimrc
>> i get additional errors.
>>
>> should these colors be in runtime/rgb.txt or are they defined in X11?
>>
>> $ gvim
>> E254: Cannot allocate color Grey40
>> E254: Cannot allocate color Grey40
>> Error detected while processing /home/f/.vim/vimrc:
>> line   74:
>> E254: Cannot allocate color Grey40
>> E254: Cannot allocate color Grey40
>> Error detected while processing /home/f/.vim/colors/darkburn.vim:
>> line   67:
>> E254: Cannot allocate color Grey40
>> E254: Cannot allocate color Grey40
>> line   68:
>> E254: Cannot allocate color Grey40
>> E254: Cannot allocate color Grey40
>> E254: Cannot allocate color Grey40
>> E254: Cannot allocate color Grey40
>> Error detected while processing 
>> /usr/local/share/vim/vim74/syntax/syncolor.vim:
>> line   36:
>> E254: Cannot allocate color Orange
>> E254: Cannot allocate color Orange
>
> You probably haven't installed rgb.txt.
>
> I do notice that we use Grey40 in the highlight init table but don't
> have it builtin.  Grey90 is there, we should also add Grey40.

IIUC, Grey40 is #66 in hex or rgb(102, 102, 102) in decimal.

Best regards,
Tony.

>
> --
> At some point in the project somebody will start whining about the need to
> determine the project "requirements".  This involves interviewing people who
> don't know what they want but, curiously, know exactly when they need it.
> (Scott Adams - The Dilbert principle)
>
>  /// 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///
>

-- 
-- 
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: gvim and ASCII glyphs

[Tony Mechelynck]

On Mon, Aug 8, 2016 at 3:16 PM, manuelschiller.pimail via vim_dev
 wrote:
> On Monday, 8 August 2016 14:51:01 UTC+2, Tony Mechelynck  wrote:
>> Well, if you let Pango do glyph reshaping for U+0020 to U+007F you
>> might end up with what you said you didn't want, i.e. fi fl st ffi ffl
>> digraphs and trigraphs, which in my experience are actually uglier (in
>> monospaced fonts) than just letting the individual letters stand side
>> by side. Try the following in a gvim (even unpatched) with 'encoding'
>> set to utf-8 to see what I mean:
>> 1. Enter Insert mode (i or a or o or whatever)
>> 2. Type the following sequences (with no spaces). Each sequence should
>> output one glyph.
>> Ctrl-V u fb00
>> Ctrl-V u fb01
>> Ctrl-V u fb02
>> Ctrl-V u fb03
>> Ctrl-V u fb04
>> Ctrl-V u fb05
>> Ctrl-V u fb06
>> You should see, in that order, the glyphs for ff fi fl ft st ffi ffl.
>> I absolutely don't like them (in the monospaced fonts that have them;
>> in serif or sans-serif fonts it's different, especially in serif
>> italic). OTOH, I think that expanding them to two or three character
>> cells would be ugly the opposite way.
>
> Point taken, but this is not what the patch does. The sets [A-Z], [a-z], 
> [0-9], and ' ' are still drawn without glyph shaping, when there's nothing 
> else in the string being drawn that requires it - just as the old code did. 
> (And the old code also fell back to full glyph shaping once you move above 
> character code 128, i.e. into the range where you start to get UTF-8 encoded 
> characters...) So in that sense, there's no substantial change in strategy.
>
> Also, I'm not changing the width of any glyph drawn, so there is no expansion 
> of glyphs going on. It's just a question of how exactly the cache works that 
> bypasses the glyph shaping (and which strings are allowed to bypass the glyph 
> shaping process by going through the cache...).
>
> Are you proposing changes to the patch, or are you more concerned about how 
> it'll look? In the former case, maybe you could outline which changes you'd 
> like to see? In the latter case, why not just give the patch a try (e.g by 
> typing one of the character combinations, and see if it does what you'd like 
> it to do), and tell me which bits you don't like (which is much more 
> productive than discussing in the abstract)?

I'm concerned about how it will look, and I wasn't aware that you were
intentionally short-circuiting Pango for all letters and digits.

Yes, these 6 codepoints (U+FB01 to U+FB06) are above the ASCII range
but they show examples of what one could get by replacing some
particular pairs of letters. Similarly, the Arabic subsystem of Vim
fetches its glyphs by (IIUC) altering their codepoint numbers
depending on whether they're joined to a preceding character, or to a
following character, or whether a lam and an alif are found together
in that order, thus implementing the rules for Arabic character
shaping by means of "presentation form" codepoints.

>
> Kind regards,
>
> Manuel

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: Quickfix List vs Location List

[Kent Sibilev]

On Monday, August 8, 2016 at 12:44:56 PM UTC-4, LCD 47 wrote:

> By default the status line of the quickfix open shows "[Quickfix
> List]" or "[Location List]", followed by the w:quickfix_title variable
> described above.  Some of the plugins that customize status lines choose
> to ignore that information.  I don't think this is something that needs
> to be fixed in Vim.

That's my point. There is no reliable way to distinguish if we are dealing with 
a quickfix or a location window.  Considering that you have to use different 
set of 
commands to handle these windows, this information has to be easily obtainable. 
But
as of right now, it's not the case. w:quickfix_window can be modified, which 
means it 
is not a reliable source.

Also status line uses buf_spname() function that is not exposed via API and as 
Bram
mentioned returns values that are translated.

Regards,
Kent

-- 
-- 
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: E254: Cannot allocate color Grey40

[Bram Moolenaar]

Frantisek Holop wrote:

> i succesfully compiled vim 7.4.2181 on openbsd
> but i am getting these "Cannot allocate color"
> errors after startup:
> 
> $ gvim -u NONE -U NONE
> E254: Cannot allocate color Grey40
> E254: Cannot allocate color Grey40
> 
> E254: Cannot allocate color Grey40
> E254: Cannot allocate color Grey40
> 
> there has been some recent work on guicolors,
> any ideas where these are coming from?
> 
> i use the darkburn colorscheme, and when i start gvim using my .vimrc
> i get additional errors.
> 
> should these colors be in runtime/rgb.txt or are they defined in X11?
> 
> $ gvim
> E254: Cannot allocate color Grey40
> E254: Cannot allocate color Grey40
> Error detected while processing /home/f/.vim/vimrc:
> line   74:
> E254: Cannot allocate color Grey40
> E254: Cannot allocate color Grey40
> Error detected while processing /home/f/.vim/colors/darkburn.vim:
> line   67:
> E254: Cannot allocate color Grey40
> E254: Cannot allocate color Grey40
> line   68:
> E254: Cannot allocate color Grey40
> E254: Cannot allocate color Grey40
> E254: Cannot allocate color Grey40
> E254: Cannot allocate color Grey40
> Error detected while processing 
> /usr/local/share/vim/vim74/syntax/syncolor.vim:
> line   36:
> E254: Cannot allocate color Orange
> E254: Cannot allocate color Orange

You probably haven't installed rgb.txt.

I do notice that we use Grey40 in the highlight init table but don't
have it builtin.  Grey90 is there, we should also add Grey40.

-- 
At some point in the project somebody will start whining about the need to
determine the project "requirements".  This involves interviewing people who
don't know what they want but, curiously, know exactly when they need it.
(Scott Adams - The Dilbert principle)

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

-- 
-- 
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.

Patch 7.4.2182

[Bram Moolenaar]

Patch 7.4.2182
Problem:Color Grey40 used in startup but not in the short list.
Solution:   Add Grey40 to the builtin colors.
Files:  src/term.c


*** ../vim-7.4.2181/src/term.c  2016-07-24 21:58:39.716057524 +0200
--- src/term.c  2016-08-08 20:43:09.360565084 +0200
***
*** 6104,6109 
--- 6104,6110 
{(char_u *)"gray",  RGB(0xBE, 0xBE, 0xBE)},
{(char_u *)"green", RGB(0x00, 0xFF, 0x00)},
{(char_u *)"grey",  RGB(0xBE, 0xBE, 0xBE)},
+   {(char_u *)"grey40",RGB(0x66, 0x66, 0x66)},
{(char_u *)"grey90",RGB(0xE5, 0xE5, 0xE5)},
{(char_u *)"lightblue", RGB(0xAD, 0xD8, 0xE6)},
{(char_u *)"lightcyan", RGB(0xE0, 0xFF, 0xFF)},
*** ../vim-7.4.2181/src/version.c   2016-08-07 20:20:46.582584213 +0200
--- src/version.c   2016-08-08 20:40:37.601690807 +0200
***
*** 765,766 
--- 765,768 
  {   /* Add new patch number below this line */
+ /**/
+ 2182,
  /**/

-- 
You can test a person's importance in the organization by asking how much RAM
his computer has.  Anybody who knows the answer to that question is not a
decision-maker.
(Scott Adams - The Dilbert principle)

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

-- 
-- 
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: Quickfix List vs Location List

[Nikolay Aleksandrovich Pavlov]

2016-08-08 19:44 GMT+03:00 LCD 47 :
> On 8 August 2016, Kent Sibilev  wrote:
>> On Monday, August 8, 2016 at 4:03:22 AM UTC-4, LCD 47 wrote:
>>
>> >
>> > Wait, isn't the title already supposed to tell you that?
>> >
>>
>> What do you mean by title?
>
> From the manual (":h :copen"):
>
> : The window will have the w:quickfix_title variable set
> : which will indicate the command that produced the
> : quickfix list. This can be used to compose a custom
> : status line if the value of 'statusline' is adjusted
> : properly.
>
> By default the status line of the quickfix open shows "[Quickfix
> List]" or "[Location List]", followed by the w:quickfix_title variable
> described above.  Some of the plugins that customize status lines choose
> to ignore that information.  I don't think this is something that needs
> to be fixed in Vim.

w:quickfix_title cannot be used: e.g. install
https://github.com/rking/ag.vim and run `:Ag -w test` then `:LAg -w
test`. If you use :copen and :lopen then you will see that in both
cases `w:quickfix_title` is `:ag --vimgrep -w test`: completely
useless.

`[Quickfix List]` vs `[Location List]` can neither be used because
they are translated as Bram said. Also parsing anything to get this
information sounds like a bad idea.

---

By the way, I remember some patches that add functions returning
information about buffer/window/tabpage. It would be logical if
information regarding whether given buffer contains
quickfix/location/no list was included there.

>
> /lcd
>
> --
> --
> 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.

Re: gvim and ASCII glyphs

[manuelschiller.pimail via vim_dev]

Hi Kazunobu,

On Monday, 8 August 2016 18:31:40 UTC+2, Kazunobu Kuriyama  wrote:
> 2016-08-08 23:06 GMT+09:00 manuelschiller.pimail via vim_dev 
> :
> 
> 
> On Monday, 8 August 2016 15:39:02 UTC+2, Kazunobu Kuriyama  wrote:
> 
> > If your windowing system is a recent X11 with fontconfig, do
> 
> >
> 
> >     $ fc-scan 
> 
> >
> 
> >
> 
> > then you'll have something human readable.
> 
> >
> 
> >
> 
> > Take a look at an item called 'spacing.'
> 
> >
> 
> >
> 
> > If you have none or the number zero, then the font is proportional.
> 
> > If you have the number 90, then the font is dual.
> 
> > If you have the number 100, then the font is monospace.
> 
> > If you have the number 110, then the font is charcell
> 
> 
> 
> Thanks, this is getting us somewhere. :)
> 
> 
> 
> I've run a couple of checks with the commands you suggested, and I get the 
> following results:
> 
> - DejaVu and PragmataPro Mono do indeed have the spacing attribute set to 100.
> 
> - Hasklig and PragmataPro do not, in fact they do not show a spacing 
> attribute. (However, as I tried to explain in that previous post in my own 
> frightfully limited way, they're effectively monospaced, and after glyph 
> shaping where appropriate, things will line up with the character cell layout 
> that the rendering code assumes, I think...)
> 
> 
> 
> By "if you have none..." I meant "(fc-scan) do(es) not show a spacing 
> attribute."
> 
> 
> Therefore, the conclusion is that both Hasklig and PragmataPro are 
> proportional.  No matter how they appear "effectively" monospaced to our 
> eyes, no rendering engine handles them as such.

I understand that now.

>
> Accordingly, Vim can't support them in an appropriate way and needn't.
> 

No, it need not do so, and for the general case of proportional fonts, I'm not 
trying to convince you, or anyone else. But the change required isn't a big 
one, and all it costs at runtime is a slightly more complicated initialisation 
of the cache bypassing the shaping, and a bit more memory for it (both of which 
are likely unnoticable among all the other things that gvim needs to do before 
it can start drawing characters in the edit section of the window). It also 
costs one left shift for the index into the cache. That's not what I'd call 
resource-hungry, or bloated. While I understand that vim wouldn't claim 
support, wouldn't it be nice if these effectively monospaced fonts would work 
to that extent at least?

> 
> Do you know any other fonts which have ligatures and are truly monospaced?   
> For such fonts, if any, I think there's room for consideration.
> 
> 
> 
> 
> So, apparently, there's monospaced fonts, and fonts that just happen to have 
> individual glyphs an intger multiple of the same width. I freely admit that I 
> did not know about this, and apologise if I have given offence in the process.
> 
> 
> 
> To my mind, the question the list now needs to decide is this: Do we want to 
> support these "effectively monospaced" fonts like Hasklig, or not? (I think 
> we should, but I'll abide by your decision, of course. :)
> 
> 
> 
> I haven't seen this community works like that.  Needless to say, it's only 
> you who can make a decision as to your way to go.
> 

Well, I have my patch which does what I want. :) If you think there's something 
salvagable from it (e.g. reworking the bit of the cache that has the assumption 
that pango shaping will give one glyph per input character), let me know, and 
I'll see what I can do in my free time.

But from what I gather from your reaction (if I read between the lines 
correctly), you'd rather not include any of it because the fonts in question 
are not truely monospaced in the sense you indicated. Fair enough.

All the best,

Manuel

> 
> Cheers,
> Kazunobu
> 
> 
> 
> 
> If the answer is yes, we can discuss which bits of the patch you'd like 
> cleaned up, and I'll do my best to provide something that's acceptable. Sorry 
> again for the "exchange of fire" earlier, I certainly didn't mean to hurt 
> anyone's feelings.
> 
> 
> 
> Best regards,
> 
> 
> 
> Manuel
> 
> 
> 
> --
> 
> --
> 
> 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+u...@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 

Re: gvim and ASCII glyphs

[Kazunobu Kuriyama]

2016-08-08 23:06 GMT+09:00 manuelschiller.pimail via vim_dev <
vim_dev@googlegroups.com>:

> On Monday, 8 August 2016 15:39:02 UTC+2, Kazunobu Kuriyama  wrote:
> > If your windowing system is a recent X11 with fontconfig, do
> >
> > $ fc-scan 
> >
> >
> > then you'll have something human readable.
> >
> >
> > Take a look at an item called 'spacing.'
> >
> >
> > If you have none or the number zero, then the font is proportional.
> > If you have the number 90, then the font is dual.
> > If you have the number 100, then the font is monospace.
> > If you have the number 110, then the font is charcell
>
> Thanks, this is getting us somewhere. :)
>
> I've run a couple of checks with the commands you suggested, and I get the
> following results:
> - DejaVu and PragmataPro Mono do indeed have the spacing attribute set to
> 100.
> - Hasklig and PragmataPro do not, in fact they do not show a spacing
> attribute. (However, as I tried to explain in that previous post in my own
> frightfully limited way, they're effectively monospaced, and after glyph
> shaping where appropriate, things will line up with the character cell
> layout that the rendering code assumes, I think...)
>

By "if you have none..." I meant "(fc-scan) do(es) not show a spacing
attribute."

Therefore, the conclusion is that both Hasklig and PragmataPro are
proportional.  No matter how they appear "effectively" monospaced to our
eyes, no rendering engine handles them as such.

Accordingly, Vim can't support them in an appropriate way and needn't.

Do you know any other fonts which have ligatures and are truly monospaced?
  For such fonts, if any, I think there's room for consideration.


> So, apparently, there's monospaced fonts, and fonts that just happen to
> have individual glyphs an intger multiple of the same width. I freely admit
> that I did not know about this, and apologise if I have given offence in
> the process.
>
> To my mind, the question the list now needs to decide is this: Do we want
> to support these "effectively monospaced" fonts like Hasklig, or not? (I
> think we should, but I'll abide by your decision, of course. :)
>

I haven't seen this community works like that.  Needless to say, it's only
you who can make a decision as to your way to go.

Cheers,
Kazunobu


> If the answer is yes, we can discuss which bits of the patch you'd like
> cleaned up, and I'll do my best to provide something that's acceptable.
> Sorry again for the "exchange of fire" earlier, I certainly didn't mean to
> hurt anyone's feelings.
>
> Best regards,
>
> Manuel
>
> --
> --
> 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.

Re: Quickfix List vs Location List

[LCD 47]

On 8 August 2016, Kent Sibilev  wrote:
> On Monday, August 8, 2016 at 4:03:22 AM UTC-4, LCD 47 wrote:
> 
> > 
> > Wait, isn't the title already supposed to tell you that?
> > 
> 
> What do you mean by title?

From the manual (":h :copen"):

: The window will have the w:quickfix_title variable set
: which will indicate the command that produced the
: quickfix list. This can be used to compose a custom
: status line if the value of 'statusline' is adjusted
: properly.

By default the status line of the quickfix open shows "[Quickfix
List]" or "[Location List]", followed by the w:quickfix_title variable
described above.  Some of the plugins that customize status lines choose
to ignore that information.  I don't think this is something that needs
to be fixed in Vim.

/lcd

-- 
-- 
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: Quickfix List vs Location List

[Kent Sibilev]

On Monday, August 8, 2016 at 4:03:22 AM UTC-4, LCD 47 wrote:

> 
> Wait, isn't the title already supposed to tell you that?
> 

What do you mean by title?

Regards,
Kent.

-- 
-- 
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] file encoding detection doesn't work with process substitution

[Ken Takata]

Hi Bram,

2016/8/6 Sat 22:30:05 UTC+9 Bram Moolenaar wrote:
> Ken Takata wrote:
> 
> > When process substitution (e.g. "<(cmd)") is used on bash (or zsh), file
> > encoding detection doesn't work, and an empty buffer is opened.
> > E.g.:
> > 
> >   $ vim -u NONE --cmd "set fencs=cp932,utf-8" <(echo テスト)
> >   # Assuming the system encoding is utf-8.
> > 
> > Vim will be executed with the command line like:
> > 
> >   $ vim -u NONE --cmd "set fencs=cp932,utf-8" /dev/fd/63
> > 
> > "/dev/fd/63" is a fifo and it is not seekable.
> > The echoed string "テスト" (utf-8) cannot be converted from cp932 to utf-8, so
> > Vim retries with utf-8, but it fails because the input is not seekable.
> > 
> > However reading from stdin can detect the encoding. E.g.:
> > 
> >   $ echo テスト | vim -u NONE --cmd "set fencs=cp932,utf-8" -
> > 
> > I think file encoding detection should also work with process substitution.
> > Attached patch fixes the problem.
> 
> Thanks.  It would be good to have a test for this.  The encoding
> detection is important, but I don't think there is a test for it.
> 
> Reading from stdin and fifo require starting Vim.  Test49 does this, it
> just uses ../vim for that.  That doesn't work on Windows though.  But
> the fifo won't work on Windows either.

I added a test for this. I also wanted to add a test for stdin on Windows,
but Windows' echo command cannot write Unicode characters to a pipe. So the
test is disabled on Windows.

BTW, I found that RunVim() in shared.vim didn't work as expected. I also
fixed this.

Regards,
Ken Takata

-- 
-- 
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  fe67d6106f686209c616b7dc937457c909b0ee31

diff --git a/src/Makefile b/src/Makefile
--- a/src/Makefile
+++ b/src/Makefile
@@ -2111,6 +2111,7 @@ test_arglist \
 	test_reltime \
 	test_ruby \
 	test_startup \
+	test_startup_utf8 \
 	test_searchpos \
 	test_set \
 	test_sort \
diff --git a/src/buffer.c b/src/buffer.c
--- a/src/buffer.c
+++ b/src/buffer.c
@@ -70,6 +70,64 @@ static char *e_auabort = N_("E855: Autoc
 /* Number of times free_buffer() was called. */
 static int	buf_free_count = 0;
 
+/* Read data from buffer for retrying. */
+static int
+read_buffer(
+int		read_stdin,	/* read file from stdin, otherwise fifo */
+exarg_T	*eap,		/* for forced 'ff' and 'fenc' or NULL */
+int		flags)		/* extra flags for readfile() */
+{
+int		retval = OK;
+linenr_T	line_count;
+
+/*
+ * Read from the buffer which the text is already filled in and append at
+ * the end.  This makes it possible to retry when 'fileformat' or
+ * 'fileencoding' was guessed wrong.
+ */
+line_count = curbuf->b_ml.ml_line_count;
+retval = readfile(
+	read_stdin ? NULL : curbuf->b_ffname,
+	read_stdin ? NULL : curbuf->b_fname,
+	(linenr_T)line_count, (linenr_T)0, (linenr_T)MAXLNUM, eap,
+	flags | READ_BUFFER);
+if (retval == OK)
+{
+	/* Delete the binary lines. */
+	while (--line_count >= 0)
+	ml_delete((linenr_T)1, FALSE);
+}
+else
+{
+	/* Delete the converted lines. */
+	while (curbuf->b_ml.ml_line_count > line_count)
+	ml_delete(line_count, FALSE);
+}
+/* Put the cursor on the first line. */
+curwin->w_cursor.lnum = 1;
+curwin->w_cursor.col = 0;
+
+if (read_stdin)
+{
+	/* Set or reset 'modified' before executing autocommands, so that
+	 * it can be changed there. */
+	if (!readonlymode && !bufempty())
+	changed();
+	else if (retval != FAIL)
+	unchanged(curbuf, FALSE);
+
+#ifdef FEAT_AUTOCMD
+# ifdef FEAT_EVAL
+	apply_autocmds_retval(EVENT_STDINREADPOST, NULL, NULL, FALSE,
+			curbuf, );
+# else
+	apply_autocmds(EVENT_STDINREADPOST, NULL, NULL, FALSE, curbuf);
+# endif
+#endif
+}
+return retval;
+}
+
 /*
  * Open current buffer, that is: open the memfile and read the file into
  * memory.
@@ -88,6 +146,7 @@ open_buffer(
 #ifdef FEAT_SYN_HL
 long	old_tw = curbuf->b_p_tw;
 #endif
+int		read_fifo = FALSE;
 
 /*
  * The 'readonly' flag is only set when BF_NEVERLOADED is being reset.
@@ -143,17 +202,42 @@ open_buffer(
)
 {
 	int old_msg_silent = msg_silent;
-
+#ifdef UNIX
+	int save_bin = curbuf->b_p_bin;
+	int perm;
+#endif
 #ifdef FEAT_NETBEANS_INTG
 	int oldFire = netbeansFireChanges;
 
 	netbeansFireChanges = 0;
 #endif
+#ifdef UNIX
+	perm = mch_getperm(curbuf->b_ffname);
+	if (perm >= 0 && (0
+# ifdef S_ISFIFO
+		  || S_ISFIFO(perm)
+# endif
+# ifdef S_ISSOCK
+		  || S_ISSOCK(perm)
+# endif
+		))
+		read_fifo = TRUE;
+	if 

Re: gvim and ASCII glyphs

[manuelschiller.pimail via vim_dev]

On Monday, 8 August 2016 15:39:02 UTC+2, Kazunobu Kuriyama  wrote:
> If your windowing system is a recent X11 with fontconfig, do
> 
>     $ fc-scan 
> 
> 
> then you'll have something human readable.
> 
> 
> Take a look at an item called 'spacing.'
> 
> 
> If you have none or the number zero, then the font is proportional.
> If you have the number 90, then the font is dual.
> If you have the number 100, then the font is monospace.
> If you have the number 110, then the font is charcell
 
Thanks, this is getting us somewhere. :)

I've run a couple of checks with the commands you suggested, and I get the 
following results:
- DejaVu and PragmataPro Mono do indeed have the spacing attribute set to 100.
- Hasklig and PragmataPro do not, in fact they do not show a spacing attribute. 
(However, as I tried to explain in that previous post in my own frightfully 
limited way, they're effectively monospaced, and after glyph shaping where 
appropriate, things will line up with the character cell layout that the 
rendering code assumes, I think...)

So, apparently, there's monospaced fonts, and fonts that just happen to have 
individual glyphs an intger multiple of the same width. I freely admit that I 
did not know about this, and apologise if I have given offence in the process.

To my mind, the question the list now needs to decide is this: Do we want to 
support these "effectively monospaced" fonts like Hasklig, or not? (I think we 
should, but I'll abide by your decision, of course. :)

If the answer is yes, we can discuss which bits of the patch you'd like cleaned 
up, and I'll do my best to provide something that's acceptable. Sorry again for 
the "exchange of fire" earlier, I certainly didn't mean to hurt anyone's 
feelings.

Best regards,

Manuel

-- 
-- 
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: Inconsistent backtick behaviour ` vs. `=

[Alex]

On Monday, 8 August 2016 14:34:34 UTC+1, Alex  wrote:
> Hi,
> 
> I use VIM 7.4 on unix, but similar behaviour was on Windows as well.
> 
> With commands that expect file names, backticks can be used similar to unix 
> shells:
> 
> :e `echo aaa`
> 
> or, assuming we have VIM variable aaa already set, we can use VIM backtick 
> expansion :
> 
> :e `=aaa`
> 
> However, shell backtick expansion is more robust, for example, the following 
> will work :
> 
> :e `echo aaa`.txt
> 
> while the following will not (at least not as expected): 
> 
> :e `=aaa`.txt
> 
> Is it a bug or made on purpose for some reason?
> 
> Regards,
> 
> Alex

There is obviously a workaround for this, but it looks kind of cumbersome :

:e `=expand(aaa . '.txt')`

-- 
-- 
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.

Inconsistent backtick behaviour ` vs. `=

[Alex]

Hi,

I use VIM 7.4 on unix, but similar behaviour was on Windows as well.

With commands that expect file names, backticks can be used similar to unix 
shells:

:e `echo aaa`

or, assuming we have VIM variable aaa already set, we can use VIM backtick 
expansion :

:e `=aaa`

However, shell backtick expansion is more robust, for example, the following 
will work :

:e `echo aaa`.txt

while the following will not (at least not as expected): 

:e `=aaa`.txt

Is it a bug or made on purpose for some reason?

Regards,

Alex

-- 
-- 
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: gvim and ASCII glyphs

[manuelschiller.pimail via vim_dev]

On Monday, 8 August 2016 14:51:01 UTC+2, Tony Mechelynck  wrote:
> Well, if you let Pango do glyph reshaping for U+0020 to U+007F you
> might end up with what you said you didn't want, i.e. fi fl st ffi ffl
> digraphs and trigraphs, which in my experience are actually uglier (in
> monospaced fonts) than just letting the individual letters stand side
> by side. Try the following in a gvim (even unpatched) with 'encoding'
> set to utf-8 to see what I mean:
> 1. Enter Insert mode (i or a or o or whatever)
> 2. Type the following sequences (with no spaces). Each sequence should
> output one glyph.
> Ctrl-V u fb00
> Ctrl-V u fb01
> Ctrl-V u fb02
> Ctrl-V u fb03
> Ctrl-V u fb04
> Ctrl-V u fb05
> Ctrl-V u fb06
> You should see, in that order, the glyphs for ff fi fl ft st ffi ffl.
> I absolutely don't like them (in the monospaced fonts that have them;
> in serif or sans-serif fonts it's different, especially in serif
> italic). OTOH, I think that expanding them to two or three character
> cells would be ugly the opposite way.

Point taken, but this is not what the patch does. The sets [A-Z], [a-z], [0-9], 
and ' ' are still drawn without glyph shaping, when there's nothing else in the 
string being drawn that requires it - just as the old code did. (And the old 
code also fell back to full glyph shaping once you move above character code 
128, i.e. into the range where you start to get UTF-8 encoded characters...) So 
in that sense, there's no substantial change in strategy.

Also, I'm not changing the width of any glyph drawn, so there is no expansion 
of glyphs going on. It's just a question of how exactly the cache works that 
bypasses the glyph shaping (and which strings are allowed to bypass the glyph 
shaping process by going through the cache...).

Are you proposing changes to the patch, or are you more concerned about how 
it'll look? In the former case, maybe you could outline which changes you'd 
like to see? In the latter case, why not just give the patch a try (e.g by 
typing one of the character combinations, and see if it does what you'd like it 
to do), and tell me which bits you don't like (which is much more productive 
than discussing in the abstract)? 

Kind regards,

Manuel

> Best regards,
> Tony.
> 
> On Mon, Aug 8, 2016 at 1:50 PM, manuelschiller.pimail via vim_dev
>  wrote:
> > On Monday, 8 August 2016 12:33:44 UTC+2, Tony Mechelynck  wrote:
> >> On Mon, Aug 8, 2016 at 11:15 AM, manuelschiller.pimail via vim_dev
> >>  wrote:
> >> > On Monday, 8 August 2016 08:31:13 UTC+2, Kazunobu Kuriyama  wrote:
> >> >> 2016-08-07 20:27 GMT+09:00 manuelschiller.pimail via vim_dev 
> >> >> :
> >> >>
> >> >>
> >> >> On Monday, 19 October 2015 08:41:36 UTC+2, Hörmetjan Yiltiz  wrote:
> >> >>
> >> >> > On Sunday, 20 April 2014 11:55:22 UTC-4, François Gannaz  wrote:
> >> >>
> >> >> > > Hello
> >> >>
> >> >> > >
> >> >>
> >> >> > > In a few words, here is a patch that makes gvim work better with 
> >> >> > > ligatures
> >> >>
> >> >> > > in fonts, which can be useful even for programmers. Details follow.
> >> >>
> >> >> > >
> >> >>
> >> >> > > I tried to use a Hasklig[^1], a font with ligatures intended for the
> >> >>
> >> >> > > Haskell language. It serves the same objective as the Haskell 
> >> >> > > Conceal
> >> >>
> >> >> > > script[^2], but with the added benefit that even a mouse copy-paste 
> >> >> > > works
> >> >>
> >> >> > > as intended.
> >> >>
> >> >> > > [^1]: https://github.com/i-tu/hasklig
> >> >>
> >> >> > > [^2]: http://www.vim.org/scripts/script.php?script_id=3200
> >> >>
> >> >> > >
> >> >>
> >> >> > > Unfortunately, gvim doesn't support ligatures on ASCII characters. 
> >> >> > > The
> >> >>
> >> >> > > following assertion fails at run-time:
> >> >>
> >> >> > >
> >> >>
> >> >> > > ascii_glyph_table_init: assertion 'gui.ascii_glyphs->num_glyphs 
> >> >> > > ==
> >> >>
> >> >> > > sizeof(ascii_chars)' failed
> >> >>
> >> >> > >
> >> >>
> >> >> > > and many characters are displayed with the wrong glyphs.
> >> >>
> >> >> > > The attached patch limits the function ascii_glyph_table_init() to
> >> >>
> >> >> > > spaces and alphanumeric chars. It solves the problem here.
> >> >>
> >> >> > >
> >> >>
> >> >> > > Yet I wonder if the current hack with ASCII characters is really 
> >> >> > > useful.
> >> >>
> >> >> > > Is there any performance test to check if a simpler behaviour 
> >> >> > > wouldn't be
> >> >>
> >> >> > > suitable, at least for modern desktop installations?
> >> >>
> >> >> > > As the code comment mentions spaces, maybe it should be restricted 
> >> >> > > to
> >> >>
> >> >> > > blank lines?
> >> >>
> >> >> > >
> >> >>
> >> >> > > Regards
> >> >>
> >> >> > > --
> >> >>
> >> >> > > François
> >> >>
> >> >> >
> >> >>
> >> >> > This would be so great to see implemented.
> >> >>
> >> >>
> >> >>
> >> >> It certainly would (and apologies for reopening such an old discussion).

Re: gvim and ASCII glyphs

[Tony Mechelynck]

Well, if you let Pango do glyph reshaping for U+0020 to U+007F you
might end up with what you said you didn't want, i.e. fi fl st ffi ffl
digraphs and trigraphs, which in my experience are actually uglier (in
monospaced fonts) than just letting the individual letters stand side
by side. Try the following in a gvim (even unpatched) with 'encoding'
set to utf-8 to see what I mean:
1. Enter Insert mode (i or a or o or whatever)
2. Type the following sequences (with no spaces). Each sequence should
output one glyph.
Ctrl-V u fb00
Ctrl-V u fb01
Ctrl-V u fb02
Ctrl-V u fb03
Ctrl-V u fb04
Ctrl-V u fb05
Ctrl-V u fb06
You should see, in that order, the glyphs for ff fi fl ft st ffi ffl.
I absolutely don't like them (in the monospaced fonts that have them;
in serif or sans-serif fonts it's different, especially in serif
italic). OTOH, I think that expanding them to two or three character
cells would be ugly the opposite way.

Best regards,
Tony.

On Mon, Aug 8, 2016 at 1:50 PM, manuelschiller.pimail via vim_dev
 wrote:
> On Monday, 8 August 2016 12:33:44 UTC+2, Tony Mechelynck  wrote:
>> On Mon, Aug 8, 2016 at 11:15 AM, manuelschiller.pimail via vim_dev
>>  wrote:
>> > On Monday, 8 August 2016 08:31:13 UTC+2, Kazunobu Kuriyama  wrote:
>> >> 2016-08-07 20:27 GMT+09:00 manuelschiller.pimail via vim_dev 
>> >> :
>> >>
>> >>
>> >> On Monday, 19 October 2015 08:41:36 UTC+2, Hörmetjan Yiltiz  wrote:
>> >>
>> >> > On Sunday, 20 April 2014 11:55:22 UTC-4, François Gannaz  wrote:
>> >>
>> >> > > Hello
>> >>
>> >> > >
>> >>
>> >> > > In a few words, here is a patch that makes gvim work better with 
>> >> > > ligatures
>> >>
>> >> > > in fonts, which can be useful even for programmers. Details follow.
>> >>
>> >> > >
>> >>
>> >> > > I tried to use a Hasklig[^1], a font with ligatures intended for the
>> >>
>> >> > > Haskell language. It serves the same objective as the Haskell Conceal
>> >>
>> >> > > script[^2], but with the added benefit that even a mouse copy-paste 
>> >> > > works
>> >>
>> >> > > as intended.
>> >>
>> >> > > [^1]: https://github.com/i-tu/hasklig
>> >>
>> >> > > [^2]: http://www.vim.org/scripts/script.php?script_id=3200
>> >>
>> >> > >
>> >>
>> >> > > Unfortunately, gvim doesn't support ligatures on ASCII characters. The
>> >>
>> >> > > following assertion fails at run-time:
>> >>
>> >> > >
>> >>
>> >> > > ascii_glyph_table_init: assertion 'gui.ascii_glyphs->num_glyphs ==
>> >>
>> >> > > sizeof(ascii_chars)' failed
>> >>
>> >> > >
>> >>
>> >> > > and many characters are displayed with the wrong glyphs.
>> >>
>> >> > > The attached patch limits the function ascii_glyph_table_init() to
>> >>
>> >> > > spaces and alphanumeric chars. It solves the problem here.
>> >>
>> >> > >
>> >>
>> >> > > Yet I wonder if the current hack with ASCII characters is really 
>> >> > > useful.
>> >>
>> >> > > Is there any performance test to check if a simpler behaviour 
>> >> > > wouldn't be
>> >>
>> >> > > suitable, at least for modern desktop installations?
>> >>
>> >> > > As the code comment mentions spaces, maybe it should be restricted to
>> >>
>> >> > > blank lines?
>> >>
>> >> > >
>> >>
>> >> > > Regards
>> >>
>> >> > > --
>> >>
>> >> > > François
>> >>
>> >> >
>> >>
>> >> > This would be so great to see implemented.
>> >>
>> >>
>> >>
>> >> It certainly would (and apologies for reopening such an old discussion).
>> >>
>> >>
>> >>
>> >> On my system, the patch François sent doesn't work for the ligatures in 
>> >> PragmataPro (but flawlessly for other fonts like Hasklig),
>> >>
>> >>
>> >> According to http://www.fsd.it/shop/fonts/pragmatapro/ ,  PragmataPro has 
>> >> "One typeface, 3 families for the right need":
>> >>
>> >>
>> >>
>> >> - PragmataPro is a spaced modularly font family with working ligatures.
>> >> - PragmataPro Mono is a very monospaced without ligatures.
>> >> - Essential PragmataPro is the cheap version to coding for English only.
>> >>
>> >>
>> >> As you know, Vim is implemented by design only to support monospace font 
>> >> families.
>> >>
>> >>
>> >> So it looks to me that, among those three font families,  the only 
>> >> possible and suitable choice for Vim to use with is PragmataPro Mono 
>> >> alone.
>> >
>> > In PragmataPro, all ASCII glyphs etc. are monospaced. Just as they are in 
>> > PragmatePro Mono or Courier, or whatever your favourite monospaced font 
>> > is. The difference between the two is what happens during shaping into 
>> > glyphs inside pango (or another library): For fonts like Hasklig or 
>> > PragmataPro, some combinations of ASCII characters get assigned a new 
>> > glyph (the ligature) which looks better (e.g. "<=" might be replaced with 
>> > a new glyph that more closely mimics the mathematical notation), but fits 
>> > into the normal monospaced character grid. These ligature characters are 
>> > two and sometimes three times the width of a single ASCII glyph, 

Re: gvim and ASCII glyphs

[manuelschiller.pimail via vim_dev]

On Monday, 8 August 2016 12:33:44 UTC+2, Tony Mechelynck  wrote:
> On Mon, Aug 8, 2016 at 11:15 AM, manuelschiller.pimail via vim_dev
>  wrote:
> > On Monday, 8 August 2016 08:31:13 UTC+2, Kazunobu Kuriyama  wrote:
> >> 2016-08-07 20:27 GMT+09:00 manuelschiller.pimail via vim_dev 
> >> :
> >>
> >>
> >> On Monday, 19 October 2015 08:41:36 UTC+2, Hörmetjan Yiltiz  wrote:
> >>
> >> > On Sunday, 20 April 2014 11:55:22 UTC-4, François Gannaz  wrote:
> >>
> >> > > Hello
> >>
> >> > >
> >>
> >> > > In a few words, here is a patch that makes gvim work better with 
> >> > > ligatures
> >>
> >> > > in fonts, which can be useful even for programmers. Details follow.
> >>
> >> > >
> >>
> >> > > I tried to use a Hasklig[^1], a font with ligatures intended for the
> >>
> >> > > Haskell language. It serves the same objective as the Haskell Conceal
> >>
> >> > > script[^2], but with the added benefit that even a mouse copy-paste 
> >> > > works
> >>
> >> > > as intended.
> >>
> >> > > [^1]: https://github.com/i-tu/hasklig
> >>
> >> > > [^2]: http://www.vim.org/scripts/script.php?script_id=3200
> >>
> >> > >
> >>
> >> > > Unfortunately, gvim doesn't support ligatures on ASCII characters. The
> >>
> >> > > following assertion fails at run-time:
> >>
> >> > >
> >>
> >> > > ascii_glyph_table_init: assertion 'gui.ascii_glyphs->num_glyphs ==
> >>
> >> > > sizeof(ascii_chars)' failed
> >>
> >> > >
> >>
> >> > > and many characters are displayed with the wrong glyphs.
> >>
> >> > > The attached patch limits the function ascii_glyph_table_init() to
> >>
> >> > > spaces and alphanumeric chars. It solves the problem here.
> >>
> >> > >
> >>
> >> > > Yet I wonder if the current hack with ASCII characters is really 
> >> > > useful.
> >>
> >> > > Is there any performance test to check if a simpler behaviour wouldn't 
> >> > > be
> >>
> >> > > suitable, at least for modern desktop installations?
> >>
> >> > > As the code comment mentions spaces, maybe it should be restricted to
> >>
> >> > > blank lines?
> >>
> >> > >
> >>
> >> > > Regards
> >>
> >> > > --
> >>
> >> > > François
> >>
> >> >
> >>
> >> > This would be so great to see implemented.
> >>
> >>
> >>
> >> It certainly would (and apologies for reopening such an old discussion).
> >>
> >>
> >>
> >> On my system, the patch François sent doesn't work for the ligatures in 
> >> PragmataPro (but flawlessly for other fonts like Hasklig),
> >>
> >>
> >> According to http://www.fsd.it/shop/fonts/pragmatapro/ ,  PragmataPro has 
> >> "One typeface, 3 families for the right need":
> >>
> >>
> >>
> >> - PragmataPro is a spaced modularly font family with working ligatures.
> >> - PragmataPro Mono is a very monospaced without ligatures.
> >> - Essential PragmataPro is the cheap version to coding for English only.
> >>
> >>
> >> As you know, Vim is implemented by design only to support monospace font 
> >> families.
> >>
> >>
> >> So it looks to me that, among those three font families,  the only 
> >> possible and suitable choice for Vim to use with is PragmataPro Mono alone.
> >
> > In PragmataPro, all ASCII glyphs etc. are monospaced. Just as they are in 
> > PragmatePro Mono or Courier, or whatever your favourite monospaced font is. 
> > The difference between the two is what happens during shaping into glyphs 
> > inside pango (or another library): For fonts like Hasklig or PragmataPro, 
> > some combinations of ASCII characters get assigned a new glyph (the 
> > ligature) which looks better (e.g. "<=" might be replaced with a new glyph 
> > that more closely mimics the mathematical notation), but fits into the 
> > normal monospaced character grid. These ligature characters are two and 
> > sometimes three times the width of a single ASCII glyph, depending on how 
> > many characters they replace (if it's a monospace font - in a proportional 
> > font like Times, the ligature for something like "fl" can be any width the 
> > font designer likes, and I'm not proposing to support this latter case).
> >
> > That kind of character/glyph juggling is okay because it fits with what vim 
> > is expecting to draw anyway (so vim's drawing code can largely remain 
> > unaware of the font shaping going on) - it's expecting to draw something 
> > that's e.g. 2 characters wide, and it draws (a single) glyph that wide.
> >
> > (In PragmataPro Mono, these ligature tables are absent, so shaping just 
> > returns the normal single-width glyphs.)
> >
> > The point of this patch is that it ensures that vim gets the right single 
> > width glyphs for all monospaced fonts, even in the code that bypasses the 
> > glyph shaping process and does its own thing.
> >
> > I've attached screenshots how unpatched vim (as shipped with the latest 
> > stable debian) and patched vim look with these fonts. In all cases, I do a 
> > ":version" before I take the screenshot. As you can see, it's totally 
> > garbled in case of the unpatched versions of the plots, 

Re: gvim and ASCII glyphs

[Kazunobu Kuriyama]

Sorry, but I still don't understand how you justify your patch that adds
0x20 to each of alphanumeric characters and send them to Pango.

Actually, what is your point to make every text data length double?  That
is 100% inefficient and totally ruins the existing optimization hack.  Just
as what you wrote in your patch yourself, that's a ugly hack, indeed.

If I wrote a patch for ligature support, I would remove the optimization
hack and add some code to cursor movement over a ligature, selection
mechanisms for visual mode and text objects when either of the region
boundaries has a ligatures on it, line wrapping handling at a ligature (to
name but a few) in order to decently accommodate ligatures in vim.

What consideration is paid to those in your patch?   I don't see any.

My question in the previous mail was whether or not PragmataPro was a
monospace font family as binary data.  Not that what you felt about it nor
what the world saw about it.  That was a purely technical question.  Was it
too hard for you to check your PragmataPro file(s) with an appropriate
utility?

I'm afraid your reply to that, which sounds somehow insulting old-school
people is completely out of place.

I'm sorry that you don't care about technical aspects of the issue.  I
really feel sick when I hear someone talks about old vs new to justify his
view.

2016-08-08 18:15 GMT+09:00 manuelschiller.pimail via vim_dev <
vim_dev@googlegroups.com>:

> On Monday, 8 August 2016 08:31:13 UTC+2, Kazunobu Kuriyama  wrote:
> > 2016-08-07 20:27 GMT+09:00 manuelschiller.pimail via vim_dev <
> vim...@googlegroups.com>:
> >
> >
> > On Monday, 19 October 2015 08:41:36 UTC+2, Hörmetjan Yiltiz  wrote:
> >
> > > On Sunday, 20 April 2014 11:55:22 UTC-4, François Gannaz  wrote:
> >
> > > > Hello
> >
> > > >
> >
> > > > In a few words, here is a patch that makes gvim work better with
> ligatures
> >
> > > > in fonts, which can be useful even for programmers. Details follow.
> >
> > > >
> >
> > > > I tried to use a Hasklig[^1], a font with ligatures intended for the
> >
> > > > Haskell language. It serves the same objective as the Haskell Conceal
> >
> > > > script[^2], but with the added benefit that even a mouse copy-paste
> works
> >
> > > > as intended.
> >
> > > > [^1]: https://github.com/i-tu/hasklig
> >
> > > > [^2]: http://www.vim.org/scripts/script.php?script_id=3200
> >
> > > >
> >
> > > > Unfortunately, gvim doesn't support ligatures on ASCII characters.
> The
> >
> > > > following assertion fails at run-time:
> >
> > > >
> >
> > > > ascii_glyph_table_init: assertion 'gui.ascii_glyphs->num_glyphs
> ==
> >
> > > > sizeof(ascii_chars)' failed
> >
> > > >
> >
> > > > and many characters are displayed with the wrong glyphs.
> >
> > > > The attached patch limits the function ascii_glyph_table_init() to
> >
> > > > spaces and alphanumeric chars. It solves the problem here.
> >
> > > >
> >
> > > > Yet I wonder if the current hack with ASCII characters is really
> useful.
> >
> > > > Is there any performance test to check if a simpler behaviour
> wouldn't be
> >
> > > > suitable, at least for modern desktop installations?
> >
> > > > As the code comment mentions spaces, maybe it should be restricted to
> >
> > > > blank lines?
> >
> > > >
> >
> > > > Regards
> >
> > > > --
> >
> > > > François
> >
> > >
> >
> > > This would be so great to see implemented.
> >
> >
> >
> > It certainly would (and apologies for reopening such an old discussion).
> >
> >
> >
> > On my system, the patch François sent doesn't work for the ligatures in
> PragmataPro (but flawlessly for other fonts like Hasklig),
> >
> >
> > According to http://www.fsd.it/shop/fonts/pragmatapro/ ,  PragmataPro
> has "One typeface, 3 families for the right need":
> >
> >
> >
> > - PragmataPro is a spaced modularly font family with working ligatures.
> > - PragmataPro Mono is a very monospaced without ligatures.
> > - Essential PragmataPro is the cheap version to coding for English only.
> >
> >
> > As you know, Vim is implemented by design only to support monospace font
> families.
> >
> >
> > So it looks to me that, among those three font families,  the only
> possible and suitable choice for Vim to use with is PragmataPro Mono alone.
>
> In PragmataPro, all ASCII glyphs etc. are monospaced. Just as they are in
> PragmatePro Mono or Courier, or whatever your favourite monospaced font is.
> The difference between the two is what happens during shaping into glyphs
> inside pango (or another library): For fonts like Hasklig or PragmataPro,
> some combinations of ASCII characters get assigned a new glyph (the
> ligature) which looks better (e.g. "<=" might be replaced with a new glyph
> that more closely mimics the mathematical notation), but fits into the
> normal monospaced character grid. These ligature characters are two and
> sometimes three times the width of a single ASCII glyph, depending on how
> many characters they replace (if it's a monospace font - in a proportional
> font like 

Re: gvim and ASCII glyphs

[Tony Mechelynck]

On Mon, Aug 8, 2016 at 11:15 AM, manuelschiller.pimail via vim_dev
 wrote:
> On Monday, 8 August 2016 08:31:13 UTC+2, Kazunobu Kuriyama  wrote:
>> 2016-08-07 20:27 GMT+09:00 manuelschiller.pimail via vim_dev 
>> :
>>
>>
>> On Monday, 19 October 2015 08:41:36 UTC+2, Hörmetjan Yiltiz  wrote:
>>
>> > On Sunday, 20 April 2014 11:55:22 UTC-4, François Gannaz  wrote:
>>
>> > > Hello
>>
>> > >
>>
>> > > In a few words, here is a patch that makes gvim work better with 
>> > > ligatures
>>
>> > > in fonts, which can be useful even for programmers. Details follow.
>>
>> > >
>>
>> > > I tried to use a Hasklig[^1], a font with ligatures intended for the
>>
>> > > Haskell language. It serves the same objective as the Haskell Conceal
>>
>> > > script[^2], but with the added benefit that even a mouse copy-paste works
>>
>> > > as intended.
>>
>> > > [^1]: https://github.com/i-tu/hasklig
>>
>> > > [^2]: http://www.vim.org/scripts/script.php?script_id=3200
>>
>> > >
>>
>> > > Unfortunately, gvim doesn't support ligatures on ASCII characters. The
>>
>> > > following assertion fails at run-time:
>>
>> > >
>>
>> > > ascii_glyph_table_init: assertion 'gui.ascii_glyphs->num_glyphs ==
>>
>> > > sizeof(ascii_chars)' failed
>>
>> > >
>>
>> > > and many characters are displayed with the wrong glyphs.
>>
>> > > The attached patch limits the function ascii_glyph_table_init() to
>>
>> > > spaces and alphanumeric chars. It solves the problem here.
>>
>> > >
>>
>> > > Yet I wonder if the current hack with ASCII characters is really useful.
>>
>> > > Is there any performance test to check if a simpler behaviour wouldn't be
>>
>> > > suitable, at least for modern desktop installations?
>>
>> > > As the code comment mentions spaces, maybe it should be restricted to
>>
>> > > blank lines?
>>
>> > >
>>
>> > > Regards
>>
>> > > --
>>
>> > > François
>>
>> >
>>
>> > This would be so great to see implemented.
>>
>>
>>
>> It certainly would (and apologies for reopening such an old discussion).
>>
>>
>>
>> On my system, the patch François sent doesn't work for the ligatures in 
>> PragmataPro (but flawlessly for other fonts like Hasklig),
>>
>>
>> According to http://www.fsd.it/shop/fonts/pragmatapro/ ,  PragmataPro has 
>> "One typeface, 3 families for the right need":
>>
>>
>>
>> - PragmataPro is a spaced modularly font family with working ligatures.
>> - PragmataPro Mono is a very monospaced without ligatures.
>> - Essential PragmataPro is the cheap version to coding for English only.
>>
>>
>> As you know, Vim is implemented by design only to support monospace font 
>> families.
>>
>>
>> So it looks to me that, among those three font families,  the only possible 
>> and suitable choice for Vim to use with is PragmataPro Mono alone.
>
> In PragmataPro, all ASCII glyphs etc. are monospaced. Just as they are in 
> PragmatePro Mono or Courier, or whatever your favourite monospaced font is. 
> The difference between the two is what happens during shaping into glyphs 
> inside pango (or another library): For fonts like Hasklig or PragmataPro, 
> some combinations of ASCII characters get assigned a new glyph (the ligature) 
> which looks better (e.g. "<=" might be replaced with a new glyph that more 
> closely mimics the mathematical notation), but fits into the normal 
> monospaced character grid. These ligature characters are two and sometimes 
> three times the width of a single ASCII glyph, depending on how many 
> characters they replace (if it's a monospace font - in a proportional font 
> like Times, the ligature for something like "fl" can be any width the font 
> designer likes, and I'm not proposing to support this latter case).
>
> That kind of character/glyph juggling is okay because it fits with what vim 
> is expecting to draw anyway (so vim's drawing code can largely remain unaware 
> of the font shaping going on) - it's expecting to draw something that's e.g. 
> 2 characters wide, and it draws (a single) glyph that wide.
>
> (In PragmataPro Mono, these ligature tables are absent, so shaping just 
> returns the normal single-width glyphs.)
>
> The point of this patch is that it ensures that vim gets the right single 
> width glyphs for all monospaced fonts, even in the code that bypasses the 
> glyph shaping process and does its own thing.
>
> I've attached screenshots how unpatched vim (as shipped with the latest 
> stable debian) and patched vim look with these fonts. In all cases, I do a 
> ":version" before I take the screenshot. As you can see, it's totally garbled 
> in case of the unpatched versions of the plots, despite the fact that the two 
> fonts are monospaced (and are counted as such by all major terminal programs).
>
> This is a corner case where the optimisation to speed up rendering of ASCII 
> glyphs in vim (by bypassing the shaping process) gets it wrong (namely the 
> corner case where the font designer specified ligatures for a font). What 
> happens in 

Re: Quickfix List vs Location List

[LCD 47]

On 7 August 2016, Kent Sibilev  wrote:
> On Saturday, August 6, 2016 at 1:02:18 PM UTC-4, Bram Moolenaar wrote:
> >
> > The problem with this solution is that the names are translated.  A
> > more direct solution would be better.
> >
> > The 'buftype' option is "quickfix" for both quickfix and location
> > list.  We can't change that without causing problems.
> >
> > Perhaps we should add a buftype({expr}) function, that can get the
> > buffer type of any buffer, and make a difference between "quickfix"
> > and "loclist".
>
> I see. Even though it's quite awkward to add a new function just
> to accommodate this particular case, i'm attaching my attempt to
> implement it.

Wait, isn't the title already supposed to tell you that?

/lcd

-- 
-- 
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: gvim and ASCII glyphs

[Kazunobu Kuriyama]

2016-08-07 20:27 GMT+09:00 manuelschiller.pimail via vim_dev <
vim_dev@googlegroups.com>:

> On Monday, 19 October 2015 08:41:36 UTC+2, Hörmetjan Yiltiz  wrote:
> > On Sunday, 20 April 2014 11:55:22 UTC-4, François Gannaz  wrote:
> > > Hello
> > >
> > > In a few words, here is a patch that makes gvim work better with
> ligatures
> > > in fonts, which can be useful even for programmers. Details follow.
> > >
> > > I tried to use a Hasklig[^1], a font with ligatures intended for the
> > > Haskell language. It serves the same objective as the Haskell Conceal
> > > script[^2], but with the added benefit that even a mouse copy-paste
> works
> > > as intended.
> > > [^1]: https://github.com/i-tu/hasklig
> > > [^2]: http://www.vim.org/scripts/script.php?script_id=3200
> > >
> > > Unfortunately, gvim doesn't support ligatures on ASCII characters. The
> > > following assertion fails at run-time:
> > >
> > > ascii_glyph_table_init: assertion 'gui.ascii_glyphs->num_glyphs ==
> > > sizeof(ascii_chars)' failed
> > >
> > > and many characters are displayed with the wrong glyphs.
> > > The attached patch limits the function ascii_glyph_table_init() to
> > > spaces and alphanumeric chars. It solves the problem here.
> > >
> > > Yet I wonder if the current hack with ASCII characters is really
> useful.
> > > Is there any performance test to check if a simpler behaviour wouldn't
> be
> > > suitable, at least for modern desktop installations?
> > > As the code comment mentions spaces, maybe it should be restricted to
> > > blank lines?
> > >
> > > Regards
> > > --
> > > François
> >
> > This would be so great to see implemented.
>
> It certainly would (and apologies for reopening such an old discussion).
>
> On my system, the patch François sent doesn't work for the ligatures in
> PragmataPro (but flawlessly for other fonts like Hasklig),


According to http://www.fsd.it/shop/fonts/pragmatapro/ ,  PragmataPro has
"One typeface, 3 families for the right need":

- PragmataPro is a spaced modularly font family with working ligatures.
- PragmataPro Mono is a very monospaced without ligatures.
- Essential PragmataPro is the cheap version to coding for English only.

As you know, Vim is implemented by design only to support monospace font
families.

So it looks to me that, among those three font families,  the only possible
and suitable choice for Vim to use with is PragmataPro Mono alone.

If that is the case, however, that font family is described as "without
ligatures," which makes your patch no sense.

Accordingly, it appears my assumption was wrong; it might be better for me
to conclude that what you meant by PragmataPro was literally PragmataPro,
not its monospace version, or PragmataPro Mono.

Then, another question arises:  What  does "a spaced modularly font" mean?
Does it imply that the font family in question is technically considered
something equivalent to a monospaced font and hence deserve Vim's support?

I'd appreciate it if you would give me some clarification or correct my
possible misunderstanding.

Best regards,
Kazunobu Kuriyama

apparently because the ASCII-to-glyph mapping won't quite work - I suspect
> that's due to PragmataPro having ligatures in that range, too. I solved
> this by inserting a space between characters that we hand to pango for
> shaping. Sane fonts will not have ligatures between a space and a printable
> character, this way we still get one glyph per ASCII character. I've
> attached the modified patch. This will work with normal fonts and ones with
> programming ligatures like Hasklig and PragmataPro; I've tested it with the
> gtk2 and gtk3 front ends.
>
> Please let me know if it would be possible to include this, and if not, at
> least the patch is public now where people can find it if they want it.
>
> Best regards,
>
> Manuel
>
> --
> --
> 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.