Re: Android port of Emacs

[Po Lu]

Arsen Arsenović <arsen@aarsen.me> writes:

> To back Po up here, the port is usable with software keyboards too IMO.
> Perhaps the only thing that's missing is an (optional) way to input
> modifiers without needing keyboards to support them directly, similar to
> Termux

IMHO, it's not Emacs's job to, in essence, provide another virtual
keyboard in addition to what the user has already installed.  People who
need these modifier keys can use any of the software keyboards that
provide options to display them: AnySoftKeyboard, Hackers Keyboard, et
cetera.

> , and to bring up the keyboard at any point, even when in RO text.
> It is possible that these features exist and that I missed them, though.

This exists, see the option `touch-screen-display-keyboard'.

> It was immediately clear to me, however, that there won't be much direct
> translation from a desktop workflow to Android, so I skipped directly to
> tweaking various GUI elements, which might be why I can't sympathize
> with the usability assessment some people had.  This will be some work
> for users and developers of Emacs and packages for Emacs in the long
> run, to provide a more pointer-approachable UI, however.

Yes, I strongly recommend that people using the Android port without a
mouse or keyboard refrain from hiding any of the display elements that
are often disabled , especially the menu bar.

> I think that, in general, this port shows Emacs as an organizer and note
> taker more than as a programming tool, so the lowered accessibility to
> advanced text entry shouldn't be too grave, though both are possible,
> especially with a hardware keyboard.

Well, I've been using Emacs as both a note taking tool, and as a mail
and news reader.  The nature of my work means that responding to mail
naturally requires some programming, so to each his own ;-)

> What's also missing is the Info viewer reflowing to fill the screen, but
> this is a fault in the Info format rather than Emacs.  This has been the
> case for a long time but the form-factor on Android is somewhat novel,
> so it was never that noticeable.

Perhaps adjusting the fill column while building documentation for
packaging on Android would be a suitable temporary solution for this.

However, I'd really like to see a form of word wrapping that does not
take new line characters into account at all, allowing filled text to be
refilled to fit windows at redisplay time.  I plan to investigate
implementing this some time.

> I've written some code already that uses the Widget library to get a
> competent workflow for note-taking and capturing (though I've not
> completed this yet), and from my testing, the port (even as it was some
> months ago) can be used quite competently.
>
> Overall, I think that the port shows great potential, and can't
> sympathize with the reasons for its omission, especially for a system
> which isn't always nonfree, as Po seems to be willing to maintain it
> long-term.

Thanks for your input.