Dealing with feature conflicts

[tarsius]

Hello,

This is a follow up to issue #15 from five years ago.

In that pull-request I suggested that you "hide" certain libraries that conflict with libraries that have the same names but are part of other packages. You replied to that suggestion with:

We dont need to do this because for now, I'm making sure to mirror over the bundled libs from Emacs@head. Over time, as Emacs 25 becomes widespread, I'm planning to delete the bundled libs ---so I'd rather not create a mechanism that makes such bundling an accepted solution.

I too prefer dealing with this "properly" but unfortunately that hasn't happened. So I am renewing my request to deal with this, and also to offer my help to do so.

But first I would like to explain why I care about this. I am sure you understand why feature conflicts are bad in general, so I won't bore you with the basic argument. I maintain the Emacsmirror a collection of currently 8100 packages and I try to make sure there are no feature conflicts between any of these packages. Maybe I am crazy for doing this but while this is a lot of work, I am very satisfied with the result.

Currently I am patching 16 packages on the Emacsmirror. About a dozen of them are patched because they bundle libraries they shouldn't bundle, and I couldn't get the maintainers to do something about it. That's 16 out of 8100 packages, which I think is pretty good!

Anyway there is one package left that has feature conflicts and which I have not patched yet: emacspeak. The reason I have not patched it yet is that doing so would risk breaking it for users who get it through the Emacsmirror. I don't know whether there actually any users who do that but still emacspeak is more important to its users than any of the other packages to their respective users.

Then again, it is now the only package out of 8100 with feature conflicts, so I would really like to address those conflicts. This will of course involve work for you but I am also willing to do a lot of the work with your guidance.

Let me list the libraries again, that conflict with libraries from other packages:

1. nm.el. There are actually two diverging copies of that file within emacspeak itself: lisp/nm.el and tvr/obsolete/nm.el. This seems like it might be an accident, so maybe we could start with this.
2. Two games: lisp/tetris.el and tvr/sudoku.el. We could deal with those next. If something goes wrong in the process, that is not the end of the world. I briefly compared tetris.el from emacspeak and from emacs and it seems your copy does not offer anything extra, it's just different due to how long ago the two versions have diverged. Maybe I missed something.
3. tvr/analog.el is an outdated copy of the one at https://github.com/emacsattic/analog
4. lisp/tapestry.el is nearly identical to the one from the VM package; only the autoload cookies are missing from your copy. VM isn't being maintained anymore, but I pseudo-maintain it in the emacsorphanage and would be willing to remove that library from there and maintain it in a separate repository, so that you could use it without having to depend on all of VM.
5. lisp/amixer.el conflicts with another independent package. I would recommend that you prefix the library name and all the symbol names with emacspeak-.

So what do you think; are you willing to work through this list with my help?

Cheers, Jonas

[tvraman]

Jonas Bernoulli ***@***.***> writes: Responses in-lined, thank you for the explanation of your reason for caring. 1. Everything under obsolete is there merely for convenience in case I need to retrieve something and dates back to a habit that preceded my becoming fluent with git and magit. None of them are packaged with emacspeak, eg when building the tarball; see top-level make dist rule.

1 nm.el. There are actually two diverging copies of that file within emacspeak itself: lisp/nm.el and tvr/obsolete/nm.el. This seems like it might be an accident, so maybe we could start with this.

I created nm.el from one of the copies on the Web; it is a small enough piece that namespacing it felt like overkill; let's place it on the todo list.

2 Two games: lisp/tetris.el and tvr/sudoku.el. We could deal with

These are here because a slight change in the mainline tetris (display chars from memory) broke the emacspeak binding. In my view, that change upstream was superfluous, but reporting it generated a "go away, dont bother us " response. For emacspeak, tetris was mostly a research proof-of-concept and the one bundled with emacspeak works with emacspeak, so there is no point in futzing with it ditto for sudoku -- so let's not take on busy work. The only negative is shadowing, but that shadowing only affects the emacspeak user and it does the right thing.

3 tvr/analog.el is an outdated copy of the one at https://github.com/emacsattic/analog

I suppose I could just delete that copy of analog.el in the emacspeak repository but in general tvr/ is not part of the emacspeak distrib, it's my personal emacs configuration --- AKA happy to clean that up, but it shouldn't affect emacspeak users who install via the tarball; if users mirror my personal setup, they get my personal quirks.

4 lisp/tapestry.el is nearly identical to the one from the VM package;

Emacspeak actually uses this, and taking it out because "vm has it" will mean that every emacspeak user will have to install vm, so No, am not going to take it out. Sad vm is not maintained any more, I still actively use VM:-)

it in a separate repository, so that you could use it without having to depend on all of VM. 5 lisp/amixer.el conflicts with another independent package. I would

Again lisp/amixer is one I wrote, it is only distributed with emacspeak; so the shadowing does the right thing. I could of course namespace amixer with emacspeak- but it's busy work.

recommend that you prefix the library name and all the symbol names with emacspeak-. So what do you think; are you willing to work through this list with

I'm willing to work through it where it makes sense, see above.

…

--Raman

