On 26/11/22 02:37, João Távora wrote:
Must be nice to be the person who gets to decide what is appropriate in any situation.Dmitry Gutov <dgutov@yandex.ru> writes:I can't understand what is discourteous about this.That would be not following the procedure the maintainer has asked you to follow.If that means silencing me on emacs-devel, then you're out of luck.Is that what you do when you ask somebody to use the bug tracker?I'll use the bug tracker when I think it's appropriate. Let's not insinuate I'm some kind of inconsiderate delinquent for not moving the discussion there as you would want. I'm not reporting a bug and I've politely declined your suggestion, so stop beating this horse.
I don't really know what "the user wants". People apparently find this discussion too scary or meandering to provide any additional input. The several who I asked to comment have walked away perplexed. Or perhaps it's just Debbugs.People seem to be contributin a healthy amount of information here.Yes and no. Nobody has bothered to comment on the messages in the bug report, or on the patches in it.If they help the discussion, suggest you put your patches in a scratch branch and announce it here. It's not much work for you, I suppose and personally I find it simpler than finding your patches and applying them to the right version.
I suggest people look at the patches where they are posted.
Note that it would also be possible to do through some other means. E.g. using some command in Xref result buffer which would filter by file names and hide the rest.*compilation* and *shell-command-output* are not in any kind of structured Xref mode where that hypothetical command would operate. Even if such a command could be devised, I don't find that don't find it a very good solution. If one knows the where to look in, it's better to grep only one haystack instead of the whole barn just to throw away most of the needles.
Sure.
Not all files that belong to the super-project necessarily belong to a sub-project. Some of them _only_ belong to the super-project.nDo the files that belong to a sub-project belong to the super-project?Yes: in my view they belong to both. i.e. if you project-find-file in the super-project, you can find a file in a subproject such that a subsequent project command operates on the subproject.
Okay, good.
By modifying each and every command. I don't think it would be appropriate for 'project-current' itself to react to the value of current-prefix-arg. As you are aware, some commands already react to prefix argument, and some third-party ones might even handle the negative value. Let every command deal with UI; we can make a helper that will make the code much shorter anyway.Anyway, indeally I want these three main operations (find-file, grep, compile) to run in the inner sub-project by default. By typing something more, like, say, a negative prefix argument, I want to be able to be given the possibility to operate on the super-project instead.See the 'project-parent' implementation I posted a couple of days ago.I've seen it. In fact, I posted the same code earlier. But how do I plug in that so that M-- C-x p f, M-- C-x p c, etc, etc make use of it?
Sounds pretty complicated. See if the latest patch solves your immediate problems just as well.The idea of customizing the projects with a list of relative subproject directory file names solves those downsides, but comes with lack of automation: you have to do it for every relevant project, and not forget to update the settings as the project structure changes. Which might also be a pain e.g. when switching branches, if your dir-locals.el is not checked in.As Juri mentioned, dir-locals-set-class-variables is the tool you need in those cases. There are ample tools to solve this problem. We should first focus on the project.el infrastructure that enables the above use case in the first place.What's missing in the infrastructure?Not much, I would say. But I think at least: * A way that I can add an element to project-find-functions that understands that a super-project has been detected already in the current search and proceeds to find sub-projects inside it. This is what I posted code for. * A way for M-- (or similar) to consistently affect all (or most) of the operations in the C-x p keymap so that we can choose if the operation operates on the super-project, if it exists. Unfortunately some of these commands (like project-find-files) already take a prefix argument to mean different things. But it's not too bad. * A new project type, similar to the '(transient . "dir") project (and inheriting most of its operations) that also keeps a record of the super-project found. This might not be strictly necessary, but could come in handy later for efficiency reasons.
Aside from the 'M--' thing, which is a compatible but separate story.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4