This F-Droid emacs appears to have been build straight from the emacs repo which is cool! I was hoping for a screenshot but I couldn't find one.
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.
Here's how to install conda, mamba, and pip with MambaForge in Termux w/ proot from FDroid because there are no official APKs on the play store as is now necessary to bless binaries with context labels:
https://github.com/westurner/dotfiles/blob/develop/scripts/s...
Just for giggles, I tried plugging a USB keyboard into my phone via an OTG cable, and wonder of wonders it worked. The catch, of course, is that you'll eat your battery by powering external devices, and the keyboard dwarfs the phone. A Bluetooth keyboard would probably be a better bet for anything but rare use, and there are mini BT keyboards that would be easier to carry.
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've used a Apple Magickeyboard and a small android eink tablet (in vertical orientation) for some writing and light programming in Termux/Emacs. Very portable setup and distraction-free
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 tried the Hacker's Keyboard, but Multiling O Keyboard has worked much better for me. It supports swipe input, so I can use it as the main keyboard. And most importantly, you can customize the layout almost however you want (including arrows, modifier keys, function keys, etc). It may be a bit confusing at first, as you need to write your own config in plain text. But other existing layouts could be a nice starting point.
I have a Razer huntsman mini that works fine with android and ipadOS. I havent figured out how it handles the control keys and such, but if it works it will be a bottle of fun!
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].
For the life of me I still do not understand the syncing model on Orgzly.
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 videos
I would expect, probably, even more. The permission model of Android is worthless, if you actually want to use it as your desktop replacement. I.e. if you want to own it rather then rent it (and be told by the manufacturer / reseller what you may or may not do).
For 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... pretty much entirely false. You don't need SMS permissions to get access to the filesystem. Also, SMS access (like most sensitive permissions in modern Android) is disabled by default when you install the app, so GP's list is just a list of permissions Emacs can theoretically request, not permissions it actually has on install. (Not sure what functionality Emacs has that requires SMS access, but I'm guessing there is some optional feature that lets you send texts or something.)
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.
>The permission model of Android is worthless, if you actually want to use it as your desktop replacement. I.e. if you want to own it rather then rent it (and be told by the manufacturer / reseller what you may or may not do).
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.
> 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.
(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.
Oh, but there are plenty of things on Android that you simply cannot do. They aren't expressed as permissions at all. And there's a lot of things that you can do, but that will void your warranty, or will make the process so painful and complicated that you will regret even thinking about it.
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.
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.
> Oh, but there are plenty of things on Android that you simply cannot do. They aren't expressed as permissions at all.
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.
You know what operating system is the most secure? The one that's turned off...
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.
That's not true. Android apps start by only having access to an app specific directory. In order for it to gain access a file or directory outside of that it needs to be selected by the user explicitly. There are also directories like the download directory which apps can't read from. For more information look up "Scoped Storage"
Very few Emacs users need a "perfectly good text editor". This is not why anyone uses Emacs.
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)...
And none of those use cases require contacts or location permission.
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.
Again, read the top post: it's not the Emacs' problem. It's the problem of how permissions are structured. Talk to your overlords at Google and tell them that their permissions system is bad. It's them who are guilty of making a bad permissions system, not the useful software that has to deal with the fallout of their bad design.
Emacs, though, is a great operating system, which just sadly doesn't ship with a decent text editor. Don't worry though, you can install the eVil plugin, and get what is essentially Vim running inside of it.
You don't give permissions to an arbitrary Android app because you don't trust it, whereas GNU Emacs can be fully trusted, (unless you run untrusted Emacs Lisp code, ofc). I even tend to think it requires too few permissions, e.g. it cannot initiate phone calls.
If you don't trust the F-droid build, you can always build it from the sources.
In Android, it's not possible to request a permission unless it's defined in the manifest, and a large number of permissions are granted without a permissions dialog.
This leads to a situation where app developers must unconditionally obtain permissions, even if they're only used on a certain code path.
I'm not the author, but I answered it above: any useful program on Android, if you want to use it in a way similar to how you'd use your PC will have to ignore Android's permissions model. That model is useful if your model user is restricted by system administrator to only performing a few tasks (i.e. users don't control their device). That whole idea flies out of the window once you want to do something like copy files or run an FTP server etc.
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.
> 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.
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.
I work in a company that was acquired by a larger company about a year ago. The original company simply gave us laptops for work and asked to put full-disk encryption on them and to follow very general, but very sensible security requirements (eg. lock the screen if going away for long time, don't leave in the office unattended etc.)
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 think you are conflating your restrictive and painful company policies with features that can be beneficial to the users.
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.
I hate that companies do this. I'm very thankful to have found a job where my boss lets me basically self-manage my tasks, and my own hardware. I trust my security more than some IT guys.
MS Windows is a lot more open than Android. Any Windows program you run can access any of your data, without any constraints. Most users, who do not carefully review every piece of code they run, probably like a more constrained environment, so "any program can do anything" cannot happen.
Yeah... I guess, Microsoft couldn't have dreamed about putting their users into such a strict jail as was made possible by the advent of iPhone and later Android. Especially so due to having a free alternative that, if they pushed too hard, might have become more attractive to their users.
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. :(
Beyond the fact that as others have said Android is not tied to a touch screen keyboard, consider how this could simply be used to view your, e.g, org agenda with the right font and buffer settings. Using ERC, gnus, Org-mode rss feeds too! There are a lot of possibilities but you have to figure it out yourself, and there are plenty of new flashy things that you can use instead if this is unacceptable to you.
You should never feel demoralized about stuff like this, thats a definite sign you're taking it all too seriously. :)
I literally laughed out loud when I saw the headline. I'm thinking of the seven people who are going to engineer some ridiculous hacks to actually make this usable.
(not intending to discourage, I say go for it! but ... yeah.)
There's a UBS-OTG thing. Allegedly. I haven't tried it, but have heard claims that you should be able to connect a normal keyboard to Android device.
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.
USB-OTG worked perfectly on my Moto G5+ with a Lenovo keyboard with built in hub to which I connected a mouse. Haven't tried yet with my Moto G30 because I haven't got, or even seen, a USB-C OTG adapter.
You don't need one. A USB C hub will probably just work except maybe the HDMI port. Even the cheapo Amazon Fire tablets just work (except video because they don't support alt-mode).
That's a lot of extra hardware to replace what was just a very short cable with a connector on each end! I'll have to look into a USB-C hub that also has USB-A for the keyboard.
You've been able to attach keyboards and pointing devices - mice, trackpads, those presenter pointer things with joysticks on ´m - to Android for a very long time. Attach a pointing device and you get a pointer on your screen which can be used together with the touch screen. Attach a keyboard and the virtual keyboard won't pop up since the thing expects you (rightly IMnsHO) to use the newly attached keyboard. With pointer device, keyboard and Termux Android devices become somewhat useable general computing devices.
This has worked for most devices for a long time, e.g. the 12yo Motorola Defy I use as 'dangerous work device' supports it and works with both keyboard, pointing devices as well as more odd things like a borescope camera.
you just have to re-learn typing them with just your thumbs, no big deal ;)
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.
Exactly. I have a full fledged emacs inside termux. With a Bluetooth keyboard, it is a surprisingly good solution. I bring this set up with me when I am on vacation and may have to do some emergency interventions for work. The only thing I have not figured out is how to re-bind the cap lock key for ctrl on the BT keyboard. BTW, I install emacs via Termux via their package utility. Termux itself is installed via F-Droid on my Android phone. One last thing: I also have tmux running inside Termux. Again, I am always surprised by how well this works.
I use my foldable bluetooth keyboard. Using iAWriter and termux, I can write posts for my PHP and ruby based blogs, run my static site generator and publish via git. Termux lets you make a shortcut that runs commands.
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.
I have a foldable BT keyboard as well (generic one on Amazon under different brand names). I find myself not using it because it sits completely flat, which is uncomfortable to type on for long periods of time. My palm doesn't seem to rest on the table, it hovers over the keys instead. Not sure if it's the same for you.
A laptop keyboard is usually a half-inch or so off the table surface, as it sits on top of the laptop base.
This is exactly what I've been trying to do. I have the CLI emacs installed through termed and nix-on-droid, but I can't get them to share with each other. It's a pity because a huge part of emacs functionality comes from interaction with external programs. I also haven't worked out how to install programs to the gui-emacs namespace through pure emacs commands. I feel that both methods should be possible though.
Amazing! Maybe in the future they'll build this into the releases, but in the mean time this is exactly what I was looking for. Thank you very much!
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've tried to use an Android device as a desktop replacement before, but the input lag is always there and it's really annoying, even when using a wired USB keyboard. It seems that input lag is an intrinsic characteristic of an Android device.
How long would you say this input lag was? Like how many milliseconds? Some people, especially non-gamers, just "don't see" lag unless it's significant. So you could be right that there is lag even if others don't see.
I'm using a physical keyboard on the nothing phone and I don't have any input lag problem. I am using it mainly for termux admittedly but I haven't perceived any in other apps.
I just tested it out and it didn't work well for me. It reliably started either on the current app or on the latest app when on the home screen but I haven't managed to change windows at all. That could be due to my weird keyboard though. It only has 34 keys and has a weird way to reach the alt key which might be messing with everything.
I'll see if I can try with a standard keyboard later.
I couldn't find any documentation on this. Seems like an experimental build. Features are hit and miss. Tried a few built-in games, and seems fine. Wanted to try further with my own configuration using doom emacs, etc, but not sure where to put the configuration files. This could be a good alternative to Emacs in Termux for my Samsung DeX setup for basic editing and org-mode, but would be hard to replace the flexibility of Termux beyond that.
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.
doom emacs on termux is great ! I might try forcing a doom install through termux but if I can find a "cleaner" way, I'd rather do that. The main problem I expect to have is the lack of git outside of termux
Yeah, I don't know where it stores its configuration directory. Also, the on-screen keyboard keeps disappearing, and I can't find a way to keep it on all the time.
I have a physical keyboard that I intend to have with me most of the time (a bluetooth ferris sweep that fits in my pocket when packed) so that part is solved, the config part is slightly more complicated
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
For whatever it's worth, I got repeated failures trying to install this through the f-droid client. But going to the f-droid web page (as pointed to in the above link) and downloading the (c. 50MB) apk and installing that from the download worked --- but didn't end up showing it as installed in the f-droid client
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...