my help? Cheers, Jonas — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

-- Thanks,

--Raman(I Search, I Find, I Misplace, I Research) ♈ Id: kg:/m/0285kf1 🦮

[tarsius]

Would you be willing to merge #55?

If you merge that, then only two libraries remain that are problematic from my perspective.

1. tapestry.el. You previously said that you won't remove that because that would mean that all emacspeak users would have to install vm. I agree that that would be highly undesirable. It also isn't what I was proposing. I was proposing that I would distribute that library as an independent package that both vm and emacspeak would then depend on. However I realize that you might not want to do that either because then all emacspeak users would have to install that package. Is that so?

2. tetris.el. I can live with that as I would just patch it out on the emacsmirror.

[tvraman]

SG. Looking at the emacspeak-nm PR will likely merge that. tapestry: Yes, I dont want it unbundled --- you need to understand that most blind users who come to emacspeak come at it with a "it's all too complicated " rant. From their perspective, unbundling tapestry would just make it worse; and there is no benefit to them. There is also no downside to the shadowing created by having multiple tapestry.el around.

…

-- Thanks,

--Raman(I Search, I Find, I Misplace, I Research) ♈ Id: kg:/m/0285kf1 🦮

[tvraman]

Please take out the creation of .nosearch in tvr/ as I said tvr is my
emacs setup and you or no one else has the right to tell me what I put
there, or block my emacs setup from searching it. Your emacs mirror if
it wants to mirror the distributed emacspeak should follow the make
dist rule in the top-level Makefile as I indicated to you yesterday.

[tvraman]

Applied PR #55, and removed tvr/.nosearch --- checked in. Thanks for
the patch!

[tarsius]

Thanks for agreeing to make some of these changes!

[tvraman]

On tapestry.el
all uses of tapestry.el are constrained to emacspeak-tapestry.el which
defines 2 functions that rest of emacspeak uses.

If we could write these independent of tapestry, we could eliminate
tapestry.el entirely -- want to give me some help doing that?

[tarsius]

If we could write these independent of tapestry, we could eliminate
tapestry.el entirely -- want to give me some help doing that?

I would be happy to help you with that.

I have already looked into it but have a question before I can continue.

Just copying the needed functions recursively amounts to 74 lines. Removing code that makes sure certain built-in functions before using them reduces this to 40 lines. Fun fact: some of these functions existed for nearly three decades now. Further refactoring could reduce this even further.

Before I know how much I can discard, I need to now whether the order of the list of windows matters, and to what extend. I assume that it should be a somewhat stable order but the exact order is not that important. Or in other words, can we just use window-list instead of tapestry-window-list?

One difference is that window-list begins with the selected window, while tapestry-window-list begins with the window in the top-left corner. We can get the behavior of the latter with the former too, but the order in which the other windows appear is likely different.

[tarsius]

I have opened the pull-request #56 to demonstrate how we could use the built-in function window-list and completely drop the tapestry library. This is only intended for you to test whether this changes the behavior of emacspeak-tapestry-describe-tapestry. I have not actually removed the library or any of the references to it.

[tvraman]

Jonas Bernoulli ***@***.***> writes: I've got a cl in process as well that eliminates tapestry.el entirely -- will look at your branch if I need help. I suspect I'm further ahead at this point since I did more than just use window-list.

…

I have pushed the version that uses the built-in function window-list and completely drops tapestry library to the "no-tapestry" branch. This is only intended for you to test whether this changes the behavior of emacspeak-tapestry-describe-tapestry. I have not actually removed the library or any of the references to it. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

-- Thanks,

--Raman(I Search, I Find, I Misplace, I Research) ♈ Id: kg:/m/0285kf1 🦮

[tvraman]

"T.V Raman" ***@***.***> writes: Emacspeak is now tapestry free -- all changes pushed to head.

…

Jonas Bernoulli ***@***.***> writes: I've got a cl in process as well that eliminates tapestry.el entirely -- will look at your branch if I need help. I suspect I'm further ahead at this point since I did more than just use window-list. > I have pushed the version that uses the built-in function window-list > and completely drops tapestry library to the "no-tapestry" branch. > This is only intended for you to test whether this changes the > behavior of emacspeak-tapestry-describe-tapestry. I have not actually > removed the library or any of the references to it. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub, or unsubscribe. > Triage notifications on the go with GitHub Mobile for iOS or Android. >

-- Thanks,

--Raman(I Search, I Find, I Misplace, I Research) ♈ Id: kg:/m/0285kf1 🦮

[tarsius]

Great! (And yes you were already way ahead.) Thanks again.

[tvraman]

Thank you for motivating me to do the cleanup. In my defense, (and this is not an excuse) that code was written circa 1996 I think -- not sure if window-list existed at that time, or may be it did, but when Kyle wrote vm and tapestry it didn't exist. Anyway cleanup always feels nice.

…

-- Thanks,

--Raman(I Search, I Find, I Misplace, I Research) ♈ Id: kg:/m/0285kf1 🦮

[tarsius]

Glad you got something out of it. I agree that getting rid of old code is nice. :-)