19 ms·

Plain text, with lines

• smcl 4y ago
  This quite nicely matches the use-case that causes me to go to a notepad - mixing text and little simple diagrams or sketches. I'm gonna have to give it a try :)
• DarkCrusader2 4y ago
  This is a great idea. I would for more plain text editors to natively support common text to diagram solutions like PlantUML etc. PlantUML notation is somewhat readable even without rendering it.
• permo-w 4y ago
  if you want this on your phone, apple's notes has this capability
  • cal85 4y ago
    It's not plain text though.
    • permo-w 4y ago
      ah, I see. it's the compatibility that's the issue?
      • cal85 4y ago
        Yeah, and longevity. If you want to be sure you can easily open and read a file in 30 years, on any device, plain text is usually the safest bet.
        • permo-w 4y ago
          agreed
• gauddasa 4y ago
  Ever heard of xournal and xournal++ They are already better solutions. I hope you had contributed to those projects rather than reinventing the wheel.
  • jstimpfle 4y ago
    If everybody used things that are "already better", then nobody would ever start something new. Even more, if everybody had to have the goal to arrive "something better" at some time in the future, most projects wouldn't get started. It's super valid to do something for your own edification and learning purposes. Another good motivation is to explore new ways to try to write the same (or even less functional) thing but in a better way.
    • gauddasa 4y ago
      They are open source, not closed source, that's the main reason I said "reinventing the wheel". xournal++ supports typing text, drawing with stroke recognition, supports touch displays, stylus, mouse, equations and also, pdf files can be used as background. I repeat: When a better "approach" is available, why go for an inferior approach. I am comparing the ways things are being done, not just comparing final products.
      • vidarh 4y ago
        The very first line of the linked article gets at why xournal++ is not suitable for the author of this: > I like plain text. xournal++ uses XML. While I'm not likely to use this editor much, the use of plain text for all but the illustrations makes me at least curious. Xournal++ is totally uninteresting to me - if I need a document format I have plenty of choices with broader support. That's not a criticism. I'm sure it's great. But people have different needs.
    • gauddasa 4y ago
      I disagree with your assumption that this approach is better than xournal++ approach.<br> Do you really believe this is "better way" than xournal++? If if had been a better way than xournal++, I would not have commented about xournal++ in first place.
• KineticLensman 4y ago
  Reminds of using pic (e.g. [0]) in the mid 80's to create typeset the images in my thesis (which was written using vi). It was possible to programmatically generate complex images with repeating elements. [0] http://floppsie.comp.glam.ac.uk/Glamorgan/gaius/web/pic-3.html http://floppsie.comp.glam.ac.uk/Glamorgan/gaius/web/pic-3.ht...
