Hi!
I have made a readtable-related pull request long time ago, it was not merged because it was breaking things that worked before.
So I suggest to discuss another approach to SLIME + NAMED-READTABLES cooperation.
Please see the essay here:
https://bitbucket.org/budden/clcon/src/e3c40c555295336a3a13c506cce6a179f9dd8...
Hi budden,
On Wed, Aug 2, 2017 at 12:33 PM, 73budden . budden73@gmail.com wrote:
I have made a readtable-related pull request long time ago, it was not merged because it was breaking things that worked before.
So I suggest to discuss another approach to SLIME + NAMED-READTABLES cooperation.
I can see how it's useful to write down your train of thought to reach your current position about how named-readtables should be better support in SLIME. Can you write down a summary of what your recommended solution is?
Cheers,
Hi! Here is a more detailed description of my suggested solution
https://bitbucket.org/budden/clcon/src/1685075f335bd6ae5ec3d13a2423b46ff8ae1...
2017-08-11 17:33 GMT+03:00, Luís Oliveira luismbo@gmail.com:
Hi budden,
On Wed, Aug 2, 2017 at 12:33 PM, 73budden . budden73@gmail.com wrote:
I have made a readtable-related pull request long time ago, it was not merged because it was breaking things that worked before.
So I suggest to discuss another approach to SLIME + NAMED-READTABLES cooperation.
I can see how it's useful to write down your train of thought to reach your current position about how named-readtables should be better support in SLIME. Can you write down a summary of what your recommended solution is?
Cheers,
-- Luís Oliveira http://kerno.org/~luis/
On Sun, Aug 13, 2017 at 9:33 PM, 73budden . budden73@gmail.com wrote:
Here is a more detailed description of my suggested solution
I was looking for an executive summary rather than more detail. :-)
In any case, your proposal generally makes sense to me. I have a question though: what should happen in the REPL? Following the spirit of your solution, it seems like we should have a new change-readtable operation. How should we represent the current readtable visually? Also, it seems like it might be useful to have some concept of default readtable for a given package: perhaps there's still a use for *readtable-alist* after all?
Hi!
Sorry, I didn't get what you meant :) Anyway, the quesion is still open if the change suggested would break someone's things, so I hope it is not a big harm to give more details.
And I had to update my proposal due to your questions - now it has even more details :) Link follows:
https://bitbucket.org/budden/clcon/src/9b3ecf3dce35a6978c57352dfc54f4a1653ac...
2017-08-17 1:31 GMT+03:00, Luís Oliveira luismbo@gmail.com:
On Sun, Aug 13, 2017 at 9:33 PM, 73budden . budden73@gmail.com wrote:
Here is a more detailed description of my suggested solution
I was looking for an executive summary rather than more detail. :-)
In any case, your proposal generally makes sense to me. I have a question though: what should happen in the REPL? Following the spirit of your solution, it seems like we should have a new change-readtable operation.
I suggest to keep (in-readtable), but it does not touch *readtable-alist* for a packages or readtables from an exclusion list. More important, (in-package) for those packages won't change *readtable* anymore. So no new operation is required.
But current behavior is a violation of standard. I remember when I suggested this change last time, I faced some objections from SLIME users, but IMO
How should we represent the current readtable visually?
Also, it seems like it might be useful to have some concept of default readtable for a given package: perhaps there's still a use for *readtable-alist* after all?
I don't think so, there is no concept of default readtable for the package in the standard, so the user would have to change a readtable explicitly. I understand it is inconvenient. So right thing might be the following:
1. Add (swank:in-package-and-readtable :package) form which would take the readtable from *readtable-alist* 2. Learn SLIME to recognise this form in editor files like it recognizes in-package now.
The only disadvantage here is a confusion which can originate from interaction of *readtable-alist* and exclusion list. With my current suggestion, we can keep *readtable-alist* and exclusion list disjoint. If we introduce the concept of default readtable for package, *readtable-alist* now serves for two goals and this is not that clear.
How should we represent the current readtable visually?
It would be nice to show it on a toolbar for editor buffers, but for REPL I think it is not hard to enter *readtable* and press return :) After all, currently we also can't see the readtable.
-- Luís Oliveira http://kerno.org/~luis/
On Fri, Aug 18, 2017 at 1:03 PM, 73budden . budden73@gmail.com wrote:
Sorry, I didn't get what you meant :) Anyway, the quesion is still open if the change suggested would break someone's things, so I hope it is not a big harm to give more details.
I suggest we move on to pull request #278 then. Maybe you can start by rebasing/merging against latest master?
Cheers,
Good idea, but this PR does not implement my current suggestion. I have to work on code for a while. Before I start, I'd like to know do you (or does anyone) see any more issues with the solution described?
2017-08-18 16:39 GMT+03:00, Luís Oliveira luismbo@gmail.com:
On Fri, Aug 18, 2017 at 1:03 PM, 73budden . budden73@gmail.com wrote:
Sorry, I didn't get what you meant :) Anyway, the quesion is still open if the change suggested would break someone's things, so I hope it is not a big harm to give more details.
I suggest we move on to pull request #278 then. Maybe you can start by rebasing/merging against latest master?
Cheers,
-- Luís Oliveira http://kerno.org/~luis/
Tracking in-readtable forms and passing the readtable designator along in evaluation/compilation requests sounds consensual. Let's start with that, what do you think?
Cheers, Luís
On Fri, Aug 18, 2017, 17:15 73budden . budden73@gmail.com wrote:
Good idea, but this PR does not implement my current suggestion. I have to work on code for a while. Before I start, I'd like to know do you (or does anyone) see any more issues with the solution described?
2017-08-18 16:39 GMT+03:00, Luís Oliveira luismbo@gmail.com:
On Fri, Aug 18, 2017 at 1:03 PM, 73budden . budden73@gmail.com wrote:
Sorry, I didn't get what you meant :) Anyway, the quesion is still open if the change suggested would break someone's things, so I hope it is not a big harm to give more details.
I suggest we move on to pull request #278 then. Maybe you can start by rebasing/merging against latest master?
Cheers,
-- Luís Oliveira http://kerno.org/~luis/
Hi! Do you mean that in any case (in-readtable) form should have a priority over *readtable-alist*? Let's speculate about it a bit.
Could the change break something? I guess no: if someone have this form in the file, then it modifies *readtable-alist* already every time the file is loaded.
So it looks like this change can make no harm. I think we don't even need exception list for now - just we don't need to alter named readtables at all for this change. Does that sound like a truth?
If so, this is a part of what I had implemented already, so I can start re-applying it as soon as I find a time (in a several days).
2017-08-18 22:02 GMT+03:00, Luís Oliveira luismbo@gmail.com:
Tracking in-readtable forms and passing the readtable designator along in evaluation/compilation requests sounds consensual. Let's start with that, what do you think?
Cheers, Luís
On Fri, Aug 18, 2017, 17:15 73budden . budden73@gmail.com wrote:
Good idea, but this PR does not implement my current suggestion. I have to work on code for a while. Before I start, I'd like to know do you (or does anyone) see any more issues with the solution described?
2017-08-18 16:39 GMT+03:00, Luís Oliveira luismbo@gmail.com:
On Fri, Aug 18, 2017 at 1:03 PM, 73budden . budden73@gmail.com wrote:
Sorry, I didn't get what you meant :) Anyway, the quesion is still open if the change suggested would break someone's things, so I hope it is not a big harm to give more details.
I suggest we move on to pull request #278 then. Maybe you can start by rebasing/merging against latest master?
Cheers,
-- Luís Oliveira http://kerno.org/~luis/
Yes, I agree. Let's have in-readtable take priority.
On Sat, Aug 19, 2017, 08:03 73budden . budden73@gmail.com wrote:
Hi! Do you mean that in any case (in-readtable) form should have a priority over *readtable-alist*? Let's speculate about it a bit.
Could the change break something? I guess no: if someone have this form in the file, then it modifies *readtable-alist* already every time the file is loaded.
So it looks like this change can make no harm. I think we don't even need exception list for now - just we don't need to alter named readtables at all for this change. Does that sound like a truth?
If so, this is a part of what I had implemented already, so I can start re-applying it as soon as I find a time (in a several days).
2017-08-18 22:02 GMT+03:00, Luís Oliveira luismbo@gmail.com:
Tracking in-readtable forms and passing the readtable designator along in evaluation/compilation requests sounds consensual. Let's start with that, what do you think?
Cheers, Luís
On Fri, Aug 18, 2017, 17:15 73budden . budden73@gmail.com wrote:
Good idea, but this PR does not implement my current suggestion. I have to work on code for a while. Before I start, I'd like to know do you (or does anyone) see any more issues with the solution described?
2017-08-18 16:39 GMT+03:00, Luís Oliveira luismbo@gmail.com:
On Fri, Aug 18, 2017 at 1:03 PM, 73budden . budden73@gmail.com
wrote:
Sorry, I didn't get what you meant :) Anyway, the quesion is still open if the change suggested would break someone's things, so I hope it is not a big harm to give more details.
I suggest we move on to pull request #278 then. Maybe you can start by rebasing/merging against latest master?
Cheers,
-- Luís Oliveira http://kerno.org/~luis/
-
73budden . -
Luís Oliveira