freenode/#clim - IRC Chatlog
Search
8:52:10
scymtym
i think INDENTING-OUTPUT should move the stream cursor before executing the body. it currently doesn't which means that e.g. (with-indented-output (stream) (formatting-table (stream) …)) will not be indented. any opinions?
8:55:57
scymtym
i didn't know about INDENTED-OUTPUT as well (more likely: i did know at some point but forgot)
8:57:41
jackdaniel
I need to look at DW documentation and see what useful features my margin-mixin could steal
9:04:52
loke
Seems there are a lot of deatures that I never knew about. I might have reimplemented all of this stuff for no good reason
9:05:27
loke
When presenting a presentation to a stream, is there a way to sepcify where the baseline should be?
9:06:36
jackdaniel
if you know the baseline coordinate, you just need to set cursor position to baseline-x - font-ascent
9:07:04
loke
jackdaniel: Yeah. I was asking because, assuming all of these things you're doing (which I havent' tested yet) is working, then the only feature my code has is the ability to specify an arbitrary baseline for added output records.
9:07:36
loke
I.e. it might be time to rip out my custom code and move back to the normal textual views.
9:08:36
jackdaniel
you may set the cursor position (hence initial baseline). keep in mind though, that if you write text with different style (i.e bigger), baseline will adjust. see introduction to 15.3
9:10:19
loke
jackdaniel: My custom code does precisely what you were talking about doing; waiting untim a line has been filled until actually painting it, so that the Y-coordinate can be adjusted to accommodate for larger text. Now, in my code, this adjustment also takes into accouint he positions (relative to baseline) of aded output records.
9:10:20
jackdaniel
I rarely use such words, but this restriction seems to be something idiotic. like: you may use the internet, but you can't. but you can if you really want via proxy, so this is not really a security measure.
10:15:17
jackdaniel
standard-extended-output-stream: "This class provides an implementation of the CLIM extended output stream protocol, based on the CLIM output kernel."
10:16:24
jackdaniel
as of extended-output-stream there seems to be nothing in the spec mandating them to be sheets (only output-streams + implement extended output streams protocol)
10:17:09
jackdaniel
for all practical purposes you want to subclass clim-stream-pane, which is guaranteed to implement recording, display and that it is a pane (hence a sheet)
10:20:58
scymtym
thanks. i'm asking because a missing method prevents WITH-SHEET-MEDIUM from working on INDENTED-OUTPUT-STREAM (or any STANDARD-ENCAPSULATING-STREAM, probably)
10:21:30
scymtym
i suspect INVOKE-WITH-SHEET-MEDIUM-BOUND should be implemented for STANDARD-ENCAPSULATING-STREAM
10:47:45
jackdaniel
encapsulating stream will delegate the question and return correct medium (no need to doing unwrap yourself)
10:49:37
jackdaniel
also regarding extended-output-stream which is not a sheet: I can imagine a wrapper around foreign console controls implementing this protocol
10:50:59
scymtym
such a restricted stream wouldn't interact with the issue i discovered since it involves bordered output
10:51:40
jackdaniel
yes, I mean that sheet-medium has a specialization on encapsulating stream (not that i-w-s-m-b has)
10:55:16
jackdaniel
I think that you can use def-stream-method (as defined in encapsulate.lisp) to be consistent with how encapsulated methods are defined
10:58:14
jackdaniel
alright. would you mind giving some input on this: https://github.com/McCLIM/McCLIM/issues/680
10:59:25
scymtym
i followed the discussion loosely and i think i agree with your conclusions. i will have to take a closer look later
11:01:07
jackdaniel
three most widespread issues in McCLIM are: threading issues and off-by-one errors.
14:48:42
scymtym
array commands and slime-style navigation: https://techfak.de/~jmoringe/new-inspector-2.ogv
14:51:34
jackdaniel
I think I have a brilliant idea about sheets and pages, still working out details
15:14:15
scymtym
jackdaniel: no. everything is still uncertain. my current employment will very likely end in october so there is that
15:15:31
beach
scymtym: I think some improved demos when you are further along would make people much more excited and therefore more likely to support. No rush of course.
15:17:59
scymtym
beach: possibly. i'm not sure how many #lisp participants envision clim-based tools in their lisp development workflow. some seem eager to even revert from "graphical" emacs to a purely terminal-based environment
15:18:52
jackdaniel
I still haven't abandoned the idea of writing terminal-based backend to discover rough edges regarding unit assumptions
15:19:22
jackdaniel
so it is not impossible that your interactor will work in terminal-based environment too ;-)
15:21:05
beach
And, in my opinion, that's the right way of doing it. Use the full CLIM machinery for presentations and such. Then have a terminal backend, likely with a subset of all the features, but still workable.
15:21:23
scymtym
i still think that making everything as modular as possible and supporting things like the language server protocol is the best way to satisfy as many people as possible (aside from the technical benefits)
15:21:59
jackdaniel
beach: apparently terminal has more features than clim! https://terranostra.one/posts/ASCII-Art-Animations-in-Lisp.html ;-)
15:26:05
jackdaniel
(I think that fully-featued interactor is ambitious enough - I'm curious because I have a few ide-part projects in mind too)
15:28:11
scymtym
jackdaniel: i don't know yet. though an actual /integrated/ development environment may be the easiest to sell as a project proposal
15:28:16
jdz
jackdaniel: Apparently terminal has even more features: https://github.com/hackerb9/lsix
15:29:06
jackdaniel
jdz: yes, I'm aware of sixel graphics - nice thing though if I need graphics I'd use a graphical toolkit not a terminal ^_^
17:00:08
jackdaniel
I already render all lines (partial fix is in input-refactor branch), but if there is no new line after last line we miss that (page-break wise and scroll-wise)
17:13:19
Inline
the correction of (count (- width (mod column tab-width)))) to (if (= tab-width 0) 1 (- tab-width (mod column tab-width))))) and then putting immediately a line (decf offset count) solves the problem
17:33:40
Inline
initially the loop does not stop at 0 when you observe the >= stuff, it has one more cycle left so to say, but with 0 it bails out and no chance of preventing that, but when you give 1 as a result of the mod operation and decrement just afterwards then one didn't change the cycle count and the relative offset differences (offset offset2) remain constant, otherwise we introduce a off-by-one error and you get something
17:35:15
Inline
my previous <= was a total noob fail, since it corresponds to a no-op, and i was wondering why it was so fast (cause it didn't change the tabification of the opened file at all)