Delimiters between items in the stdout buffer?

[mars0i]

I love that iced_print_last pretty-prints data, including syntax highlighting, by the way.

When using Clojure to generate or manipulate data, I repeatedly display data structures using iced_print_last. For example, might display a vector of pairs of doubles, and then display a vector of pairs of doubles that is a transformed version of the first vector. This means that one vector is immediately below the other, and it can be visually difficult to see immediately where one ends and the next begins. This is especially true if the vectors are large, and I am scrolling quickly to find out where the second vector starts.

Similarly, if I cause an error, so that there's a stacktrace in the stdout buffer, and then cause another error, I will quickly scroll up to find the beginning of the second error. It would be easier to find this if there was a break between the stacktraces.

For the first case, in my local copy of autoload/iced/nrepl/eval.vim, I added "----\n" . to the line

call iced#buffer#stdout#append(a:resp['value'])

in the definition of iced#nrepl#eval#print_last(). This is much nicer for me; I can see where the data structures start and end now. (I don't know why simply adding "\n" . doesn't have any effect.)

(I haven't tried to figure out how to do something similar with stacktraces, but I am more concerned with displaying data.)

That solves my problem, but now I might have to add the "----" visual delimiter again if the release version of eval.vim is changed.

I don't know whether there are other people who would like to be able to insert a blank line or other delimiter between items in the stdout buffer. Not everyone would like that, I think, because (a) it uses up screen space, and (b) it could be confusing if someone runs println, prn, etc., and they don't know whether what is added to the stdout buffer comes from their print statements or something that vim-iced is adding. So I am not arguing that vim-iced should always insert a blank line or some delimiter text between items in the stdout buffer.

In my case I don't mind wasting the extra screen space, and I am not worried about being confused about print statements.

What do you recommend, @liquidz ? Do you think it would be worth adding a user configuration to add a delimiter between items in the stdout buffer? I would like that, personally, but if no one else would use such a feature, then maybe it would clutter up the vim-iced source code. It's not always good to add new features.

(If any other vim-iced users read this issue, perhaps they will have comments.)

[liquidz]

@mars0i Thanks for your suggestion!

In my case I don't mind wasting the extra screen space, and I am not worried about being confused about print statements.

Me too.

What do you recommend, @liquidz ? Do you think it would be worth adding a user configuration to add a delimiter between items in the stdout buffer?

Other than iced_print_last, I too sometimes put in delimiters manually, so it would be useful for me to have them automatically. We can fix iced_print_last and stack traces individually, but personally I would be happy to have a delimiter even for print statements.

So, for example, if we add a delimiter after a certain time has elapsed since the last append, we can add a delimiter to print statements, including iced_print_last and stack traces at once. I've implemented it in the feature/stdout-buffer-delimiter branch for trial, so could you try it?

Currently, the time to add delimiters is set to 500 ms, but it can be customized by g:iced#buffer#stdout#delimiter_delay. https://github.com/liquidz/vim-iced/blob/eb77d533642bf8cc410574e284a9da02eae245eb/autoload/iced/buffer/stdout.vim#L21-L22

[mars0i]

@liquidz, so far, this works very well. Thank you!

I don't mind delimiters between print statements, either.

I experimented with changing the delay time, making it larger and smaller, and it seems to work the way that one would expect.

This seems like a good solution to me, because if someone doesn't want delimiters at all, they can set delimiter_delay to a large number--something that will be more milliseconds than the maximum time that they would leave vim or nvim running.

[liquidz]

@mars0i Sorry for late merge. Just released v3.10.0 #422

[mars0i]

Not a problem for me. I'm grateful that you put out releases as often as you do.