Re: I want to contribute and chose right project for graduate thesis

2017-07-21 Fir de Conversatie Kazunobu Kuriyama
2017-07-22 3:11 GMT+09:00 Christian Brabandt :

>
> On Fr, 21 Jul 2017, Mario Krajačić wrote:
>
> > Hello,
> >
> > I am student of IT from Croatia on finishing year for my bachelor's
> degree.
> >
> > For the graduate thesis I would like to contribute some open source
> project. For example it can be  some bug fix. Language in I work is C. My
> knowledge is shown in programs on git profile: https://github.com/mkrajaci
> >
> > Project which I choose will be sent to my professor - mentor who will
> approve or not difficulty of project.
> >
> > Please advice me about how to help you and choose right project.
>
> Hi,
> welcome to this community. We really appreciate if someone wants to
> contribute. However, please note, this is a mature OpenSource project
> that has been under development for over 25 years. That means, although
> we are using git, we do not follow the github workflow much. Usually
> patches are committed by Bram, acknowledging the author in the commit
> message (therefore you'll see only one contributor at
> https://github.com/vim/vim/graphs/contributors).
>
> You can create PRs at github and the automatic continuous integration
> system will test that PR against the normal test suite, but they wont
> get merged. Everything is handled by Bram as the project maintainer.
> That also means, that Bram is very busy, so he might not react or review
> immediately, so please be patient and the rest of us will try to comment
> and give helpful advises.
>
> That does not mean, that patches are not appreciated, so do not let that
> scare you!
>
> As for what could be done, this depends on your C-skills and the amount
> of time you want to spend. The link to the todo list has already been
> given. However, here are some things that come to my mind, where Vim
> could need some improvements:
>
> - Make the gvim prettier
>

One of the ways for making things easier to attain that purpose would be to
separate GUI initialization and layout from core logic as much as possible,
e.g., conversion from a pure C program
https://developer.gnome.org/gtk3/stable/ch01s02.html into  a combination of
 a piece of C code for the core logic and another piece of code to define
the default resource values and describe the initial layout of the GUI
https://developer.gnome.org/gtk3/stable/ch01s03.html, though there's
effectively no core logic in this example, actually :)

Because prettiness is more or less a matter of taste, it could be much
better to provide a way to make the UI "prettier" with ease whenever
necessary rather than aiming directly at prettiness itself.  The separation
is obviously helpful for that purpose (and more mentioned below :)