• tannhaeuser 4y ago
  > What if we pretend we can go back in time, and create a transparent, gracefully degrading plain-text format that is trivial to build viewers and editors for? Actually, the idea behind SGML's SHORTREF feature is exactly that: yöu can define char sequences consisting of newlines, tabs, or any sequence of chars not already interpreted as markup delimiter, and gave SGML replace those into eg a start- or end-element tag or whatever, in a context-dependent way so you can cover most of markdown, or CSV, or JSON. And we have to go only as far back in time as 1986 when SGML was published as an ISO standard after a decade or so of reaching consensus. It's not exactly trivial though, but not that hard either by today's standard. Beyond SGML, what's really puzzling to me is that we keep on throwing mud against a wall to see what sticks, and every comp.sci. generation seem to reinvent everything from scratch without consideration what came before. It's especially paradoxical considering SGML legacy as a text format is directly in front of you as HTML, and materials on SGML and HTML are broadly accessible. Why invent text formats for the long haul if nobody bothers reading?
  • jasim 4y ago
    Is there a tool that does what Karthik's software does, but with SGML?
  • ekidd 4y ago
    > Beyond SGML, what's really puzzling to me is that we keep on throwing mud against a wall to see what sticks, and every comp.sci. generation seem to reinvent everything from scratch without consideration what came before. I'm old enough to remember the height of SGML's popularity. I used to work in the office next to someone who was writing an SGML parser. He was an incredibly skilled developer; he was also the editor of the spec for a major programming language. And he loathed SGML. The SGML standard was a $99 doorstop of a book. Parsing SGML (and DTDs, and capability declarations) was basically impossible using standard parsing theory. Instead, you needed hundreds of hand-built parsing routines. And even when you parsed some SGML, you were left with the frustrating fact that there was no standard "document information set" (if I recall the name correctly) that told you what your parser should return. One of our favorite lunch-time rants was "Someone should define a stripped-down version of SGML that doesn't require a 2.3 MB C++ parsing library (because our users only have 8MB of RAM, and they're using 12 MB of that to run Netscape and an OS)." Then one day, my boss walks in and says, "Hey, our corporate W3 representative just got a copy of this. You'll like it." And he dropped an early draft of XML on my desk. The spec was 30 pages long, and easy to implement. Within a month, pretty much everyone who could abandon SGML had done so. A few legacy vendors continued supplying enterprise SGML users, but every other SGML developer pivoted to the web and XML. It was a chance to trade frustrating niche tools for a hot web market. SGML occupied a weird middle space: It was not only programmer hostile, but its creator bragged about how it was programmer hostile, because users came first. Except SGML was still far too technical for any mainstream users, who normally wanted GUI tools. SGML was not mysteriously forgotten. It was buried at a crossroads with a stake through its heart. And plenty of programmers who worked with SGML volunteered to shovel.
• tuxie_ 4y ago
  I love it when someone writes an app to scratch an itch they have. That's why I got into software in the first place, great work!
• chrismorgan 4y ago
  > Instead of the above syntax combining Markdown and JSON, I could use a Unicode private use area to define bytes that mean “line,” “circle” and so on. That would not be a good idea because of contention, as you may wish to use those code points for their meaning in some icon font. You’d be better to use HTML elements, which is the proper way of embedding such stuff in Markdown. (Look, even hijacking code blocks as an extension mechanism is a controversial technique.) And then SVG, or at least a subset of it, becomes an obviously excellent solution; the {"p2":{"x":141,"y":85},"mode":"line","p1":{"x":34,"y":44}} example becomes: <svg viewBox="0 0 200 100"> <path d="M 34 44 L 141 85"/> </svg>
  • tomxor 4y ago
    > in Markdown Author said plaintext not markdown.
    • deleted 4y ago
      [deleted]
    • kamray23 4y ago
      markdown is plain text though
      • if_by_whisky 4y ago
        plaintext is not markdown, though
        • cestith 4y ago
          In a sense, sure. Plaintext input is completely valid markdown though. You can take text from any plaintext editor and paste it into a markdown input and it will render as HTML or XHTML that very much resembles what you copied. Then, if you want lines, you can embed SVG in it. You could also draw in a box, use a tool like ImageMagic to make a PNG or GIF, encode that as base64, and embed it into the document as HTML source. What the author has done is basically invent their own JSON-based syntax for Pic, Fig, or SVG and their own comment/template tag format.
• nvdrx 4y ago
  Finally, a text editor to compliment my network diagram!
• yanis_t 4y ago
• blumomo 4y ago
  Now we should build a converter for turning vector files from the ePaper device reMarkable.com into this file format via OCR + line drawings. Would be nice for sharing, archiving and further processing.
• GnarfGnarf 4y ago
  It would be great if this were available as a plugin for Visual Studio and Qt Creator. Store the drawing commands as special comments, and display them in real time in the code editor.
• willjp 4y ago
  People that liked this post may also be interested in drawit, a vim plugin that helps you create ascii diagrams. https://github.com/vim-scripts/DrawIt https://github.com/vim-scripts/DrawIt
  • pmoriarty 4y ago
    Also, Emacs' artist mode.[1] [1] - https://www.emacswiki.org/emacs/ArtistMode https://www.emacswiki.org/emacs/ArtistMode
• phiresky 4y ago
  https://casual-effects.com/markdeep/ https://casual-effects.com/markdeep/ has a similar idea but different execution. I use something similar for my blog (I don't have a WYSIWYG editor for the widgets though, that's pretty neat): The posts are written in markdown, but then there's a few "widgets" that are basically markdown code blocks with a special "language" tag set that will render a React component with the text content as a input prop. I also use pandoc-flavored markdown (https://pandoc.org/ https://pandoc.org/) which already has many features that make formatting a bit more complex things easier (tables, latex math, ...) For example a bar chart widget ( https://phiresky.github.io/blog/2019/rga--ripgrep-for-zip-targz-docx-odt-epub-jpg/ https://phiresky.github.io/blog/2019/rga--ripgrep-for-zip-ta... ): [...] it will be much slower: ```barchart title: Searching in 65 pdfs with 93 slides each series: run time (seconds, lower is better) data: pdfgrep: 19.16 rga (first run): 2.95 rga (subsequent runs): 0.092 ``` becomes a colored bar chart with three bars. So the file is both kinda readable in a plain text editor, in a browser with js disabled (with React server side rendering), and in the richest version with JS enabled. Full example: Markdown: https://github.com/phiresky/blog/blob/master/posts/2021/hosting-sqlite-databases-on-github-pages.md https://github.com/phiresky/blog/blob/master/posts/2021/host... Corresponding post with interactive widgets: https://phiresky.github.io/blog/2021/hosting-sqlite-databases-on-github-pages/ https://phiresky.github.io/blog/2021/hosting-sqlite-database...
• the_kLeZ 4y ago
  There's emacs for that use case. Orgmode with HTML SVG, ditaa and plantuml are well suited for almost any use case I could think of. Why reinvent the wheel again and again?
  • BeetleB 4y ago
    > Why reinvent the wheel again and again? Because in this case, the wheel (Org mode) requires you to purchase the Ferrari that goes with it. Anti-disclaimer: Org mode user for over a decade.
• markstos 4y ago
  This looks not too different than modern versions of the block-based blog editors in Wordpress or Ghost where you can alternate Markdown blocks with rich elements. Ghost persists the data using the Mobiledoc format, which is JSON, not rendered HTML. This allows flexibility for display. https://madhatted.com/2015/7/31/announcing-content-kit-and-mobiledoc https://madhatted.com/2015/7/31/announcing-content-kit-and-m...
• ilaksh 4y ago
  xterm can actually display before graphics in Tektronics mode. https://github.com/bennetyee/TekGraphics https://github.com/bennetyee/TekGraphics
• MrLeap 4y ago
  This is cool. I could see myself adding support for this in Tentacle Typer. It's a text editor with a similar just-save-plain-text philosophy, main difference is that it has more tentacles. Giving a tentacle a paint brush for mid text doodling would be fun. Bookmarking for later.
• aendruk 4y ago
  In markdown blog posts I occasionally just write an inline SVG for simple line drawings. Example: https://andrew.kvalhe.im/2020-01-29 https://andrew.kvalhe.im/2020-01-29
• throwaway892238 4y ago
  I'm tired of Markdown hacks to try to justify not using Microsoft Word or LibreOffice. Every kind of functionality you can imagine already exists in open formats with powerful programs designed to make it easy for you to compose rich documents. For the love of god, use them. Yeah, those large documents don't work well with Git and other line-by-line diff systems. That doesn't mean line-by-line is better, it means we're too lazy to build a better version control system. Our tools should adapt to us, not the other way around!
  • BeFlatXIII 4y ago
    Perhaps someone ought to make an Ask HN about source control that works with prose. What can give the best diffs for soft-wrapped paragraphs using solely the default command?
  • dixego 4y ago
    Isn't making your own tool to satisfy your own needs the most "Our tools should adapt to us" possible, though?
  • incanus77 4y ago
    You’ve literally contradicted yourself between the two paragraphs. You’ve said that powerful tools exist, but for people who need or appreciate line-by-line diffing, they should adapt to the state of the tools as they exist today. I would argue that we’ve been too lazy to create powerful programs with open formats that do work well with Git and other line-by-line diff systems. Version control as functionality is a solved problem (yes, it’s got lots of usability problems and should probably make it impossible for a user to lose work, but those are separate from this discussion). Creating a hack that does in fact adapt the text tools to us (defining us as, like the author, someone who wants to use plain text) is exactly what they’ve done.
  • mikewave 4y ago
    > Every kind of functionality you can imagine already exists in open formats with powerful programs designed to make it easy for you to compose rich documents. Not only that, but this kind of thing has existed for ~30 years now. I remember MS Word 6.0 on Windows 3.1, 16 bits and 4MB of RAM, with large documents with significant styling, embedded Powerpoint and Excel documents, MS Draw vector art, etc. I concur that the line-based approach most Git tooling uses is not good enough. At the very least, even for code, it should be integrated with Tree-Sitter etc. by now and be comparing changes at the AST level, not just the raw text; and when it comes to documents, we should get side-by-side diffs showing the rendered document. But is there a market for this, besides just you and me?
• nmz 4y ago
  Or you can draw a picture, and use libcaca to convert to text. copy/paste.
• jhoechtl 4y ago
  I need markdown and the ability to save screenshots. But there it starts to fall apart. No satisfactory solution available.
  • Madeindjs 4y ago
    I use this VSCode plugin yo do that and it works well https://marketplace.visualstudio.com/items?itemName=mushan.vscode-paste-image https://marketplace.visualstudio.com/items?itemName=mushan.v...
• wolverine876 4y ago
  Instead of trying to hack drawings into plain text, why not add enough Unicode drawing symbols to create functional, basic line drawing using just Unicode symbols. It seems doable: Currently Unicode's box drawing range (U+2500 - U+257F) [0] has 128 symbols, but the resolution seems much too low and the angles and options too limited. Visually, you get one line segment per 'monospace' (specifically, each visual segment extends from the center of one monospace to the center of an adjoining one), and generally it's straight and only at the four 90 deg angles. More useful is the Block Elements range (U+2580 - U+259F) [1]. I don't know the intent of it, but it effectively subdivides each character space into 4 cells that could be used like pixels. Due to Unicode's effectively unlimited capacity, we could provide much more powerful: Simply divide each character space into a grid, as with Block Elements (I think font designers already do this, but don't recall the details well), let's say 12x16 = 192 cells (a somewhat arbitrary number; if that ratio is wrong or there's an existing standard, it can be adjusted). We might need higher resolution: Think of each cell as a pixel: A text character usually is much smaller than 1 inch, but zoomed into 1 inch/character you would have only ~12 dpi. What resolution is needed for basic line drawing? Displaying a line would require characters to overlay each other, which is built into Unicode and necessary for many languages, though I don't know if there's currently a limit to how many characters can be overlayed. We would need up to 192, or more if we adopt a higher resolution. We could add lower-resolution symbols for manual drawing - the Block Elements range does something similar - otherwise, manual drawing would be tedious. A solution with 192 cells is designed to be used programmatically. With a little structure, we could organize the code points so that the developer can predict the location of each code point without looking them up, e.g., a predictable offset from the first codepoint. Also, I wonder if drawing is within Unicode's current scope. The Box Drawing range says [0]: "All of these characters are intended for compatibility with character cell graphic sets in use prior to 1990.". That implies a disinterest in its use or development, though the Block Element range [1] includes no such disclaimer, and scopes and interests can change. Also, are there other Unicode ranges that cover graphics besides the Box Drawing range and Block Element range? [0] https://www.unicode.org/charts/PDF/U2500.pdf https://www.unicode.org/charts/PDF/U2500.pdf [1] https://www.unicode.org/charts/PDF/U2580.pdf https://www.unicode.org/charts/PDF/U2580.pdf
  • wolverine876 4y ago
• dgudkov 4y ago
  This looks almost like an Obsidian plugin.
• syrrim 4y ago
  I have, on occasion, made plain text files with simple diagrams in them using unicode box drawing characters. These copy the advantage of markdown of being readable in a plain text editor. They can also be written in a plain text editor, if a simple macro is written to enable drawing boxes and lines. A program could be written to convert such a diagram to html, to enable more elegant display. The original markdown spec of course included the ability to interleave html, but I always interpreted this as a compromise, a recognition that occasionally, features beyond what is otherwise supported might be necessary. The idea of writing markdown in a WYSIWYG editor, which outputs to a human unreadable format - not just human unreadable like html, but in fact nonsense to any human that reads it - encoded in a generic object format, as an extension to markdown - and to call the result plain text - is quite ridiculous to me. At some point we have jumped the shark, with respect to the purpose of markdown. There is now little distinction from existing document formats, like, say, rtf, which is "plain text" in the same sense as this is. * * * I had thought about calling my extended markdown, with box drawings and the like, sharkdown, for which I at one point even drew a cute logo. I got no farther than this.
• bitwize 4y ago
  Why not just inline Tektronix 4014 codes into the text file, and then I can view it by cat-ing it into my xterm in 4014 mode?
• makach 4y ago
  I thought the point of plain text is ability to read the content without having a specific parser to view the content?
• togaen 4y ago
  This is… really fucking cool.
• martyalain 4y ago
  It is said that the father of LISP, John McCarthy, lamented the W3C's choice of SGML as the basis for HTML : « An environment where the markup, styling and scripting is all s-expression based would be nice. » S-expressions can be an answer to write "plain text with lines", for instance http://lambdaway.free.fr/lambdawalks/?view=textanddraw http://lambdaway.free.fr/lambdawalks/?view=textanddraw
• neosat 4y ago
  Just the kind of things that keep me coming back to hacker news. Thanks for building and sharing.
• omar_alt 4y ago
  I’m still waiting for a text editor to incorporate a line paper effect which I think would help for code readability
  • robin_reala 4y ago
    Interesting. For me lines are for writeability, not readability. Is there any research on this?
    • omar_alt 4y ago
      I found it significant for readability but have only seen it so far in github gists. I use vim and sometimes sublime text so a plugin could probably insert a faint line per row similar to how it is done indicate character length.
    • flobosg 4y ago
      That’s a good question. I’m not an expert, but lines could probably contribute to the vertical rhythm.
      • omar_alt 4y ago
        Yes it would be significant for me, inserting a one pixel thick faint grey horizontal line per row in vimscript should be possible
  • MarcusE1W 4y ago
    I create a theme for Atom with lines once. Maybe that can be some inspiration? https://github.com/MarcusE1W/eastend-notebook-syntax https://github.com/MarcusE1W/eastend-notebook-syntax
    • truckerbill 4y ago
      Would this be easy to convert to vscode? I've never looked at theming either before.
  • 4y ago
• flobosg 4y ago
  Nice job. It reminds me a bit of the projects from Hundredrabbits, like https://100r.co/site/left.html https://100r.co/site/left.html
• oniony 4y ago
  Instead of your own format, why not use SVG for the drawings?
  • Athas 4y ago
    SVG is very complex. This format is very simple because it is not supposed to solve a very complex problem. That makes it easier to write other viewers and editors.
    • mg 4y ago
      It's not too complex. A line is just <line x1=10 y1=20 x2=30 y2=40>: https://jsfiddle.net/46q5srhg/ https://jsfiddle.net/46q5srhg/ It can also be used inside markdown, which supports it out of the box because SVG is part of HTML: https://markdownpastebin.com/?id=7d7b2f9dc65448ddbd7d1576676301a7 https://markdownpastebin.com/?id=7d7b2f9dc65448ddbd7d1576676...
    • ainar-g 4y ago
      A subset of SVG with just basic lines and shapes is fairly simple, and in fact is very similar to what OP is doing. It's only when you go into colours, fonts, animations, and stuff like that stuff gets progressively more complex.
      • cal85 4y ago
        I've often just wanted a "simple SVG" subset with just basics, as you describe, omitting all the fancy stuff that tends to lead to surprises and incompatibilities. For example, as the format for a very simple icon editor. Do you know if there is some formal way to 'declare' such a subset (something to do with XML/namespaces maybe?), or if there's any existing standard "simple SVG" format that someone has already defined? Obviously I could just informally stick to a subset by avoiding whatever features I don't want to use, but I think it would be useful to have a formally defined subset, and to be able to scan an SVG to detect if it's within the subset or not.
        • 4y ago
• enriquto 4y ago
  Since everybody talks about the format for figures, I feel the need to mention the .fig format [0] that was made exactly for that use case (human-editable textual description of simple line figures). It is also the native file format of the venerable Xfig figure editor [1]. [0] http://linux.math.tifr.res.in/manuals/html/xfig/fig-format.html http://linux.math.tifr.res.in/manuals/html/xfig/fig-format.h... [1] https://en.wikipedia.org/wiki/Xfig https://en.wikipedia.org/wiki/Xfig
  • chrismorgan 4y ago
    The fig format isn’t very human-editable. It has a few nice features that SVG doesn’t (e.g. concise pattern and arrow head styling, which have to be done separately and more explicitly in SVG, though on the other hand SVG gives you more flexibility), but its actual syntax is bluntly horrible. It’s mostly just a sequence of space-separated numbers, where some are enumerated values, some integer coordinates, some float coordinates, some integer sizes, some still other stuff; where some values change the syntax for subsequent lines; and there are two different sets of units intermingled, one defined in the document and the other in 80ths of an inch (… though it might just get thinned to 160ths of an inch, and is also defined as one screen pixel, whatever that means, given that it came from before the high-DPI era); and… Oh, let’s just take an example, a small excerpt from one of the diagrams at https://www.southampton.ac.uk/~dales/teaching/xfig/xfig.html https://www.southampton.ac.uk/~dales/teaching/xfig/xfig.html: 2 1 0 3 -1 7 0 0 -1 0.000 0 0 -1 1 0 2 1 0 3.00 180.00 360.00 11745 6750 9450 6750 Just to explain the first line: 2: polyline or similar. 1: actually polyline. 0: solid line. 3: line is 3⁄80in thick. -1: default pen colour. 0: white fill (… but ignored because of “no fill” later). 0: depth (z-index). 0: unused. -1: no fill. 0.000: to do with dashes (not used because of “solid line” earlier). 0: mitre join. 0: butt cap. -1: radius (not used as this is an actual polyline). 1: forward arrow (so the next line must now define the arrow style). 0: no backward arrow. 2: two points (so on the third line it expects four numbers—x₁, y₁, x₂, y₂). An inexact SVG paraphrase (most inexact because of the two different types of units, which SVG doesn’t fully or consistently have—the closest is vector-effect="non-scaling-vector"; also I will note that a number of the properties are the defaults and would thus be likely to be omitted in real life): <polyline stroke-dasharray="0" stroke-width="3px" stroke="currentColor" fill="white" stroke-linejoin="mitre" stroke-linecap="butt" marker-end="url(#arrow)" points="11745,6750 9450,6750"/> <marker id="arrow" orient="auto-start-reverse" markerWidth="180" markerHeight="360" markerUnits="userSpaceOnUse" viewBox="-2 -1 2 2"><path d="M0 0l-2 1V-1z" stroke="context-stroke" fill="none" stroke-width="3px"/></marker> This is vastly more human-editable. I write SVG by hand regularly, and edit tool-assisted SVG by hand even more regularly. I could not do the same for Fig in a regular text editor—I’d want tooling that labelled every field and enumeration value.
• nicbou 4y ago
  A few years ago, I created Markdown Notes with the same goal in mind. Markdown with LaTeX formulas and graphs was a powerful tool. However I eventually left university and stopped using it. Then I started using paper and pen to great effect. I can draw in seconds what I can type in minutes. Now I use Notability on an iPad Mini. Same thing but with better editing tools. Frankly, I just like pencil notes a lot more than text. It just works better for free form thinking. Immediate and short-term convenience is more important than having my notes in text files.
  • japanuspus 4y ago
    For anyone looking in this direction, Obsidian[0] with the excalidraw-plugin[1] is an awesome solution: Free for personal use and cross-platform. [0]: https://obsidian.md/ https://obsidian.md/ [1]: https://github.com/zsviczian/obsidian-excalidraw-plugin https://github.com/zsviczian/obsidian-excalidraw-plugin
    • malnourish 4y ago
      There is also Logseq [0][1], which provides excalidraw[2] support out of the box. [0]: https://logseq.com/ https://logseq.com/ [1]: https://github.com/logseq/logseq https://github.com/logseq/logseq [2]: https://docs.logseq.com/#/page/draw https://docs.logseq.com/#/page/draw
      • trenchgun 4y ago
        Also, Logseq is open source
• Zhyl 4y ago
  For me the most interesting thing about this is that it's written in LÖVE, a small 2D game engine. I've also heard about people making UIs in Godot, another FOSS engine. It's interesting times for FOSS game engines and UI frameworks alike.
  • tlarkworthy 4y ago
    The use of LOVE is the biggest limiter IMHO, simple stuff is missing because a game engine does not really cater to text editing in any meaningful way. The copy and paste keybindings are wrong on Mac for instance. Selection behaviour is a bit weird and non-standard. I am not even sure you can paste from an external text source etc. Everything clearly has had to be custom made.
    • akkartik 4y ago
      I appreciate your comments, Tom. Particularly that you actually installed it and tried it out before coming to a conclusion. I'm not sure what you mean by "external text source". Ctrl-v does read from the system clipboard regardless of who wrote to it. Did I understand you right?
      • michaelnoguera 4y ago
        I think what Tom might mean is that because Ctrl-v is not the standard system paste shortcut on Mac (it is Cmd-v), the editor is not inheriting default functionality here. If the editor does in fact implement its own copy and paste, there is a possibility that it would not use the system clipboard (although it might, the NSPasteboard interface enables this).
      • tlarkworthy 4y ago
        yes your right, I can get external copy and paste working, I just have to switch key bindings mid-flight. Still, my main point is that LUA and Love conspire to make development of this kind of software difficult. IMHO. It's a suboptimal tool choice for the job. Its making the journey longer. The choice of using JSON over SVG is basically because you have no SVG facilities at hand. Please continue your good work on a better substrate, I mean this as constructively as possible. It's very interesting that the article has resonated so well. I am fairly sure it means 99% of people have not tried it. People will not try it because the install process is painful, which is another issue with LUA/LOVE.
• nonrandomstring 4y ago
  Plain text is a very powerful tool in education [1]. I use org-mode. It's essential to have universal tools that all students have access to at almost zero cost, work across platforms, are light enough to work remotely over poor connections, don't go out of date, quick to learn. Unfortunately Microsoft keep bribing our admins to push Office365 cruft on the poor souls. I have to do a lot of work to repair the damage that does and get them back to a stage where they can think about ideas, not battling with buggy, over-complex, insecure application suite. [1] https://www.timeshighereducation.com/campus/joy-text-world-tech-zealotry https://www.timeshighereducation.com/campus/joy-text-world-t...
  • quickthrower2 4y ago
    The nice thing about office is at least the file format is an open standard and can be opened in myriad programs as is or converted to html, rtf, markdown etc.
    • Asraelite 4y ago
      In theory. In practice I have yet to see free software that fully supports it. Both Google and LibreOffice mangle docx and pptx documents. This isn't Microsoft's fault though. I'm really glad it's an open standard.
      • dotancohen 4y ago
        Open in the sense that the standard literally states "will handle XYZ case as the case is handled in MS Office 2000. So to implement the standard one needs a copy of Office 2000 to see how it handles specific cases. That's black box testing, as Office source code is not available.
    • wolverine876 4y ago
      > the file format is an open standard and can be opened in myriad programs as is or converted to html, rtf, markdown etc. Have you seen that work well in practice? I haven't - if you want to reliably open Microsoft Office docs, the only answer is Microsoft Office. Just because it's open doesn't mean it's coherent, consistent, or possible to implement.
• thih9 4y ago
  > I actually spent a few years building my own computer from scratch so I could have perfect control over security Sounds interesting. Could you elaborate? Or is there an article that tells more about this?
  • akavel 4y ago
    I assume the author may be referring to the projects at http://akkartik.name/code http://akkartik.name/code, notably Mu - though not 100% sure, doesn't seem to really extend to the "computer" part at a glance.
    • akkartik 4y ago
      Yes thank you, I was indeed alluding to https://github.com/akkartik/mu https://github.com/akkartik/mu. Perhaps a more precise term would be "software stack".
• mlom 4y ago
  i think i'd rather draw directly on my screen than use a whole new text editor for this. what if i'm typing in vim and want to just draw some vectors on the screen? you could use a vim plugin to associate the viewport of your pad in vim with the svg data.
• Gualdrapo 4y ago
  I think once I read that Temple OS' "text editor" works kind of the same way - regular plain text but lets you incorporate things like 3d gradient meshes
  • AlanYx 4y ago
    Yes, in some ways it is like TempleOS' text editor. It also has some similarities to the Oberon project's text editor.