Easier ways to change default text editor in jgmenu commands?

Since the following question came up, I have been meaning to go through all the /usr/bin files for jgmenu and change the invocations of geany to subl, the command for sublime text.

It’s been 8 months? And I am no closer to doing that than I was before. I’m old, time is fleeting, etc. And it has occurred to me that extensively customizing the jgmenu system would mean needing to keep an eye on updates and figure how best to merge any new features that I wanted–or just let the future of the menus unfold without me.

Thus: would you, keeper(s) of this awesome distro, consider adding support for text editors besides geany to the jgmenu system? It would make the menus themselves much more portable. Given all the work you have done on them, they could be worth sharing outside of Mabox. Fame and fortune await! Maybe.

Two ways to do this occur to me at the moment:

  1. instead of having geany hard-coded as the text editor throughout the menus, scripts could check the mimetype of the file to be edited and open it in the default app for that mimetype.

  2. add a mechanism for assigning a default text editor; scripts could then call for that default to open text files for editing.

There may be other, faster ways to do this, but if I were feeling very ambitious and wanted to implement this myself, I would probably start with one of these.

(And if it were a decade or so ago and/or time would slow back down to a reasonable rate of passage and/or the body would return to a reasonable rate of doing things, I would offer that ambition, time and energy for this. As it is, I will just thank you in advance for anything you do decide to do. Even if it’s just thinking about it and deciding not to do more than that.)

Hi @josefk

I will try to improve this soon. Probably xdg-open will do the trick. I will work on this and test it tomorrow.

I checked it out … and geany actually appears in many places in scripts :frowning:

napcok@mabox ~ $ grep geany /usr/bin/{mb,jg}* |wc -l

There is probably even more geany in the configuration files in $HOME

Expect news on this topic in the coming days :wink:

I know. :wink: This has dampened my own enthusiasm for changing things as well.

No rush. I appreciate the effort.

Today updates should fix that by relpacing geanyxdg-open in all scripts.
Please update:


and then to update partials included in some places in menus/panels by command:
(be aware it will replace your customisations if any)

mb-reset allmenus

You should be able to assign your editor of choice to some filetypes in PCManFM. By context menu → Properties → Open with…
Let me know if that helps.

1 Like

Sweet! Thank you for this. I have customized a few jgmenu-related things on my desktop, but I can check this out more quickly on my laptop later today. Will let you know how it works!

It works! That is, xdg-open does what it is supposed to do where you put it in the menu scripts: it opens text and other sublime-text-assigned mime types in sublime text.

Cool beans. Also, thanks. :slight_smile:

It took me a bit to test this out as I decided to update the menu system on my desktop which meant moving a few customizations into mb-jgtools, including a submenu of tag^s that I figured out where to put the first time and then forgot why it was there and not somewhere else. In the middle of everything, my back decided it did not want to do its job anymore, so I have been in bed reading for the last few days.

There are worse things.

In any case, these menus are inspiring me to try learning bash scripting again. Like, from a book and examples on the internet. I may or may not find the energy to become proficient, but a little more practice can’t hurt. I can figure out what most scripts do, but bash is so terse, and confusingly like C but not always, that writing a working script from scratch is dicey.

But if I manage to produce anything interesting, I’ll be happy to share.

1 Like

Helo @josefk,
I hope your back will get better soon.
Thanks for feedback about xdg-open.

About bash scripting …
Sometimes I love it and sometimes I hate it … I’m still learning and having fun with bash :wink:

I don’t think there is anything better to glue together all these wonderful little cli tools that we have available on Linux.


Yes bash is the most practical way to glue things together and is even fascinating to me–in the way an alien language might be fascinating.

&, for instance, sends tasks to the background. Sure, I’m good with that.

But… will it also act as a dereference for file descriptors? Are file descriptors C-style pointers? What is really happening with 2>&1 ? I have seen that construction sent to /dev/null/ in a couple of different ways, but I am still looking for a comprehensible description of why or how it works.

You don’t have to answer this either. I’m betting that Stephen Kochan’s book on bash scripting will tell me what I want to know, but I keep opening other books and reading about completely unrelated topics.

My back has stopped with the unusual pain and has returned to the minor nagging pains I am used to. Thanks for the good wishes! :slight_smile:

About 2>&1

The numbers 0, 1 & 2, are associated with:

STDIN (the standard input device, usually the keyboard but this can be changed)
STDOUT (usually the screen, but again this can be changed, for example to send the output of a command to a file)
STDERR (which receives the output from system errors, and by default sends them to the screen so that the user is aware of the error).

These are known as file descriptors, they describe where the output should go. These three are always open by default .

The expression 2&>1 simply means redirect file descriptor 2 (all errors) to file descriptor 1 (Usually the screen as stated above). The & is required to tell the system that we are redirecting to file descriptor 1 not a file named 1. The 1 is still pointing to the screen (STDOUT)

When we type 2&>1 we are telling the shell to send any errors (2 is STDERR) and the commands output (1 is STDOUT) to the same place. Sending this to /dev/null (the Bash black hole from which nothing escapes) simply means discard all output.

If we point a new file descriptor, say 4, to a new destination, here a file named myfile.

exec 4>myfile

Then if we now typed echo “Hello napcok!” >&4 then we would not see anything on screen as the output would go to the file myfile instead of the screen.

$ cat myfile
Hello napcok!

Hope this helps :slight_smile: