Add region comment support for vi-mode and region commands

[Sasanidas]

• Change set-region-point to a generic to facilitate extension
• Add help function current-global-mode-keyword-name on lem-core
• Add implementations of set-region-point for emacs and vi-mode global mode

[Sasanidas]

Interesting, the linter is triggering "simple-warning: The function EQL is called with one argument, but wants exactly two."
But the eql in that case is a method specializer, which AFAIK it's a correct way to use it
https://github.com/lem-project/lem/actions/runs/7118673847/job/19382116290?pr=1176#step:4:390

[Sasanidas]

I just removed the key specifier and seem to work now 👍

[Sasanidas]

So, I expanded the issue, adding support for other modes when using the region option "r".

The thing is, vi-mode has another way of understanding a region but both vi-mode and emacs-mode have the understanding of the beginning of their "regions", so with generics I can get the current global-mode and dispatch the correct one.

In some cases, I decided not to change the original function with a generic mostly for performance reasons (https://github.com/lem-project/lem/pull/1176/files#diff-2240c3cc423763222d7a831b2ed8631486b6f41f5f9cf384b0af0954a2d252b4L264).

Given that the region management is from the lem-base package that at this point, is already locked, I also had to unlock it to add the methods and then lock it away.

There is the improvement of exporting some symbols that are called with double dots ::

[Sasanidas]

An interesting "bug" is that given the nature of the vi-mode region, when calling a region command with M-x doesn't work, because it removes the overlay. So in order to get the correct region, the command has to be bind to a key combination.

[Sasanidas]

This PR is ready to be merge, any reason why not to merge it? (ping @cxxxr )

[vindarel]

Don't we want a SBCL feature flag? Or see https://quickdocs.org/cl-package-locks which defines lock/unlock for 4 implementations.

[Sasanidas]

Oh indeed, nice catch, I'm not sure If I want to add another package, but I'll use a flag for that expression 👍

[cxxxr]

Why do you need to use current-global-mode-keyword-name instead of current-global-mode?

[Sasanidas]

https://github.com/lem-project/lem/pull/1176/files#r1444574079

[cxxxr]

I think it would be better to define a new method (e.g. set-region-point-using-global-mode) that takes global-mode as an argument, with set-region-point as the default value. What do you think?

[Sasanidas]

Indeed, we can change the name of the function to reflect it, and at this point we can use the global-mode symbol so that's a good option too

[cxxxr]

I cannot accept this kind of barbaric behavior.

[Sasanidas]

Fair, I also think it's kind of ugly, but I would have to change a lot of how lem is written to accommodate an improvement approach. I'll dig around and see what I can do, thanks for the feedback 👍

[cxxxr]

The concept of global-mode does not exist at the time of loading lem-base.
This causes interdependencies between lem-base and lem-core.

[Sasanidas]

That's why I'm using keywords to dispatch the global modes, as in this stage lem/base doesn't have the concept yet. But we can always work with keywords.

[Sasanidas]

So, I think I address most of issues, these are the changes I made:

• I extract the functions to a package called lem-generics, the idea of this package is to have generics with a default behaviour that other packages can extend (like in this case).

• As point out, I changed the methods to accept the global-mode itself instead of the keyword, now that the function is not in the base package.

With these changes, the functionality remain the same, but the code should be more in line with the Lem codebase.

(ping @cxxxr for the review)