emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Android port of Emacs


From: Arsen Arsenović
Subject: Re: Android port of Emacs
Date: Sun, 02 Jul 2023 17:26:33 +0200

Po Lu <luangruo@yahoo.com> writes:

> 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.

I agree, but the angle of "the status quo of this platform can't do
Emacs justice without this feature" outweighs that in my mind.

I expect that most people, including myself, that'd be interested in the
Android port have established muscle memory, and so, would benefit from
continuing to use the same keyboard they had used for a long time.

>> , 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'.

Ah!  Thanks, that's helpful.

>> 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'm not sure that's enough to fix the shortcomings of the Info format.
I had intended to work on an Info file format that can be parsed
(almost) just as easily as the current one, but that does not strip
formatting as much as the current one does, this summer; sadly, it seems
that I vastly underestimated how busy my schedule will be.

There's some discussion about this in TODO.HTML in the Texinfo Git
repository, though that focuses on replacing the info-at-rest format
with HTML, which I'm not sure I like yet.  There's a possibility that we
could use CSS heavily to define new elements and similar, to lose less
semantically, and so, to be able to recover formatting in a less
web-oriented fashion for display in the Emacs and standalone info
viewer, but I haven't explored that idea yet.

>> 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.

Thank you for your work :-)

Have a lovely day.
-- 
Arsen Arsenović

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]