Emacs is on F-Droid
f-droid.org
f-droid.org
I have emacs installed in Termux on Android. Termux provides an extra button bar above the main keyboard for things like Ctrl, arrow keys, Esc, Meta which makes emacs just about usable in Termux. Without those things it would be unusable!
Without the magic button bar you'd need the hackers keyboard which works very well on tablets but it is just a bit squashed for phones unless you use them in landscape.
https://play.google.com/store/apps/details?id=org.pocketwork...
https://f-droid.org/packages/org.pocketworkstation.pckeyboar...
Too bad built-in slider keyboards went the way of the dodo. There are times when the extra screen real estate from not needing an on-screen keyboard can really come in handy (and Termux is one of them).
I don't really know if an external corded keyboard would draw much more power than bluetooth one (one could argue it'd be less b/c no wireless radio). Would be a bit tricky to confirm
I especially look forward to trying Org mode with this. One of the biggest weaknesses of Org-mode as a planning tool is the situation on mobile.
Any tips for configuring Emacs to work well in this environment? E.g. with strokes-mode or gestures? I saw Emacs is getting some improvements to touchscreen support which is coming in Emacs 29 [1].
[1] https://git.savannah.gnu.org/cgit/emacs.git/tree/etc/NEWS?id...
I love this app, I use it daily, I just do not understand why it needs it's own internal node model that it has to sync to file, instead of just.... reading the file, parsing it, and writing it....
read your contacts
modify your contacts
access approximate location only in the foreground
send and view SMS messages
receive text messages (SMS)
receive text messages (MMS)
read your text messages (SMS or MMS)
take pictures and videosFor example, I use Termux app on my Android (which gives me access to the terminal version of Emacs, without the GTK stuff). In order for the terminal to be practically useful, it needs very broad permissions. The permissions you listed come as a side effect of the bad underlying permissions model. It's not like Emacs is going to send SMS, it's just because that service in Android will get exposed if you need something more general, like access to the file system that isn't restricted to the directory where you program is installed.
This is a very restricted description of Emacs though.
Emacs happens to provide a text editor ;-)
For me, personally, Emacs is a terminal emulator, interface to Git, MUA, file manager, organizer and planner, a gateway for configuring various aspects of the system I'm using... I even use it to run alsamixer, because it's easier for me to control sound volume this way.
Oh, and an interface to govmomi / aws-cli / az with a bunch of custom code written around those tools. Openstack pending.
And any Emacs user you ask will have a bunch of other uses... Some other things I've done / or played around in the past include: Wiki server, cooperative editing (with Rudel, probably dysfunctional by now), binary files editing (well, I still do every now and then), Web browsing, IRC (and Jabber way, way back)...
You could argue that a general-purpose planner might, but that's not what Emacs is, nor do I believe that it supports parsing contacts in the format provided by the Android APIs.
Generally these days when Android apps request permissions they don't need it's because they're either old or poorly written; not because Android doesn't have more granular APIs available. For example, applications requesting full file system access when all they need is the ability to read and write to a user-selected file (which requires absolutely zero permissions now thanks to the documents provider API) is a personal pet peeve of mine. Ditto for services that ask for permission to run continuously in the background when they could just use WorkManager or similar, or IOT apps that ask for location permissions when they could be using the Nearby Connections API.
You make no sense. The permission model is what makes these operating systems so secure. It's not worthless as it significantly hurts the capabilities of malware. If your definition of owning a device is that you should be able to install an app that can steal all of your login information to every other app you have then you are alone with that definition. People don't want to have to care about security when installing random apps.
(not GP) This is false, I should be able to install an app that can steal all of my login information to every other app I have. I want the freedom to do stupid things with my device but also the freedom to avoid doing stupid things with my device. It's why you're informed of such permissions and allowed to accept them rather than just being prevented from installing any app that wants them.
Note that I love sandboxing and safe/isolated APIs, it's just that, more often than not, OSes literally can't include any escape hatches or else, no matter how complex they are, normal people will get tricked into activating them.
They created a permission system with a powerless users in mind. Their model user is the one who doesn't want to own the device, it's the useful idiot who rents the device and swipes on ads. This user needs to be showed ads by "partners" and because it's too financially taxing to approve "partners" individually, there's a system with some heuristics in place that makes sure that the diligent ads consumer doesn't rebel or doesn't get side-tracked by "partners" breaching provider's trust.
I describe their model user as "idiot" because it's an idiom in the language. I don't mean the user is generally stupid, rather that the user is not knowledgeable and not wanting to gain any knowledge in a very convenient (for the provider) way. Someone who may be duped into doing things against their own best interest.
But, yes, if you don't want to match that profile, you will be offended by that kind of attitude from the provider.
---
And, more on the reasons why Android's permission system sucks: it's, again, built at the wrong level. This is very often the case with software: it's usually much easier to build things at higher level, but that also gives worse results. It built this way to make the development on the part of the provider cheaper. It covers the needs of their model user, the one which potentially generates the most profits for them. They have never meant or wanted to make a system that's most useful for any potential users. It just needs to be barely useful to turn profits.
Yeah, see what I said about escape hatches above.
> But, yes, if you don't want to match that profile, you will be offended by that kind of attitude from the provider.
> It covers the needs of their model user, the one which potentially generates the most profits for them. They have never meant or wanted to make a system that's most useful for any potential users. It just needs to be barely useful to turn profits.
Agreed~
1. Users will be tricked into giving permissions to apps. There isn't a reason why apps should be able to while in the background before you've even opened them be constantly listening to your mic and then uploading the audio and your location 24/7. That's simply something that Google has chosen to not be something apps should be able to do. And that's okay. It keeps 100% of the users secured against these malicious app.
2. The users are not the only stakeholders. The app developers are too. It's Google's job to make a platform that takes in the needs of both the app developers and the users to create the platform that gives users the most value possible. This is where things like DRM come in. One could say that you are taking power away from the user my creating secure layers that can't be recorded or screenshoted, but on the other hand you are giving content owners more assurance that your platform is safe for them to distribute their content on. This is a compromise between the needs of the user and the needs of the app developer. It's about giving the users the most value possible instead of the most control possible. This is the main reason why Android is the most popular consumer oriented Linux distro. Desktop Linux distros prioritize giving users control over security and user value and it turns out that is not the way to get mass market appeal os it remains niche.
My definition of security is that programs have access on a need to know basis. Especially to my files. On Android is all or nothing.
Yeah, maybe you can spin Android as being more secure (than what?) But it's also useless. It's like with the rifle, if it's always in "safe" it's very secure... but useless as a rifle as you cannot fire it.
This leads to a situation where app developers must unconditionally obtain permissions, even if they're only used on a certain code path.
If you don't trust the F-droid build, you can always build it from the sources.
All the permissions are set to FALSE. They are there, if any package you install needs that permission, it will be asked to allow such.
I guess this is what it takes when implementing an OS in an Android app.
zypper install --no-recommends emacs
Loading repository data...
Reading installed packages...
Resolving package dependencies...
The following 24 NEW packages are going to be installed:
cpp13 emacs emacs-el emacs-eln emacs-info emacs-x11 etags gcc13 gnu-unifont-bitmap-fonts guile guile-modules-3_0 libXaw3d8 libgccjit0 libgsasl7 libguile-3_0-1 libhwasan0 libkyotocabinet16 libm17n0 libmailutils9 libntlm0 libotf1 m17n-db mailutils system-user-games
24 new packages to install.
Overall download size: 112.3 MiB. Already cached: 0 B. After the operation, additional 374.4 MiB will be used.
Continue? [y/n/v/...? shows all options] (y):
Interesting (almost half of this is cpp13, gcc13 and libhwasan0 though).My guess is that MS Windows or MacOS users will feel more at home with using their Android device because they are more used to the system telling them what they may or may not do. But, to Linux user this feels very user-ugly.
Being in the latter category, I've been oscillating between two states of using my phone: either go all-in, and wipe the OS entirely replacing it with something sensible, or never trust it and don't put any personal data on the phone.
Unfortunately, neither state is really feasible at this point. Living in an almost cash-less society, phone is almost a necessary payment tool (my bank tends to randomly lock my debit card every few months...) I also need to use my phone to authenticate to various government and work-related services. And that requires installing the toxic garbage OS on it.
I wish services like cash payments and identification were provides as public interfaces instead of installable closed-source software... but, unfortunately, it seems like free software world had lost the battle for the phones. At least for now.
Don't lose patience though, it's coming on Linux too with Flatpaks :-)
For instance the second screenshot of the latest post of "Adventures in Linux and KDE" [1] shows how it looks in Discover.
[1] https://pointieststick.com/2023/02/17/this-week-in-kde-a-smo...
We were allowed to keep our original laptops so far.
The IT department of the new overlords declared that eventually, they are going to retire our current generation of laptops and replace them with something that they, themselves, install and control. Users of such laptops will not have root access, for instance. Will have some mandatory garbage antivirus and other corporate spyware installed on them. The company is said to cycle their laptops every 4 years or so. And that's the time when I'm planning on handing in my two month notice.
Yeah, it's possible to make Linux suck as much as Windows or MacOS (in this respect), but this will cause people to revolt. That's why I also won't use Flatpacks or similar containerized / read-only bind-mounted installs etc. This goes against the reason why I chose to use Linux. I feel upset and confused seeing how tools like these get more and more traction.
I believe such a permission system can be a good thing. Apart from the "the app could be a bit malicious and I can't check by looking at its code because it's not available" situation which does not really concern me because I avoid proprietary apps, let alone apps that could be a bit malicious, it reduces the surface attack. Imagine a browser that asks for no permissions, or for temporary ones when needed (access to the microphone or the webcam for example - not sure Flatpak allows temporary permissions, but still). Some malicious website trying to exploit a security flaw would be restricted in the harm it can cause by the permission system. The user is still in control because they can decide what to allow. Actually, such a system improves the user control because now, the user can also deny things if they want.
Such system can be abused by restrictive policies, but the problem is there: in the policies.
Now, I won't use Flatpak as long as I can, because I don't like its heaviness. It takes space on the disk. I don't like the delays it causes when running an app. The integration of Flatpak apps in the system is not perfect yet and I notice it. But this permission system? Yes, looks good :-)
I'm talking about both the typical user, and the intention behind creating Linux. The intention was to give freedom to explore and to modify. Using something like Flatpack takes that freedom away. Yes, unfortunately, Linux may be subverted into doing things its authors didn't intend... well, giving freedom has that kind of danger.
> Imagine a browser
It's a browser problem. It's not a Linux problem. We have an awful application distribution platform that grew out of distributed document database. Something that, from engineering standpoint should have never been allowed to happen, but happened due to greed of some and hubris of others. We should fix browsers, not operating systems to deal with this problem.
They were also sued more than Android have been so far. And the legislation has still to pick up steam to crack on the scam that some of the Android (or iPhone) parts are. Unfortunately, legislation needs to have much more technological sophistication that they currently have to be able to deal with this. :(
I tried to make gtk3 GUI apps with ruby on termux, apparently termux now supports this new mode that works in the browser, but some libs seem to be missing! I think that would be a cool platform.
A laptop keyboard is usually a half-inch or so off the table surface, as it sits on top of the laptop base.
You should never feel demoralized about stuff like this, thats a definite sign you're taking it all too seriously. :)
My Android phone is planned to be made obsolete this April because the banking app decided to drop support to the Android version I'm running (and cannot upgrade). So, come April, I'll have to re-investigate the options available for making phone experience palatable, and will probably try this USB-OTG thing, so, will be better prepared for stuff like this.
i've been using emacs in termux for my org file, and for sone reason the big thing i can never manage to pull off is moving to the top or botton of the buffer. i don't know if it's me or my keyboard.
(not intending to discourage, I say go for it! but ... yeah.)
[1] https://marek-g.github.io/posts/tips_and_tricks/emacs_on_and...
edit:
I realise now that it's better than expected, apart from giving instructions there are also prebuilt packages. You have to trust the packages of course, but the instructions are simple enough and can be done within tmux.
I'll see if I can try with a standard keyboard later.
[1]: https://marek-g.github.io/posts/tips_and_tricks/emacs_on_and...
Any sort of OS integration like opening filetypes, sharing, shortcuts, widgets?
1. Graphics. Emacs is a graphical application, even if many people forget this sometimes. I like to link to the Emacs Tour: https://www.gnu.org/software/emacs/tour/
2. Access to the entire filesystem and operating system, free from the Termux sandbox.
I tried emacs via termux and it gobbled up the opulent spacemacs without issues.
I just couldn't find a way to associate it with certain file types or even just to create i shortcut opening a specific file.
- You can't just "git clone" doom emacs using a rooted termux, because /data/data/org.gnu.emacs/ is read-only.
- So it seems that you have to use the emacs process. I went to buffers -> scratch to get a keyboard, and then used https://f-droid.org/en/packages/juloo.keyboard2/ to `M-x shell`.
- You don't have `git` in this shell, but you can still download doomemacs from github using
curl -LJO https://github.com/doomemacs/doomemacs/archive/refs/heads/master.zip
- and `unzip` the archive, moving it into place.- .emacs.d/bin/doom is just a shell script, so you can invoke installation with
- `sh .emacs.d/bin/doom install`
- This is where I left off, for this script fails with "`emacs` not found on path".
All-in-all, a very, very exciting release! I hope somebody else manages to hack this.
1. Access to SAF content providers. This is the intended way to mount cloud storages in Android and it even supports offline access, so it would finally give us a decent and trivial way to sync org files without fiddling with rclone/foldersync/etc...
2. Server mode: making Emacs run in the background seamlessly would make it a really handy swiss knife. Also, this should be necessary in order to use stuff like org-protocol
3. Interaction with other apps: make it callable from Tasker or stuff like that. I'd like to use the "share with" menu to capture quick notes and bookmarks