freenode/#clim - IRC Chatlog
Search
12:03:43
jackdaniel
loke: do you have in mind valid use case (for the application programmer) to use clime:clear-selection? similar question applies to clime:clear-clipboard
12:04:39
jackdaniel
(for clime:clear-clipboard there is one more question: do you have in mind *any* valid use case, even for internal protocols)
13:35:03
loke
jackdaniel: When you copy/paste a password. You want to clear it from the clipboard afterwards.
13:35:50
loke
Also, if the object you've put on the clipboard is large, and you want to allow it to be GC'ed
13:43:06
loke
Hmm... now that I think about it, the selection is always cleared when the shift-dragged text is unselected.
13:53:28
jackdaniel
also I think (and I'll share the details when I'm done with flow analysis), that selection protocol should be internal and mixed into basic-port (with clx specializing on it in :after method)
13:54:37
jackdaniel
I have more remarks, but this has to wait. I've started going through actual workings of your change. I've also identified some race issues which are easy to fix (I suppose)
13:54:39
loke
I was more considering implementing a fallback implementation that would work enever the backend doesn't support it.
13:55:56
jackdaniel
as of copy being an actual command, I'm still concerned (and unsure what to do about it); it is not a command in clim sense, but we clearly want to have it as a "selectable" action
13:58:43
loke
What I would like to do is to have an ability to specify whether a command should be added to the history or not. There doesn't _seem_ to be such a capability available.
14:02:50
loke
Basically, I have "special" commands that perform specific operations, and I don't want them to appear in when I meta-p through the history. I just want the Maxima commands to show up.
14:08:34
loke
jackdaniel: I have a proposal that would allow me to do what I want, and at the same time not make any other changed
14:08:56
loke
I propose we make PRESENTATION-HISTORY-ADD into a generic function instead of a regular function.
14:09:21
loke
That allows an application to alter what goes into the history (if anything) depending on type.
14:53:52
jackdaniel
i.e if there are more functions which manipulate presentation history, then it should be consistent
14:54:05
jackdaniel
also, if we are going to promote it for external protocol, then it should be documented
14:55:18
jackdaniel
speaking of: I think your pull request doesn't have a documentation draft, are you waiting for our peer review ping pong to end (so you have something finalized to document) or there are other reasons?
14:56:31
jackdaniel
one remark you may think about right now: generic functions meant to be implemented by backend should be exported from clim-backend package
14:56:58
jackdaniel
climb package "uses" clim and clim-extensions packages, so there won't be conflict
14:59:18
loke
Most of the functions were moved to clim-external, remember? It used to be split in a frontend and a backend.
14:59:33
loke
but then it was merged into a single function, which obviously have to be in the clim-externals
15:00:07
jackdaniel
and as I said, "clim-backend" uses "clim-extensions", so there won't be conflicts
15:00:43
jackdaniel
some protocols are implemented in backend (hence should be in climb package) and used in extensions (hence should be in clime package)
15:01:11
loke
jackdaniel: Yes. that was how I made it. Do you have an example of a funciton which is not in the correct place?
15:01:16
jackdaniel
i.e copy-to-clipboard is implemented for each backend specifically (so it should be in climb), it is also part of programmer api, so it should be in clime
15:46:17
jackdaniel
nb: I hope you do not mind that I have so many remarks – I have them because I want this change and I want it to be sustainable; probably we are both tired of this PR ;-)