On Sun, 6 Jul 2014 12:56:39 Wen Lin wrote:

For longer doc as you mentioned, i thought Google doc would be pretty good? It should have most of the features you require, and It also has offline mode nowadays.

Thanks for the suggestion, I just tried out Google Docs (I hadn't previously realised that there was an Android app). The big problem with Google Docs is that it's "Document" is a desktop publishing file. When I'm writing a document that is going to end up as a blog post or magazine article it's not possible to do much formatting. In the case of magazine articles in most cases the editor will reject any formatting. So having a "portrait" layout of a desktop publishing WYSIWYG file in the middle of a "landscape" screen (which means any of the affordable monitors in recent times) is very inefficient. Also cut/paste operations include fonts, so when I copy references from web pages into a "Document" in Google Docs I have to go back and fix the font afterwards. Keep is even worse in regard to screen space, it uses significantly less than 1/3 of the screen space when editing a note. It seems that the Google people just decided that we shouldn't edit big files in Keep. I used Keep fro the notes for the last couple of LUV talks I gave and those notes were stretching the limits of what Keep can conveniently edit on the screen of a Thinkpad T420. On Sun, 6 Jul 2014 12:12:16 Jeremy Visser wrote:

Microsoft OneNote works fantastically for this. You’ve probably previously experienced OneNote as it comes with MS Office, but what a lot of people don’t realise is that they have a free-as-in-beer web-based version instead which is functional enough for my needs.

I've never used OneNote. The last time I did anything serious with MS Software was when MS defined TCP as "Transport Control Protocol". The last thing I did with MS-Office was to uninstall it to make more space for games (the only purpose of a Windows system IMHO).

OneNote notebooks are hierarchical (Section -> Page -> Content), pretty free-form (just click anywhere, start typing — great for mind-mapping), and yes, it does spell-checking.

Sounds nice.

It does have a native Android app which I’ve never used. From what I’ve read, the app is more apt for reading than writing, but for best results give it a try.

Don’t automatically discount it because it’s Microsoft.

<http://www.onenote.com/>

I might give it a go, but not today (I've got stuff to do and I've wasted enough time on Google Docs). The app being more suitable for reading is OK. What I'm after is doing most of my serious writing on a laptop or workstation and using a phone for any ideas that I get when a laptop/workstation isn't available. On Sun, 6 Jul 2014 02:13:09 James Harper wrote:

Any free-as-in-beer app is likely to be laden with ads. Do you have any particular aversion to paying for such an app if it did all you wanted?

I might pay, but not a lot. What do you suggest? -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/

On Sun, Jul 6, 2014 at 3:05 PM, Russell Coker <russell@coker.com.au> wrote:

I've never used OneNote. The last time I did anything serious with MS Software was when MS defined TCP as "Transport Control Protocol". The last thing I did with MS-Office was to uninstall it to make more space for games (the only purpose of a Windows system IMHO).

Another vote for OneNote. I understand your feelings about Microsoft (and share many of them) but the OneNote team seems to be a very innovative team that operates kind of semi-autonomously even from the rest of the Office team. Time and again, I've used Keep and Evernote (and Springpad before them) and everytime I come to appreciate OneNote more. In fact, from a purely technical point of view for note taking on the road, IMO nothing beats the combination of a good tablet with a Wacom pen and OneNote. Unfortunately it's not a very FOSS friendly solution. Cheers -- Aryan Ameri

On Mon, 7 Jul 2014, at 09:29 AM, Brian May wrote: On 6 July 2014 01:33, Russell Coker <[1]russell@coker.com.au> wrote: I've been using Google Keep for editing small documents on a PC (web interface) and Android (native app). It works well for shopping lists and for notes for a LUV lecture. But I'd like to find something suitable for editing longer documents, blog posts and magazine articles. As an aside the Wordpress Android app is terrible if you are writing anything significant. In the past, I have tried Evernote, for taking notes at conferences. When it worked while, it worked while. Trouble is it was rather fragile with network problems, which is to be expected at conferences. I think it would try to make changes to the server copy, succeed, but not get the success response. So it would try again, detect that the copy on the server has changed, raise a conflict, and save under a new name. So in some cases I ended up with hundreds of file names, when I was the only one editing the one file. This was several years ago when I tried it last, it is possible things have changed now. Hi Brian. I use Evernote a lot. The conflict management has improved significantly over the last year or so, at least for notes (I have not explored how well conflicts are handled for audio tracks and the other formats that Evernote supports). I use it on iOS, Android, Windows, Mac and the web client (for Linux). With the recent versions of the applications, I have had very few conflicts occur when using the Android or iOS clients on intermittent wifi or 3G connections. Regards Graeme References 1. mailto:russell@coker.com.au

Russell Coker <russell@coker.com.au> writes:

The way vi handles lines is good for source code but not good for documents. The up/down commands should go to the previous/next line of ~80 characters not the previous/next paragraph.

Boggle. Are you saying you don't use hard wrapping? Anyway I dunno about vim, but in Emacs it's configurable: (setq line-move-visual nil) ; I am *not* a NOTEPAD.EXE refugee! By default in Emacs 23+ <down> will move to the next visible line, so if you have an 80x25 tty and you're at character 20 of a 400 character line, <down> will actually move you to character 100 of the same (soft-wrapped) line. (Or near enough -- my math may be off.) SURELY that's equally configurable in vim.

On 07.07.14 22:49, Russell Coker wrote:

The way vi handles lines is good for source code but not good for documents. The up/down commands should go to the previous/next line of ~80 characters not the previous/next paragraph.

Russell, there are several wrapping modes in Vim, all of them capable of satisfying your expressed need, and switching between them can be automatic (e.g. on file extension or resident directory), or manual, as desired. The mode I use does what you prefer: ----------------------- DEFAULT ----------------------- set wrap ; It is the default in vim 7.4. (Not in yours?) ; and if desired: set ww=<,>,[,] ; whichwrap: Cursor-key around line ends. (I like it.) In this mode, a new line is started when typing flows past column 80 (or `textwidth` columns, if that is set), and up/down traverses those lines. There is a small cost to using this mode, when editing paragraphs, if lines end up overlong after going back and inserting text. Then the paragraph needs trimming. I have in .vimrc: noremap ^W gq} So that ^W suffices in lieu of gq} to reflow everything to the end of the paragraph. To trim narrower for emails, this serves me: au BufNewFile,BufRead ~/Desktop/mutt-* set textwidth=72 because I use vim in mutt. (au is short for autocommand) ----------------------- VISUAL WRAP ----------------------- Or, if some document benefits from very long lines, wrapped only in the display, then you can have both cursor motions: set wrap set linebreak ; Break lines at chars in "breakat" (:h breakat) That _will_ have up/down traversing by buffer lines, i.e. jumping visually wrapped line continuations, but also allows interpolation: "Move between display lines of a long wrapped source text (buffer) line: noremap <S-Down> gj noremap <S-Up> gk I.e. <SHIFT> refines the motion. ----------------------- FLOWED ----------------------- Alternatively, when editing a purely blank-line-separated-paragraphs document, one could ignore all of the above, and just issue the command in vim: :set fo+=a (fo is short for formatoptions, and ":h formatoptions" offers: » a Automatic formatting of paragraphs. Every time text is inserted or deleted the paragraph will be reformatted. See |auto-format|. « The hints at ":h auto-format" are worth a gander. It takes but a moment to make that "set" automatic on a file extension, using "setlocal", rather than "set", if the vim session is used to edit multiple files. Alternatively, set up Alt-something to set it, and Alt-other to: set fo-=a N.B. The cursor keys work as you prefer in this case as well. ----------------------- Admittedly, eliciting that information from the on-line help is a bit of an expedition if one is unfamiliar with the editor. (A bit like plumbing manpages, really.) Erik ( Who won't change the autocommand for mutt to: au BufNewFile,BufRead ~/Desktop/mutt-* set textwidth=72 fo+=a because having to insert a blank line to defeat wrapping appended text back into the previous line (if there's space) doesn't suit emails, I find. Note to mutt users: I've moved mutt's tmpdir with: set tmpdir="~/Desktop" # If not in ~/postponed after a crash, look here. in .muttrc ) -- Every nonfree program has a lord, a master -- and if you use the program, he is your master. - Richard Stallman