For popups such as various dialogs, this should be done with ease.  For the
main UI,  you would need to make GtkForm (Historical misnomer.  That's
Vim's own custom layout widget, actually) gtk-buildable so that it can
easily be incorporated into an XML description.

Furthermore, if you could make the main UI a subclass of
GtkApplicationWindow (plus, replacement of gtk_main() with
g_application_run()), then the GTK+3 GUI would be smoothly converted into
the one for the coming GTK+ 4 with little effort, which would be much
appreciated by the community.


> - Implement smooth scrolling
>

Scroll consists of copy and repaint.  Different operations happening at
different places at different times, initiated by different entities.  How
can we make those operations seamless?  There's no trivial answer.  People
often talk about double-buffering to attain that.   But, does it actually
work just as described in abstracted manners in textbooks on a given,
actual windowing system on a given hardware?  Can we fully take advantage
of hardware's direct rendering though a GUI toolkit which is designed to
work for various platforms?  I think all those are good for undergrad
thesis subjects (Actually, some of them might be grad level or even
appropriate for dissertation, though they are not "modern" :).

Oh, probably I need to mention use of cache, too.  That could be useful to
implement smooth scrolling.  At the same time, however, we also need to
care about loading time for huge files getting longer and all jump commands
such as G losing their swiftness due to cache creation or update.  Will
people really like Vim more if it gives smooth scrolling like browsers at
the cost of the current file loading and cursor jump behaviors as fast as
lightning?   That question makes the issue really tricky to address.

Surely, anyone who is willing to challenge those issues as well as the ones
mentioned by other people is always welcome and her/ his work is definitely
appreciated.

Best regards,
Kazunobu


- Drop dependency on external diff
> - Implement missing VimScript API for e.g. :signs, :digraphs, (there are
>   probably more features, for which no native VimScript functions
>   exists)
> - Analyse and profile Vim identifying bottlenecks and try to come up
>   with improvements (e.g. 

[doc][patch] There is one extra closing square bracket in document

2017-07-21 Fir de Conversatie h_east
Hi Bram and all,

Patch attached.
--
Best regards,
Hirohito Higashi (h_east)

-- 
-- 
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/eval.txt b/runtime/doc/eval.txt
index add95bc..cc7539f 100644
--- a/runtime/doc/eval.txt
+++ b/runtime/doc/eval.txt
@@ -2179,7 +2179,7 @@ index({list}, {expr} [, {start} [, {ic}]])
 Number	index in {list} where {expr} appears
 input({prompt} [, {text} [, {completion}]])
 String	get input from the user
-inputdialog({prompt} [, {text} [, {completion}]]])
+inputdialog({prompt} [, {text} [, {completion}]])
 String	like input() but in a GUI dialog
 inputlist({textlist})		Number	let the user pick from a choice list
 inputrestore()			Number	restore typeahead


An error on patch 8.0.0736

2017-07-21 Fir de Conversatie Rick Howe
Hello,

I found an error on patch 8.0.0736.
With the following sample function,
'diffthis' and 'diffoff' will cause
"E788: Not allowed to edit anoter buffer now"
on 'wincmd'.

augroup xyz
au!
au OptionSet * call XYZ()
augroup END

function! XYZ()
if expand('') == 'diff'
let c = winnr()
for w in range(1, winnr('$'))
exec w . 'wincmd w'
echo w . ':' . 
endfor
exec c . 'wincmd w'
endif
endfunction

The error does not happens when I removed
++curbuf_lock;
--curbuf_lock;
in set_diff_option() of diff.c.

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Patch 8.0.0739

2017-07-21 Fir de Conversatie John Marriott

On 21-Jul-2017 07:05, Bram Moolenaar wrote:

Patch 8.0.0739
Problem:Terminal resizing doesn't work well.
Solution:   Resize the terminal to the Vim window and the other way around.
 Avoid mapping typed keys.  Set the environment properly.
Files:  src/terminal.c, src/os_unix.c, src/structs.h



After this patch, my build fails on HPUX like so (ok on mingw):
...
    cc -c -I. -Iproto -DHAVE_CONFIG_H -O2    -o 
objects/os_unix.o os_unix.c

cc: "os_unix.c", line 4082: error 1588: "envbuf_Term" undefined.
cc: "os_unix.c", line 4082: warning 563: Argument #1 is not the correct 
type.
cc: "os_unix.c", line 4082: error 1594: The sizeof operator cannot be 
applied to types with unknown size.
cc: "os_unix.c", line 4082: warning 527: Integral value implicitly 
converted to pointer in assignment.
cc: "os_unix.c", line 4082: warning 563: Argument #2 is not the correct 
type.
cc: "os_unix.c", line 4082: warning 526: Pointer implicitly converted to 
integral value in assignment.
cc: "os_unix.c", line 4082: warning 563: Argument #3 is not the correct 
type.
cc: "os_unix.c", line 4083: warning 563: Argument #1 is not the correct 
type.

*** Error exit code 1

Stop.
*** Error exit code 1

Stop.

New variable envbuf_TERM (line 4062) is referred to as envbuf_Term on 
line 4082. Please check the attached patch which attempts to fix it.

Cheers
John

--
--
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.
--- os_unix.c.orig  2017-07-21 07:12:52.120032000 +1000
+++ os_unix.c   2017-07-22 05:55:45.875933500 +1000
@@ -4059,7 +4059,7 @@
 # ifdef HAVE_SETENV
 char   envbuf[50];
 # else
-static charenvbuf_TERM[30];
+static charenvbuf_Term[30];
 static charenvbuf_Rows[20];
 static charenvbuf_Lines[20];
 static charenvbuf_Columns[20];


Patch 8.0.0740

2017-07-21 Fir de Conversatie Bram Moolenaar

Patch 8.0.0740
Problem:Cannot resize a terminal window by the command running in it.
Solution:   Add support for the window size escape sequence.  Make BS work.
Files:  src/terminal.c, src/libvterm/src/state.c


*** ../vim-8.0.0739/src/terminal.c  2017-07-20 23:04:42.967282191 +0200
--- src/terminal.c  2017-07-21 21:05:44.680468274 +0200
***
*** 572,578 
  {
case CAR:   key = VTERM_KEY_ENTER; break;
case ESC:   key = VTERM_KEY_ESCAPE; break;
!   case K_BS:  key = VTERM_KEY_BACKSPACE; break;
case K_DEL: key = VTERM_KEY_DEL; break;
case K_DOWN:key = VTERM_KEY_DOWN; break;
case K_END: key = VTERM_KEY_END; break;
--- 572,579 
  {
case CAR:   key = VTERM_KEY_ENTER; break;
case ESC:   key = VTERM_KEY_ESCAPE; break;
!   /* VTERM_KEY_BACKSPACE becomes 0x7f DEL */
!   case K_BS:  c = BS; break;
case K_DEL: key = VTERM_KEY_DEL; break;
case K_DOWN:key = VTERM_KEY_DOWN; break;
case K_END: key = VTERM_KEY_END; break;
*** ../vim-8.0.0739/src/libvterm/src/state.c2017-07-07 11:53:29.519876497 
+0200
--- src/libvterm/src/state.c2017-07-21 20:53:39.117709279 +0200
***
*** 9,14 
--- 9,16 
  # define DEBUG_GLYPH_COMBINE
  #endif
  
+ static int on_resize(int rows, int cols, void *user);
+ 
  /* Some convenient wrappers to make callback functions easier */
  
  static void putglyph(VTermState *state, const uint32_t chars[], int width, 
VTermPos pos)
***
*** 1396,1401 
--- 1398,1411 
  
  break;
  
+   case 0x74:
+ switch(CSI_ARG(args[0])) {
+   case 8: /* CSI 8 ; rows ; cols t  set size */
+   if (argcount == 3)
+ on_resize(CSI_ARG(args[1]), CSI_ARG(args[2]), state);
+ }
+ break;
+ 
case INTERMED('\'', 0x7D): /* DECIC */
  count = CSI_ARG_COUNT(args[0]);
  
***
*** 1534,1540 
switch(state->mode.cursor_shape) {
  case VTERM_PROP_CURSORSHAPE_BLOCK: reply = 2; break;
  case VTERM_PROP_CURSORSHAPE_UNDERLINE: reply = 4; break;
! case VTERM_PROP_CURSORSHAPE_BAR_LEFT:  reply = 6; break;
}
if(state->mode.cursor_blink)
  reply--;
--- 1544,1550 
switch(state->mode.cursor_shape) {
  case VTERM_PROP_CURSORSHAPE_BLOCK: reply = 2; break;
  case VTERM_PROP_CURSORSHAPE_UNDERLINE: reply = 4; break;
!   default: /* VTERM_PROP_CURSORSHAPE_BAR_LEFT */  reply = 6; break;
}
if(state->mode.cursor_blink)
  reply--;
*** ../vim-8.0.0739/src/version.c   2017-07-20 23:04:42.971282163 +0200
--- src/version.c   2017-07-21 20:50:36.835026706 +0200
***
*** 771,772 
--- 771,774 
  {   /* Add new patch number below this line */
+ /**/
+ 740,
  /**/

-- 
Some of the well known MS-Windows errors:
ESLEEP  Operator fell asleep
ENOERR  No error yet
EDOLLAR OS too expensive
EWINDOWSMS-Windows loaded, system in danger

 /// 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: I want to contribute and chose right project for graduate thesis

2017-07-21 Fir de Conversatie Christian Brabandt

On Fr, 21 Jul 2017, Mario Krajačić wrote:

> Hello,
> 
> I am student of IT from Croatia on finishing year for my bachelor's degree. 
> 
> For the graduate thesis I would like to contribute some open source project. 
> For example it can be  some bug fix. Language in I work is C. My knowledge is 
> shown in programs on git profile: https://github.com/mkrajaci
> 
> Project which I choose will be sent to my professor - mentor who will approve 
> or not difficulty of project.
> 
> Please advice me about how to help you and choose right project.

Hi,
welcome to this community. We really appreciate if someone wants to 
contribute. However, please note, this is a mature OpenSource project 
that has been under development for over 25 years. That means, although 
we are using git, we do not follow the github workflow much. Usually 
patches are committed by Bram, acknowledging the author in the commit 
message (therefore you'll see only one contributor at 
https://github.com/vim/vim/graphs/contributors).

You can create PRs at github and the automatic continuous integration 
system will test that PR against the normal test suite, but they wont 
get merged. Everything is handled by Bram as the project maintainer. 
That also means, that Bram is very busy, so he might not react or review
immediately, so please be patient and the rest of us will try to comment 
and give helpful advises.

That does not mean, that patches are not appreciated, so do not let that 
scare you!

As for what could be done, this depends on your C-skills and the amount 
of time you want to spend. The link to the todo list has already been 
given. However, here are some things that come to my mind, where Vim 
could need some improvements:

- Make the gvim prettier
- Implement smooth scrolling
- Drop dependency on external diff
- Implement missing VimScript API for e.g. :signs, :digraphs, (there are 
  probably more features, for which no native VimScript functions 
  exists)
- Analyse and profile Vim identifying bottlenecks and try to come up 
  with improvements (e.g. relativenumber and cursorline are known to be 
  slow. What could be done to improve performance here?)
- Make concealing work better. (e.g. mouse clicking does not take 
  concealed characters into account)
- See more here: http://vim.wikia.com/wiki/Vim_contribution_Ideas

So if you want to work on Vim, you should make yourself familiar with 
the Code base hang around here at vim-dev and at the github issue 
tracker and try to reproduce problems and find out how to fix them. 
There should be a couple of easy to reproduce bugs on the issue tracker. 
That will help you getting an understanding of how the Code works and 
will help us acknowledge that you really want to contribute ;)

Oh and sorry for the long mail I usually do not write such long mails.

Best,
Christian
-- 
Die Menschen - dies beweiset die Liebe der Kinder - werden nicht zu
den Menschen erst hingewöhnt, sondern nur spät(er) von ihnen
abgewöhnt.
-- Jean Paul

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: I want to contribute and chose right project for graduate thesis

2017-07-21 Fir de Conversatie Ingo Karkat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 21-Jul-2017 11:16 +0200, Mario Krajačić wrote:
> Hello, I am student of IT from Croatia on finishing year for my
> bachelor's degree.
> 
> For the graduate thesis I would like to contribute some open source
> project. For example it can be  some bug fix. Language in I work is
> C. My knowledge is shown in programs on git profile:
> https://github.com/mkrajaci
> 
> Project which I choose will be sent to my professor - mentor who
> will approve or not difficulty of project.
> 
> Please advice me about how to help you and choose right project.

Hello Mario,

Thank you for your willingness to support Vim. The source code (mostly
C code) can be found at [1], this includes instructions for compiling
on the various platforms.

There are many enhancement requests and bug fixes to choose from :-)
Have a look at the Todo list [2], and the issue tracker [3].

If you have any questions / need help, or want to get feedback before
embarking on a bigger task, feel free to ask on this mailing list.

[1] https://github.com/vim/vim
[2] https://github.com/vim/vim/blob/master/runtime/doc/todo.txt
[3] https://github.com/vim/vim/issues

- -- regards, ingo
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJZcie0AAoJEA7ziXlAzQ/vqHIH/3FeouFptHQX5zXqMeUssYhC
fGQOeazDuFix/Pws4GX0HfjG5xaMMvhud0pxNz06X+cZmyC2wlQpyycczxis+1Jb
/of13w1RMOZZDLTbsustpvdsoO4bRnVTRdvKeJbn7Q4y6rRMjPTBsi+Nt20RuclD
9S3jnD9Pf0HACSMCmhDIKXCBVO/OcaaYcgX3/Jrw3swXsYng72D2ArtOuAUFXMLQ
wZyViAgL3+XfYjJ1tKsQxz0YeM0/HMdWfeIlDgwVsYbBsXrbLE0pBR7qxvGgUI9n
DDqZOSTW1ZCHTO+XFS4Q7qc4vduX4c6E4zaq/shGx2xP8syi7MLrHyOYqN8iOF4=
=k/w6
-END PGP SIGNATURE-

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: I want to contribute and chose right project for graduate thesis

2017-07-21 Fir de Conversatie Sven Guckes
* Mario Krajačić  [2017-07-21 12:54]:
> I am student of IT from Croatia on finishing year for
> my bachelor's degree.  For the graduate thesis I would
> like to contribute some open source project. ...  Please
> advice me about how to help you and choose right project.

sounds you are looking for this:

  "I Want 2 Do Project. Tell Me Wat 2 Do." by Shakthi Kannan
  978-935196738-5 Hardback 136 pages 2015-06-01
  http://www.shakthimaan.com/what-to-do.html

enjoy!  :-)

as for the project.. choose one
about the software you are using.
ask on the relevant IRC channels.

be sure about your timeframe.
be realistic about your goals.
keep a log about what you learnt.
talk to your advisor often.

Sven

-- 
Vimfest 2017 on Sep22-24 Fri/Sat/Sun in Berlin
2017-09-22/24 Fr-Sa VimFest http://vimfest.de/
chat via web:http://tinyurl.com/vimfestchat
chat via gitter: https://gitter.im/vimberlin/vimfest
participation:   http://doodle.com/poll/dadrizhcp9uevde8

-- 
-- 
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 to add support for parsing lines using setqflist()

2017-07-21 Fir de Conversatie Yegappan Lakshmanan
Hi,

On Fri, Jul 21, 2017 at 3:13 AM, LCD 47  wrote:
> On 20 July 2017, Yegappan Lakshmanan  wrote:
>> Hi,
>>
>> On Thu, Jul 20, 2017 at 6:59 AM, Yegappan Lakshmanan
>>  wrote:
>> > Hi,
>> >
>> > I am investigating a memory leak reported by valgrind with this
>> > patch.
>> >
>>
>> I am attaching an updated patch with the fix for this memory leak and
>> additional tests.
>>
>> Once this patch is incorporated, output can be parsed using
>> 'errorformat' and resulting entries can be added to any
>> quickfix/location list by using setqflist().
>
> Sadly, this still won't allow one to parse errors with errorformat
> to a list in memory, disconnected from the stack.
>
> You see, the problem with the stack is that in order to use it in
> a plugin beyond basic lolder / lnewer navigation, you need to assume
> your plugin is the only one manipulating said stack.  If another plugin
> comes into picture and you try to accomodate it, it immediately becomes
> an uphill battle.  There is no way to keep track which loclist belong
> to which plugin, and there is basically no way to tell the state of the
> stack.
>

A plugin can associate a context with a quickfix/location list
and also save the quickfix/location list number. By checking the context,
the plugin can make sure that it is updating the correct list.
Of course, this will work only if all the plugins start using/checking the
context information before updating the quickfix list.

>
>  The other plugin can add or remove entries, and there is no way
> for you to detect that.  You could look at the number of elements, but
> once the stack gets full that number becomes useless.  You could hook
> to autocmds, but quickfix commands can be run silent.  You could keep
> track of the stack pointer, but the other plugin can play tricks with
> the stack pointer too.  In fact I'd be very curious to see a plugin do
> something useful with the quickfix / loclist stack without asserting
> exclusive ownership to it.  As it is, it's simply too user-hostile.
>
> Ok, I'll crawl under my rock now, this is likely to be my last
> message on this topic.
>

The current quickfix implementation is heavily tied to managing a
list in the quickfix stack. I am incrementally making changes to
unwind some of these dependencies and cleaning up the code.
The support for creating and managing a quickfix list in memory
is coming.

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


I want to contribute and chose right project for graduate thesis

2017-07-21 Fir de Conversatie Mario Krajačić
Hello,

I am student of IT from Croatia on finishing year for my bachelor's degree. 

For the graduate thesis I would like to contribute some open source project. 
For example it can be  some bug fix. Language in I work is C. My knowledge is 
shown in programs on git profile: https://github.com/mkrajaci

Project which I choose will be sent to my professor - mentor who will approve 
or not difficulty of project.

Please advice me about how to help you and choose right project.


* God bless You! *

-- 
-- 
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 to add support for parsing lines using setqflist()

2017-07-21 Fir de Conversatie LCD 47
On 20 July 2017, Yegappan Lakshmanan  wrote:
> Hi,
>
> On Thu, Jul 20, 2017 at 6:59 AM, Yegappan Lakshmanan
>  wrote:
> > Hi,
> >
> > I am investigating a memory leak reported by valgrind with this
> > patch.
> >
>
> I am attaching an updated patch with the fix for this memory leak and
> additional tests.
>
> Once this patch is incorporated, output can be parsed using
> 'errorformat' and resulting entries can be added to any
> quickfix/location list by using setqflist().

Sadly, this still won't allow one to parse errors with errorformat
to a list in memory, disconnected from the stack.

You see, the problem with the stack is that in order to use it in
a plugin beyond basic lolder / lnewer navigation, you need to assume
your plugin is the only one manipulating said stack.  If another plugin
comes into picture and you try to accomodate it, it immediately becomes
an uphill battle.  There is no way to keep track which loclist belong
to which plugin, and there is basically no way to tell the state of the
stack.  The other plugin can add or remove entries, and there is no way
for you to detect that.  You could look at the number of elements, but
once the stack gets full that number becomes useless.  You could hook
to autocmds, but quickfix commands can be run silent.  You could keep
track of the stack pointer, but the other plugin can play tricks with
the stack pointer too.  In fact I'd be very curious to see a plugin do
something useful with the quickfix / loclist stack without asserting
exclusive ownership to it.  As it is, it's simply too user-hostile.

Ok, I'll crawl under my rock now, this is likely to be my last
message on this topic.

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