Re: org-startup-truncated default should be nil [legibility 2/6]
Emacs has a giant normie-noob shaped hole in its intake funnel. The warnings against using Emacs on Windows on the download page are good, but not enough. Noobs need a positive recommendation of platform, and a practical one, not ideological. It should say something like: "If you've never coded, then Emacs can be very difficult if approached wrong. Avoid Windows (unless you have someone to do your tech support). Use MacOS (or a user-friendly Linux such as Ubuntu Mint). Install Emacs with homebrew (on MacOS). Then install Spacemacs. Visit their chat channel if you need help. Run the tutorial. Learn Org mode. Become more productive!" AFAIK Spacemacs is the only major consumer-oriented distro; the rest are aimed at devs. Dev-noobs will stick with Emacs cuz they need it for various techie workflows and competing tools are similarly arcane. But normie-noobs will bounce if they don't find a quick path to PIM. Endorsing MacOS violates the free software ethos. But realistically, normie-noobs shouldn't try Linux until they've learned Emacs. Emacs allows them to control the Linux environment. Until then, Apple can hold their hands. Getting them hooked on Emacs pretty much guarantees they'll try Linux anyway. It's drug dealer marketing: the first hit is always free. How does that metaphor apply, if Emacs is already free software? Because the cost of free software is the learning curve. Be as ruthless about extracting that price as Microsoft is about extracting theirs.
Re: org-startup-truncated default should be nil [legibility 2/6]
That's a great idea. And if the Org tutorial included an easy option to enable "PIM" mode for normie-noobs, so that Emacs starts behaving like a PIM instead of an IDE, that would be even better. Someone who's never coded before doesn't need IDE defaults. On Fri, Feb 7, 2020 at 8:37 AM Corwin Brust wrote: > > Greetings, > > On Thu, Feb 6, 2020 at 5:33 PM Texas Cyberthal > wrote: >> >> No, that isn't what I'm saying. I'm quite happy with Emacs, especially >> Spacemacs. However, I had a much harder adoption experience than >> necessary, and I find that the barriers to entry are preventing >> normie-noobs from choosing Org as a PIM. So I intend to fix that. > > > I'm not sure this is on-topic, but... what about creating a separate tutorial > just org-mode? > > The possibilities seem endless but, for example, this could > * provide instruction for different primary use cases (for me: note-taking, > prose, agenda, habit, babel, and literature) > * mention especially important customizations for the given usage > * offer "express setup" buttons to instantly apply settings from a sample > configuration. > > Finally, this could be added into the Emacs splash-screen alongside the > general tutorial. > > I like the idea of promoting org-mode to people using Emacs for the first > time and I like the idea of sensible defaults, especially that reduce > frustrations for users new to the GNU tool-chain That said, org-mode is lots > of things to lots of people, even notwithstanding the reticence to break > things for people who've had them working the way the like for decades. I > think this is fundamentally an education problem. But even if that's wrong, > I think we should look closely at education as a solution. > > -- > Corwin > 612-217-1742 > 612-298-0615 (fax) > 612-695-4276 (mobile) > corwin.brust (skype) > cor...@bru.st
Re: org-startup-truncated default should be nil [legibility 2/6]
Greetings, On Thu, Feb 6, 2020 at 5:33 PM Texas Cyberthal wrote: > No, that isn't what I'm saying. I'm quite happy with Emacs, especially > Spacemacs. However, I had a much harder adoption experience than > necessary, and I find that the barriers to entry are preventing > normie-noobs from choosing Org as a PIM. So I intend to fix that. > I'm not sure this is on-topic, but... what about creating a separate tutorial just org-mode? The possibilities seem endless but, for example, this could * provide instruction for different primary use cases (for me: note-taking, prose, agenda, habit, babel, and literature) * mention especially important customizations for the given usage * offer "express setup" buttons to instantly apply settings from a sample configuration. Finally, this could be added into the Emacs splash-screen alongside the general tutorial. I like the idea of promoting org-mode to people using Emacs for the first time and I like the idea of sensible defaults, especially that reduce frustrations for users new to the GNU tool-chain That said, org-mode is lots of things to lots of people, even notwithstanding the reticence to break things for people who've had them working the way the like for decades. I think this is fundamentally an education problem. But even if that's wrong, I think we should look closely at education as a solution. -- *Corwin* 612-217-1742 612-298-0615 (fax) 612-695-4276 (mobile) *corwin.brust (skype)cor...@bru.st *
Re: org-startup-truncated default should be nil [legibility 2/6]
No, that isn't what I'm saying. I'm quite happy with Emacs, especially Spacemacs. However, I had a much harder adoption experience than necessary, and I find that the barriers to entry are preventing normie-noobs from choosing Org as a PIM. So I intend to fix that. On Fri, Feb 7, 2020 at 5:38 AM Fraga, Eric wrote: > > Okay, I get it: Emacs (especially vanilla) just doesn't meet your > requirements. So be it! Horse for courses, as they say here in the > UK. All I can say is that I find most, if not all, other tools so > frustrating. I can never get them to work the way I want. With Emacs, > I can. Yes, this means that I have to work at customizing and this is > not easy for a beginner. But I can. > > One minor point, in case anybody else reading this thread might find > this useful: > > >> What about turning on whitespace-mode? > > > > That makes all the spaces visible, which isn't legible. > > As with all things Emacs, this is completely customizable. You can have > whitespace mode show/highlight the bits you want and not the others. > > -- > : Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-233-gc2bc48
Re: org-startup-truncated default should be nil [legibility 2/6]
Okay, I get it: Emacs (especially vanilla) just doesn't meet your requirements. So be it! Horse for courses, as they say here in the UK. All I can say is that I find most, if not all, other tools so frustrating. I can never get them to work the way I want. With Emacs, I can. Yes, this means that I have to work at customizing and this is not easy for a beginner. But I can. One minor point, in case anybody else reading this thread might find this useful: >> What about turning on whitespace-mode? > > That makes all the spaces visible, which isn't legible. As with all things Emacs, this is completely customizable. You can have whitespace mode show/highlight the bits you want and not the others. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-233-gc2bc48
Re: org-startup-truncated default should be nil [legibility 2/6]
> I get this. My own approach is to simply use - at the start of the line and > then each of these demi-paragraphs becomes a list item which are wrapped > nicely (whether with visual or fill mode). The cost of this approach is that one can't distinguish between demi-paragraphs and actual bullet points. I used both in my prior email. I'd prefer to use \\ instead. Unlike the - prefix, appending \\ doesn't require anticipation that the line will be followed by another demi-paragraph. However, it's ugly and distracting. The problem is that the normie-noob bootstrapper is unlikely to know either trick. He will probably wind up using visual-line-mode once he Googles his frustration over the strange line truncation, and then he won't be able to return to the start of demi-paragraphs with org-beginning-of-line, even if he knew to prefix a "-". > Does for me. Maybe I've customized something... that's the problem with a > .emacs file that has elements that date back 37 years... ;-) Vanilla Emacs doesn't. Yes, I'd forgotten some of my earliest Spacemacs Org customizations as well. It's not that Spacemacs' defaults are vastly better, it's that Spacemacs' UI is vastly more discoverable. The one issue that's hard to fix, single-space sentence detection, is fixed by default. Spacemacs guides the user to the other solutions. E.g., using visual-line-mode introduces one to the superior spacemacs/toggle-truncate-lines because it's on the lowercase version of the same keybind. Which is in the UI toggles section, which also offers related toggles and theme control, via whic-key. The normie-noob bootstrapper will wonder whether he can even cope with Emacs' notoriously challenging environment. Before investing lots of time reading the manual of a program he's never used, it's rational for him to hop in and see whether he can stand it. This means installing vanilla Emacs and starting the tutorial. Maybe, if he's particularly well informed, he manages to open an Org file to take notes as he learns. Then, while he's trying to learn these bizarre keybinds for mouse-less editing, he struggles to find a way to display and edit a paragraph. He finds he can't even document his learning efforts. He resorts to switching between Word and Emacs. Word is easier to use. He gives up and goes back to whatever GTD PIM is next on his list to try. The problem with vanilla Emacs' defaults for prose paragraphs is that there's too many things wrong for the normie-noob to unravel the Gordian knot. Toggling truncation off doesn't look viable because the continuation marks without word wrap with close line spacing are very hard to read. So he uses visual-line-mode instead, which destroys demi-paragraphs, which is hostile to experimental learning. Or maybe he struggles with filled paragraphs instead, which are even clunkier. > Visual mode does this; so does fill mode. Vanilla Emacs with truncation off does not word wrap by default; it wraps in the middle of words. You're right, visual-line-mode does wrap words by default, as does filling. So this is another push away from the truncation toggle, which is the actual correct solution. > This is "look and feel" and easily addressed, as others have noted, by a > theme. It's standard for modern programs to ship with a default theme that already makes it look good and usable. Spacemacs comes with themes but none add variable pitch and line spacing to Org, IIRC. Emacs' default custom themes don't either. Themes seem to be mostly about color scheme. I doubt a theme is the right answer, since specifying variable pitch and line spacing would reduce its compatibility. If a theme is the answer, it's something like Poet, which I haven't tested: https://github.com/kunalb/poet > What about turning on whitespace-mode? That makes all the spaces visible, which isn't legible. > So turn off line-move-visual. I wasn't able to do so for visual-line-mode, but it worked for truncation off. Unfortunately, this also disables visual movement for C-n/p next-line, which renders paragraphs un-navigable again. There's no need for logical C-n/p when one already has logical C-a/e and C-up/down. So in the unlikely event the bootstrapper finds this, he will get excited and congratulate himself on his cleverness, only to realize he's made it even worse than before. This is the kind of experience that leads to quitting. > a simple org mode hook with some settings would be all the customization you > would need to achieve your desired writing experience and could easily be an > example early in the org mode manual. I don't think that's early enough in the bootstrapper's info consumption pipeline. He's going to try to learn the basic keybinds and UI of Emacs before diving into the Org manual. Otherwise how will he even apply customizations? But it's definitely a step in the right direction. On Thu, Feb 6, 2020 at 8:40 PM Fraga, Eric wrote: > > On Thursday, 6 Feb 2020 at 20:09, Texas Cyberthal wrote: > > A blank
RE: attachment: link type export to HTML invalid attach dir
Hi again, > -Original Message- > From: Nicolas Goaziou > Sent: den 5 februari 2020 17:54 > To: Gustav Wikström > Cc: emacs-orgmode@gnu.org > Subject: Re: attachment: link type export to HTML invalid attach dir > > > That was kind of what I was trying to do, by allowing subtyping, so > > that the parser would be more knowledgeable about particular types of > > links, by allowing extended attributes. Maybe not implemented in the > > most extensible way though I'll admit. > > Just to be clear, I firmly believe Element library should be as > low-level as possible. Ideally (we're not there yet), it should not > depend on any other part of Org. It should be the step (largely) above > "re-search-forward". Ok, fair enough. I guess where I was going was a bit further than only parsing the characters, into also interpreting them in meaningful ways. Especially true for attachment links that would need to look up other parts of the tree to fetch extended information. I'll leave that trail of thought. > > My suggestion to the link parser would be to have the following properties > > as the catch-all properties for links: > > - type :: Which type of link protocol applies. E.g. file, http, ftp, > > attachment, duckduckgo (ex. for a custom link abbreviation to search ddg) > > - raw-path :: The path to use for the particular protocol. Would contain > > everything in the link following "protocol:" > > - format :: Which format the link has. Plain, bracket or angular bracket > > Barring custom link abbreviations, this is already the case. Hmm, maybe that is so.. Except raw-path is called path (not really an issue though) and there is another property called raw-link. Not sure how to interpret the use of both path and raw-link. And there are things happening between parsing the actual buffer link and storing the raw-link and path parameters. In the end, what made me consider the sub-typing I've been writing about could very well just have been the ambiguities regarding what's what, and the lack of treatment for parts that arguably could be seen as additional parameters to the link-path. For example the "::extra_content" suffix in file links, that by the parser currently is just a part of the path itself. Maybe clearer documentation in the function of what each part is /supposed/ to be, and the design principle that is applied, i.e. that the path is the raw path with options included can help future me and others who might want to understand. Thoughts on that? > > - description :: The description part of the link > > ([[protocol:path][description]]) > > Description is not meaningful here. This is parsed content. > > > - begin, end, post-blank :: The default properties used for all elements. > > Not sure if contents-begin and contents-end are a part here as well. > > They are when the link has contents, i.e., a description. Hmm, don't really know if a link description should be regarded as content. I for one hadn't considered it until now when you mentioned it! But it preserves space in the parse tree I suppose. If the docstring of the link parser would make it clear what each property is supposed to contain, in this case :contents-begin & :contents-end, I'm sure I would have been less confused about this, and wouldn't have had any objections. > > As you've stated previously, from a performance perspective maybe it > > will be best to not expand the specific properties and instead let the > > expansion of those be handled in code by the link type owner (e.g. > > org-attach.el for attachment links). > > More than performance, this is a design issue. > > > Ah yes. Just briefly looking at the docview code. Docview doesn't seem > > to use the parser when extracting information about that "go to page" > > information from the link. Which means docview links doesn't really > > care how the link information is encoded in the parser anyways. > > Indeed. However, higher level functions, e.g., org-open-link, do care > about it and ensure that "ol-docview.el" really processes a link. > > > Maybe if docview were allowed to encode custom docview information > > into the parsed link in the parser it and others could reused that > > encoded information later? Docview would be able to add > > a ":go-to-page" option, for example. Just a thought. > > I'm quite sure this is a wrong way to go. Ok, got it. You're saying the link interpreter for docview (in this case) have to be able to parse the link one step further, to be able to extract this ":go-to-page" information, before being able to operate on it. Indeed a design decision. Maybe the best one, who am I to say otherwise. It will make the Org link parser leaner for sure. > > Most link types probably won't need custom link properties anyways. > > But could maybe let the parser know stuff by use of higher order > > functions? Or push for being important enough to be included into Org > > and allowed to be known by the parser. > >
Re: How to intersperse commands with their output in RESULTS block?
Hi Eric, Great idea! I hadn't considered using the =script= command, it's a great starting point. Thanks! --Diego On Thu, Feb 6, 2020 at 7:55 AM Fraga, Eric wrote: > On Wednesday, 5 Feb 2020 at 18:25, Diego Zamboni wrote: > > tl;dr: is there a way to have ob-shell (or some similar mode) run > commands > > one by one and include the commands, interspersed with their output, in > the > > #+RESULTS block? > > You haven't said on what type of system but, if Linux, you could try > using =script= as a starting point: > > #+begin_src shell :results output > script < ls > echo 'hello' > EOF > #+end_src > > You may wish to have a second shell script that massages the output in > the =typescript= file and ouputs that instead, e.g. to filter the > carriage returns. > -- > : Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-233-gc2bc48 >
Re: org link to OCaml comment
Hello Nicolas, On 2020-02-06 18:10, Nicolas Goaziou writes: > Link enclosed within parens meant coderef links, i.e., the syntax is > reserved. You can probably remove the closing parenthesis to avoid this. Thank you for the explanation. Is there a way to either escape the parentheses (maybe url-encode them), or to automatically not include the closing one as you suggest when creating the link? (I'm asking someone who does not know org-mode to document his code, use links to point to the relevant code. I'm afraid it will be tricky to ask him to tweak the links that org create so that they work.) Thanks again, Alan
org-babel strange html print in R
Hello, I've found that some strange results when outputing html from R. Do you have some insights on a potential solution? Best regards, Jeremie Org mode version 9.3.4 (9.3.4-elpa @ /home/djj/.emacs.d/elpa/org-20200206/) #+PROPERTY: header-args:R :eval yes :exports results :colnames yes :results output :output-dir images/:cache yes :session *R* #+begin_src R :results output html library(xtable) x <- rnorm(100) y <- x + rnorm(100) print(xtable(summary(lm(y ~ x))),type="html") #+end_src #+RESULTS: #+begin_export html < < < < #+end_export ** Expected results #+begin_export html Estimate Std. Error t value Pr(|t|) (Intercept) -0.0130 0.1023 -0.13 0.8991 x 1.0011 0.0987 10.14 0. #+end_export
Re: org link to OCaml comment
Hello, Alan Schmitt writes: > The strange part is that linking to arbitrary code works. It seems that > the OCaml comment syntax is problematic here. Link enclosed within parens meant coderef links, i.e., the syntax is reserved. You can probably remove the closing parenthesis to avoid this. Regards, -- Nicolas Goaziou
Re: org link to OCaml comment
Hello John, On 2020-02-06 09:58, John Kitchin writes: > I think you need to do it like this: > > #+BEGIN_SRC test.ml -r > > (* Object projection functions *) (ref:opf) > > > #+END_SRC > > [[file:2020-02-05.org::(opf)]] > > The -r in the header removes the coderef when you run it. Thank you for the suggestion. Unfortunately I need to link to an external ml file. I can change it, but I need to get a syntactically valid file. I tried putting the ref part inside the comment and unfortunately it does not work. The strange part is that linking to arbitrary code works. It seems that the OCaml comment syntax is problematic here. Best, Alan
Re: org link to OCaml comment
I think you need to do it like this: #+BEGIN_SRC test.ml -r (* Object projection functions *) (ref:opf) #+END_SRC [[file:2020-02-05.org::(opf)]] The -r in the header removes the coderef when you run it. John --- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu On Thu, Feb 6, 2020 at 9:48 AM Alan Schmitt wrote: > Hello, > > I'm trying to create an org link to a specific place in an OCaml file. I > thought I would use some specific target in an OCaml comment, but it > does not work. > > Here is an OCaml comment: > > (* Object projection functions *) > > Here is the link create by `org-store-link` (I put it here with no > description) > > [[file:~/work/jsexplain/jsexplain/jsref/JsSyntax.ml::(* Object projection > functions *)]] > > When I try to follow this link, I get the following error (note the > missing parentheses): > > org-open-file: No match for coderef: * Object projection functions * > > and I am moved to the top of the file (instead of where I stored the > link). > > Is there an escape problem here? And if so, is it a bug of > `org-store-link` of not doing the escaping? > > Thanks, > > Alan > >
org link to OCaml comment
Hello, I'm trying to create an org link to a specific place in an OCaml file. I thought I would use some specific target in an OCaml comment, but it does not work. Here is an OCaml comment: (* Object projection functions *) Here is the link create by `org-store-link` (I put it here with no description) [[file:~/work/jsexplain/jsexplain/jsref/JsSyntax.ml::(* Object projection functions *)]] When I try to follow this link, I get the following error (note the missing parentheses): org-open-file: No match for coderef: * Object projection functions * and I am moved to the top of the file (instead of where I stored the link). Is there an escape problem here? And if so, is it a bug of `org-store-link` of not doing the escaping? Thanks, Alan
Re: org-startup-truncated default should be nil [legibility 2/6]
On Thursday, 6 Feb 2020 at 20:09, Texas Cyberthal wrote: > A blank line is useful, yes. Use of demi-paragraphs implies use of > line breaks to signal stronger transitions. E.g., from my recent > workflow: I get this. My own approach is to simply use - at the start of the line and then each of these demi-paragraphs becomes a list item which are wrapped nicely (whether with visual or fill mode). > What vanilla Emacs Org default visual-line-mode is missing for > informal prose notes: > - recognize sentences with a single space after terminal punctuation Does for me. Maybe I've customized something... that's the problem with a .emacs file that has elements that date back 37 years... ;-) > - word wrap Not sure what you mean here. Visual mode does this; so does fill mode. What I am failing to understand from you is your frequent reference to truncation but then wanting wrapping? I'm obviously missing something. > - more line spacing and a variable pitch font This is "look and feel" and easily addressed, as others have noted, by a theme. > - denote single line breaks with the absence of continuation marks, as > truncate lines nil does What about turning on whitespace-mode? > visual-line-mode's minor luxury of slightly easier navigation to > arbitrary visual line endpoints doesn't compensate for loss of the > critical ability to identify logical lines with single line breaks, > and the loss of keybinds for quick navigation to their endpoints. So turn off line-move-visual. I guess what I am saying is what I said earlier: a simple org mode hook with some settings would be all the customization you would need to achieve your desired writing experience and could easily be an example early in the org mode manual. Does spacemacs initialise things they way you want them? If so, go with it but I guess there are other things about spacemacs that you do not like? -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-233-gc2bc48
Re: org-startup-truncated default should be nil [legibility 2/6]
No, I just didn't repeat everything. A blank line is useful, yes. Use of demi-paragraphs implies use of line breaks to signal stronger transitions. E.g., from my recent workflow: #+begin_quote turning the mic off/on manually also causes a pop so would need to pause recording first simpler to just leave the mic on then fair enough. [2020-02-05 Wed 08:47] seems I'm suffering from electet mic pop which can be solved by adding a capacitor and resistor to the circuit? [2020-02-05 Wed 08:52] http://www.discovercircuits.com/H-Corner/popfree%20micophone%20switch.htm pop-free microphone switch could sample out the sound in audacity easily #+end_quote Single line breaks allow preservation of the chronological sequence of thoughts, which is useful for e.g. debugging false assumptions. The above was a simple example with short lines. But if they were long and complex, vanilla Emac's defaults would make paragraph navigation difficult. > For writing and for intra-paragraph navigation, what is necessary beyond > visual-line-mode, next-line (C-n, ), forward-word (M-f), forward > sentence (M-e), and forward-paragraph (M-}), and equivalent for opposite > direction? What vanilla Emacs Org default visual-line-mode is missing for informal prose notes: - recognize sentences with a single space after terminal punctuation - word wrap - more line spacing and a variable pitch font - denote single line breaks with the absence of continuation marks, as truncate lines nil does - C-a/e begin/end of line should still operate on logical lines. It's easier to achieve the last two points without visual line mode, since line-move-visual is t by default. Toggling truncation off is enough. visual-line-mode's minor luxury of slightly easier navigation to arbitrary visual line endpoints doesn't compensate for loss of the critical ability to identify logical lines with single line breaks, and the loss of keybinds for quick navigation to their endpoints. On Thu, Feb 6, 2020 at 7:17 PM Fraga, Eric wrote: > > So, the only problem that you have, as far as I can tell, is that Emacs > doesn't distinguish paragraphs by a single newline character but > requires 2 instead? For me, a blank line between paragraphs is very > useful to visually identify new paragraphs (or demi-paragraphs). > > For writing and for intra-paragraph navigation, what is necessary beyond > visual-line-mode, next-line (C-n, ), forward-word (M-f), forward > sentence (M-e), and forward-paragraph (M-}), and equivalent for opposite > direction? (Okay, maybe a few others like begin/end of line, paging up > and down, etc.) What does spacemacs provide that vanilla Emacs does > not? (I've never used spacemacs so please excuse my ignorance.) > > -- > : Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-233-gc2bc48
Re: org-startup-truncated default should be nil [legibility 2/6]
So, the only problem that you have, as far as I can tell, is that Emacs doesn't distinguish paragraphs by a single newline character but requires 2 instead? For me, a blank line between paragraphs is very useful to visually identify new paragraphs (or demi-paragraphs). For writing and for intra-paragraph navigation, what is necessary beyond visual-line-mode, next-line (C-n, ), forward-word (M-f), forward sentence (M-e), and forward-paragraph (M-}), and equivalent for opposite direction? (Okay, maybe a few others like begin/end of line, paging up and down, etc.) What does spacemacs provide that vanilla Emacs does not? (I've never used spacemacs so please excuse my ignorance.) -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-233-gc2bc48
Re: org-startup-truncated default should be nil [legibility 2/6]
auto-fill-mode is unsuitable for prose work, and especially for rough notes which rely on demi paragraphs. Demi-paragraphs are important for conveying uncertainty. Polished publishable prose can usually be written with proper syntax and paragraphs separated by blank lines, but the requisite forethought and certainty are unavailable for raw notes, which is exactly what a boostrapper needs to write. When writing for publication in a markup that doesn't recognize single line breaks as paragraphs, there is no disadvantage to using filled paragraphs, since demi-paragraphs require ugly markup to survive refilling. However, raw Org notes aren't written for publication. The best solution for one's informal notes is truncation off and word wrapping on. This respects demi-paragraphs, and permits dynamic visual line length, depending on window width. When I'm composing a longer document, I often prefer a column width of around 160 chars, or fullscreen, to see the document overview. However, for close work I prefer 80 chars, or for comparing two documents with a vertical window split. > My question was: what do you mean by paragraph navigation? In this case, I meant intra-paragraph navigation. > what is missing in vanilla emacs in this respect? It's hard for a bootstrapping normie-noob to achieve a paragraph-editing experience that isn't significantly worse than Microsoft Word's. Which is basically the same as telling him to leave. Last month I averaged a daily Org text intake+production of over 4.5k words, so I have little tolerance for ergonomic friction. Failure to support demi-paragraphs introduces UI friction right when the brain is most overloaded, which is unacceptable for a productivity workspace. On Thu, Feb 6, 2020 at 6:16 PM Fraga, Eric wrote: > > On Thursday, 6 Feb 2020 at 17:46, Texas Cyberthal wrote: > > auto-fill-mode definitely isn't what I want. > > Why not? Just curious. Before I switched to visual-line-mode for all > org documents, I used auto-fill-mode for prose all the time. Together > with fill-paragraph (M-q), this did the job very well. > > > Beyond that I don't understand your question. > > My question was: what do you mean by paragraph navigation? And, > supplementary, what is missing in vanilla emacs in this respect? > > And, yes, if I had a beard, it would be grey. ;-) But I would be more > than happy to see new users embrace Emacs & org mode. They are missing > out on a fantastic system. Unfortunately, people are blind to the "it's > all text" paradigm due to the frills of buttons, mice, and menus which > paradoxically get in the way of productivity. > > The same issues arise in the LaTeX vs Word debate... and having to > produce technical documents (articles, books, proposals, presentations) > for a living, LaTeX is the only way to go. But this is for another > day. :-) > > -- > : Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-233-gc2bc48
Re: org-startup-truncated default should be nil [legibility 2/6]
On Thursday, 6 Feb 2020 at 17:46, Texas Cyberthal wrote: > auto-fill-mode definitely isn't what I want. Why not? Just curious. Before I switched to visual-line-mode for all org documents, I used auto-fill-mode for prose all the time. Together with fill-paragraph (M-q), this did the job very well. > Beyond that I don't understand your question. My question was: what do you mean by paragraph navigation? And, supplementary, what is missing in vanilla emacs in this respect? And, yes, if I had a beard, it would be grey. ;-) But I would be more than happy to see new users embrace Emacs & org mode. They are missing out on a fantastic system. Unfortunately, people are blind to the "it's all text" paradigm due to the frills of buttons, mice, and menus which paradoxically get in the way of productivity. The same issues arise in the LaTeX vs Word debate... and having to produce technical documents (articles, books, proposals, presentations) for a living, LaTeX is the only way to go. But this is for another day. :-) -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-233-gc2bc48
Re: org-startup-truncated default should be nil [legibility 2/6]
auto-fill-mode definitely isn't what I want. Beyond that I don't
understand your question.
I doubt it's productive to reiterate my legibility critiques since
I've concluded they're more appropriate for Spacemacs.
> the solution may simply be some example org mode hooks with, say, settings
> for writing prose and have these in the org mode manual?
Sounds like a step in the right direction.
It sounds like vanilla Emacs' primary mission is to be the common
component between all configurations, and to be by the devs and for
the devs. Greybeard compatibility is big due to the proliferation of
heavily individualized configs. It can be user-friendly for dev noobs
but not normie noobs.
In that light, leaving Org's defaults no different than an IDE's makes sense.
That leaves Spacemacs being to vanilla Emacs as Ubuntu is to Debian.
Spacemacs is crowd-configured and vanilla Emacs isn't.
It doesn't make sense for vanilla Emacs to be more normie-noob
friendly than Spacemacs, so I feel most of my Org legibility
suggestions should be implemented on Spacemacs before vanilla, if at
all.
Vanilla documentation incompatibility due to distro drift isn't as bad
as I thought, thanks to Emacs being self-documenting. I think I can
construct a decent normie-noob adoption funnel in Spacemacs, based off
the tutorial, friendly defaults, and probably a tutorial layer. In
other words, create the equivalent of Ubuntu Mint.
Once someone starts living in Emacs, they'll eventually reach sage
status. It's just a matter of easing them in.
On Thu, Feb 6, 2020 at 3:16 PM Fraga, Eric wrote:
>
> On Thursday, 6 Feb 2020 at 10:33, Texas Cyberthal wrote:
> > Visual line mode is annoying and unnecessary; Spacemacs users do not
> > need it because its defaults offer adequate paragraph navigation.
>
> I'm not sure I understand the conflation of visual-line-mode with
> paragraph navigation. Is it because you mean intra-paragraph navigation
> as opposed to M-{ and M-} for navigating from paragraph to paragraph?
>
> Maybe auto-fill-mode is what you want?
>
> In any case, the solution may simply be some example org mode hooks
> with, say, settings for writing prose and have these in the org mode
> manual?
>
> Fundamentally, emacs is challenging because it is both powerful and
> completely customizable. I remember a colleague complaining that Linux
> was not friendly because you had too much choice. Emacs takes that to
> another level. And that's why many of us live in it...
> --
> : Eric S Fraga via Emacs 28.0.50, Org release_9.3.2-233-gc2bc48
