On 07-May-2013 21:44 +0200, ZyX wrote: >> The functions in message.c write message with color attributes. So if >> splitting per line, it must get whole contents at the first. >> I guess someone want to get the contents as text which contains \n, but >> someone want to get the contents as array of lines. So I want to keep the >> contents as text. >> >> Thanks. > > Almost never used not splitted messages (they were only needed by me in case > there is only one line of output; and only because splitting one line does > not make much sense; code with proposed by @Ingo Karkat implementation of > `capture()` is not a tiny bit harder to write in this case).
Yes, that's what I thought. Thanks for this data point! > I have another proposal: You bring up very good points; I fully agree. > 1. Fix :redir to allow nesting. I think everyone agrees with this, and it should be first priority. > 2. Fix :redir to hold reference to dictionary containing variable (like l:, > g:, s: or such) to workaround problem I mentioned in > https://groups.google.com/forum/#!searchin/vim_dev/redir/vim_dev/1M3QS46SrAk/a13SqNpPWywJ. > Obviously only in case redirecting to variable. I don't fully understand, but as long as it's backwards compatible, additional syntax, why not!? > 3. Make :redir automatically end when function ends if it holds reference to > l:. In any case I doubt anybody needs to start redir in one function and end > in another and do redirection to function-local variable at the time. This > also must workaround stale :redir's left due to an exception (plugin authors > almost always capture to function-local variables). This would alleviate a common programming error. Currently, all :redir commands have to be wrapped in try..finally to be safe, but few people do this. > 4. (optional) Add capture() function, but it should return a list of lists of > dictionaries: > > [ > [{'hl': "Error", 'text': "Error on first line"}, {'hl': "OtherHL", > 'text': "Other highlight in first line (possible when using :echon)"}], > [{'hl': "Normal", 'text': "Regular message on second line"}], > ] > > . It is useful in some cases (like any use of :redir this cases happen > mainly because of problems in API: distinguishing between `<LT>Space>` and > `<Space>` in :map output (current code I use assumes nobody needs to define > mapping like `<LT>F1>`; assumption has not proved false by the time, but > having to use it bugs me); distinguishing between regular text and special > characters in messages (don’t remember when I needed this, but there was some > case)). Good idea. I had this need once with the :jumps output: Without the highlighting information, I had to implement a 99%-successful heuristic to decide whether the line refers to the current buffer or another file. It would be even better if the (mostly column-based) information issued by most commands came pre-parsed, but that probably would mean modifying all command implementations. > 5. (optional) Extend syntax of :redir to capture to a list of lines. Since this only applies for redirecting into a variable (not files or registers), I'd rather not further complicate the existing :redir command with this. Instead, if your proposal 4. capture() is implemented, have it take an argument {includeHl}, and just return a list of lines (without the Dictionary stuff) if 0 is passed. Most uses don't need the highlighting; this would make the function applicable to more use cases. I'd love to have all of those good enhancements, but I know that unless someone now starts working on a patch, this great discussion will again fizzle out, like so many before. -- regards, ingo -- -- 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/groups/opt_out.
