sinkuri256 / android-scripting

Automatically exported from code.google.com/p/android-scripting
0 stars 0 forks source link

Enable SL4A to edit any text/* file. #481

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
SUGGESTION
Enable SL4A to edit any text/* file.

JUSTIFICATION
I spend almost all my computer time in SL4A writing scripts. I store documents 
-- text and HTML -- within the scripts directory where I can easily read text 
in the editor and launch HTML in the viewer. I also have scripts write their 
logs (HTTP, POP, SMTP, NNTP) in a directory under "scripts" created for them. 
Unfortunately text files I wish to edit must be saved either as '.html' or one 
of the script extensions. There is one advantage to that: I can use the 
different icons to categorize some of the files; but I would rather have the 
ability to edit any text file and use meaningful filename extensions. The 
extensions I need most are .txt, .log, .cfg, .csv, .eml, .and .xml.

I am not suggesting that SL4A have the ability to create these files as it has 
with directories and scripts. It might be useful to some people to have some or 
all files that don't belong to SL4A passed on to the systems configured 
handler, but I think SL4A should at least handle '.txt' and not pass it on.

Original issue reported on code.google.com by frank.we...@gmail.com on 21 Nov 2010 at 2:27

GoogleCodeExporter commented 9 years ago
Isn't this already in the latest version? 
Preferences-->Show All Files

Original comment by rjmatthews62 on 19 Dec 2010 at 11:25

GoogleCodeExporter commented 9 years ago

> Isn't this already in the latest version?
> Preferences-->Show All Files

That feature is, but that setting doesn't effect the problem. Here is a 
demonstration:

  - Create a new file (menuitem "Add") of any type; name it then "save and exit".

  - Rename that file giving it the extension ".txt".

  - Open the file for editing and add text.

I get a forced close of SL4A at the first character entry. The three steps 
above are simplified for demonstration but the same occurs with any 
unrecognized file extension, pre-exising or new, and of any size. I have not 
done any testing but it seems that the failure might only occur when the file 
size is increased. I have had successes when cutting but not when adding. 

Android 1.6, Archos 5 IT, firmware 2.0.38 (WMDRMPD 10.1).

Frank

Original comment by frank.we...@gmail.com on 19 Dec 2010 at 1:48

GoogleCodeExporter commented 9 years ago
I've found what was raising the exceptions, and placed the fix in:
clone rjmatthews62-android-scripting 
ScriptEditor.java

NB: There is currently no warning that you are attempted to edit binary code... 
it is possible to edit (for eg) .pyc files. Would it be worth putting in a 
warning message prior to saving, or just assume that the programm knows what 
they are doing?

Original comment by rjmatthews62 on 19 Dec 2010 at 11:18

GoogleCodeExporter commented 9 years ago

> NB: 

I don't know what NB means so you might be not be addressing me, but I'll 
comment just in case. 

I suggest a warning -- or a warning and read-only lock -- only if the editor 
cannot reliably handle the content type.

BACKGROUND
The Windows command interpreter (CMD.EXE) reads only US-ASCII but will allow 
binary data to exist in the file outside of code. For example:

  goto :skip
  Binary data here.
  :skip

This allows the script writer to run a command which can read that data from 
the script file -- the script file thereby serves as the script and as a 
database. If Windows can do it other interpreters can too, so I think the 
editor should not prohibit editing a file with binary data unless it is 
unreliable. I don't think hex editors are available for Android yet.

Frank

Original comment by frank.we...@gmail.com on 20 Dec 2010 at 2:43

GoogleCodeExporter commented 9 years ago
NB means "take note", or something similar. Probably in Latin.
Your suggestion sounds not only sensible but easy.

as

the

Original comment by rjmatthews62 on 21 Dec 2010 at 3:54

GoogleCodeExporter commented 9 years ago
N.B.:  http://en.wiktionary.org/wiki/nota_bene explains it. ""note well" :-)

Original comment by willison...@googlemail.com on 25 Dec 2010 at 10:05

GoogleCodeExporter commented 9 years ago
fixed in unofficial release R3x

Original comment by rjmatthews62 on 7 Jan 2011 at 1:46