Aside from the slightly less important but kindof bothersome lack for things like chat and list formatting, Essentials doesn't seem to recognize any group names established in LuckPerms.

Now assuming I have LuckPerms groups with names like staff_enforcer, voterone_global, votertwo_global, etc... I should be able to create text files that can be accessed using essentials such as:
custom_staff_enforcer.txt
info_voterone_global.txt
info_votertwo_global.txt

And so on... from that point on whenever a member of those groups does a /custom or /info, they should see the appropriate file. However, the only file that is ever accessed is "info.txt" and "custom.txt", so it would seem that Essentials is not gathering that critical group information (the name).

I've done some attempting to adjust formatting the list display using groups that are established in LuckPerms as well as in the chat format area (where you can set display for certain groups) to know this feature doesn't recognize the groups either... oddly the /ess debig seems to report the existence of the LuckPerm's groups from time to time so Essentials is aware of them, just isn't using them for every case for whatever reason.

EssentialsX version (/essentials):
Essentials reloaded 2.0.1-b550
Server software (/version):

Server (logs/latest.log):
git-Spigot-549c1fa-70cc382 (MC: 1.12.2)
EssentialsX config (if applicable):

Does it work if you define a chapter in info.txt like

#voterone_global

#dfsfdsfaf
<todo, whatever you wish xD

then in your commands.yml, try

aliases:
__voterone:
__- essentials:info voterone_global

I can be wrong on this, but thats my suggestion idea xD

(I typed essentials:info incase another plugin overrides /info)

Chapters do work as advertised. Using it like this... would be theoretically possible but would not give the desired effect. The appropriate behavior would be to not open the file at all unless the user had access to the information they were about to read - which is why I included a "staff_enforcer" group, my assumption being I'd have a info_staff_enforcer.txt file I'd want THEM to see, but I would not want the casual player to read. Anyway no other plugin provides the /info command other than essentials as far as I know. I think it might be that anycommand.txt can be made in the essentials folder and used in this way but I haven't tried that... but the "custom.txt" file seems to suggest that's exactly what you can do here. In any case the documentation it states that you can custom_groupname.txt or info_groupname.txt and have it work that way... this is not working in the case of LuckPerms and from what I can tell this only ever worked for GroupManager which is a hideous plugin to use for nearly anything. If there was some way to limit permissions to the aliases, then implementing some sort of work around could be possible, but I don't think that's something that can be done.

I couldn't find any documentation for this feature, but it appears that it does exist. It isn't specific to GM; in fact, it should work for every Vault permissions plugin through the Vault permissions handler.

It appears that TextInput will sanitise the group name before trying to read the file, but this shouldn't cause issues here as the group name shouldn't be changed by this sanitisation (underscores replaced by underscores).

Could you paste the console log when /ess debug is enabled and you run /customtext as a player? Make sure the file is named after a user's primary group.

Oh sorry I missed the meaning of that message... as well as in the documentation... I thought it was
/[anything_here_will_work]
[as_long_as_it_matches_this].txt
Not
/[anything_here_will_work]text
[as_long_as_it_matches_this].txt
But after you've said that and I've tried that... I'm thinking only /customtext works for cusstom.txt, and that is all. Even though it is "called" custom, it cannot be changed to anything, nor was it included as an example of how to include custom command names for accessing documents. Is this correct, or should that approach be working here?

The Essentials docs are misleading in that regard, I'll admit that.

The default command is /customtext and aliases can be added for that command, but the file is always custom.txt.

Well then... lol. Ok well that clears this up for me. Between the primary group changes that have gone on due to the setting change I made in LuckPerms and your clarifications of how this worked, I'm good to go. Thanks so much!

Ok maybe THAT was the issue? The primary group, that is. Except that "/custom" came back as a 'Unknown Command...' even with the files present, so that may be something else or... i just have to do a total server restart every time I add one. I couldn't get it to work before even with the primary groups on info but, it does appear to be working as advertised now, at least on the /einfo command. Maybe had been a problem with a previous build I had that got patched along the way, I don't know. There wasn't anything helpful in debug since... it acts like the command was never even attempted.

My mistake, meant /customtext rather than /custom.

well either way... I used /custom given that I had a /custom_primarygroup.txt that existed, but that didn't work. But I'm not confident I don't need a server restart for that to be active... I know changes to existing text files are instantaneous, but I'm not sure that's true if they do not already exist... and while custom.txt may still have existed, I only just made the custom_groupname.txt one... anyway I got people online now so I'll recheck this out later. Thanks for the input so far anyway...

I also changed something in LP the other day where it iterates through all parent groups to find the "primary" group... like weighs each against each other since I was getting some unexpected behavior when it came to weights and things previously which may have been a source of my headache the first time I tried dealing with this months ago. This may not have be a problem after all, I may just have implemented it wrongly, but I'll verify that whatevercustom_groupstuff.txt works as soon as I can get some restarts in to check it.

The relevant file is read every time a text command is run, so if you edit or create the file then it will be reflected the next time the command is run.

Ok then... the /custom_group.txt while the /einfo_group.txt seems to be. But I don't know for certain, I'll need a restart before I can retest since 4 or 5 commands just arbitrarily quit working since the last time I did an /essentials reload... I don't know if it's really not working or if it's just 'not working now because I reloaded essentials' which seems to be happening since the last few builds I've put on. (I'll retest when some people log out).

ok verified after server restart... even with an appropriately named custom_groupname.txt present, /custom and /ecustom do not result in anything happening at all other than "Not a recognized command" I tried with essentials debug, it acted as if I had not entered a command so... don't know about that one. On the plus side I was wrong about the info_groupname.txt not working, since it does, I"m not terribly worried about this.

As I said, /custom isn't a command. Use /customtext to display custom.txt and custom_<user/group>.txt files.